Oracle MAA across multi-cloud extends Oracle's Maximum Availability Architecture beyond the single-cloud reference model into the cross-cloud world that most enterprise customers now operate. The original MAA reference architecture assumed Oracle Database on premises with a Data Guard standby across the customer's secondary data centre. The single-cloud version assumes Exadata Cloud Service in two OCI regions. The multi-cloud version assumes Oracle Database deployments across two or more hyperscaler boundaries — Database@AWS in one region, Database@Azure in another, OCI ExaCS in a third — with Active Data Guard and GoldenGate stitching them together.
This piece works the multi-cloud MAA architecture the way an Oracle insider sizing a cross-cloud HA proposal would work it: the MAA components first, the multi-cloud topology patterns second, the licensing footprint third, the network cost profile fourth, and the buyer-side decision framework last. For the broader Oracle multi-cloud BYOL framework see multi-cloud Oracle BYOL rules. For multi-cloud Oracle support paths see multi-cloud Oracle support paths.
The Oracle MAA components — what we are deploying
Real Application Clusters (RAC)
RAC provides intra-cluster high availability within a single Oracle Database deployment. RAC is bundled in Exadata Cloud Service, Database@AWS, Database@Azure, and Database@Google Cloud at the Licence Included rate; on customer-managed Oracle Database on hyperscaler compute, RAC requires the standard Oracle RAC option licence at the customer's existing list rate. RAC handles instance-level failover inside the cluster — node failure, planned maintenance, intra-cluster scaling. RAC does not provide cross-region or cross-cloud failover; that is the Active Data Guard layer.
Active Data Guard
Active Data Guard provides physical standby replication between Oracle Database deployments across distance — same region, different region, different cloud. Active Data Guard is a separately licensed Oracle Database option that must be licensed on both the primary and the standby database when the standby is actively used for read offload or open for query. The licence requirement is Processor-based, matched to the vCPU count of the primary and the standby. Active Data Guard is bundled into Exadata Database Service deployments through the per-ECPU-hour add-on rate ($0.14 – $0.18 per ECPU-hour at indicative published list).
Oracle GoldenGate
GoldenGate provides logical replication between Oracle Database instances across different Oracle Database versions, character sets, and platforms — and to non-Oracle targets where the use case calls for it. GoldenGate is a separately licensed Oracle product with a Processor metric similar to the Database options, requiring per-vCPU licence coverage at each replication endpoint. In multi-cloud MAA, GoldenGate is the typical choice when the source and target are different Oracle Database versions, when bidirectional replication is required, when zero-downtime migration is the use case, or when heterogeneous replication is required.
Oracle Data Guard (the free version)
Data Guard is the Oracle Database Enterprise Edition feature that provides physical standby replication without the Active Data Guard option. A standby database mounted as a closed-mount physical standby (used only for switchover, not open for read traffic) is covered by Data Guard at no incremental option cost beyond the Oracle Database Enterprise Edition licence. The buyer-side decision is whether the standby is used purely for switchover (Data Guard sufficient) or for read offload and reporting (Active Data Guard required). Most production MAA deployments use Active Data Guard to monetise the standby capacity for read traffic.
Oracle MAA reference architectures consistently default to Active Data Guard plus GoldenGate plus RAC plus the full option stack across primary and standby. The customer pays the licence cost on every component on every database. The buyer-side defence is to right-size the MAA components against the actual recovery objectives — many customers can defend a more economical architecture (Data Guard rather than Active Data Guard, GoldenGate only on critical replication paths, RAC only on Tier 1 workloads) without compromising the actual business recovery posture.
The multi-cloud MAA topology patterns
Pattern 1 — Active-passive across two clouds
The simplest multi-cloud MAA topology runs the primary Oracle Database deployment in one cloud (typically OCI ExaCS or Database@Hyperscaler in the customer's primary region) with an Active Data Guard standby in a different cloud. Failover is manual or automated through Data Guard switchover. The licence footprint is the primary database Processor or ECPU count plus the standby database Processor or ECPU count plus the Active Data Guard option on both sides. The network connectivity is the Interconnect or carrier-hotel path between the two clouds.
Pattern 2 — Active-active with GoldenGate
The active-active topology runs two Oracle Database deployments — typically one in OCI and one in Database@Hyperscaler — with bidirectional GoldenGate replication keeping the two synchronised. The pattern supports geographic load balancing of read and write traffic with eventual consistency. The licence footprint is the primary and secondary database Processor or ECPU count plus GoldenGate Processor coverage on both sides plus the per-vCPU option licences where applicable. The network connectivity carries the replication traffic both directions continuously.
Pattern 3 — Hub-and-spoke with multi-region standby
The hub-and-spoke topology runs a primary Oracle Database in one cloud (typically OCI) with multiple Active Data Guard standby databases across different regions and different clouds. Geographic replication serves regional reporting workloads and provides multi-region disaster recovery. The licence footprint is the primary database plus each standby database plus Active Data Guard on every node. The network connectivity is the multiple Interconnect or cross-cloud paths from the hub to each spoke.
Pattern 4 — Tier 1 multi-cloud cluster
The Tier 1 multi-cloud cluster combines RAC on the primary cluster (typically Exadata Database Service on Database@Hyperscaler), Active Data Guard to a standby cluster in a different cloud, and GoldenGate replication to a reporting layer on a different platform. The architecture supports zero-downtime maintenance, region-failure recovery, and read offload to the reporting layer simultaneously. The licence footprint is the most extensive — RAC, Active Data Guard, GoldenGate, and the supporting option stack across every endpoint.
The licensing footprint — what each topology costs
The figures above are indicative published list at the time of writing. Real enterprise pricing is heavily negotiated against the customer's broader Oracle commercial commitment. The BYOL economics on multi-cloud MAA deployments are particularly favourable — customers with material on-premise Processor and option licence inventory can deploy multi-cloud MAA at 60 – 70% below the Licence Included rate by carrying forward the existing inventory.
The network cost profile
Cross-cloud replication bandwidth
Multi-cloud MAA replication generates continuous cross-cloud network traffic in the redo stream (Active Data Guard) or the trail file stream (GoldenGate). The bandwidth requirement scales with the primary database write volume. A Tier 1 production database generating 2 TB of redo per day requires sustained 200 Mbps of cross-cloud bandwidth to maintain real-time apply. Peak windows (quarter-end batch, large data loads) can spike the requirement to 1 Gbps or higher.
Connectivity cost summary
The cross-cloud connectivity for multi-cloud MAA typically runs through Oracle Interconnect for Azure, the Oracle-Google managed Interconnect, or customer-established carrier-hotel connectivity for AWS-side paths. Combined 10 Gbps connectivity costs $2.5k – $4.5k per month depending on the cloud pair. For the connectivity options and pricing see Oracle Interconnect for Azure and Oracle Interconnect for AWS and GCP.
Cross-cloud egress charges
Cross-cloud replication traffic over the managed Interconnect generally bypasses standard egress charges, but the supporting traffic patterns (cross-cloud backup replication, multi-region observability data, application-tier cache invalidation) frequently bill at standard egress rates. The total network cost on a multi-cloud MAA deployment is typically $50k – $200k annually. For the egress detail see Oracle@Hyperscaler egress economics.
Designing Oracle MAA across multiple clouds — request a confidential architecture review.
We deliver the forensic MAA topology mapping, the licence footprint analysis, the BYOL inventory verification, the network cost projection, and the buyer-side commercial provisions to cap exposure. Independent of Oracle and hyperscaler commercial motions.
Engage Oracle cloud advisory →The buyer-side defence — right-sizing the MAA topology
Defence 1 — Match the topology to the actual recovery objectives
Most enterprise customers have differentiated recovery objectives across the application portfolio. Tier 1 workloads warrant the full MAA stack (RAC + Active Data Guard + GoldenGate, multi-cloud). Tier 2 workloads can be defended with Data Guard switchover (not Active Data Guard) and a single-cloud standby. Tier 3 workloads warrant a backup-and-restore recovery model without standby infrastructure. The maximalist Oracle Reference Architecture treats every workload as Tier 1 — the buyer-side defence is to differentiate.
Defence 2 — Challenge the Active Data Guard requirement
Active Data Guard is required when the standby is open for read traffic or actively used for reporting. A closed-mount physical standby used purely for switchover is covered by Data Guard at no incremental option cost. Customers using the standby purely for failover frequently licence Active Data Guard unnecessarily because the Oracle account team defaults to it. The defence is to map the actual standby usage and licence Data Guard where the standby is closed-mount.
Defence 3 — Right-size the GoldenGate footprint
GoldenGate licensing is per-vCPU at both the source and the target replication endpoint. Customers running GoldenGate across the full database footprint frequently overpay — most enterprise GoldenGate use cases are limited to specific tables or schemas with material business value. The defence is to scope GoldenGate to the actually-replicated workload and licence only the vCPUs that touch the GoldenGate streams.
Defence 4 — Carry forward on-premise option licences
The customer's on-premise Active Data Guard, GoldenGate, and RAC option licences carry forward into Database@Hyperscaler and ExaCS deployments through the standard BYOL conversion. The economic gain is material — a customer with 50 Processor licences of Active Data Guard on SULS can BYOL a 100-ECPU standby database into Database@Hyperscaler at zero incremental Active Data Guard cost. Inventory the existing option licences explicitly before signing.
Defence 5 — Defend the multi-cloud network cost
The network cost profile on multi-cloud MAA can be materially compressed by routing replication through the managed Interconnects (Azure, Google Cloud) rather than carrier-hotel paths, by scheduling backup replication into off-peak windows, and by aggregating the multi-region traffic through hub-and-spoke patterns rather than mesh patterns. The defence is to model the network architecture as a commercial input, not as a fixed infrastructure cost.
"Oracle MAA across multi-cloud is the most licensing-intensive architecture in the Oracle portfolio. Every option licenced twice, every Processor counted twice, every cross-cloud egress charge accruing in both directions. The buyer-side defence is to right-size the topology against the actual recovery objectives — and to challenge every component of the Oracle Reference Architecture against the cost it adds. Tier 1 deserves Tier 1 architecture; the rest of the portfolio rarely does."
An anonymised case study — Tier 1 European insurer, multi-cloud MAA right-sizing
A Tier 1 European insurer with €1.4bn of Oracle Database workloads ran a multi-cloud MAA architecture review in 2025 covering the core policy administration system, the claims processing system, and the actuarial reporting platform. The Oracle account team proposed a full Tier 1 multi-cloud MAA architecture across all three systems: RAC + Active Data Guard + GoldenGate, primary on OCI ExaCS Frankfurt, standby on Database@Azure West Europe, third copy on Database@Google Cloud europe-west3 for analytics. The proposed annual Universal Credits commitment was $18m across all three systems.
The buyer-side defence rebuilt the architecture against differentiated recovery objectives. The core policy administration system warranted the full Tier 1 MAA architecture — RAC + Active Data Guard + GoldenGate, primary OCI ExaCS Frankfurt, standby Database@Azure West Europe. The claims processing system warranted Tier 2 protection — RAC on the primary cluster, Data Guard (not Active Data Guard) physical standby in OCI Amsterdam, no GoldenGate, no third copy. The actuarial reporting platform warranted Tier 3 protection — single-cluster RAC, backup-and-restore recovery, no standby infrastructure.
The rebuilt architecture reduced the annual Universal Credits commitment from $18m to $11m — a $7m annual saving against the Oracle proposal — while improving the recovery posture by aligning the architecture with the actual business recovery objectives. The customer's existing on-premise Active Data Guard inventory (45 Processor licences on SULS) covered the standby Active Data Guard requirement at zero incremental cost. The GoldenGate footprint was scoped to the 12-ECPU subset of the policy administration database touching the analytics replication stream, rather than the 100-ECPU full deployment. For the broader Oracle licence optimisation framework see our Oracle licence optimisation service.
Designing or reviewing a multi-cloud MAA architecture — request a confidential briefing.
We deliver the forensic topology analysis, the licence footprint optimisation, the BYOL inventory verification, the network architecture cost model, and the buyer-side negotiation playbook to challenge the Oracle Reference Architecture default. Buyer-side only. Confidential.
Request a multi-cloud MAA briefing →Independent · Confidential · Not affiliated with Oracle Corporation
The five buyer-side moves on multi-cloud Oracle MAA
Move 1 — Differentiate the workload recovery objectives. Tier 1, Tier 2, and Tier 3 workloads warrant different MAA architectures. The defence is to map the actual business recovery requirement and licence the architecture against the requirement — not against the maximalist Oracle Reference Architecture.
Move 2 — Challenge the Active Data Guard default. Data Guard (without the Active Data Guard option) covers closed-mount physical standby for switchover. Active Data Guard is only required when the standby is open for read traffic. Map the actual usage and right-size the licence position.
Move 3 — Scope GoldenGate to the actually-replicated workload. GoldenGate is per-vCPU at both source and target. Scope to the specific tables and schemas that warrant replication, not the full database footprint.
Move 4 — Carry forward on-premise option licences into the cloud deployment. Active Data Guard, GoldenGate, and RAC option licences from the customer's on-premise inventory carry forward through BYOL. Inventory them before signing.
Move 5 — Model the network cost as a commercial input. Multi-cloud network costs on MAA deployments are non-trivial and frequently negotiable. The defence is to model the network architecture explicitly and challenge the inherited assumptions.
Many of the customers now planning multi-cloud MAA architectures are doing so to support 23ai workloads layering AI capabilities on top of the high-availability database tier — the supporting Oracle 23ai AI Vector Search licensing position, the Oracle Machine Learning OML licensing rules on self-managed Enterprise Edition, and the HeatWave GenAI licensing framework for MySQL-side equivalents all carry distinct commercial implications that compound against the multi-cloud architecture decision.