An active-active multi-region, multi-cloud reference architecture has six layers: global routing, ingress, stateless compute, data, cross-cloud networking and identity, and operations. Every location serves live production traffic simultaneously, and the design is only as available as its data layer and its routing. This guide breaks the architecture into its six layers, maps each layer against five failure scopes from a single instance crash to losing an entire cloud provider, and provides the capacity math that determines how many locations you actually need.
Disclosure: Control Plane publishes this guide.
TL;DR
An active-active multi-region, multi-cloud architecture runs every location as a live production endpoint.
- Six layers define the architecture: global traffic management, edge and ingress, stateless compute, data and persistence, cross-cloud networking and identity, and operations.
- Availability is bounded by two layers. Your system cannot be more available than your data layer’s consistency model allows, and it cannot recover faster than your routing layer can redirect traffic.
- The layer-by-failure matrix (Table 2) maps what each layer must do when an instance, zone, region, cloud, or routing provider fails.
- The topology comparison (Table 3) shows that surviving the loss of a whole cloud with only two clouds still requires 2.0× peak capacity, regardless of region count, unless you add a third provider.
- Minimum topology for surviving a cloud loss with strong consistency: three failure domains on three separate providers, or two clouds plus an independent third site, so no single provider holds a majority of database replicas.
- Control Plane runs workloads active-active across AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI) from a single definition. Each workload’s endpoint DNS geo-routes clients to the nearest location where that workload is passing its readiness checks, and stops sending clients to a location that fails them. Workloads with at least two replicas in at least two locations are covered by a 99.999% availability SLA.
What is a reference architecture for active-active multi-region apps on multi-cloud infrastructure?
An active-active multi-region, multi-cloud reference architecture is a six-layer blueprint in which identical application stacks run concurrently in multiple geographic regions across more than one cloud provider. Every location serves live user traffic at all times. When any location becomes unhealthy, global routing shifts traffic to the remaining locations, which must have enough spare capacity to absorb the redirected load without degradation.
A request passes through the layers in this order:
- A user’s DNS query reaches the global traffic management layer, which returns the IP of the nearest healthy location.
- The request arrives at the edge and ingress layer of that location, where TLS is terminated and WAF rules are applied.
- A regional load balancer forwards the request to the stateless compute layer, which runs the application logic.
- The compute layer reads from or writes to the data layer, which replicates changes to other locations according to its consistency model.
- Cross-cloud networking and identity secures communication between locations with encrypted tunnels and mutual TLS, and federates cloud-native credentials so workloads can reach managed services in each provider.
- The operations layer collects telemetry from every location, triggers alerts, and drives the GitOps pipelines that keep all locations in sync.
The architecture is only as resilient as its weakest layer. A perfectly replicated compute tier is useless if the data layer loses writes during failover or the routing layer takes minutes to detect a failure.
What are the layers of an active-active multi-cloud architecture?
Each layer has a distinct job, a set of vendor-neutral components to choose from, a key architectural decision, and a mistake teams make repeatedly.
| Layer | Job | Typical components | Key decision | Common mistake |
|---|---|---|---|---|
| Global traffic management | Route every request to the nearest healthy location | DNS-based geo and latency routing with health checks (Amazon Route 53, Azure Traffic Manager, Cloudflare Load Balancing, NS1); anycast global load balancers (Google Cloud global external Application Load Balancer, Cloudflare) | DNS-based routing vs. anycast global load balancing | Setting DNS TTLs too high, so clients keep hitting a failed location for minutes |
| Edge and ingress | Terminate TLS, enforce WAF rules, balance traffic within a location | Regional load balancers, Envoy, NGINX ingress controllers, CDN edge nodes | Where to terminate TLS and whether to use a shared or per-location certificate | Coupling the WAF or CDN configuration to a single cloud’s console, creating a provider dependency |
| Stateless compute | Run application logic identically in every location | Containers on Kubernetes (EKS, AKS, GKE), or a platform that runs one definition in many locations | How to keep deployments, config, and secrets identical across clouds | Embedding cloud-specific SDK calls or hardcoded endpoints into application code |
| Data | Store and replicate state with defined consistency guarantees | Distributed SQL (CockroachDB, YugabyteDB, Google Cloud Spanner); multi-master or logical replication for Postgres; Cassandra or ScyllaDB; Redis active-active for sessions; object storage replication | Consistency model: strong consensus vs. async replication with a defined RPO | Assuming a two-location consensus cluster can survive losing one location for writes (losing the location that holds the replica majority loses quorum) |
| Cross-cloud networking and identity | Encrypt traffic between locations, federate identities, manage secrets | Private interconnects, IPsec or WireGuard tunnels, service mesh with mTLS (Istio, Linkerd, or Cilium, whose mutual authentication is in beta); workload identity federation per cloud; secrets replicated per location | Whether to build your own mesh or use a managed cross-cloud network | Storing long-lived cloud keys in environment variables instead of using workload identity federation |
| Operations | Observe, deploy, test, and recover | OpenTelemetry, Prometheus and Grafana, GitOps with Argo CD or Flux, scheduled failover drills | Single pane of glass vs. per-cloud observability stacks | Never running a failover drill, so the first real outage is also the first test |
Global traffic management
The global traffic management layer is the front door. It must detect an unhealthy location and stop sending traffic there. DNS-based routing is the most portable option because every cloud and every third-party DNS provider supports it, but it is subject to client-side DNS caching. If a client holds a cached DNS answer past the TTL, it will keep trying the failed location until the cache expires. Anycast global load balancers avoid this problem because they route at the network layer, but they are tied to a single provider’s infrastructure. Teams that need both portability and fast failover often place an anycast CDN or global load balancer in front of DNS-based routing.
Edge and ingress
This layer handles TLS termination, request filtering, and regional load balancing. The key trade-off is between centralizing edge policy in a single CDN or WAF provider, which is simpler to manage, and distributing it per cloud, which avoids a single-provider dependency at the edge. A regional load balancer within each location distributes traffic across compute replicas and provides the health-check endpoint that the global routing layer probes.
Stateless compute
Stateless services are the easiest layer to make active-active. If the application stores no local state, you can run identical copies in every location. Container orchestration platforms like Kubernetes provide a consistent deployment model across clouds. The honest trade-off is that “stateless” is aspirational for many services. Session affinity, local caches, and in-memory queues all introduce soft state that must be handled explicitly during failover.
Data
Data is the hardest layer. A consensus-based distributed database like CockroachDB or YugabyteDB can provide strong consistency across locations, but it needs a majority of replicas available to accept writes. In a two-location cluster one location must hold the replica majority, so losing that location stops writes. Asynchronous replication with Postgres logical replication or Cassandra can tolerate a location loss without blocking writes, but recent writes that have not yet replicated may be lost. The multi-region database and failover guide covers these trade-offs in detail.
Cross-cloud networking and identity
Traffic between locations must be encrypted and authenticated. A service mesh with mTLS handles east-west traffic within and between locations. Cross-cloud connectivity options range from private interconnects, which offer low latency and predictable bandwidth, to IPsec or WireGuard tunnels over the public internet, which are cheaper but less predictable. Workload identity federation lets services authenticate to each cloud’s APIs without long-lived keys. Secrets like database credentials must be replicated to every location, ideally through a secrets manager that supports multi-region replication. More detail on connecting clouds privately is in the cross-cloud private networking guide.
Operations
Observability must span every location and every cloud. OpenTelemetry provides a vendor-neutral telemetry pipeline. GitOps tools like Argo CD or Flux ensure that every location converges to the same desired state. Schedule failover drills. Until a location withdrawal has been tested, the architecture’s failure behavior is unknown.
What must each layer do when an instance, zone, region, or cloud fails?
Each cell states what a layer must do at one failure scope. The last column covers the routing or DNS provider itself. If your global routing depends on a single DNS provider and that provider goes down, none of your health checks or failover logic will execute. Mitigating this requires authoritative DNS hosted at two independent providers.
| Layer | Instance fails | Zone fails | Region fails | Whole cloud provider fails | Routing or DNS provider fails |
|---|---|---|---|---|---|
| Global traffic management | No action needed; instance-level health is handled below | No action needed if the region’s endpoint remains healthy | Health check withdraws the region; clients still holding cached DNS answers keep trying it until their cache expires, which can be later than the TTL | Same as region fails, but all regions in that cloud are withdrawn simultaneously | Routing itself is down; clients resolve stale DNS or fail; mitigation requires a second authoritative DNS provider |
| Edge and ingress | Load balancer stops sending traffic to the failed instance | Load balancer drains the failed zone’s backends | Entire regional ingress is offline; global routing must redirect | All ingress endpoints in that cloud are offline | Edge still works per-location, but no new clients can be routed to it |
| Stateless compute | Orchestrator reschedules the container on a healthy node | Orchestrator reschedules across remaining zones in the region | All replicas in the region are lost; surviving regions must have enough replicas to handle redirected traffic | All replicas in that cloud are lost | Compute is unaffected, but it receives no new traffic if routing is down |
| Data | Database promotes a replica or the consensus group continues without the lost member | Database continues with replicas in surviving zones; no data loss if synchronous replication is used within the region | Consensus database: needs a majority of replicas in surviving locations to continue writes; async replication: recent un-replicated writes may be lost | Same as region fails, applied to every region in that cloud; a two-location consensus cluster across two clouds loses write availability if the cloud holding the replica majority fails, or if either cloud fails when replicas are split evenly | Data layer is unaffected; internal traffic keeps flowing if it does not resolve through the failed provider |
| Cross-cloud networking and identity | Mesh routes around the failed instance | Mesh routes around the failed zone | Tunnels or interconnects to the failed region are down; surviving locations must already have direct connectivity to each other | All tunnels terminating in that cloud are down; workloads in surviving clouds must not depend on that cloud’s identity service or secrets store | Networking and identity between locations are unaffected if they do not resolve through the failed provider |
| Operations | Alert fires; auto-healing resolves it | Alert fires; dashboards show zone-level degradation | Alert fires; runbook or automation withdraws the region from routing; post-incident review | Alert fires; all dashboards sourced from that cloud’s monitoring may be unavailable; observability must be hosted outside the failed cloud or in multiple clouds | Alerting on the routing provider itself must come from an independent monitoring system |
A two-location consensus cluster deserves emphasis. If you deploy a database like CockroachDB across exactly two locations, losing the location that holds the replica majority stops writes. With an even split, losing either location stops writes. Surviving a location loss for writes requires at least three failure domains.
Which topology should you choose?
| Topology | Minimum locations | Survives | Spare capacity needed to survive losing one location | Data pattern that fits | Main trade-off |
|---|---|---|---|---|---|
| Two regions in one cloud | 2 | One region failing | 2.0× peak (each location must carry full peak alone) | Async replication with defined RPO, or single-writer with read replicas | Cannot survive a cloud-wide outage; 2.0× capacity cost |
| Three regions in one cloud | 3 | One region failing with quorum intact | 1.5× peak | Consensus-based distributed SQL (three-node quorum) | Still single-cloud; cannot survive a provider-wide failure |
| Two clouds with one region each | 2 | One cloud failing | 2.0× peak | Async replication; consensus stops writing if the majority cloud fails | True multi-cloud, but 2.0× cost and no quorum for strong consistency |
| Two clouds with two regions each | 4 | One region failing, or one cloud failing if the surviving cloud can carry peak | 1.33× peak for a region loss; 2.0× for a cloud loss (the surviving cloud must carry full peak) | Async replication for cloud loss; a consensus cluster split two and two loses quorum when either cloud fails | Complex networking; 2.0× capacity still needed for cloud-loss survival |
| Three failure domains on three separate providers (or two clouds plus an independent third site) | 3 | Any one provider failing with quorum intact | 1.5× peak if all three sites serve traffic; 2.0× if the third site only holds a quorum replica | Consensus-based distributed SQL with one replica site per provider | Minimum topology for strong consistency that survives a cloud loss; a third provider adds networking and operations work |
Surviving the loss of a whole cloud requires enough capacity in the remaining clouds to carry peak alone. With only two clouds, that means 2.0× peak capacity regardless of how many regions you have in each cloud. Adding a third cloud or a third independent failure domain brings the multiplier down to 1.5× when that domain also serves an equal share of traffic.
Decision guide by requirement:
- Survive a region failure with strong consistency: three regions in one cloud (1.5× capacity).
- Survive a cloud failure with eventual consistency: two clouds, async replication, 2.0× capacity.
- Survive a cloud failure with strong consistency: three failure domains on three separate providers, or two clouds plus an independent third site, 1.5× capacity if all three sites serve traffic and 2.0× if the third site only holds a quorum replica.
- Data residency constraints: place failure domains within the required jurisdictions; this may force specific region choices that limit topology options.
The active-active vs. active-passive cost comparison covers the financial trade-offs in more depth.
How do you handle data in an active-active multi-cloud design?
Data consistency is the defining constraint of any active-active architecture. Every other layer can be made location-independent with enough engineering effort. Data cannot, because physics imposes a latency floor on cross-region communication and the CAP theorem forces a choice between consistency and availability during a network partition.
Consistency choices
- Consensus across three failure domains. Databases like CockroachDB, YugabyteDB, and Google Cloud Spanner use Raft or Paxos to maintain strong consistency. They need a majority of replicas to commit a write, so three failure domains is the minimum for surviving one domain’s loss.
- Async replication with a defined RPO. Postgres logical replication, Cassandra, and ScyllaDB can replicate asynchronously. Writes committed at the origin are visible at other locations after a delay. If the origin fails before replication completes, those writes are lost. The Recovery Point Objective (RPO) quantifies the acceptable data loss window. The RTO and RPO budget guide explains how to set these targets.
- Conflict resolution. Multi-writer systems must handle concurrent writes to the same key. Last-write-wins (LWW) is simple but silently discards one write. Conflict-free Replicated Data Types (CRDTs) merge concurrent updates deterministically but only work for specific data structures like counters, sets, and registers.
- Partitioning users by home region. Assigning each user a home region for writes and serving reads from local replicas avoids most write conflicts. Writes for each user still go to one region, which simplifies the data layer while keeping reads local.
What to keep regional. Session state, shopping carts, and ephemeral caches do not need global replication. Keeping them regional reduces cross-region replication traffic and avoids unnecessary conflict resolution.
Egress cost as a design input. Cloud providers charge for data leaving their network. Cross-cloud replication generates egress on every write. For write-heavy workloads, egress cost can dominate the infrastructure bill. Treat it as an architecture input; it can push you toward partitioning writes by region or batching replication. The multi-cloud networking platforms comparison covers connectivity options that can reduce egress costs.
How do you test an active-active architecture?
Testing must be scheduled, automated where possible, and run under realistic production load.
Failover drill checklist
- Withdraw one location from the global routing layer under production-like load and verify that traffic shifts to surviving locations within the expected time.
- Block all connectivity to a whole cloud provider’s regions and confirm that the remaining clouds absorb traffic without errors.
- Take the primary authoritative DNS provider out of service and confirm the secondary keeps answering.
- Partition two clouds from each other while both stay reachable by clients, and verify the minority side rejects writes and no split-brain writes land.
- Fail the database leader node and measure how long writes are unavailable and whether any writes are lost.
- Measure client reconnect behavior, including how long clients hold stale DNS answers and retry against the failed location.
- Verify that surviving locations have enough capacity headroom to handle the redirected load without autoscaling delays causing errors.
- Confirm that observability and alerting continue to function when the failed location hosted part of the monitoring stack.
Run these drills on a schedule, such as quarterly, and after every major architecture change. Document every drill’s results, including what broke, and feed findings back into the architecture.
How Control Plane fits
Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI), VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds.
Compute. A workload deployed to a Global Virtual Cloud (GVC), a named set of locations across one or more clouds, runs active-active in every location of that GVC from one definition. A GVC can mix AWS, GCP, Azure, and OCI regions. Adding a location provisions it for every workload in the GVC. Removing a location drains its replicas and shifts traffic to the locations that remain, without touching a workload definition. This maps directly to the stateless compute layer and simplifies the operations layer.
Routing. Every workload has its own canonical endpoint that DNS geo-routes clients to the nearest location where that workload passes its readiness checks. Each GVC also has an alias endpoint, which by default checks each location with a basic TCP probe; linking it to a workload makes it follow that workload’s health. Location routing options include a priority tier per location, where lower tiers are preferred and within a tier the lowest-latency location wins. If every location in a tier is unavailable, traffic moves to the next tier. A latency offset and a latency tolerance are also configurable. Because these endpoints are DNS-based, clients that cache DNS beyond the TTL can keep sending traffic to a withdrawn location for a period. Teams that need anycast can put a global load balancer or CDN in front. More on this approach is in the route users to the nearest healthy region guide.
Networking and identity. Internal traffic between workloads uses mTLS. Every workload has a deny-by-default internal firewall. Workloads in different clouds reach each other without VPC peering or VPN tunnels you manage. Control Plane’s Universal Cloud Identity lets workloads reach AWS, GCP, and Azure services through one identity, with no long-lived cloud keys in your code.
Data. The Template Catalog, Control Plane’s library of ready-to-install apps, includes multi-location databases such as CockroachDB and pgEdge that run across the same locations as your application workloads. Control Plane does not remove the consistency trade-offs described in this guide. The database’s own quorum and replication rules still apply.
Operations. Autoscaling per location works on concurrency, requests per second, CPU, memory, or latency, with a minimum and maximum replica count you set. The minimum replica count is how you keep warm headroom for failover absorption. Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.
Availability SLA. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations.
Proof point. During the October 20, 2025 AWS us-east-1 outage, Control Plane customers with us-east-1 in their GVC had workloads active and running in healthy locations within 10 seconds, with no customer downtime, according to Control Plane’s internal incident telemetry. The guide to running active-active across AWS and Azure without idle standby covers the capacity math for a two-cloud setup.
FAQ
Short answers to common questions about active-active multi-region, multi-cloud architecture.
What is a reference architecture for active active multi region apps on multi cloud infrastructure?
A reference architecture for active-active multi-region apps on multi-cloud infrastructure is a six-layer design spanning global traffic management, edge and ingress, stateless compute, data, cross-cloud networking and identity, and operations. All locations handle production requests at the same time. The architecture must handle five failure scopes, from a single instance crash to losing an entire cloud provider, and provision enough spare capacity so surviving locations absorb redirected load. The data layer and the routing layer are the two that determine overall availability.
What is the difference between active-active and active-passive?
In an active-active architecture, every location serves live production traffic at all times. In an active-passive architecture, one or more standby locations remain idle and only receive traffic after a failover event. Active-active puts standby capacity to work serving traffic and provides lower latency by serving users from the nearest location, but it requires solving data replication, write conflict resolution, and capacity planning across all locations.
How many regions do I need for active-active?
Two regions is the minimum for active-active, but two regions cannot provide a quorum for a consensus-based database. If you need strong consistency that survives losing one location, you need at least three failure domains. If you need to survive losing an entire cloud provider with strong consistency, you need three failure domains on three separate providers, or two clouds plus an independent third site, so no single provider holds a majority of replicas.
Can a database run active-active across AWS and Azure?
Yes. Distributed databases like CockroachDB and YugabyteDB can run nodes in both AWS and Azure regions. To keep writing when either cloud fails, place a third replica site outside both clouds so neither provider holds a majority. The database’s consensus protocol works across clouds as long as network latency between nodes is acceptable for your write-latency requirements. Cross-cloud replication adds latency to every consensus round, so write-heavy workloads should benchmark carefully. Async replication with Postgres logical replication is another option that avoids cross-cloud consensus latency at the cost of a defined RPO.
How do I route users to the nearest healthy region?
DNS-based geo-latency routing is the most portable approach. Services like Amazon Route 53, Azure Traffic Manager, Cloudflare Load Balancing, and NS1 return the IP of the nearest healthy location based on the client’s resolver location, or the client’s subnet when the resolver sends EDNS Client Subnet. Anycast global load balancers route at the network layer and avoid DNS caching delays but are tied to a single provider. Some architectures combine both: an anycast CDN or global load balancer in front, with DNS-based routing as a fallback.
What happens to DNS-based routing when a region fails?
The DNS provider’s health checks detect the failure and stop returning the failed region’s IP in DNS responses. However, clients and recursive resolvers that have cached the previous DNS answer will continue sending traffic to the failed region until the cached entry expires, which can be later than the TTL when resolvers or clients ignore it. Short TTLs reduce this window but increase DNS query volume. Teams that cannot tolerate any misdirected traffic during the TTL window should use an anycast global load balancer in front of DNS.
How much extra capacity does active-active need?
Total capacity must be N/(N-1) times peak, where N is the number of equal locations, because each location must carry peak divided by N-1 after one fails. Two locations require 2.0× peak capacity total. Three locations require 1.5×. Four locations require 1.33×. Surviving the loss of a whole cloud with only two clouds still requires 2.0× peak in total, because the surviving cloud must carry 1.0× peak alone, regardless of how many regions each cloud has. Additional headroom is needed for autoscaling ramp-up time, cache warm-up, and replication traffic.
Do I need Kubernetes for a multi-cloud active-active architecture?
No. Kubernetes is the most common compute substrate for multi-cloud active-active because it provides a consistent deployment model across AWS (EKS), Azure (AKS), and GCP (GKE). Any platform that can run the same workload definition identically in multiple locations across multiple clouds will work. What matters is deployment consistency.
How does Control Plane run active-active across regions and clouds?
Control Plane’s Global Virtual Cloud (GVC) lets you define a set of locations spanning AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI) regions. Every workload deployed to a GVC runs active-active in every location from a single definition. Each workload’s endpoint DNS geo-routes clients to the nearest location where that workload passes its readiness checks. When a location stops passing them, clients are routed to the remaining healthy locations. Autoscaling per location with a minimum replica count you set keeps warm headroom available for failover. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations.
To run active-active across regions and clouds without building the platform yourself, talk to the Control Plane team or sign up free.
