Oracle Database@Azure Explained: What Actually Runs Where?

Oracle Database@Azure is a jointly engineered enterprise cloud service that places Oracle's flagship database workloads directly inside the Microsoft Azure ecosystem. For years, architects faced an uncomfortable trade-off: move mission-critical apps to the public cloud and lose bare-metal Exadata performance, or split app and data tiers across clouds and absorb 2–45 ms of cross-cloud latency on every SQL round trip.

Database@Azure resolves that tension. It is not a marketplace VM image, not a third-party managed service, and not Oracle software on standard Azure compute. Oracle installs physical Exadata hardware inside Microsoft's hyperscale data centers — dedicated OCI server pools adjacent to Azure compute clusters, connected by a private low-latency interconnect.

The result: Azure's operational agility (App Services, AKS, Synapse, OpenAI) combined with OCI's database performance, predictability, and HA — provisioned, billed, managed, and monitored entirely from the Azure control plane.

Oracle Database@Azure

Multi-cloud service co-locating OCI Exadata inside Azure DCs with Azure-native provisioning, identity, monitoring, and MACC billing.

Oracle Exadata

Physical database appliance — compute nodes, smart storage cells, and RoCE fabric — that powers the data tier.

OCI Control Plane

In-facility Oracle orchestration layer receiving ARM signals to provision clusters, run backups, and apply patches.

Private Interconnect

Dedicated hardware bridge between Azure VNets and OCI VCNs delivering sub-1 ms RTT without public internet.

Azure is the front door — application ecosystem, identity source, and primary management layer. If your team lives in the Azure Portal, that is by design.

Azure Applications and Compute

Your entire business logic and application tier remain natively hosted in Azure:

• Azure Virtual Machines — SAP, Oracle E-Business Suite, custom .NET or Java backends
• Azure Kubernetes Service (AKS) — containerized microservices needing high-throughput relational data
• Azure App Services — managed web apps and API gateways calling database backends

Identity and Access Management

Microsoft Entra ID (formerly Azure AD) is the definitive source of truth. User management, RBAC, MFA, and security auditing for operators and applications all originate in the Azure ecosystem — then federate into OCI IAM for database administration.

Monitoring, Operations, and Management

Administrators manage the service without opening the OCI Console for routine work:

• Azure Portal & CLI — provision Exadata infrastructure, VM clusters, and Autonomous Databases through standard Azure interfaces
• Azure Resource Manager (ARM) — database assets modeled as native Azure resources via ARM templates, Bicep, or Azure Terraform providers
• Azure Monitor & Log Analytics — database metrics, telemetry, and audit logs in a single pane of glass
• Azure Billing — OCI database consumption on your Microsoft invoice, drawing from your MACC commitment

The operational interface is pure Azure. The data tier is pure OCI. Oracle retains full accountability for hardware, virtualization, and database management — on infrastructure physically positioned inside the Azure data center boundary.

Exadata Physical Infrastructure

• Exadata Database Servers — high-performance x86 nodes tuned for heavy database processing
• Exadata Storage Servers — smart storage cells with NVMe flash and Exadata storage software offloading query processing via Smart Scans
• RDMA Network Fabric — internal RoCE switches interconnecting compute and storage with sub-millisecond latency

Database Services

• Oracle Exadata Database Service — root access to database nodes, Oracle RAC for scale-out and fault tolerance
• Oracle Autonomous Database — self-driving service handling tuning, patching, provisioning, and scaling automatically
• Oracle Database Software — Enterprise Edition with Multitenant, Advanced Compression, Real Application Security, and Database In-Memory

OCI Control Plane

Hidden behind the Azure interface sits a dedicated, secure OCI control plane instance in the same Azure facility. It receives instructions from the Azure Resource Provider to orchestrate storage grid provisioning, VM cluster deployment, automated RMAN backups to OCI Object Storage, and zero-downtime infrastructure patches.

The diagram below is the mental model I draw on every architecture review: two cloud domains, one physical building, one private bridge between them.

Figure 1 · What runs in Azure vs OCI — and how the private interconnect bridges them

The primary blocker in traditional multi-cloud setups is network latency. Splitting an app tier in Cloud A from a database in Cloud B typically adds 2–45 ms per round trip. For workloads executing hundreds of SQL calls per web transaction, that penalty breaks performance.

Database@Azure solves this by co-locating OCI racks in the same physical buildings as Azure availability zones, bridged by a dedicated high-speed private interconnect.

Interconnect Mechanics

When an Azure VNet needs connectivity to an Exadata VM Cluster, traffic bypasses public routing entirely. Packets move from the customer VNet through a low-latency network interface into a dedicated OCI VCN on the Exadata hardware. Round-trip latency is frequently under 1 millisecond — comparable to two Azure VMs in the same region.

Private IP and DNS Resolution

• Virtual Network Injection — OCI network endpoints injected into a dedicated delegated subnet within your Azure VNet
• DNS Integration — private DNS zones in Azure resolve Oracle RAC SCAN listener addresses seamlessly
• Security Groups — Azure NSGs and OCI Security Lists filter traffic, keeping all packets on a secure, non-routable private transport layer

Securing a split-cloud architecture requires robust identity lifecycle management. Database@Azure implements automated identity federation bridging Microsoft Entra ID with OCI IAM.

When a cloud engineer manages an Oracle database resource in the Azure Portal, their security context flows through an enterprise federation loop:

• Single source of authentication — administrators authenticate once against Entra ID
• Federated mapping — Entra ID issues a SAML/OIDC token with identity and group assignments
• OCI IAM authorization — OCI IAM maps Entra groups to OCI policies and authorizes the action (scale-up, patch, create database)

For application and DBA access to the database engine, the platform supports traditional Oracle authentication alongside Entra ID-based OAuth2 token authentication — keeping database access policies consistent across both environments.

Figure 2 · Identity federation and private data path — two separate flows, one co-located facility

Enterprise workloads vary in complexity, regulatory requirements, and operational overhead. Database@Azure offers two primary tiers.

Oracle Exadata Database Service

Designed for granular administrative control over mission-critical workloads. Exposes the underlying Linux OS on compute nodes — ideal for large-scale ERP systems, customized third-party architectures, or legacy apps requiring specific OS tuning. Supports Oracle Database 19c and 23ai with native RAC and independent compute/storage scaling.

Oracle Autonomous Database

A serverless, fully containerized, self-managing option. Oracle handles patching, infrastructure optimization, HA, and index tuning. Optimized for ATP (transactional) or ADW (analytical) workloads — best for teams focused on application delivery rather than routine infrastructure maintenance.

Four common production patterns across different industry segments:

Scenario 1: SAP/EBS Migration with Microsoft 365 Integration

Profile International firm running Oracle E-Business Suite alongside global Microsoft 365.
Architecture EBS on Azure VM Scale Sets across availability zones; transactional schema on Exadata Database Service.
Value Entra ID SSO for EBS users; microsecond-level connection loops for complex financial reporting.

Scenario 2: Real-Time Fraud Analytics (Financial Services)

Profile Banking group using Azure AI/ML models requiring continuous transactional data access.
Architecture Transactional ledger on Autonomous Database; Azure Synapse and OpenAI via private endpoints for live scoring.
Value Compliance isolation on dedicated Exadata storage with Azure-native analytics pipelines.

Scenario 3: Healthcare EHR with Strict HA Targets

Profile Hospital network hosting EHR platforms with zero tolerance for unplanned downtime.
Architecture EHR on AKS connected to Exadata Database Service with RAC; Active Data Guard to secondary Azure/OCI region.
Value Containers scale dynamically in Azure; RAC node-failover guarantees uptime during hardware events.

Scenario 4: Elastic E-Commerce During Traffic Spikes

Profile Online merchant with unpredictable global sales event traffic.
Architecture Customer-facing web tier on Azure App Services; Autonomous Database with auto-scaling enabled.
Value App Services scale horizontally; Autonomous DB scales CPU up to 3× instantly — both tiers scale back down after the spike.

This is the production topology I recommend as a starting point for most enterprise designs — web and app tiers in Azure, database tier on co-located Exadata, identity and monitoring unified under Azure.

Figure 3 · Production reference architecture — web tier in Azure, database tier on co-located Exadata

• Co-locate regions precisely — provision Database@Azure in the exact same physical region as your application VNet (East US, West Europe, etc.). Cross-region layouts reintroduce the latency you are trying to eliminate.
• Dedicate a clean delegated subnet — reserve a discrete subnet exclusively for Oracle database network interfaces; do not mix app servers or proxies in it.
• Automate via Azure-native IaC — incorporate provisioning into CI/CD pipelines using Azure Terraform or Bicep templates for a single deployment approach.
• Establish baseline latency metrics — run persistent ping and traceroute from app containers to SCAN listeners before loading production data.
• Evaluate licensing early — model BYOL vs License Included against your ULA or core-count entitlements before provisioning Exadata VM clusters.

• Application Location: Are target workloads already in an Azure region that supports Database@Azure?
• Performance Profile: Do transaction volumes or IOPS demands require dedicated Exadata hardware?
• IP Address Planning: Have you allocated a clean, non-overlapping block for OCI subnet delegation?
• Identity Federation: Is Entra ID configured to federate group assertions into OCI IAM?
• Latency Tolerances: Have you defined maximum allowable RTT between app tier and database layer?
• Licensing Strategy: Have BYOL vs License Included options been reviewed by your SAM team?
• Disaster Recovery: Is Active Data Guard replication to a secondary geographic region defined?
• Monitoring Framework: Are Azure Monitor sinks ready to ingest Oracle alert logs and system metrics?

1. Jointly engineered infrastructureDatabase@Azure combines Azure front-ends with physical OCI-managed Exadata inside Azure data centers.
2. Explicit structural isolationApplications execute in Azure compute; database engines run on dedicated Exadata infrastructure.
3. High-performance architectureExadata smart storage grids and flash caches power heavy database workloads — not generic cloud VMs.
4. Autonomous operational optionsAutonomous Database offloads indexing, patching, and tuning to a self-driving engine.
5. Federated identity managementEntra ID is the single source of truth, federating admin credentials into OCI IAM.
6. Sub-millisecond network performanceA physical hardware interconnect links Azure VNets to OCI — under 1 ms RTT, no public internet.
7. Unified management experienceProvision, monitor, and pay entirely through Azure Portal with ARM templates and single-invoice MACC billing.
8. Strategic modernization pathScale application tiers in Azure without rewriting core database logic or abandoning Oracle features.

Oracle Database@Azure is not about moving Oracle into Microsoft Azure — it is about letting two industry-leading platforms work together, giving enterprises the freedom to run applications where they make sense while keeping Oracle databases on the infrastructure built specifically for them.