3 · Oracle Database@Azure architecture
These are original revision notes for the architecture course video. They summarize the design in our own words rather than reproducing the video.
Core message
The Oracle database service runs on Oracle Cloud Infrastructure (OCI) hardware that is physically placed inside the Microsoft Azure datacenter as an OCI child site — often called an OCI pod. Each pod behaves as a genuine extension of the nearest OCI region, and a direct private network link keeps application-to-database traffic inside the Azure datacenter at very low latency.
Physical layout: regions, availability domains, and child sites
- An OCI region contains one or more availability domains (ADs).
- An availability domain can include child datacenter sites that act as extensions of the AD while remaining an integral part of OCI.
- For Oracle Database@Azure, these child sites are built inside Azure datacenters and referred to as OCI pods.
- Each pod is paired with the OCI region that is closest in both physical and network distance.
What runs inside the OCI pod
- Oracle Database@Azure and its key dependencies are hosted entirely inside the pod.
- The pod uses the same underlying OCI infrastructure as any other OCI region: the Gen2 network stack, off-box virtualization, and an RDMA network that powers the Exadata and Autonomous Database services.
- The service stack also matches a normal OCI region — the OCI virtual networking stack, the OCI Exadata service, the OCI Autonomous Database service, and so on.
- Security updates, patching, deployments, and the security and operational controls all follow the same OCI process. In effect, the pod is an extension of the OCI region.
How the network mapping works
When a customer creates a database cluster in a subnet of their Azure virtual network (VNet), the platform does three things behind the scenes:
- Creates a private IP address in the designated subnet of the customer's Azure VNet.
- Creates the matching VNICs in the private OCI virtual cloud network (VCN) of the database instance.
- Builds a virtual mapping between the Azure NIC and IP address and the OCI VNIC.
The result is that an Azure-side private IP and an OCI-side VNIC refer to the same database endpoint.
The direct private link
- Oracle and Microsoft built direct private network connectivity between the OCI pod and the Azure network in the same datacenter.
- When an Azure application connects to the database using the private IP assigned to the Exadata instance's NIC, Azure networking routes the packets over the direct local link to the edge gateway in the pod.
- The OCI virtual networking stack receives the packets at the edge gateway and forwards them to the Exadata service instance.
- This link delivers ultra-low latency between Azure clients and Oracle database instances, while ensuring the traffic does not leave the Azure datacenter.
Provisioning flow (control plane)
Creating an Exadata instance follows an ordered control-plane path:
- The customer uses the Azure portal — or Azure APIs — to create an Exadata instance, then DB clusters and databases inside it.
- The calls first reach Azure Resource Manager, which forwards them to the Oracle Database@Azure resource provider. The resource provider can be hosted anywhere; in this design it runs in an OCI region.
- The resource provider translates the request and performs identity validation — authentication and authorization.
- It then invokes the OCI control plane, which creates and manages the Exadata instance.
The customer signs in with Azure identity and uses Azure tooling; OCI uses Identity Federation behind the scenes to authenticate and authorize the API calls.
Customer value
- Ultra-low latency between Azure applications and Oracle databases, because both sit in the same datacenter.
- Network traffic stays inside the Azure datacenter, which helps with a predictable and contained data path.
- The pod is operated to OCI standards, so customers get OCI service parity without designing a cross-cloud network themselves.
- Customers provision and manage the service with familiar Azure identity and the Azure portal.
Risks and constraints to remember
- The pod is paired with the nearest OCI region, so region pairing and availability still matter when planning.
- The low-latency benefit comes from colocation and the direct link — confirm the application and database land in the same datacenter footprint.
- Identity is federated: plan the Azure-to-OCI identity mapping so authentication and authorization behave as expected.
- Control-plane operations still involve OCI even though the experience is Azure-native, because the resource provider and OCI control plane sit on the OCI side.
- These are inherent platform behaviors — validate current networking, identity, and region details against Microsoft Learn before designing with a customer.
Terms to remember
- OCI region and availability domain (AD)
- OCI child site (OCI pod)
- Gen2 network stack
- Off-box virtualization
- RDMA network
- Exadata service and Autonomous Database service
- Azure VNet and delegated subnet
- NIC and VNIC virtual mapping
- OCI virtual cloud network (VCN)
- Edge gateway
- Direct private link
- Azure Resource Manager (ARM)
- Oracle Database@Azure resource provider
- OCI control plane
- Identity Federation
The architecture story for a customer is short: the Oracle database service runs on OCI hardware that physically lives inside the Azure datacenter, operated exactly like a normal OCI region. A direct private link connects the application's Azure subnet to the database, so the data path is fast and stays inside the datacenter, while provisioning and identity stay Azure-native through Identity Federation.