
The internet broke three times inside a month. On [October 20, 2025](https://www.thousandeyes.com/blog/aws-outage-analysis-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](https://www.thousandeyes.com/blog/microsoft-azure-front-door-outage-analysis-october-29-2025), taking Microsoft 365 and the Azure portal along. Then on [November 18](https://blog.cloudflare.com/18-november-2025-outage/), 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](https://kempitlaw.com/insights/the-end-of-switching-charges-commercial-impact-and-compliance-priorities/), 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](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en), 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](/multi-cloud/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](https://light-cloud.com).


Run one cloud. Hold a real option to leave it.

Multi-Cloud Is Overrated. Portability Isn't.


AWS just gave us another reminder that vendor lock-in is about as smart as using "password123" for your production database.

On October 20, 2025, at 11:48 PM PDT (because outages always happen when engineers are either sleeping or three beers into their weekend), AWS's US-EAST-1 region decided to take an unscheduled 15-hour vacation. And when US-EAST-1 sneezes, the entire internet catches pneumonia, gets quarantined, and starts panic-buying toilet paper.

This wasn't just any outage. This was **AWS's longest service disruption in a decade**. Think about that. A DECADE. These are the people who promise 99.99% uptime, and they just blew through an entire year's worth of their error budget in one spectacularly bad Monday.

## A Race Condition Walks Into a Bar...

Here's what happened: AWS's DynamoDB service had a "race condition" in its DNS management system. For the non-technical folks, imagine two robots trying to update the same phone book at the exact same time, but one robot is drunk and the other one is running Windows Vista.

Specifically, one DNS Enactor was taking its sweet time applying old DNS records (probably stopped for coffee), while another DNS Enactor applied new records and started cleaning up. The slow one then overwrote everything, and the cleanup process immediately deleted those records.

The result? **All IP addresses for DynamoDB's main DNS records just... disappeared.** Poof. Gone. Like your motivation on a Monday morning, except this actually mattered.

At 12:26 AM PDT, AWS sheepishly admitted: "We determined that the event was the result of DNS resolution issues for the regional DynamoDB service endpoints."

Translation: "Our internet phone book ate itself and we're very sorry your billion-dollar company can't access anything right now."

## The Domino Effect From Hell

The cascade was beautiful in its destruction:
- DynamoDB stops responding (11:48 PM PDT)
- Every service depending on DynamoDB panics
- EC2 instances start failing
- 113 AWS services experience "difficulties" (corporate speak for "completely hosed")
- Amazon.com itself goes wobbly (Amazon broke Amazon)
- **United Airlines** and **Delta** can't check passengers in (hello, manual check-in lines at ATL and ORD)
- **Robinhood** locks everyone out during market hours (sorry, no panic selling today)
- **Coinbase** goes dark (your crypto is "safe" but also completely inaccessible, which is basically Schrödinger's Bitcoin)
- **Roblox's** 70 million daily users get kicked offline (finally, parents get some peace)
- **Fortnite** players ejected mid-battle (230 million gamers crying in unison)
- **Ring** doorbells go blind (all those packages, just sitting there, vulnerable)
- **Alexa** becomes a very expensive brick
- **Disney+**, **Netflix**, **Hulu**, and **Prime Video** all buffer eternally
- **Snapchat's** 400 million users lose their streaks (the horror)
- **Signal** goes offline (so much for "secure" communications)
- Even the **UK's tax website** crashed (tax evasion was briefly consequence-free)

Meanwhile, somewhere in Seattle, AWS engineers were getting the kind of phone calls that start with "DROP EVERYTHING" and end with "JEFF WANTS UPDATES EVERY 5 MINUTES."

## Engineers: The Five Stages of Cloud Grief

**Stage 1: Denial (11:48 PM - 12:30 AM)**

"It's probably just a monitoring glitch. Have you tried turning CloudWatch off and on again?"

"The dashboard must be wrong. DynamoDB doesn't just... stop."

"Maybe it's just affecting that one region... oh wait, it's US-EAST-1. We're doomed."

**Stage 2: Anger (12:30 AM - 2:00 AM)**

The Slack channels explode:

```
@channel WHO DEPLOYED TO PROD ON A SATURDAY NIGHT?!
@channel DNS is down AGAIN. AGAIN!!!
@channel I TOLD YOU WE NEEDED MULTI-REGION
@channel We have 6.5 MILLION error reports on Downdetector
@channel Coffee machine is also down. THIS IS NOW PERSONAL.
```

**Stage 3: Bargaining (2:00 AM - 8:00 AM)**

"What if we just... route everything through US-WEST-2?"

"Has anyone tried calling Jeff Bezos directly?"

"I'll name my firstborn DynamoDB if it just starts working again."

Someone definitely suggested [have we tried sacrificing a goat to the cloud gods?](https://blog.light-cloud.com/cloud/rethinking-infrastructure) like that crazy lady from [light-cloud](https://light-cloud.com/). Multiple someones, probably.

**Stage 4: Depression (8:00 AM - 3:00 PM)**

Picture this: hundreds of engineers, fueled by Red Bull and existential dread, silently typing while their managers hover behind them like anxious helicopters. The pizza boxes stack up. Hope dwindles. Someone starts calculating the cost per minute and immediately regrets their career choices.

**Financial analysts are estimating losses in the hundreds of billions of dollars.** Not millions. BILLIONS. With a B. That's "buy a small country" money, except instead you're paying for the privilege of watching error messages.

**Stage 5: Acceptance (3:01 PM)**

"Fine. We'll implement the ugly workaround."

"Add 'implement multi-cloud strategy' to the Q1 roadmap. No, make it Q4. We're tired."

"At least we're not the only ones down?"

After 15.2 hours of chaos, AWS finally declared victory at 3:01 PM PDT. The post-incident report emphasized "rapid response," which is corporate speak for "our engineers haven't slept in 36 hours and are now communicating exclusively in memes and profanity."

## The Hidden Costs (AKA: The Bill You Don't Want to See)

While AWS was down, thousands of companies discovered the true cost of single-cloud dependency:

- **Lost revenue**: Every minute of downtime = thousands in lost sales. For 15 hours. Do the math. Then cry.
- **Engineer overtime**: Nothing says "budget overrun" like emergency all-hands debugging sessions that last through sunrise
- **Customer trust**: "Sorry, AWS is down" doesn't sound professional when you're trying to check into your flight and the gate agent is waving a printed boarding pass at you like it's 1995
- **Stress-induced coffee consumption**: Seattle's coffee shops made a fortune. Starbucks mobile ordering was down, but in-person sales probably hit record highs
- **Trading losses**: Robinhood and Coinbase users couldn't trade during market hours. That's not just annoying-that's potentially lawsuit territory

**Venmo** had 8,000+ outage reports. People couldn't split their brunch bills. Do you know how many friendships ended that day because someone couldn't immediately settle their $12 avocado toast debt?

## The Reality Check Nobody Wanted

Here's the uncomfortable truth AWS doesn't want you thinking about: **Multi-cloud isn't paranoia, it's insurance.**

AWS controls 30-37% of the global cloud market. That's roughly a THIRD of all cloud infrastructure. When they sneeze, a third of the internet needs a tissue.

As Rob Jardin, Chief Digital Officer at NymVPN, noted: "The internet was originally designed to be decentralized and resilient, yet today so much of our online ecosystem is concentrated in a small number of cloud regions."

Translation: We built the internet to survive nuclear war, but can't survive AWS having a bad day.

But here's the problem: making your infrastructure multi-cloud ready is like learning to juggle while riding a unicycle through a minefield:

### The Traditional Multi-Cloud Nightmare:

- **AWS**: Uses CloudFormation templates, speaks AWS-ish
- **Google Cloud**: Requires Deployment Manager, speaks Google-ese
- **Azure**: Demands ARM templates, speaks Microsoft-ian
- **Your sanity**: 404 Not Found

Each provider has its own:
- Authentication methods (because standards are for losers)
- SDK quirks (same function, 47 different names, because consistency is boring)
- Pricing models (comparing them requires a PhD in Advanced Mathematics and a minor in Interpretive Dance)
- Documentation style (ranging from "overly verbose" to "did an AI having a stroke write this?")

The financial impact? **Hundreds of billions in losses**, according to Mehdi Daoudi, CEO of Catchpoint. That includes lost productivity for millions of workers, stopped airline operations, missed trading opportunities, inability to access funds, lost gaming revenue, and advertising losses.

For perspective: The July 2024 CrowdStrike incident cost Fortune 500 companies $5.4 billion in direct losses. This AWS outage lasted longer and affected more services. You do the math-it's depressing.

## How ICE Would've Saved Your Monday (And Your Job)

**Before the Outage:**
1. Deploy your infrastructure using our visual studio (no YAML gymnastics required, no crying at 3 AM over indentation errors)
2. ICE automatically maintains templates for AWS, GCP, and Azure (we speak all three dialects of cloud gibberish)
3. Our AI-powered cost predictor shows you pricing across all providers (so you can see exactly how much you're overpaying)
4. One-click to replicate your setup across multiple clouds (seriously, one click, we're not exaggerating)

**During the Outage:**
1. AWS goes down? Click the "Oh Shit, Migrate!" button (yes, we actually call it that internally)
2. ICE translates your AWS infrastructure to GCP or Azure format (like Google Translate, but actually useful)
3. Deploys your backup infrastructure in minutes, not hours (your competitors are still on hold with AWS support)
4. Traffic routing switches automatically (because manual DNS updates at 3 AM are how mistakes happen)
5. You go back to sleep while your competitors panic-tweet at @AWSSupport

**After the Outage:**
- Keep both deployments for redundancy (because you just learned this lesson the hard way)
- Or migrate back with one click (no hard feelings, AWS)
- Either way, you're never held hostage by a single provider again

## The "We're Sorry" (But Not Really) Response

AWS's apology was peak corporate-speak: "We apologize for the impact this outage has had on our customers. We have a strong track record of operating our services with high levels of availability."

"Strong track record"? This was your **third major US-EAST-1 outage in five years** and your **longest disruption in a decade**. That's not a track record, that's a pattern.

Their fix? They **disabled the DynamoDB DNS automation worldwide**. You know, the thing that caused the problem. Just... turned it off. Everywhere.

It's like your smoke detector kept going off randomly, so you solved the problem by removing all the batteries. Technically effective, but maybe concerning?

AWS also promised to "add mechanisms to limit the number of servers Network Load Balancer will disconnect when health checks fail" and "strengthen recovery tests."

Translation: "We're going to add more duct tape and actually test our disaster recovery plans instead of just assuming they work."

## The Standardization Revolution (Or: Why We Keep Building the Same Wheel)

Here's the thing that makes me irrationally angry: **80% of cloud infrastructure follows the same patterns.**

- Web server + Database + Cache
- Microservices + Message Queue + Storage
- API Gateway + Lambda + DynamoDB

Yet every cloud provider acts like they invented these concepts from scratch. It's like car manufacturers making you learn a completely different way to drive for each brand.

"Oh, you want to turn left in a Honda? That's the red pedal. In a Toyota? Purple lever. In a Ford? You have to sing the ABCs backwards."

ICE standardizes these patterns into reusable blocks:
- **Deploy once, run anywhere** (yes, like Docker promised, but for entire infrastructures)
- **Provider-agnostic templates** (your "web app" block works on any cloud)
- **Automatic translation** (CloudFormation -> Terraform -> ARM, seamlessly, like magic but with more Python)

## Lessons from the Trenches (Written in Blood and Error Logs)

After analyzing this outage and hundreds before it, here's what we've learned:

### 1. Multi-Cloud is No Longer Optional

If you're running anything mission-critical on a single cloud, you're one DNS race condition away from explaining to your CEO why the company lost millions on a Monday.

### 2. US-EAST-1 is Cursed

This region has failed three times in five years. At what point do we admit that us-east-1 is built on an ancient burial ground?

### 3. Migration Preparedness is Key

Can you move your infrastructure in under an hour? If not, you're one outage away from disaster and a resume-generating event.

### 4. Standardization Beats Optimization

That perfectly optimized, AWS-specific architecture? Worthless when AWS is down. Better to be 90% optimized and 100% portable than 100% optimized and 0% functional.

### 5. AWS's Apology Doesn't Pay Your Bills

They'll give you service credits. You know what doesn't accept service credits? Your investors. Your customers. Your mortgage company.

## The Bottom Line

AWS's October 20 outage wasn't unique. It won't be the last. Every cloud provider has these moments-it's not about *if* but *when*.

The question is: Will you be the company that tweets "We're experiencing issues due to AWS" or the one that tweets "Business as usual, thanks to our multi-cloud architecture" while your competitors burn?

Because let me tell you, when United Airlines passengers are standing in line for manual check-in and Robinhood users can't panic-sell during market hours, nobody cares about your 99.99% uptime SLA. They care about whether your service works RIGHT NOW.

With [Light Cloud's ICE](https://www.light-cloud.com/ice), you can:
- **Provision** infrastructure on any cloud in minutes (faster than your morning coffee)
- **Migrate** between providers with one click (no, seriously, ONE CLICK)
- **Visualize** your entire architecture (instead of praying your YAML is correct)
- **Predict** costs before deployment (no more $50,000 surprise bills)
- **Standardize** your infrastructure (use the same blocks everywhere, like Lego but for clouds)

Because in 2025, vendor lock-in isn't just expensive-it's irresponsible. It's the technical equivalent of keeping all your money under your mattress and hoping your house doesn't burn down.

Spoiler alert: The house is currently on fire.

---

*P.S. - To the AWS engineers who pulled a 15-hour shift on October 20: we salute you. May your coffee be strong, your DNS be fast, and your race conditions be forever caught in code review. Also, maybe test that automation before deploying it worldwide next time?*

*P.P.S. - This outage cost hundreds of billions of dollars. For that price, we could have built a entirely new internet. From scratch. With blackjack. And working DNS.*

Multi-Cloud

Multi-Cloud Is Overrated. Portability Isn't.

AWS Goes Dark: How October 20's Outage Proved Multi-Cloud Isn't Just Paranoia