Oracle Exadata on Azure: How Oracle AI Database@Azure Works

On this page

1. 01 · Why Azure Was First, and Why That Matters
2. 02 · What Oracle AI Database@Azure Includes
3. 03 · The Architecture Inside an Azure Region
4. 04 · Identity: How Microsoft Entra ID Fits In
5. 05 · Operations: Portal, Automation and Monitoring
6. 06 · Who Owns What: The Responsibility Model
7. 07 · High Availability, DR and Connectivity Choices
8. 08 · Getting Started: A Practical Sequence
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · Why Azure Was First, and Why That Matters

Architecture brief · Oracle AI Database@Azure

"Our apps are on Azure, our identity is Entra ID. Where does Oracle fit?"

Microsoft and Oracle have connected their clouds since 2019, first through the Oracle Interconnect for Azure, which links OCI FastConnect with Azure ExpressRoute. That worked, but the database still lived in OCI, a network hop away from the application. Oracle Database@Azure, generally available since December 2023, moved the database itself into Azure data centers.

Being first has practical consequences. Azure has had the longest time to mature its integration: the delegated subnet model, Azure portal provisioning, Microsoft Entra ID sign-in, Azure Monitor metrics, and Exascale since March 2025. For an Azure-centred enterprise, Oracle AI Database@Azure, as it has been called since October 2025, is now the most complete way to run Exadata next to Azure workloads.

02 · What Oracle AI Database@Azure Includes

Answer: Oracle AI Database@Azure is a jointly offered service in which Oracle runs Exadata infrastructure and Oracle Database services inside Azure regions. You subscribe through Azure Marketplace, create resources in the Azure portal or with ARM templates and Terraform, and connect them to your VNets through a delegated subnet.

Under the Azure experience is the same architecture Oracle uses with every hyperscaler. The Exadata racks are installed in the Azure facility as an OCI child site, linked to an OCI parent region for the control plane. When you create a VM cluster in the Azure portal, the request goes to OCI, which builds the cluster on the Exadata hardware a short distance from your Azure workloads.

03 · The Architecture Inside an Azure Region

Answer: Four parts make up every deployment: your Entra ID tenant, your VNet with an application subnet and a delegated subnet, the Oracle-operated Exadata site in the same Azure data center, and an OCI parent region that runs the control plane. Application traffic stays inside the Azure region.

The topology below follows the layout most Azure landing zones use. Entra ID sits across the top because it spans everything: it authenticates users to the Azure portal, to your applications and, optionally, to the database itself. The VNet holds an application subnet for AKS or Azure VMs and a delegated subnet for the Exadata VM cluster. The Oracle-operated site holds the VM cluster and Exadata infrastructure. Azure monitoring and storage run along the bottom, and the OCI parent region sits on the right.

Follow the blue arrows: the application calls the SCAN listener in the delegated subnet, which routes to the VM cluster. The two green arrows are identity: one token for the application, one for the database login. The dashed red "mgmt" arrow is OCI managing the cluster; Azure only sees the result in the portal.

The delegated subnet

The delegated subnet is the heart of the network design. You create a subnet in your VNet and delegate it to the Oracle.Database/networkAttachments service. The VM cluster's client VNICs and SCAN addresses are placed in that subnet, so the database has private IP addresses that belong to your address space. Routing from other subnets, peered VNets and hub networks then works the way it does for any Azure resource.

Size the subnet for the VM cluster's nodes, SCAN and virtual IPs with headroom for growth, and avoid overlaps with on-premises ranges reached over ExpressRoute or VPN. Check which network features, such as NSG support on the delegated subnet and access from peered VNets, are enabled in your region before you finalise a hub-and-spoke design.

04 · Identity: How Microsoft Entra ID Fits In

Answer: Microsoft Entra ID plays three roles. It controls who can create and manage Oracle AI Database@Azure resources through Azure RBAC, it can federate with OCI IAM for access to the OCI console, and Oracle Database can accept Entra ID tokens for database logins, so users and applications sign in without database passwords.

The sequence diagram below traces one end-to-end request. A user signs in through Entra ID with MFA and conditional access. The application on AKS gets a token for itself and then a database access token for its managed identity. It connects to the SCAN listener in the delegated subnet over TCPS, presenting the token. The database verifies the token, maps it to a database user or role, and returns rows. Finally, metrics, logs and audit records flow to Azure Monitor. Each numbered arrow is one hop you can test separately during a pilot.

Steps 3 and 4 are what remove stored database passwords from the application. Steps 5 to 7 never leave the VNet and the Oracle-operated site, and step 8 is what puts the database on the same dashboards as the rest of your Azure estate.

Configuring Entra ID logins in the database

Database-side setup is a few statements once you have registered the database as an application in Entra ID. Users and app roles from Entra ID are mapped to global database users or roles:

ALTER SYSTEM SET IDENTITY_PROVIDER_TYPE = AZURE_AD SCOPE = BOTH;
-- IDENTITY_PROVIDER_CONFIG holds the tenant ID, application ID and app ID URI

CREATE USER hr_app IDENTIFIED GLOBALLY AS '[email protected]';
CREATE ROLE hr_readers IDENTIFIED GLOBALLY AS 'AZURE_ROLE=HR.Read';

Use TCPS for token-based connections, and keep at least one break-glass database account with a password stored in a vault, so you can still log in if the identity configuration fails.

05 · Operations: Portal, Automation and Monitoring

Answer: You create and change resources from the Azure portal, Azure CLI, ARM or Bicep templates and the Terraform AzureRM provider, and you see metrics and logs in Azure Monitor and Log Analytics. Database-level work, such as patching Oracle homes and configuring Data Guard, uses Oracle tooling reached from the portal or the OCI console.

For an Azure platform team, the experience is deliberately familiar. Exadata infrastructure and VM clusters are Azure resources with resource groups, tags, locks and RBAC. Policy and cost management work on them. Infrastructure as code pipelines that already deploy VNets and AKS clusters can deploy Exadata VM clusters too.

Billing and commitments

Oracle AI Database@Azure is purchased through Azure Marketplace, usually as a private offer, and appears on your Azure invoice. Depending on your agreement, that spend can count toward your Microsoft Azure Consumption Commitment. License included and BYOL options are available, and Oracle Support Rewards can apply. Confirm commitment eligibility with your Microsoft account team before sizing a deal around it.

06 · Who Owns What: The Responsibility Model

Answer: Oracle operates the Exadata hardware, the hypervisor and system software, and provides database software images. You own your data, users, database operations and VNet design. Microsoft owns the data center, the Azure network fabric, the Entra ID platform and billing. A few layers, such as guest OS updates and identity configuration, are shared.

The grid below is the most useful slide in any Database@Azure kickoff, because almost every operational question maps to one row. Each row is a layer of the service, from your data at the top down to the facility and billing. The coloured bar shows who owns it: blue for you, red for Oracle, amber for Microsoft, and purple where two parties share the work. Use it to build the RACI for your operating model before go-live, not after the first incident.

The two purple rows cause the most confusion. Guest OS updates are provided by Oracle but scheduled and applied in your maintenance windows. Entra ID is Microsoft's platform, but the users, groups, conditional access policies and app registrations in it are yours to design.

07 · High Availability, DR and Connectivity Choices

Answer: Inside a region, Oracle RAC on the Exadata VM cluster provides local high availability. For disaster recovery, use Active Data Guard to a second Oracle AI Database@Azure region or to OCI, following the MAA tiers. When the database must stay in OCI, the Oracle Interconnect for Azure links OCI FastConnect and Azure ExpressRoute.

Exadata on Azure gives you the same MAA building blocks as on OCI. RAC covers node failures and rolling patching. Data Guard or Active Data Guard covers site and region failures, and GoldenGate supports active-active or Platinum-tier designs. What changes is the network: replication traffic runs between Azure regions or across the interconnect to OCI, and you size and secure it like any other cross-region flow.

Migration into Database@Azure uses the same toolset: Zero Downtime Migration with Data Guard for physical online moves, GoldenGate or Data Pump for logical moves, and RMAN for backup-based copies. Later posts in this series cover migration and cross-cloud DR in detail.

08 · Getting Started: A Practical Sequence

Teams that move fastest treat the first deployment as a joint platform, network, identity and DBA exercise. This order avoids most of the delays we see:

1. Accept the Marketplace offer. Subscribe to Oracle AI Database@Azure in the right subscription and link or create the OCI tenancy during onboarding.
2. Decide on identity federation. Choose whether OCI console access federates with Entra ID, and assign Azure RBAC roles for the platform team.
3. Design the delegated subnet. Pick the VNet, size the subnet for the VM cluster with headroom, delegate it to Oracle.Database/networkAttachments, and plan DNS.
4. Create infrastructure and a VM cluster. Use the portal for the first build, then capture it in Terraform or Bicep for every build after.
5. Wire up operations. Enable diagnostic settings to Log Analytics, create Azure Monitor alerts, and set backup destinations and retention.
6. Prove the identity path. Configure Entra ID logins for one application and one DBA group, and test the break-glass account.

Oracle AI Database@Azure works because it stops asking Azure teams to learn OCI first. The database arrives as a VNet resource, signs users in with Entra ID and reports to Azure Monitor. The Exadata underneath is the same one DBAs already trust.

09 · Key Takeaways

1. Azure is the most mature Database@ partnership. GA in December 2023 and Exascale since March 2025.
2. The delegated subnet is the network model. The VM cluster gets private IPs in your VNet, so routing works like any Azure resource.
3. Entra ID can cover database logins too. Token-based logins remove stored database passwords from applications.
4. Operations stay in Azure tools. Portal, ARM, Terraform, Azure Monitor and Cost Management all see Oracle resources.
5. Agree the responsibility model early. Oracle runs the platform, you run the databases and network design, Microsoft runs the facility and identity platform.

10 · Frequently Asked Questions