How to Add a Second Cloud Provider for Failover Without Doubling Your Ops Work

You avoid doubling ops work by keeping one deployment workflow, one identity and secrets model, one observability stack, and one on-call process for both providers, and by changing only the provider-specific layer underneath. The second provider should be a target your existing pipeline deploys to, not a second stack your team runs. On Control Plane, adding a second cloud means adding a location to a Global Virtual Cloud (GVC), Control Plane’s set of locations where a workload runs, and the same workload definition runs active-active on both providers.

Disclosure: Control Plane publishes this guide.

TL;DR

• What doubles and what does not. Infrastructure definitions gain a second provider module. Deployments, identity, observability, on-call, and compliance processes stay single if you standardize the operational layer. Kubernetes upgrades and networking double unless a platform takes them over.
• Warm standby vs. active-active. Warm standby is cheaper at rest but slower to recover, and a rarely used standby can fail when you need it. Active-active keeps serving capacity on both providers, with autoscaling holding it close to real traffic, and makes failover a routing change for stateless tiers with no cold start.
• The data layer. Async replication of a single primary is simplest. Distributed SQL databases such as CockroachDB or YugabyteDB can span providers when self-hosted, and need replicas in at least three failure domains to survive losing one provider. Object storage needs a sync tool, and backups restored on the other provider recover the slowest.
• Traffic routing. A global routing layer outside either provider, or health-checked DNS with low TTLs and client retries, steers traffic to healthy locations without manual intervention.
• The phased plan. Pick one critical service, containerize it, unify your pipeline and identity, replicate data, deploy to the second provider, send it traffic, drill failover and failback, and expand service by service.
• How Control Plane fits. Control Plane’s GVC lets you add a location on another provider and run the same workload definition active-active in every location from one deployment, with multi-location database templates for the data tier.

How do I add a second cloud provider for failover without doubling my ops work?

Standardize the operational layer and isolate provider differences in a thin substrate. Your deployment pipeline, identity model, secrets management, observability stack, alerting rules, compliance evidence process, and on-call rotation should all be provider-agnostic. The parts that change when you add a second provider are the infrastructure modules that provision resources there and the networking that connects them.

When teams skip this step, they end up running two parallel stacks with two sets of dashboards, two alerting configurations, two identity systems, and two on-call rotations. That is what doubles ops work, and it is avoidable.

This ops work ledger compares each operational task across three approaches: two fully native stacks, shared tooling (Terraform or OpenTofu plus Kubernetes plus GitOps), and a platform that abstracts providers, described here as Control Plane implements it.

Operational task	Two native stacks	Shared tooling (IaC + Kubernetes + GitOps)	Platform that abstracts providers (Control Plane)
Infrastructure definitions	Doubles: separate IaC per provider	Partially doubles: shared modules, provider-specific resources	Single workload definition; provider details handled by the platform
Deployments and CI/CD	Doubles: separate pipelines per provider	Stays single: one pipeline targets both clusters	Stays single: one deploy to multiple locations
Kubernetes clusters or runtimes to upgrade	Doubles: two clusters, two node pool lifecycles	Doubles: two clusters, two sets of node pools and upgrades	Removed on Control Plane-managed locations, where there is no cluster to operate; still yours only on clusters you choose to bring
Identity and secrets	Doubles: separate IAM policies and secret stores	Stays single if federated, but roles must be mapped across providers	Stays single: one workload identity gets short-lived credentials for each cloud, with no long-lived keys in code
Networking and private connectivity	Doubles: separate VPCs, peering, firewalls	Doubles: two networking setups, connected by VPN or mesh	Shrinks: public routing and service-to-service traffic across locations are handled, and private networks connect through a tunnel agent in each network instead of per-provider VPNs and peering
Observability and alerting	Doubles: separate dashboards and alert rules	Stays single if centralized in one backend	Stays single: logs and metrics from every location land in one built-in backend, and so do traces once tracing is enabled
Security reviews and compliance evidence	Doubles: separate audit trails and controls	Partially doubles: shared policies, provider-specific evidence	Fewer surfaces to review, though each provider remains in scope
On-call and incident response	Doubles: separate runbooks per provider	Stays single if runbooks are provider-agnostic	Stays single: one operational surface
Cost tracking	Doubles: separate billing consoles and commitment models	Partially doubles: unified dashboards, separate billing APIs	Shrinks: one bill for compute on platform-managed locations, across every provider
Failover testing	New task: cross-provider drills	New task: cross-provider drills	New task, but an active-active path carries traffic every day

Even with Terraform and a GitOps controller such as Argo CD or Flux deploying to both providers, you still manage version upgrades for two Kubernetes control planes, two sets of node pools with their own upgrade cadences, and two networking setups that need separate configuration and troubleshooting. Shared tooling removes much of the duplication and leaves the infrastructure lifecycle work in place. Run the GitOps controller per cluster, or outside both providers, so deployments still work when one provider is down.

How to fail over an application across cloud providers automatically

Automatic cross-provider failover needs four components working together.

Health checks that test real user journeys. Run synthetic checks from several vantage points outside both providers against the same endpoints your users hit, and fail over only when most of them agree for a sustained window. A checker inside the failing provider can go down with the workload, and a check that touches a shared database can fail both providers at once.

A global routing layer independent of either provider. This can be a global load balancer, a DNS service with health-checked records and low TTLs, or both. The routing layer cannot live only inside the provider you are failing away from, and it is a single point of failure in its own right, so run authoritative DNS on two providers or use a routing service with its own multi-provider footprint.

Stateless services deployed to both providers from one pipeline. When a service carries no local state, failover is a traffic routing decision. Containerized workloads with externalized configuration are the natural building block.

A data strategy aligned to your RPO. Each approach has a different recovery point.

Approach	How it works	RPO	Trade-off
Async replication of a single primary	The primary database on one provider streams changes to a replica on the other, which is promoted at failover	Sub-second to minutes of possible data loss, depending on replication lag	Simplest to operate; writes go to one provider; promotion must fence the old primary so it cannot keep accepting writes
Distributed SQL spanning providers	Self-hosted deployments of databases such as CockroachDB or YugabyteDB spread replicas across providers, and each write commits only when a majority of replicas (a Raft quorum) acknowledges it	Zero for the loss of one provider, provided no single provider holds a majority of replicas, which takes at least three failure domains; with two providers, losing the one that holds the majority stops writes	Higher write latency from cross-provider round trips; cross-cloud private networking; you operate a distributed database
Object storage replication with a sync tool	A tool copies objects between buckets on each provider, on events or on a schedule	Seconds to hours, depending on whether sync is event-driven or scheduled	Fits static assets and backups; not suitable for transactional data
Backups restored on the other provider	Periodic backups stored on the second provider are restored to a new database at failover	Up to the backup interval; restore time adds to RTO, often hours for large databases	Lowest ongoing cost; slowest recovery; suits non-critical workloads

Automated promotion needs a tiebreaker outside both providers, such as a witness or consensus store in a third location, so a partition between providers does not produce two primaries. The source provider bills cross-provider replication as egress, at lower per-GB rates over a dedicated or cross-cloud interconnect, so price your write and change volume before choosing a design. Replication also copies corruption and accidental deletes to the other provider, so keep point-in-time backups alongside any replication method.

Many teams combine approaches: a replicated primary or distributed SQL for transactional data, and object sync for media and assets. For routing and database patterns in more depth, see running an app across multiple regions with routing, databases, and failover.

Warm standby or active-active across providers?

The choice depends on your RTO and RPO targets, budget, team size, and data model.

Warm standby keeps a scaled-down copy of the application on the second provider. At failover you scale up compute, promote database replicas, and switch traffic. It costs less in normal operation, but recovery takes minutes to tens of minutes, and the scale-up can fail if the second provider lacks capacity or the environment has drifted from production.

Active-active across providers serves real traffic from both providers continuously. Every deployment exercises both environments, failover for stateless services is a routing change, and the second provider is never cold. It needs continuous serving capacity, headroom and raised quotas on each provider to absorb the other’s full load, and a data strategy that supports reads or writes in more than one location.

The underrated risk of warm standby is that a rarely used environment fails when you need it. Configuration drifts, capacity reservations lapse, and certificates renew on the primary but not on the standby. Teams that choose warm standby have to drill often to keep it viable. For a cost comparison, see active-active vs. active-passive cost.

A middle path is to run staging, batch jobs, or internal tools on the second provider, so it carries real load without serving production users and stays tested at limited cost.

How do I reduce the blast radius of a cloud provider outage?

Failover is only as strong as its weakest shared dependency.

• Map every dependency. Include DNS, the CDN and WAF, your identity provider, CI/CD, the secrets manager, the container registry, the observability backend, the status page, and third-party APIs such as payments, email, and authentication. Any of them living only on the failing provider stalls failover.
• Keep single-provider global control planes out of the failover path. A deployment tool, secrets vault, or service mesh control plane that runs on one provider becomes a bottleneck during that provider’s outage.
• Push container images to registries on both providers as part of CI, so you can deploy and scale on the second provider while the first is down.
• Replicate secrets and certificates to both providers, and rotate them in both. A rotation that reaches only one side breaks the other at failover, and if you publish CAA records, they must list every CA that issues your certificates.
• Isolate by cell or tenant. Partitioning the application keeps a failure in one cell from reaching every user.
• Use feature flags to degrade non-critical features when a dependency is unavailable, so core functions keep working.
• Monitor from outside the affected provider, so alerting still works when that provider is down.
• Keep DNS TTLs short and pair them with client retries. Failover still takes detection time plus TTL, some resolvers and runtimes cache past the TTL, and keep-alive, gRPC, and WebSocket connections stay on the old endpoint until they fail. Anycast global load balancing moves traffic faster than DNS changes.
• Run game days that simulate provider-level failures, then fix what breaks. See how to test failover without taking production down and, for AWS-specific steps, keeping your app online when an AWS region goes down.

Is multi-cloud a real solution to vendor lock-in?

Multi-cloud for failover reduces your dependence on one provider’s availability. Whether it reduces lock-in depends on how you build.

Workloads in containers that use open-source databases and standard protocols such as HTTP, gRPC, and SQL are portable. Moving their compute between providers is mostly configuration, while moving their data still takes migration time and egress cost. Workloads built deeply on provider-managed services, such as proprietary serverless functions, managed queues, or specialized AI APIs, stay locked in on each provider, and running on two providers can mean two sets of lock-in to maintain.

The practical approach is to use provider-specific services where they deliver clear value, isolate them behind application interfaces, and build the failover path on the portable layer. For a deeper analysis, see managed services vs. portability and cloud lock-in.

A phased plan for adding a second cloud provider

1. Pick one critical service and set RTO and RPO. Choose a service that matters enough to justify the work and is simple enough to succeed with first.
2. Containerize it and make it stateless. Externalize session state, configuration, and secrets.
3. Unify the pipeline, identity, secrets, and observability. One CI/CD pipeline deploys to both providers, one identity model governs access, one replicated secrets store provides credentials, and one backend, hosted outside either provider or on both, collects logs, metrics, and traces.
4. Replicate data. Pick an approach from the data table, set up the replica on the second provider, and confirm replication lag meets your RPO.
5. Deploy to the second provider and send it traffic. Real traffic is better than an idle standby because it validates the environment continuously.
6. Drill failover and failback. Simulate a provider outage, measure the RTO and RPO you actually achieve, and fix every gap. Make failback a planned manual step: rebuild the old primary as a replica of the promoted one, let it catch up, then move traffic back in a scheduled window.
7. Expand service by service, in order of business criticality. Each iteration is faster because the shared operational layer is in place.

How do I know ops work did not double?

Track these before and after adding the second provider:

• Engineer hours per release. A big jump means the pipeline is not unified.
• Number of pipelines. One per service, regardless of provider count.
• Alert volume per provider. It should follow traffic. A spike from the second provider signals drift.
• On-call pages per provider. A new class of incidents from the second provider means the environments are diverging.
• Drill RTO and RPO achieved. Stable or improving numbers show the failover design is maturing.
• Configuration drift. Growing differences between the two environments predict future ops burden.

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, and Azure, VM workloads on locations joined through Control Plane’s Managed Kubernetes (MK8s), which runs Kubernetes nodes in your own cloud account or on your own servers, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds.

For example, a GVC can hold a GCP region next to an AWS region. A workload deployed to a GVC runs active-active in every location of that GVC from one definition, and a global endpoint routes each request to the nearest healthy location, so failover is a routing change with no standby to start. For a walkthrough, see how to run the same app on AWS, GCP, and Azure.

On Control Plane-managed locations in AWS, GCP, and Azure regions, there is no Kubernetes cluster to operate, which removes the cluster-upgrade row of the ledger for those locations.

Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security. The CLI, console, Terraform and Pulumi providers, and the Control Plane MCP server all work through the same Control Plane API and cover every location. Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run. Control Plane’s Universal Cloud Identity (UCI) lets workloads in any location call AWS, GCP, and Azure services with no long-lived cloud keys in your code.

Control Plane covers the data layer too. Control Plane’s Template Catalog, a library of preconfigured stacks you install into a GVC, includes multi-location PostgreSQL and CockroachDB templates whose members span the locations of a GVC, so the database spans providers along with the application. Multi-location PostgreSQL keeps one primary with asynchronous replicas. With three or more locations, it promotes a replica in a surviving location automatically. With two locations, the surviving replica stays read-only until you promote it. CockroachDB with three or more locations keeps serving reads and writes through the loss of one location. To survive the loss of a whole provider with either template, spread at least three locations across three providers, so no provider holds a majority. You pick the template that matches your RPO and drill failover on a schedule.

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 (how that failover worked). For outage trends, see the 2026 cloud outage report.

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. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. You pay for the CPU and memory a workload reserves, with no contracts or minimums. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

FAQ

Answers to the questions engineering leaders ask most before adding a second provider.

Do I need Kubernetes on both clouds to fail over between them?

No. Kubernetes on each provider gives a consistent runtime at the cost of operating two clusters. On Control Plane-managed locations, the same workload runs on AWS, GCP, and Azure with no cluster to manage. Teams that want Kubernetes can still use Control Plane’s Managed Kubernetes or add clusters they already run as locations.

What is the hardest part of multi-cloud failover?

The data layer. Stateless services move easily between providers, while stateful services need replication, fencing, and tested promotion. Most teams underestimate how hard it is to prove the replication strategy meets the RPO under real failure conditions.

How much does adding a second cloud for failover cost?

Warm standby costs the least at rest, active-active costs more but recovers fastest, and cross-provider data transfer adds cost to both. Warm standby keeps a scaled-down copy, so recovery is slower. Active-active runs both providers at full readiness, so recovery is a routing change. On Control Plane, active-active runs without paying for idle standby capacity, because every location serves real traffic and scales with it.

Can I fail over between clouds without a second operations team?

Yes. One pipeline, one identity model, one observability stack, and one on-call rotation can cover both providers. If the second provider needs its own team, the operational layer has not been standardized.

How do I test multi-cloud failover without affecting production users?

Send a small share of traffic to the second provider, validate it with synthetic checks, and simulate failures by blocking the primary provider’s endpoints in a controlled window. On Control Plane, a workload can be suspended in one location while others keep serving, which turns a drill into a configuration change.

How long does it take to add a second cloud provider?

For a stateless service with a unified pipeline already in place, days to weeks. For a stateful service with demanding replication requirements, weeks to months. The phased plan delivers value one service at a time.

What happens to compliance when I add a second provider?

Each provider adds its own audit surface, configuration baselines, and evidence. Standardizing policies, logging, and access across both keeps the work from doubling, but both providers stay in scope for your audits.

Is multi-cloud failover worth it if my primary provider has multi-region redundancy?

Yes, if you need to stay up through a provider-wide incident or a failure in a provider’s global services. Multi-region within one provider covers regional failures only.

To add a second cloud without a second operations team, talk to the Control Plane team or sign up free.

---

Originally published on the Control Plane blog.