Multi-Cloud Is Overrated. Portability Isn't.

The internet broke three times inside a month. On October 20, 2025, a latent race condition in DynamoDB's DNS automation took down AWS us-east-1 and dragged a large slice of the consumer internet with it. Nine days later, an errant configuration change broke Azure Front Door, taking Microsoft 365 and the Azure portal along. Then on November 18, a database permissions change at Cloudflare made a Bot Management feature file double in size, and a long list of dependents went dark for hours.

Each time, the same advice arrived within the hour: this is why you need multi-cloud.

We sell software that models three clouds, so believe me when I say we'd love that advice to be right. It mostly isn't. Active-active multi-cloud is complexity theater for the majority of companies that attempt it, and what last autumn's outage cluster actually argues for is portability: a credible, tested ability to leave. Those are different products. They carry wildly different prices.

What active-active actually costs

Running production on two clouds at once means engineering for the intersection of their feature sets. You give up the managed services that made either cloud attractive, because DynamoDB doesn't run on Azure, and build against the lowest common denominator instead. Then everything doubles. Two IAM models with different permission semantics, two networking stacks, two sets of quotas and failure modes, and an observability layer that has to stitch it all into one picture. Your on-call now debugs two providers instead of one.

There's a people bill too. Every engineer you hire needs fluency in two permission models and two failure vocabularies, or you split the team into provider silos and reinvent the coordination problems you bought a cloud to escape. Hiring gets slower. The pager gets worse.

Data is where the theater collapses. Compute is fairly portable. State has mass. Keeping your primary database live in two clouds means continuous cross-cloud replication, and the EU Data Act's ban on switching charges, fully in force on January 12, 2027, won't help you there, because it covers leaving a provider while the meter on ordinary operational egress keeps running every month you stay. And a standby you've never failed over to isn't a disaster plan. It's a hope with a budget line.

October 29 held a quieter lesson: the Azure portal itself was impaired during the Azure outage. If the failover runbook lives in the cloud that's down, the multi-cloud strategy has a single point of failure with a wiki URL.

Portability is an option you hold

In finance terms, portability is an option: you pay a small ongoing premium for the right, never the obligation, to move. You rarely exercise it. Its value shows up anyway. At contract renewal, a vendor who knows you can leave prices differently than one who knows you can't. During incidents, a restore you've tested elsewhere turns catastrophe into degradation. And in front of regulators it's now a required artifact: DORA, applying to EU financial entities since January 17, 2025, requires documented exit strategies for critical ICT providers, and auditors have started asking to see them.

Most companies can't produce a real one. A credible exit plan is an inventory of what you actually run, a mapping of each piece to a provider-neutral equivalent, a data restore executed at least once somewhere else, and an honest time estimate. If assembling that takes your team a quarter, you don't hold the option. You hold a slideshow about the option.

Holding the option cheaply is an architecture decision, and mostly a boring one: containers over proprietary runtimes where the managed premium isn't earning its keep, and plain PostgreSQL over a proprietary database API unless you've priced the divorce. Add a written map of what runs where, kept current, because inventory is the part that rots fastest. None of this requires a second cloud. It requires saying no to a few conveniences whose real price is the exit.

The case for the second cloud

Here's the steelman, fairly: selective redundancy saved real companies last autumn. A status page hosted on a different provider, DNS with a second resolver, a read-only mode served from another CDN: cheap, and effective on October 20. Some businesses justify full active-active, trading venues among them, where minutes of downtime cost more than years of duplicated infrastructure. And plenty of enterprises are multi-cloud whether they chose it or not, because acquisitions arrive carrying their own stacks.

All conceded. Notice, though, what the wins have in common: thin, stateless layers, chosen deliberately, tested regularly, and priced honestly, which is portability practiced at the edges rather than a second copy of production. Duplicate the cheap layers where failure is loud. Hold the option on everything else.

This distinction is what ICE is built around. Its deterministic graph models your infrastructure across AWS, GCP, and Azure as one structure, which makes the exit-plan artifact, what runs where and what maps to what, a byproduct of normal operation instead of a quarterly archaeology project. Portability as a property you hold rather than a second production you fund.

I'll admit regulation is a tailwind we didn't earn: DORA made the deliverable mandatory while the tooling to produce it barely exists. Small companies get few gifts from Brussels. We plan to use this one.

The next request for your exit plan might come from a regulator, an insurer, or your board after the next headline outage. Could you hand over a tested document by Friday, or would you be scheduling a meeting to plan the plan?

Related: AWS Goes Dark: October 20, 2025, my write-up of the first outage in the cluster. More about what we're building at light-cloud.com.