OCINetworkingadvanced

OCI + Azure Multi-Cloud Guide

Build multi-cloud architectures with OCI and Azure: OracleDB@Azure, FastConnect-ExpressRoute interconnect, identity federation, and data transfer patterns.

CloudToolStack Team26 min readPublished Mar 14, 2026

Prerequisites

Experience with both OCI and Azure cloud platforms
Understanding of network interconnect and hybrid cloud concepts

Introduction to OCI + Azure Multi-Cloud

Oracle and Microsoft have established a unique multi-cloud partnership that provides direct, low-latency network interconnection between OCI and Azure. This partnership enables customers to run Oracle databases on OCI while hosting application tiers on Azure, leveraging the best of both platforms without the performance penalties typically associated with multi-cloud architectures.

The partnership includes three key offerings: Oracle Database@Azure (Oracle Exadata infrastructure running within Azure data centers), OCI-Azure Interconnect (cross-cloud network connectivity with sub-2ms latency), andOracle Database Service for Azure (ODSA) (simplified Azure-native access to Oracle databases on OCI). Together, these services make OCI+Azure the most tightly integrated multi-cloud combination available today.

This guide covers the architecture of each integration approach, network interconnect setup, OracleDB@Azure deployment, identity federation between OCI and Azure, data transfer patterns, and production best practices for building multi-cloud applications.

Available Interconnect Regions

OCI-Azure Interconnect is available in multiple regions where OCI and Azure data centers are co-located or closely connected. Key regions include Ashburn/East US, Phoenix/West US, London/UK South, Amsterdam/West Europe, Frankfurt/Germany West Central, Tokyo/Japan East, and Sao Paulo/Brazil South. Cross-cloud latency in co-located regions is typically under 2 milliseconds, comparable to same-cloud latency.

Architecture Patterns

There are three primary architecture patterns for OCI+Azure deployments, each suited to different requirements:

Pattern 1: Split-Tier Architecture runs Oracle Database on OCI and application/web tiers on Azure. This is the most common pattern, leveraging Oracle's database expertise with Azure's rich application platform (App Service, AKS, Azure Functions). The OCI-Azure Interconnect provides the high-bandwidth, low-latency network bridge between the tiers.

Pattern 2: OracleDB@Azure deploys Oracle Exadata infrastructure directly inside Azure data centers. The database is managed through OCI APIs and console, but the Exadata hardware resides in Azure, eliminating cross-cloud network latency entirely. This pattern is ideal for latency-sensitive applications that cannot tolerate any cross-cloud hop.

Pattern 3: Hybrid Active-Active runs workloads across both clouds with bidirectional data replication. This pattern provides geographic redundancy and enables failover between OCI and Azure for disaster recovery. It requires careful data consistency management.

bash

# Architecture decision matrix:
#
# | Requirement           | Split-Tier | DB@Azure | Hybrid A-A |
# |-----------------------|-----------|----------|-----------|
# | Cross-cloud latency   | < 2ms     | < 0.5ms  | < 2ms     |
# | Oracle DB licensing   | OCI BYOL  | Azure    | Both      |
# | App platform          | Azure     | Azure    | Both      |
# | DR capability         | Manual    | Azure HA | Automatic |
# | Data sovereignty      | Multi-DC  | Single   | Multi-DC  |
# | Operational complexity| Medium    | Low      | High      |

# Check available interconnect locations
oci network fast-connect-provider-service list \
  --compartment-id $C \
  --query 'data[?contains("provider-name", '''Microsoft''')].{"provider-name":"provider-name", "provider-service-name":"provider-service-name"}' \
  --output table

Setting Up OCI-Azure Interconnect

The OCI-Azure Interconnect uses OCI FastConnect and Azure ExpressRoute to create a direct, private network link between your OCI VCN and Azure VNet. Traffic flows over Oracle and Microsoft's co-located network infrastructure without traversing the public internet, providing consistent low latency, high bandwidth, and improved security.

Setting up the interconnect requires configuration on both the OCI side (FastConnect virtual circuit) and the Azure side (ExpressRoute circuit). The two circuits are linked through the co-located exchange, and BGP peering establishes route exchange between the two networks.

bash

# Step 1: Create OCI resources

# Create a DRG (Dynamic Routing Gateway)
oci network drg create \
  --compartment-id $C \
  --display-name "azure-interconnect-drg"

# Attach the DRG to your VCN
oci network drg-attachment create \
  --drg-id <drg-ocid> \
  --vcn-id <vcn-ocid> \
  --display-name "vcn-to-drg"

# Create a FastConnect virtual circuit
oci network virtual-circuit create \
  --compartment-id $C \
  --display-name "azure-expressroute-link" \
  --type "PRIVATE" \
  --bandwidth-shape-name "1 Gbps" \
  --gateway-id <drg-ocid> \
  --provider-service-id <microsoft-provider-ocid> \
  --cross-connect-mappings '[{
    "customerBgpPeeringIp": "10.0.0.1/30",
    "oracleBgpPeeringIp": "10.0.0.2/30"
  }]'

# Get the Azure peering key from the virtual circuit
oci network virtual-circuit get \
  --virtual-circuit-id <vc-ocid> \
  --query 'data.{"oracle-bgp-peering-key":"reference-comment"}'

# Step 2: Azure side (using Azure CLI)
# az network express-route create \
#   --resource-group myRG \
#   --name oci-interconnect \
#   --provider "Oracle Cloud Infrastructure" \
#   --peering-location "Washington DC" \
#   --bandwidth 1000 \
#   --sku-tier Standard \
#   --sku-family MeteredData

# Link ExpressRoute to VNet
# az network express-route peering create \
#   --resource-group myRG \
#   --circuit-name oci-interconnect \
#   --peering-type AzurePrivatePeering \
#   --peer-asn 31898 \
#   --primary-peer-subnet 10.0.0.0/30 \
#   --secondary-peer-subnet 10.0.0.4/30 \
#   --vlan-id 200 \
#   --shared-key <oracle-bgp-peering-key>

# Step 3: Verify connectivity
# From an OCI instance, ping an Azure VM's private IP:
# ping 172.16.1.10
# Expected: < 2ms latency for co-located regions

Use Matching Region Pairs

For the lowest latency, deploy your OCI and Azure resources in co-located regions where the interconnect is a direct cross-connect within the same data center facility. For example, use OCI US East (Ashburn) with Azure East US, or OCI UK South (London) with Azure UK South. Co-located pairs provide sub-2ms latency, while non-co-located pairs may have higher latency due to fiber distance.

Oracle Database@Azure

Oracle Database@Azure runs Oracle Exadata infrastructure directly within Azure data centers. Unlike the interconnect model where the database is in an OCI data center, DB@Azure places the Exadata hardware inside Azure, accessible through an Azure VNet. This eliminates all cross-cloud network latency because the database and application are in the same physical facility.

DB@Azure is managed through the OCI console and APIs for database operations (provisioning, patching, backups, scaling) but integrates with Azure networking, identity (Entra ID), and billing. You see the charges on your Azure bill, can use Azure Reserved Instances for cost optimization, and manage network access through Azure VNets and NSGs.

bash

# Oracle Database@Azure is provisioned through the Azure portal
# or Azure CLI with the Oracle.Database resource provider

# Azure CLI: Register the Oracle resource provider
# az provider register --namespace Oracle.Database

# Create an Exadata Infrastructure (Azure CLI)
# az oracle-database cloud-exadata-infrastructure create \
#   --resource-group myRG \
#   --name prod-exadata \
#   --location eastus \
#   --zone "1" \
#   --shape "Exadata.X9M" \
#   --compute-count 2 \
#   --storage-count 3 \
#   --delegated-subnet-id <azure-subnet-resource-id>

# Create a VM Cluster on the Exadata Infrastructure
# az oracle-database cloud-vm-cluster create \
#   --resource-group myRG \
#   --name prod-vmcluster \
#   --location eastus \
#   --cloud-exadata-infrastructure-id <exadata-id> \
#   --cpu-core-count 4 \
#   --ssh-public-keys @~/.ssh/id_rsa.pub \
#   --vnet-id <azure-vnet-id> \
#   --subnet-id <azure-subnet-id> \
#   --gi-version "19.0.0.0" \
#   --hostname "proddb"

# Once the VM cluster is ready, manage the database through OCI:
oci db database create \
  --db-home-id <db-home-ocid> \
  --db-name "PRODDB" \
  --admin-password "<password>" \
  --db-workload "OLTP" \
  --character-set "AL32UTF8" \
  --pdb-name "PRODPDB"

# Connect from an Azure VM:
# sqlplus admin/password@<db-private-ip>:1521/PRODPDB

Identity Federation: OCI and Azure

In a multi-cloud environment, maintaining separate user identities for OCI and Azure creates management overhead and security risk. Identity federation enables a single sign-on experience where users authenticate once and access both OCI and Azure resources.

The recommended approach is to use Microsoft Entra ID (Azure AD) as the primary identity provider and federate it with OCI Identity Domains using SAML 2.0. This allows users to log into the OCI console using their Entra ID credentials without maintaining separate OCI passwords.

bash

# Federation setup: Entra ID -> OCI Identity Domains

# Step 1: In OCI Identity Domains admin console
# Navigate to: Security > Identity Providers > Add SAML IDP
# Download the OCI SP metadata XML

# Step 2: In Azure Entra ID
# Navigate to: Enterprise Applications > New Application > Oracle Cloud Infrastructure Console
# Configure SAML SSO:
# - Entity ID: https://<domain-url>/fed
# - Reply URL: https://<domain-url>/fed/v1/sp/sso
# - Sign-on URL: https://cloud.oracle.com
# Upload the OCI SP metadata
# Download the Entra ID Federation Metadata XML

# Step 3: In OCI Identity Domains
# Upload the Entra ID metadata XML
# Configure attribute mappings:
# - NameID -> userName
# - user.mail -> email
# - user.givenname -> firstName
# - user.surname -> lastName

# Step 4: Configure group mapping
# Entra ID Group -> OCI Group mapping:
# "OCI-Admins"         -> "Administrators"
# "OCI-NetworkAdmins"  -> "NetworkAdmins"
# "OCI-Developers"     -> "Developers"
# "OCI-ReadOnly"       -> "ReadOnlyAuditors"

# Step 5: Test federation
# Navigate to cloud.oracle.com
# Select "Sign in with Microsoft"
# Authenticate with Entra ID credentials
# Verify OCI console access

# IAM policies for federated users
oci iam policy create \
  --compartment-id $C \
  --name "federated-dev-access" \
  --description "Access for Entra ID federated developers" \
  --statements '["Allow group Developers to manage all-resources in compartment development"]'

Data Transfer Patterns

Moving data between OCI and Azure efficiently requires choosing the right transfer mechanism based on data volume, frequency, and latency requirements.

Real-Time Replication: Use OCI GoldenGate for continuous, low-latency replication between Oracle databases on OCI and application databases on Azure. GoldenGate supports Oracle-to-Oracle, Oracle-to-PostgreSQL, and Oracle-to-SQL Server replication.

Batch Transfer: Use the OCI-Azure interconnect for bulk data transfers between OCI Object Storage and Azure Blob Storage. Tools like AzCopy, rclone, or custom scripts can transfer data over the private interconnect at up to 10 Gbps.

Event-Driven: Use OCI Streaming (Kafka-compatible) with Azure Event Hubs to exchange events between OCI and Azure applications. Both services support the Apache Kafka protocol, enabling direct interoperability.

bash

# Batch transfer: OCI Object Storage to Azure Blob Storage
# Using rclone over the interconnect (from a VM with access to both clouds)

# Configure rclone for OCI Object Storage:
# [oci]
# type = oracleobjectstorage
# namespace = <namespace>
# compartment = <compartment-ocid>
# region = us-ashburn-1

# Configure rclone for Azure Blob Storage:
# [azure]
# type = azureblob
# account = <storage-account>
# key = <storage-key>

# Sync data from OCI to Azure:
# rclone sync oci:my-bucket/data/ azure:my-container/data/ --progress

# Sync data from Azure to OCI:
# rclone sync azure:my-container/reports/ oci:my-bucket/reports/ --progress

# Real-time replication with GoldenGate:
# 1. Deploy OCI GoldenGate in the OCI VCN
# 2. Configure extract from Oracle DB on OCI
# 3. Configure replicat to Azure SQL or PostgreSQL
# 4. Route replicat traffic over the interconnect
# 5. Monitor lag with GoldenGate metrics

# Event-driven: OCI Streaming to Azure Event Hubs
# Both support Kafka protocol, so a Kafka consumer on Azure
# can consume from OCI Streaming using the Kafka endpoint:
#
# Bootstrap servers: streaming.<region>.oci.oraclecloud.com:9092
# SASL mechanism: PLAIN
# Username: <tenancy>/<username>/<stream-pool-ocid>
# Password: <auth-token>

Monitoring Across Clouds

Monitoring a multi-cloud environment requires visibility into both OCI and Azure resources, as well as the interconnect health. Use a combination of OCI Monitoring, Azure Monitor, and optionally a third-party tool like Grafana or Datadog for unified dashboards.

bash

# Monitor OCI FastConnect virtual circuit health
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_fastconnect" \
  --query-text 'ConnectionState[1m]{resourceId = "<vc-ocid>"}.max()'

# Monitor interconnect bandwidth usage
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_fastconnect" \
  --query-text 'BytesReceived[5m]{resourceId = "<vc-ocid>"}.rate()'

oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_fastconnect" \
  --query-text 'BytesSent[5m]{resourceId = "<vc-ocid>"}.rate()'

# Create alarm for interconnect down
oci monitoring alarm create \
  --compartment-id $C \
  --display-name "azure-interconnect-down" \
  --metric-compartment-id $C \
  --namespace "oci_fastconnect" \
  --query-text 'ConnectionState[1m]{resourceId = "<vc-ocid>"}.min() < 1' \
  --severity "CRITICAL" \
  --destinations '["<critical-topic-ocid>"]' \
  --is-enabled true \
  --body "OCI-Azure interconnect is down - check FastConnect and ExpressRoute"

# Monitor cross-cloud latency (from an OCI instance)
# ping -c 100 <azure-vm-private-ip> | tail -1
# Expected: rtt avg < 2ms for co-located regions

# Azure side monitoring (Azure CLI):
# az monitor metrics list \
#   --resource <expressroute-resource-id> \
#   --metric "BitsInPerSecond" "BitsOutPerSecond" \
#   --interval PT5M

Production Best Practices

Building production multi-cloud architectures with OCI and Azure requires careful planning across networking, security, operations, and cost management:

Network Redundancy: Deploy at least two FastConnect/ExpressRoute circuits for high availability. Use different physical paths or exchange locations if available. Configure BGP failover so traffic automatically reroutes if one circuit fails.

Consistent Security: Apply the same security standards across both clouds. Use federated identity (Entra ID to OCI Identity Domains) for unified access management. Encrypt all cross-cloud data in transit using TLS. Maintain consistent firewall rules on both OCI NSGs and Azure NSGs.

Unified Monitoring: Use a single observability platform (Grafana, Datadog, or Splunk) that aggregates metrics and logs from both OCI and Azure. Create cross-cloud dashboards that show end-to-end application health including interconnect latency and bandwidth.

Cost Management: Track cross-cloud data transfer costs separately from same-cloud costs. The OCI-Azure interconnect has data transfer charges on both sides. Optimize by compressing data before transfer, caching frequently accessed data locally, and batching small transfers into larger ones.

Disaster Recovery: Define clear RPO and RTO targets for your multi-cloud application. Test failover procedures regularly, including interconnect failure, database switchover, and DNS failover. Document runbooks for each failure scenario.

Infrastructure as Code: Use Terraform with both the OCI and AzureRM providers to manage infrastructure declaratively across both clouds. Store all configurations in a single Git repository with separate modules for OCI and Azure resources. This ensures consistency and enables reproducible deployments.

OCI VCN Networking Deep Dive OCI GoldenGate Guide OCI Identity Domains Guide

Key Takeaways

1OCI-Azure Interconnect provides sub-2ms latency through co-located data center cross-connects.
2OracleDB@Azure runs Exadata hardware inside Azure data centers for zero cross-cloud latency.
3Identity federation with Entra ID enables single sign-on across both OCI and Azure resources.
4GoldenGate enables real-time data replication between Oracle databases on OCI and Azure databases.

Frequently Asked Questions

What is the latency between OCI and Azure through the interconnect?

In co-located regions (where OCI and Azure share the same data center facility), cross-cloud latency is typically under 2 milliseconds, comparable to same-cloud latency. Co-located regions include Ashburn/East US, London/UK South, Amsterdam/West Europe, and Tokyo/Japan East. Non-co-located regions may have higher latency depending on fiber distance between data centers.

What is Oracle Database@Azure?

OracleDB@Azure deploys Oracle Exadata infrastructure directly inside Azure data centers, managed through OCI APIs and console but billed through Azure. This eliminates all cross-cloud network latency because the database and Azure application tiers are in the same physical facility. It supports Oracle Database Enterprise Edition and offers the same features as OCI-hosted Exadata including RAC, Data Guard, and automatic backups.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.