Oracle Interconnect for Azure — Pricing, Licensing and Architecture

Oracle Interconnect for Azure is the cross-cloud private network connection that lets enterprise customers run Oracle Database workloads in OCI regions and access them from Azure-resident application tiers with sub-2ms latency and dedicated bandwidth. The architecture launched in 2019 as the first formal Oracle-Microsoft multi-cloud peering, and remains the default architecture for customers who want to keep their Oracle Database deployment inside OCI while their application tier migrates to Azure. The newer Oracle Database@Azure model deploys Exadata inside Azure regions natively and serves a different use case — the two architectures coexist in the Oracle commercial portfolio.

This piece works the Interconnect architecture the way an Oracle insider sizing a multi-cloud commercial proposal would work it: the architecture and supported region pairs first, the pricing model second, the licensing rules third, the audit exposure fourth, and the buyer-side decision framework last. For the broader Oracle multi-cloud context, see the Oracle Cloud licensing master guide. For Oracle Database@Azure specifically, see our Database@Azure pricing benchmarks.

The Interconnect architecture — what it actually is

The physical connection

Oracle Interconnect for Azure is a Layer 2 private network peering between specific OCI regions and specific Microsoft Azure regions. The peering is established through Oracle FastConnect on the OCI side and Microsoft Azure ExpressRoute on the Azure side, with both providers operating dedicated edge connectivity inside the same physical metro carrier-hotel facility. Traffic between an OCI virtual cloud network and an Azure virtual network paired through the Interconnect routes over the dedicated peering — never traversing the public internet.

The supported region pairs

The Interconnect supports specific OCI-to-Azure region pairs where both providers have established the metro peering infrastructure. The pairs include OCI Ashburn ↔ Azure East US, OCI Phoenix ↔ Azure West US 2, OCI London ↔ Azure UK South, OCI Frankfurt ↔ Azure Germany West Central, OCI Amsterdam ↔ Azure West Europe, OCI Toronto ↔ Azure Canada Central, OCI Tokyo ↔ Azure Japan East, and several additional regional pairs. The customer's deployment topology must align to one of the supported pairs — pairs outside the supported list require routing through the public internet or through customer-supplied private connectivity.

The bandwidth profile

Interconnect bandwidth is provisioned in 1 Gbps, 10 Gbps, and higher tiers depending on the supported region pair. Single-digit-millisecond round-trip latency between the OCI virtual cloud network and the Azure virtual network is typical inside the metro pair. The peering supports BGP routing, customer-controlled IP space, and standard private connectivity behaviour — DNS resolution, load balancing, and security controls work in the standard FastConnect and ExpressRoute patterns.

The Interconnect pricing model

The connection itself

The Interconnect cross-cloud peering connection between Oracle and Microsoft is provisioned at no incremental charge from either provider for the cross-cloud peering layer. The customer pays the standard OCI FastConnect port charge on the Oracle side (typically $250 – $1,500 per month depending on bandwidth tier and term) and the standard Microsoft Azure ExpressRoute port charge on the Microsoft side (typically $300 – $2,500 per month depending on bandwidth tier and term). The combined port charge is the predictable per-month cost of the connectivity layer.

Data transfer over the Interconnect

Data transfer over the dedicated Interconnect peering is generally not subject to standard cross-cloud egress charges in the same way public internet traffic would be — the peering is a private connection with a negotiated bandwidth tier. Specific traffic-flow billing varies by Interconnect contract and the customer should verify against current Oracle and Microsoft commercial documentation. The data transfer cost profile is materially lower than public internet egress between OCI and Azure on equivalent volumes, which is the primary economic justification for the Interconnect provisioning.

The Oracle Database licensing cost

The Oracle Database workload running on the OCI side of the Interconnect bills under standard Oracle Cloud commercial terms — Licence Included against Universal Credits, BYOL against the customer's on-premise Processor or NUP inventory, or Autonomous Database consumption. The Interconnect does not change the database tier billing — it is a network connection, not a database service. The Azure-side application tier bills under standard Microsoft Azure commercial terms with no Oracle commercial overlay.

Indicative pricing table — Interconnect 2026 baseline

The rates above are indicative published list at the time of writing. The customer's specific commercial position on FastConnect and ExpressRoute is frequently negotiated as part of a broader OCI or Microsoft commercial commitment — the published rates are the input to the negotiation, not the final position.

The licensing rules — Oracle on Azure-side compute under Interconnect

Standard Oracle Database licensing applies on the Azure side

When the customer deploys Oracle Database on standard Microsoft Azure VMs in the Azure region paired through the Interconnect (i.e., not on Database@Azure, but on customer-managed Azure VMs), the standard Oracle Cloud Computing Policy applies. The Azure compute consumption is treated as Authorized Cloud Environment infrastructure under the Oracle Cloud Computing Policy, with the 2-vCPU-per-Processor conversion for Enterprise Edition and the 4-vCPU-per-Processor conversion for Standard Edition. The Interconnect does not provide any special licensing position — the database licence requirement is the same as it would be without the Interconnect.

The customer-supplied BYOL requirement

Customer-deployed Oracle Database on the Azure side under the Interconnect requires customer-supplied Oracle Database Enterprise Edition Processor licences (or Standard Edition where applicable) covering the vCPU count of the Azure VMs running the database. The licences must be on active Oracle Software Update Licence and Support (SULS). Customers running an Oracle database test environment on a 16-vCPU Azure VM require eight Processor licences (16 vCPUs ÷ 2 per Processor) on the customer's Azure account.

The Oracle option licence position

The same applies to the Oracle Database options — Real Application Clusters, Partitioning, Advanced Compression, Advanced Security, Active Data Guard, Database Vault — running on the Azure side under the Interconnect. The customer must supply the matching option licences from the on-premise inventory, or face a back-licence claim if LMS audits the deployment. The compliance gap that most frequently surfaces in audit is the customer activating Partitioning or Advanced Compression on the Azure-side database for performance tuning, without realising the option licence requirement extends to Azure-resident workloads.

The audit exposure profile — Interconnect deployments under LMS scrutiny

The audit scope question

LMS treats Azure compute running Oracle Database workloads as in audit scope under the standard Oracle Cloud Computing Policy. The Interconnect creates an architecturally tightly-coupled relationship between the OCI side and the Azure side, and LMS audit teams have repeatedly extended audit population scope to the Azure subscription when the OCI side is in audit. The compliance gap to defend is the Azure-side Oracle workload that was treated as outside Oracle audit scope by the customer but is treated as in scope by LMS. For the broader audit framework see audit risk in Oracle Database@Hyperscaler.

The metering challenge

OCI-side Oracle consumption is metered automatically by Oracle through the Universal Credits commitment reporting. Azure-side customer-deployed Oracle Database is not metered by Oracle — the customer is responsible for self-reporting the vCPU count and the option activation. LMS audits routinely surface Azure-side deployments that the customer's Oracle commercial team was unaware of, because the deployments were spun up by the Azure-side application team without engaging Oracle commercial governance.

The cross-cloud licence position

Customer-deployed Oracle Database on Azure under the Interconnect cannot be a BYOL of a Database@Azure subscription — the Database@Azure subscription is the Oracle-deployed Exadata Database Service inside Azure, not the customer's Azure VM compute. The customer must hold separate on-premise Processor or NUP licences for the customer-deployed Azure-side Oracle workload. The buyer-side defence is to document the licence allocation by subscription explicitly, so the audit response can demonstrate compliance.

The buyer-side decision framework — Interconnect vs Database@Azure

Choose Interconnect when

Choose Oracle Interconnect for Azure when (1) the Oracle Database tier is already deployed in OCI and the customer wants to keep it there, (2) the application tier is migrating to Azure or already runs in Azure, (3) the customer's existing Oracle commercial commitment is on OCI Universal Credits and the customer wants to preserve that commitment without restructuring, or (4) the customer's network architecture benefits from a clean Layer 3 boundary between the database tier and the application tier. Interconnect is the right architecture when keeping the database in OCI is the strategic intent.

Choose Database@Azure when

Choose Oracle Database@Azure when (1) the application tier is already in Azure and the customer wants the database tier in the same Azure region without any cross-region routing, (2) the customer has material Microsoft MACC headroom that can absorb the Marketplace consumption, (3) the integration pattern with Azure-native services benefits from intra-region private connectivity at sub-millisecond latency, or (4) the customer's strategic cloud posture is Microsoft-primary and Oracle is the database tier that needs to land alongside the Azure-native estate. Database@Azure is the right architecture when Azure-native deployment is the strategic intent.

Choose both when

Mixed deployments are common. Customers with an OCI-native enterprise application alongside an Azure-native analytics workload frequently run the OCI side on Exadata Cloud Service with the Azure-side application tier connected over the Interconnect for the enterprise workload, plus a separate Database@Azure deployment in the same Azure region for the analytics workload that integrates with Azure Synapse. The two architectures coexist in the same enterprise estate without commercial conflict.

"Oracle Interconnect for Azure and Oracle Database@Azure are two answers to two different questions. Interconnect answers 'how do I keep my OCI Oracle Database while my application tier moves to Azure'. Database@Azure answers 'how do I run Oracle Database inside Azure alongside my Azure-native application'. The buyer-side defence is to pick the architecture whose answer matches the customer's actual question — not the architecture the Oracle account team is incentivised to push hardest in the current quarter."

An anonymised case study — global manufacturer, Interconnect deployment

A global automotive manufacturer with $880m of Oracle Database workloads operated a long-standing OCI deployment of Oracle E-Business Suite and Oracle Fusion ERP on Exadata Cloud Service. The company's broader application portfolio was migrating to Azure as part of a five-year Microsoft commercial commitment, and the customer needed to connect the OCI-resident ERP database tier to the Azure-resident application tier for the migrating workloads without sacrificing the OCI investment.

The buyer-side architecture review compared two options. Option A was a full migration to Oracle Database@Azure in Azure West Europe, which would have required restructuring the existing OCI Universal Credits commitment ($24m remaining), establishing a fresh Database@Azure commercial commitment with the Marketplace overlay, and absorbing a 14-month migration project. Option B was an Oracle Interconnect for Azure deployment between OCI Amsterdam and Azure West Europe, keeping the database tier in place on ExaCS and connecting the migrating application tiers over the dedicated peering.

The buyer-side recommendation was Option B. The Interconnect provisioning cost was $48k annually (10 Gbps combined FastConnect and ExpressRoute), the architecture preserved the existing OCI commercial commitment, and the migration timeline reduced from 14 months to 4 months because the database tier did not move. The Azure-side application tier connected at single-digit-millisecond latency to the OCI database tier, the existing Universal Credits commitment continued to fund the Exadata consumption, and the customer's Microsoft commercial commitment was preserved for its primary purpose (Azure-native application workloads). Net five-year saving against Option A: $7.2m through preservation of the existing OCI commercial position and avoidance of the migration project. For the broader Oracle multi-cloud architecture framework see our Oracle cloud advisory service.

The four buyer-side moves on Oracle Interconnect for Azure

Move 1 — Treat Interconnect and Database@Azure as architecturally distinct. They solve different problems. Pick the architecture whose answer matches the customer's strategic intent — not the architecture the Oracle account team is pushing this quarter.

Move 2 — Document the Azure-side Oracle licence allocation explicitly. Customer-deployed Oracle Database on Azure VMs under the Interconnect requires on-premise Processor or NUP licences. Map the allocation by subscription, document the SULS status, and maintain the audit-defence position.

Move 3 — Defend the audit scope boundary against LMS overreach. LMS audit teams routinely extend scope to Azure subscriptions adjacent to Interconnect deployments. The customer's defence is to document which Azure subscriptions are in scope and which are not, in advance of the audit notice.

Move 4 — Negotiate the FastConnect and ExpressRoute pricing as part of the broader commercial position. The Interconnect connectivity costs are negotiable as part of the OCI Universal Credits commitment and the Microsoft Azure commitment. Position them as commercial line items, not as fixed infrastructure costs.

For customers running Fusion Cloud workloads on Azure-resident application tiers connected through the Interconnect, the supporting Oracle AI Apps for Fusion licensing metrics — per-employee, per-transaction, and consumption-based against Universal Credits — should be modelled against the Azure deployment topology. Similarly, development teams whose workstations sit inside Azure tenancy should model the Oracle Code Assist licensing position against the broader cross-cloud commercial relationship.