Multi-Cloud Design Tradeoffs

An architecture review proposes "active-active across AWS and GCP" for 99.99% availability. Your job in the room is to name what actually doubles — not the slide, the bill and the 3 a.m. page. This topic follows Abstraction Modules Across Clouds, which showed you how to hide a second provider; here we ask whether the second provider deserves to exist.

Nothing about the diagram is free. Two active networks means two of almost everything you operate:

The last row is the answer interviewers want, and the one that costs the most. In a single-cloud incident your hypothesis space has one layer. In a two-cloud incident every symptom gains three candidate causes, runbooks fork into two versions, and your responders need fluency in both consoles. Mean time to recovery grows even when nothing else does — and availability math says a more probable failure mode than "AWS had a regional outage" is "our failover logic had a bug we tested quarterly."

The money column deserves real numbers:

Typical total: 40–80% higher infrastructure spend plus a second on-call runbook, before counting the engineering months. And the latency math constrains the design at the same time: same-region cross-AZ round trips run well under a millisecond, interconnect between clouds adds single-digit milliseconds, and the public internet path runs 20–60 ms — which is why these designs serve failover, not hot paths, a point established when wiring resources across providers.

Now compare against the honest alternative. One cloud with three availability zones, a warm multi-region standby, load balancers with health checks across zones, and managed services with availability SLAs lands at 99.95–99.99% for a fraction of that bill, with one IAM model and one debugging world. Single-cloud with strong redundancy usually wins on availability per dollar — the second cloud buys resilience you already bought regionally, then taxes you for operating it.

None of this says "never." It says: in the review, refuse to approve a two-cloud design whose justification slide says "resilience." Push for the failure mode, the number, and the owner of the second runbook — and if those exist, the next chapter covers which reasons survive that interrogation.

"We should go multi-cloud" is a preference until it names the failure mode it protects against and the monthly price of that protection. Most proposals fail that sentence. Run every justification through this table before any architecture work starts.

The interview version of this skill is a question you ask back: "What is the failure you are protecting against, and what does the protection cost per month?" Candidates who can only quote SLA percentages have not done the analysis; candidates who answer "AWS outage takes us down — we measured a 4-hour regional event as $900k, and the second cloud costs $7k/month plus two engineering quarters" have. Note that this frame also handles the true positive: residency and acquisition requirements survive the interrogation precisely because they name concrete, non-hypothetical constraints.

Sequencing matters as much as the verdict. Adding a second cloud after 200 services exist means re-implementing modules, splitting state, forking pipelines, and retraining responders — an order of magnitude more expensive than deciding at service number ten. But deferring is still a decision, and undocumented decisions get relitigated every reorg. Write an Architecture Decision Record: the reasons considered, the verdict, the price of the rejected option, and a review date. When the acquisition closes or the residency rule lands, the ADR shows the trigger you were waiting for instead of looking like nobody thought about it.

One more cost that never appears in the initial proposal: optionality decay. A second cloud kept idle — a passive standby with real resources — generates bills without generating evidence that failover works, because nobody exercises it. If you keep the second network, budget the quarterly failover drill alongside it. An untested second cloud is not resilience; it is a duplicate that has never been asked to do anything.

Verdict in hand, the remaining decision is mechanical but unforgiving: where the state lives. Get that wrong and even a well-justified design becomes surgery later.

Two teams once stood up one Terraform state for a workload spanning AWS and Azure. Six months later the split had to happen for blast-radius reasons — and it took a maintenance window, three engineers, terraform state pull with hand-edited JSON, and an import pass for the resources whose addresses moved. The design question this illustrates is not technical preference: state partitioning must be decided before the first resource spans providers, because retrofitting it is surgery on your single source of truth.

Four strategies, with what each actually buys:

The atomic-plan column is the seductive one. A single state lets a plan order an Azure private endpoint after the AWS-side DNS record it depends on, and no data source is involved. You pay for that with the blast radius: a corrupted or mis-targeted plan touches everything, one lock serializes every engineer, and the plan output for a 400-resource cross-cloud graph is a document nobody reviews carefully — which defeats the purpose of gating on plans.

Wiring across state boundaries has three forms, ordered from tightest to loosest coupling. terraform_remote_state reads another state directly: convenient, but it couples the reader to the writer's backend permissions and schema. Data source lookups — reading a DNS zone, a parameter store, a resource attribute by name — decouple the two states; ordering becomes eventual rather than graph-enforced, which is the correct semantics for a failover relationship. Using the network itself (queues, databases, global DNS) as the integration point is loosest and most realistic: these clouds are supposed to survive each other's absence, so a hard reference to the other cloud's state backend contradicts the goal.

Backend and lock choices follow the partition. Each state gets its own backend and its own lock resource — an S3 bucket with a DynamoDB LockID table, an Azure storage account with blob lease — so two pipelines can never contend across partitions:

terraform {
  backend "s3" {
    bucket         = "corp-tfstate-platform"
    key            = "services/payments/prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "corp-tfstate-locks"
    encrypt        = true
  }
}

Locks do not span states, which is the point: a stuck run in staging-network must not block prod-app. Keep each state's backend inside a platform-controlled account, and mirror periodic state pull snapshots to the other cloud's object store: if the partition exists for outage resilience, your ability to rebuild it cannot live entirely in the cloud you are recovering from.

Then the retrofit cost, concretely, because this is where the interview answer separates from the résumé answer. Splitting one state means terraform init -migrate-state to relocate a whole state, or state pull → partition the JSON by address → state push into new backends, then re-point every output and data source that crossed the old boundary, then verify with a no-op plan in each partition. Every step has a failure mode where a resource ends up in two states — which produces a later apply that destroys a resource another state believes it owns. Weeks of work, done under a freeze, versus an hour of decision at day zero.

Decide the partition table the same week you choose the backend. With that settled, the roadmap moves into verification: The Native terraform test Framework.