How to Run Active-Active Across AWS and Azure Without Paying for Idle Standby

Run both clouds live behind one health-checked global endpoint, size each location so the survivors can carry the full load when one fails, and put the data in a database built to run in more than one cloud. Two locations need 2× peak in total capacity to survive losing one; three equal locations need 1.5×, and keeping that ratio through the loss of a whole cloud takes a third provider. Control Plane, the unbreakable platform for production workloads, runs the same workload active-active in AWS and Azure regions from one definition, with routing, failover, mTLS, and autoscaling built in.

Disclosure: Control Plane publishes this guide.

TL;DR

Active-active across AWS and Azure means every location serves production traffic at all times. No location sits idle as a standby.

• Traffic. A global endpoint with health checks routes each request to the nearest healthy location. The routing layer must keep working when either cloud fails.
• Capacity. With two locations, each must be able to handle 100% of peak, so failover capacity totals 2× peak. Three equal locations need 1.5× to survive one location failure. Surviving the loss of a whole cloud needs the remaining cloud to carry 100% of peak. Autoscaling keeps steady-state spend below that ceiling, and minimum replica counts keep warm capacity for the first minutes of a failover.
• Data. Use a database designed for multi-cloud writes: distributed SQL such as CockroachDB or YugabyteDB with replicas in at least three failure domains, multi-master Postgres such as pgEdge, or writes partitioned by tenant. DynamoDB global tables and Azure Cosmos DB replicate within their own cloud only.
• Networking. Options range from public endpoints with mTLS to VPN, private circuits that meet at a colocation exchange, and AWS Interconnect multicloud with Azure, in public preview since August 31, 2026.
• Identity. AWS IAM roles and Microsoft Entra ID managed identities, bridged by workload identity federation so workloads in one cloud call the other without long-lived keys.
• Cost. You pay for failover capacity in every live location, cross-cloud data transfer, interconnect ports, two sets of managed services, and staff time to operate both environments.
• Control Plane. Deploy a workload to Control Plane’s Global Virtual Cloud (GVC), a named set of locations that can span AWS and Azure regions. Control Plane handles routing, failover, cross-cloud mTLS, autoscaling, and cloud identity from one definition.

What does active-active across AWS and Azure mean?

Both clouds run your production workloads at the same time, and each serves real user traffic. No location waits as a standby. Every location runs replicas that handle requests, so failover capacity is already warm and exercised by real traffic.

In active-passive, one cloud handles all traffic and the other waits as a failover target. A full-size hot standby provisions the same 2× peak compute as two-location active-active, but it serves no traffic until failover and needs a promotion step. A scaled-down standby costs less but must scale up during the outage. Our active-active versus active-passive cost model puts a hot-standby active-passive setup at about 1.62× the total bill of a single region, with nearly the whole second stack idle until a failover, and active-active at about 1.86×, with the difference coming from running a full read-write database copy in the second region.

How much extra capacity does active-active need?

Each surviving location must absorb the traffic of any location that goes down. With N equal locations, each must be able to carry 1/(N−1) of total peak traffic after losing one location, so total provisioned capacity equals N/(N−1) times peak.

The formula assumes the routing layer spreads a failed location’s traffic evenly across the survivors. Latency-based routing can send most of it to the nearest survivor, so size that location higher or cap per-location load. The formula covers losing one location. To survive losing a whole cloud, the locations left in the other cloud must carry 100% of peak.

Worked example

A service that needs 40 vCPU at peak with two locations (one AWS region, one Azure region) needs 40 vCPU in each location, 80 vCPU in total. With three locations, such as two AWS regions and one Azure region, each location needs 20 vCPU to survive one region failure, 60 vCPU in total. That saves 20 vCPU. It does not cover an AWS-wide outage, which would leave one Azure location at 20 vCPU facing 40 vCPU of load. Surviving a full cloud outage needs 40 vCPU in each cloud (80 total), or a third provider, where three equal locations on three clouds bring the total back to 60 vCPU.

At normal peak, each location runs at (N−1)/N of its failover ceiling: 50% with two locations, 67% with three. Off-peak, autoscaling can run it lower. Scaling up takes time: new replicas take seconds to start, and new nodes can take minutes. Keep enough warm capacity, through minimum replica counts, to absorb the first minutes of redirected traffic while autoscaling catches up.

This headroom sits on replicas that already serve traffic. It is underused in steady state: with two locations, about half of failover capacity is spare at peak. It is warm, proven by live requests, and needs no promotion step when a location fails.

How do I route traffic between AWS and Azure automatically?

The routing layer decides whether a failover reaches users, so it must keep working when either cloud fails. If the global endpoint lives only in AWS and AWS goes down, healthy Azure workloads become unreachable. Options include:

• Control Plane ’s built-in global endpoint, which routes each request to the nearest healthy location and moves traffic automatically when a location fails, with no routing layer for you to run in either cloud.
• Third-party global load balancers or DNS services that operate independently of AWS and Azure.
• Amazon Route 53 with health checks and latency-based routing. Latency data comes from AWS data centers, so Azure endpoints are tagged with the nearest AWS Region. This creates a dependency on AWS.
• Azure Front Door or Azure Traffic Manager , which accept non-Azure endpoints such as AWS load balancers and create a dependency on Azure.

Attach health checks to every routing record. Weighted routing with health checks drops unhealthy endpoints, but weights are static, so latency or priority routing is usually a better fit for sending users to the nearest healthy location. DNS-based failover is also bounded by record TTL and client caching, so set short TTLs or use an anycast or proxy-based endpoint.

Health checks must go deeper than a TCP connect. Check the application path and the dependencies local to that location, such as its database replica. A location that returns HTTP 200 but cannot reach its database is not healthy. Keep shared global dependencies out of the routing health check, or every location fails together during that dependency’s outage. Probe from several vantage points outside both clouds, and configure the router to fail open when all locations report unhealthy.

Which databases can run active-active across AWS and Azure?

The data layer is the hardest part of any active-active architecture. Stateless compute can be replaced in any location. Data must be replicated and kept consistent across clouds.

Synchronous cross-cloud writes add latency. In a consensus cluster, each write waits for a majority of replicas, so it adds at least the round trip from the leader to the nearest other replica, plus the round trip to the leader when the request lands in a different cloud. Measure that round trip between your own regions before choosing synchronous writes. A cluster that spans only one AWS region and one Azure region cannot keep quorum if the cloud holding the majority of replicas fails, so add a third location or a witness node on another provider. For latency-sensitive workloads, partitioning writes by tenant or geography keeps writes local when requests reach the tenant’s home cloud. See building active-active high availability across regions and clouds for data layer patterns.

How do I connect AWS and Azure for active-active?

Cross-cloud networking sets the latency, security, and cost of traffic between your AWS and Azure workloads.

For many active-active deployments, public endpoints with mTLS are enough and avoid the cost and work of private interconnects. As cross-cloud traffic grows or compliance requirements tighten, a dedicated interconnect becomes worthwhile. See cross-cloud private networking options for VPC-to-VNet patterns.

How do I handle identity across AWS and Azure?

Running in two clouds means two identity systems. AWS uses IAM roles. Azure uses Microsoft Entra ID managed identities and app registrations. Each cloud’s managed services expect credentials from their own identity provider.

Workload identity federation bridges the two without long-lived keys. After you enable IAM outbound identity federation on the account, a workload in AWS calls the STS GetWebIdentityToken API for a signed JWT and exchanges it at the Microsoft identity platform for a short-lived Entra access token. To set that up, add a federated identity credential on an Entra user-assigned managed identity or app registration that trusts your AWS account’s issuer URL. In the other direction, you register your Entra tenant as an IAM OIDC identity provider in AWS, and an Azure workload passes its Entra-issued token to AssumeRoleWithWebIdentity to get temporary AWS credentials. See workload identity federation for configuration in both directions.

What does it cost?

Active-active across AWS and Azure has five main cost drivers.

• Live compute capacity. The failover ceiling follows the capacity table. Autoscaling keeps steady-state spend below it, and minimum replica counts for warm headroom set the floor.
• Cross-cloud data transfer. Every byte that moves between AWS and Azure incurs egress charges from the sending cloud. Database replication, service-to-service calls, and cache synchronization all add to it.
• Interconnect ports. Direct Connect, ExpressRoute, and exchange ports and cross-connects are billed monthly whatever the traffic.
• Two sets of managed services. Managed databases, caches, queues, or object stores in both clouds mean paying both providers.
• Staff time. Operating two clouds takes familiarity with two sets of tooling, two identity systems, two networking models, and two billing structures.

See adding a second cloud provider for failover without doubling ops for ways to control operational overhead.

How does Control Plane run active-active across AWS and Azure?

Control Plane runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, and Azure. VM workloads run on locations joined through Control Plane’s Managed Kubernetes. Workloads can also run on Kubernetes clusters you already operate or on your own machines, including on premises, in the same active-active GVC. Control Plane handles Day 2 operations, including autoscaling, built-in observability, and security, with no Kubernetes cluster you have to operate in Control Plane-managed regions.

A workload deployed to a GVC runs active-active in every location of that GVC from one definition, and a GVC can include AWS regions and Azure regions together. Adding a region or another cloud means adding a location to the GVC, and Control Plane deploys every workload in the GVC there. Going from two locations to three is one change to the GVC’s location list. To realize the drop in total capacity from 2× to 1.5× peak, you then lower each workload’s minimum and maximum replica counts to match the smaller per-location failover share, and database replicas need their own placement in the new location.

The global endpoint fails traffic over between locations automatically, routing by priorities and latency. Internal traffic between workloads uses mTLS, every workload has a deny-by-default internal firewall, and workloads in different clouds reach each other without VPC peering or VPN tunnels you manage.

Autoscaling per location works on concurrency, requests per second, CPU, memory, or latency, with a minimum and maximum replica count you set. The minimum is how you keep warm headroom for a failover.

Control Plane’s Universal Cloud Identity gives workloads access to 600+ AWS, GCP, and Azure services with no long-lived cloud keys in your code. For the data layer, 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 the GVC.

The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be on different providers. You pay for the CPU and memory a workload reserves, with no contracts or minimums. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

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.

See running the same app on AWS, GCP, and Azure for the single-definition deployment model.

FAQ

Answers assume equal-size locations and the loss of one location unless stated.

How do I run active-active across AWS and Azure without paying for idle standby capacity?

Run both clouds at once behind a health-checked global endpoint so every location serves production traffic. Size each location to absorb the load of a failed one, and use autoscaling with minimum replica counts to keep warm capacity for the first minutes of a failover. Store data in a database that supports multi-cloud writes, such as CockroachDB or YugabyteDB with replicas in at least three failure domains, or partition writes by tenant.

How much extra capacity does active-active need to survive losing one cloud?

With two clouds, surviving the loss of one cloud needs 2× peak in total, because the remaining cloud must carry 100% of peak. Adding regions inside each cloud lowers the size of each region but not that 2× total. For single-location failures, N equal locations need N/(N−1) times peak: 2× at two, 1.5× at three, 1.33× at four.

Is active-active across AWS and Azure more expensive than active-passive?

Usually somewhat, but not because of compute. Two-location active-active and a full-size hot standby both provision 2× peak compute; active-active costs more mainly because the second location runs a full read-write database copy instead of a replica. Our cost model puts hot standby at about 1.62× a single region and active-active at about 1.86×. A scaled-down standby costs less but recovers more slowly because it must scale up during the outage. Active-active’s advantage is recovery: the surviving location already serves traffic, so failover needs no promotion or warm-up. Both models add cross-cloud data transfer and dual managed services.

Which databases can run active-active across AWS and Azure?

Distributed SQL databases such as CockroachDB and YugabyteDB use consensus for strong consistency across clouds and need replicas in at least three failure domains to keep quorum when one cloud fails. Multi-master Postgres such as pgEdge uses asynchronous replication with conflict resolution. DynamoDB global tables and Azure Cosmos DB multi-region writes replicate within their own cloud only. Partitioning writes by tenant or geography keeps writes local when requests reach the tenant’s home cloud.

How do I connect AWS and Azure privately?

Use AWS Direct Connect and Azure ExpressRoute meeting at a colocation exchange such as Equinix Fabric or Megaport, or a site-to-site VPN. AWS and Microsoft also offer AWS Interconnect multicloud with Azure (Azure Multicloud Interconnect on the Microsoft side), a private connection provisioned on demand without a colocation intermediary, in public preview since August 31, 2026 in four AWS regions. For many workloads, public endpoints secured with mutual TLS are enough.

Do I need Kubernetes on both clouds?

No. Kubernetes on both clouds (EKS on AWS, AKS on Azure) is a common approach for running stateless compute active-active. On Control Plane, you deploy workloads to a GVC spanning both clouds from one definition. In Control Plane-managed AWS and Azure regions there is no Kubernetes cluster you have to operate, and no separate Helm releases or cloud-specific deployment pipelines per environment. Teams that want Kubernetes can still run it through Control Plane’s Managed Kubernetes (MK8s) or connect clusters they already operate.

How do I test failover between AWS and Azure?

Run scheduled failover drills that simulate the loss of one cloud. Fail the location itself, for example by stopping its workloads or blocking its network, so health checks have to detect the failure. Verify that the global endpoint redirects all traffic to surviving locations within your target recovery time. Confirm that autoscaling adds replicas, that the database keeps quorum or replication has converged, and that sessions stored in a replicated store or signed tokens survive. Measure the error rate for in-flight requests during the cutover, since requests in progress at the failed location fail.

How does Control Plane run active-active across AWS and Azure?

Deploy your workload to a Global Virtual Cloud (GVC), Control Plane’s named set of locations, that includes AWS and Azure regions. Control Plane deploys the workload to every location in the GVC from one definition, routes requests to the nearest healthy location, handles cross-cloud mTLS and internal firewalling, and autoscales per location based on the metrics and minimum replica counts you set. Control Plane also handles Day 2 operations such as built-in observability and security.

Can I start with two locations and add more later?

Yes. Start with one AWS region and one Azure region in your GVC. Adding a third location cuts total capacity for a single-location failure from 2× to 1.5× peak, and the new location gets every workload in the GVC automatically. Then lower each workload’s minimum and maximum replica counts to match the smaller per-location failover share. To keep that ratio through a full cloud outage, put the third location on a third provider.

Does a GVC that spans AWS and Azure qualify for Control Plane’s 99.999% SLA?

Yes. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, and those locations can be on different providers, such as one AWS region and one Azure region.

To run active-active across AWS and Azure from one definition, talk to the Control Plane team or sign up free.

Originally published on the Control Plane blog.