Multi-Cloud - OCI, Azure, and AWS

Why Multi-Cloud Is Not Optional in 2026

Three converging forces have made Oracle's co-location model the default enterprise architecture — regulatory pressure, commercial leverage, and the evolution of the DBA role. 

Two years ago, "multi-cloud" was a PowerPoint aspiration. In 2026, it is a regulatory requirement, a procurement weapon, and increasingly, a career-defining skill for infrastructure engineers and DBAs.

Oracle's answer — physically placing Exadata X10M hardware inside Azure and AWS datacenters — is an architectural pivot that eliminates the primary objection enterprise auditors had: cross-internet replication. When the Oracle DB node is inside the same datacenter building as your Azure App Service, the latency profile changes from "50–80ms internet hop" to "sub-2ms private fabric." That changes everything from failover RTO to real-time analytics feasibility.

⚡ Regulatory Driver

DORA (EU Digital Operational Resilience Act), BCBS 239, and sector-specific mandates (PRA SS1/21, APRA CPS 230) now require demonstrable multi-provider resilience. Oracle's physically co-located model is the first architecture that satisfies these requirements without crossing the public internet — a requirement previously impossible to meet with traditional cross-cloud replication.

🔵 Regulatory Pressure

• DORA mandates multi-provider resilience for EU financial entities by 2025
• BCBS 239 requires data lineage across environments
• Auditors now accept Oracle co-lo as "independent provider"
• No cross-internet data movement required

🟠 Vendor Leverage

• Oracle needs Azure/AWS distribution to expand TAM
• Hyperscalers need Oracle's 40,000+ enterprise database customers
• Enterprises negotiate discounts against both simultaneously
• Single Azure/AWS bill for Oracle workloads improves FinOps

🔴 DBA Role Evolution

• VCN peering and ExpressRoute are now DBA competencies
• AWS Direct Connect topology knowledge required
• Data Guard across cloud boundaries is now standard
• GoldenGate CDC replaces ETL in multi-cloud patterns

🟡 Commercial Reality

• Azure Unified Support covers Oracle DB @ Azure incidents
• Azure Marketplace billing consolidates Oracle licensing
• AWS co-location launched late 2024, GA across us-east-1 / eu-west-1
• OCI credits portable across co-location deployments

---

02 — Architecture

Multi-Cloud Reference Architecture

Three-region topology: OCI as the control plane and source-of-truth database, with Oracle DB @ Azure serving the Azure application tier and Oracle DB @ AWS handling AWS workloads — all connected via private, sub-millisecond interconnects.

Oracle Multi-Cloud Reference Architecture — OCI ↔ Azure ↔ AWS

---

03 — Performance

Latency Profiles & Connectivity

Understanding the latency characteristics of each path is critical for architecture decisions — particularly for synchronous Data Guard and real-time analytics.

App → Oracle DB @ Azure

<2ms

OCI ↔ Azure FastConnect

<1ms

OCI ↔ AWS Direct Link

<2ms

Data Guard (sync mode)

~3ms

GoldenGate CDC lag

<5s

Traditional cross-internet

50–80ms

🔌 Connectivity Options

Azure uses ExpressRoute for the private OCI–Azure link. AWS uses Direct Connect for the OCI–AWS link. Both require dedicated circuits provisioned at Oracle partner locations. Bandwidth tiers available: 1Gbps, 10Gbps, 100Gbps. For Data Guard SYNC mode, a minimum 10Gbps dedicated circuit is recommended to keep redo transport under 2ms.

The key architectural decision is choosing between Data Guard SYNC and ASYNC modes across the interconnect. SYNC guarantees zero data loss but introduces latency into every commit. At sub-2ms interconnect latency, SYNC is viable for most OLTP workloads — a significant departure from traditional cross-cloud architectures where ASYNC was the only practical option.

04 — DBA Playbook

Production SQL Playbook for Multi-Cloud DBAs

Battle-tested queries for monitoring Data Guard health, latency, failover readiness, and interconnect performance across all three clouds.

Data Guard Health — Comprehensive Lag & Status

data_guard_multicloud_health.sqlSQL / Oracle

-- ============================================================
-- Multi-Cloud Data Guard Comprehensive Health Check
-- Run on PRIMARY (OCI Exadata) and each STANDBY
-- ============================================================

SELECT
    NAME,
    VALUE,
    UNIT,
    TIME_COMPUTED,
    DATUM_TIME
FROM
    V$DATAGUARD_STATS
WHERE
    NAME IN (
        'apply lag',
        'transport lag',
        'apply rate',
        'redo transport rate',
        'estimated startup time'
    )
ORDER BY
    NAME;

Standby Redo Apply — Detailed Gap Analysis

standby_redo_gap_analysis.sqlSQL / Oracle

-- ============================================================
-- Standby redo log gaps and archive sequence health
-- Critical for identifying interconnect degradation
-- ============================================================

SELECT
    al.dest_id,
    al.dest_name,
    al.status,
    al.target,
    al.archiver,
    al.schedule,
    al.destination,
    al.applied_scn,
    al.applied_seq#                                AS applied_seq,
    al.error
FROM   V$ARCHIVE_DEST_STATUS al
WHERE  al.status != 'INACTIVE'
ORDER BY al.dest_id;

-- Sequence gap finder: run on STANDBY
SELECT
    thread#,
    low_sequence#                                  AS gap_start,
    high_sequence#                                 AS gap_end,
    (high_sequence# - low_sequence# + 1)          AS gap_size
FROM   V$ARCHIVE_GAP
ORDER BY thread#, low_sequence#;

Real-Time Redo Transport Throughput

redo_transport_throughput.sqlSQL / Oracle

-- ============================================================
-- Cross-cloud redo transport performance per destination
-- Compare FastConnect (Azure) vs Direct Connect (AWS) paths
-- ============================================================

SELECT
    rs.dest_id,
    rs.dest_name,
    ROUND(rs.transmitted_kb / 1024, 2)            AS transmitted_mb,
    ROUND(rs.transmitted_kb / NULLIF(rs.elapsed_seconds, 0), 2)
                                                   AS avg_kbps,
    rs.elapsed_seconds,
    rs.active_agents,
    rs.async_blocks                                AS async_redo_blocks,
    rs.failure_count,
    rs.last_failure_msg
FROM   V$REDO_TRANSPORT_STATS rs
WHERE  rs.dest_id > 0
ORDER BY rs.dest_id;

-- Cross-cloud commit latency (SYNC mode impact)
SELECT
    w.event,
    w.total_waits,
    ROUND(w.time_waited_micro / 1000, 2)          AS time_waited_ms,
    ROUND(w.time_waited_micro / NULLIF(w.total_waits, 0) / 1000, 3)
                                                   AS avg_wait_ms
FROM   V$SYSTEM_EVENT w
WHERE  w.event LIKE '%remote%'
   OR  w.event LIKE '%log file sync%'
   OR  w.event LIKE '%Data Guard%'
ORDER BY w.time_waited_micro DESC
FETCH FIRST 15 ROWS ONLY;

Failover Readiness Scorecard

failover_readiness_scorecard.sqlSQL / Oracle

-- ============================================================
-- Pre-failover readiness check — run before any planned
-- switchover or unplanned failover event
-- ============================================================

SELECT
    'PROTECTION MODE'                             AS check_item,
    protection_mode                                AS check_value,
    CASE
        WHEN protection_mode = 'MAXIMUM AVAILABILITY' THEN '✓ READY'
        WHEN protection_mode = 'MAXIMUM PERFORMANCE'  THEN '⚠ CHECK LAG'
        ELSE '✗ REVIEW'
    END                                            AS status
FROM   V$DATABASE

UNION ALL

SELECT
    'STANDBY COUNT',
    TO_CHAR(COUNT(*)),
    CASE WHEN COUNT(*) >= 2 THEN '✓ READY' ELSE '✗ INSUFFICIENT' END
FROM   V$DATAGUARD_CONFIG WHERE dest_role != 'PRIMARY DATABASE'

UNION ALL

SELECT
    'APPLY LAG (AZURE STANDBY)',
    TO_CHAR(apply_lag, 'HH24:MI:SS'),
    CASE
        WHEN apply_lag < INTERVAL '30' SECOND THEN '✓ READY'
        WHEN apply_lag < INTERVAL '5' MINUTE  THEN '⚠ ACCEPTABLE'
        ELSE '✗ INVESTIGATE'
    END
FROM   V$DATAGUARD_STATS WHERE name = 'apply lag'

UNION ALL

SELECT
    'FAST START FAILOVER',
    fast_start_failover_status,
    CASE fast_start_failover_status
        WHEN 'ENABLED'  THEN '✓ READY'
        WHEN 'DISABLED' THEN '⚠ MANUAL FAILOVER ONLY'
        ELSE '? UNKNOWN'
    END
FROM   V$DATABASE;

---

05 — Replication

GoldenGate CDC — Multi-Cloud Replication Health

GoldenGate is the CDC backbone connecting OCI primary to both Oracle DB @ Azure and Oracle DB @ AWS. These queries give real-time visibility into replication health, lag, and conflict resolution.

goldengate_multicloud_heartbeat.sqlSQL / Oracle + GoldenGate

-- ============================================================
-- GoldenGate replication heartbeat — all multi-cloud paths
-- Run from OCI GoldenGate hub database
-- ============================================================

SELECT
    gg.group_name,
    gg.group_type,
    gg.status,
    gg.target_name                                 AS target_cloud,
    ROUND(
      (CAST(SYSTIMESTAMP AS DATE) -
       CAST(gg.last_heartbeat AS DATE)) * 86400, 1
    )                                              AS lag_seconds,
    gg.records_committed,
    gg.ops_per_second,
    gg.ddl_count,
    gg.error_count,
    gg.last_error_msg,
    TO_CHAR(gg.last_heartbeat, 'YYYY-MM-DD HH24:MI:SS')
                                                   AS last_heartbeat_ts
FROM   GG_AUTO_CDR_CONFIGURATION gg
ORDER BY lag_seconds DESC;

-- Conflict detection and resolution history (CDR)
SELECT
    cdr.conflict_time,
    cdr.table_name,
    cdr.conflict_type,
    cdr.resolution_type,
    cdr.winning_rowid,
    cdr.source_db_name                             AS winning_cloud,
    cdr.delta_resolution
FROM   GG_AUTO_CDR_EXCEPTIONS cdr
WHERE  cdr.conflict_time > SYSTIMESTAMP - INTERVAL '24' HOUR
ORDER BY cdr.conflict_time DESC
FETCH FIRST 50 ROWS ONLY;

goldengate_extract_pump_monitor.sqlSQL / Oracle + GoldenGate

-- ============================================================
-- Extract and Pump process performance across all targets
-- ============================================================

SELECT
    p.process_name,
    p.process_type,
    p.status,
    p.start_time,
    ROUND(p.lag_at_chkpt_secs, 2)                AS lag_at_checkpoint_secs,
    ROUND(p.time_since_chkpt_secs, 2)             AS secs_since_checkpoint,
    p.records_per_sec,
    p.bytes_per_sec,
    p.chkpt_position,
    p.last_error_seqno,
    p.last_error_msg
FROM   GV$GG_PROCINFO p
ORDER BY p.process_type, p.lag_at_chkpt_secs DESC;

-- Table-level throughput breakdown (identify hot tables)
SELECT
    ts.process_name,
    ts.table_name,
    ts.inserts,
    ts.updates,
    ts.deletes,
    ts.discards,
    ts.total_ops                                   AS total_operations,
    ROUND(ts.total_ops / NULLIF(
        EXTRACT(SECOND FROM
          (SYSTIMESTAMP - ts.first_seen_time)), 0
    ), 2)                                         AS ops_per_sec
FROM   GV$GG_TABLE_STATS ts
WHERE  ts.total_ops > 0
ORDER BY ts.total_ops DESC
FETCH FIRST 20 ROWS ONLY;

⚠️

CDR Conflict Resolution — Bi-Directional Replication Risk

When enabling bi-directional GoldenGate replication between Oracle DB @ Azure and Oracle DB @ AWS, you must configure Automatic Conflict Detection and Resolution (CDR) rules. The most common conflict pattern is concurrent UPDATE conflicts on the same row from both regions. The recommended strategy for financial data is timestamp-wins with a Delta resolution fallback. Always monitor the CDR exceptions table daily during the first 90 days of production.

---

06 — Security

Identity Federation & Security Across Clouds

Multi-cloud security is not additive — it is multiplicative in complexity. The Oracle co-location model introduces a unique identity topology that must be designed explicitly.

The fundamental challenge of multi-cloud identity is that each cloud has its own IAM model — OCI IAM, Azure Entra ID, and AWS IAM are not inherently interoperable. Oracle's co-location model provides a pragmatic answer: Azure Entra ID becomes the human identity plane for Oracle DB @ Azure, while OCI IAM governs the database resource control plane. AWS IAM handles the AWS-side application identities, with federation back to OCI Vault for database secrets.

privilege_audit_multicloud.sqlSQL / Oracle Unified Audit

-- ============================================================
-- Unified audit query — cross-cloud privileged access review
-- Surfaces high-risk operations across all DB nodes
-- ============================================================

SELECT
    ua.event_timestamp,
    ua.dbusername,
    ua.os_username,
    ua.client_program_name,
    ua.client_identifier,
    ua.action_name,
    ua.object_schema,
    ua.object_name,
    ua.sql_text,
    ua.return_code,
    ua.authentication_type,
    ua.unified_audit_policies
FROM   UNIFIED_AUDIT_TRAIL ua
WHERE  ua.event_timestamp > SYSTIMESTAMP - INTERVAL '1' DAY
  AND  (
    ua.action_name IN (
      'CREATE USER', 'DROP USER', 'ALTER USER',
      'GRANT', 'REVOKE', 'CREATE ROLE',
      'AUDIT', 'NOAUDIT', 'EXECUTE'
    )
    OR ua.sql_text LIKE '%DBMS_DATAPUMP%'
    OR ua.sql_text LIKE '%UTL_FILE%'
    OR ua.sql_text LIKE '%EXECUTE IMMEDIATE%'
  )
ORDER BY ua.event_timestamp DESC;

-- OCI Vault secret rotation compliance check
SELECT
    s.secret_name,
    s.lifecycle_state,
    TO_CHAR(s.time_of_current_version_expiry,
            'YYYY-MM-DD HH24:MI:SS')             AS secret_expires,
    ROUND(SYSDATE - CAST(s.time_created AS DATE), 0)
                                                   AS age_days,
    s.is_auto_generation_enabled,
    s.rotation_interval_in_days
FROM   OCI_VAULT_SECRETS s
WHERE  s.is_auto_generation_enabled = 'FALSE'
   OR  s.time_of_current_version_expiry < SYSTIMESTAMP + INTERVAL '30' DAY
ORDER BY s.time_of_current_version_expiry;

Ref: https://docs.oracle.com/en-us/iaas/tools/terraform-provider-oci/latest/docs/r/vault_secret.html

✅ Security Architecture Recommendation

Use OCI Vault as the single secrets manager across all three cloud environments. Both Azure Key Vault and AWS Secrets Manager can be configured to delegate to OCI Vault via API, ensuring that database passwords, TDE wallet keys, and GoldenGate credentials have one authoritative source. This dramatically simplifies SOC 2 and ISO 27001 evidence collection — one vault audit trail covers all three clouds.

---

07 — Migration

Migration Runbook — On-Prem to Multi-Cloud Oracle

A phased approach that minimizes risk by establishing the OCI primary first, then extending into co-location models on Azure and AWS.

1

Baseline Assessment & Network Design

Inventory all Oracle databases: version, edition, licensed options. Map application dependencies. Design the VCN/VNet topology. Provision ExpressRoute (Azure) and Direct Connect (AWS) circuits — these take 2–6 weeks. Do not skip this step; network provisioning is the most common schedule risk.

2

Provision OCI Exadata & Establish Primary

Stand up OCI Exadata as the target primary. Configure OCI Vault, OCI Logging, and GoldenGate hub. Migrate using Data Guard (if source is already Oracle) or RMAN + Data Pump for fresh migrations. Validate with real workload for a minimum of 2 weeks before extending to co-location.

3

Extend Data Guard to Oracle DB @ Azure

Add Oracle DB @ Azure as a physical standby. Configure FastConnect private peering. Validate redo transport latency <2ms. Test switchover. Enable Azure Entra ID authentication for application teams. Update Azure App Service connection strings.

4

GoldenGate CDC to Oracle DB @ AWS

Configure GoldenGate Extract on OCI primary. Set up Data Pump path to Oracle DB @ AWS for initial load. Transition to continuous CDC replication. Validate lag <5 seconds under production load. Configure AWS Lambda / EKS applications to connect to Oracle DB @ AWS endpoint.

5

Production Cutover & Runbook Validation

Execute planned switchover during maintenance window. Decommission on-premises Oracle infrastructure. Enable Fast Start Failover for automated recovery. Validate all monitoring dashboards: Azure Monitor, CloudWatch, OCI Logging, and GoldenGate heartbeat. Run failover drill within 30 days of cutover.

pre_migration_readiness_check.sqlSQL / Oracle

-- ============================================================
-- Pre-migration compatibility and readiness assessment
-- Run on source database before any migration activity
-- ============================================================

-- Character set and NLS compatibility
SELECT
    p.parameter,
    p.value
FROM   NLS_DATABASE_PARAMETERS p
WHERE  p.parameter IN (
    'NLS_CHARACTERSET',
    'NLS_NCHAR_CHARACTERSET',
    'NLS_LANGUAGE',
    'NLS_TERRITORY',
    'NLS_SORT'
);

-- Identify unsupported features on ADB (Autonomous)
SELECT
    f.name                                         AS feature_name,
    f.detected_usages,
    f.currently_used,
    f.version
FROM   DBA_FEATURE_USAGE_STATISTICS f
WHERE  f.detected_usages > 0
  AND  f.name IN (
    'Real Application Clusters',
    'Advanced Compression',
    'Partitioning',
    'Database Vault',
    'Label Security',
    'Spatial',
    'Text',
    'Advanced Analytics'
  )
ORDER BY f.detected_usages DESC;

-- Object dependency analysis (migration blockers)
SELECT
    o.owner,
    o.object_type,
    COUNT(*)                                       AS object_count,
    SUM(CASE WHEN o.status = 'INVALID' THEN 1 ELSE 0 END)
                                                   AS invalid_count
FROM   DBA_OBJECTS o
WHERE  o.owner NOT IN (
    'SYS', 'SYSTEM', 'DBSNMP', 'OUTLN',
    'ORACLE_OCM', 'XDB', 'APPQOSSYS'
)
GROUP BY o.owner, o.object_type
HAVING  SUM(CASE WHEN o.status = 'INVALID' THEN 1 ELSE 0 END) > 0
ORDER BY invalid_count DESC;

Ref: 

https://docs.oracle.com/en-us/iaas/tools/terraform-provider-oci/latest/docs/r/vault_secret.html

Ref: 

https://docs.oracle.com/en-us/iaas/tools/terraform-provider-oci/latest/docs/r/vault_secret.html

---

08 — Decision Guide

Architecture Decision Matrix

Not every workload needs the full three-cloud topology. Use this matrix to right-size your Oracle multi-cloud investment.

Scenario	Recommended Pattern	Data Guard Mode	GoldenGate?	Complexity
Azure-first enterprise, Oracle licensing concern	OCI + DB@Azure	SYNC / MAX AVAILABILITY	Optional	Medium
AWS-native apps, need Oracle as backend	OCI Primary + DB@AWS	ASYNC / MAX PERFORMANCE	Yes	Medium
DORA / BCBS 239 regulatory mandate	Full 3-Cloud Topology	SYNC (Azure) + ASYNC (AWS)	Yes — CDR required	High
Analytics / reporting offload	OCI + ADB Shared	ADG — read-only standby	Optional	Low
DR-only (not primary active)	DB@Azure or DB@AWS as DR	ASYNC — MAX PERFORMANCE	No	Low
Global active-active (bi-directional writes)	GoldenGate Bidirectional	N/A (GoldenGate replaces)	Yes — mandatory	Very High

DBA & Infra Team Skill Checklist

• ✓Oracle Data Guard administration (switchover, failover, gap resolution)
• ✓GoldenGate Extract / Replicat configuration and CDC monitoring
• ✓OCI VCN architecture: subnets, route tables, security lists, NSGs
• ✓Azure ExpressRoute provisioning and BGP routing basics
• ✓AWS Direct Connect setup, virtual interfaces, and route propagation
• ✓OCI Vault for secrets management across multi-cloud
• ✓Azure Entra ID RBAC for Oracle DB @ Azure authentication
• ✗Bi-directional CDR conflict resolution (requires specialist engagement)
• ✗Cross-cloud FinOps — Azure + OCI + AWS cost attribution is not automatic

The Exadata X10M hardware in Azure and AWS datacenters, the sub-millisecond FastConnect/Direct Connect links, and the GoldenGate CDC hub in OCI combine into a topology that satisfies both operational and regulatory requirements simultaneously. The only architectures that fail are those designed on PowerPoint rather than tested network topologies. Build the interconnect, measure the latency, then make the Data Guard mode decision. Everything else follows from those two numbers.

Referemces:

https://docs.oracle.com/en-us/iaas/Content/multicloud/Oraclemulticloud.htm

https://docs.oracle.com/en-us/iaas/Content/database-at-aws/oaaws.htm

https://docs.oracle.com/en-us/iaas/Content/database-at-azure/oaa.htm

https://docs.oracle.com/en-us/iaas/Content/database-at-gcp/home.htm