us-east-1: The Region the Internet Leans On

You've probably lived through this without knowing the details. One morning half your apps stop working at once. Your group chat won't send, your doorbell camera is offline, a game is down, a bank's app throws errors, and somewhere a headline says the internet is having problems. A few hours later it quietly comes back, and the explanation, almost every time, is four characters long: us-east-1.

This is Amazon's oldest and busiest data-center region, in Northern Virginia, and it has a strange habit of taking a shocking slice of the internet down with it when it stumbles. The previous lesson's Kinesis outage happened here. So did the famous 2017 S3 outage, a big 2021 event, and a 2025 one that knocked out everything from Snapchat to Signal to Ring doorbells for most of a day. Same region, over and over.

But here's the part that should bother you, and it's the reason this lesson isn't just a list of Amazon's bad days: a lot of the companies that go down when us-east-1 goes down don't even run there. Their apps are in Oregon, or Frankfurt, or Singapore, and they still fall over. To understand how that's possible is to understand one of the most important and least discussed risks in all of system design: concentration risk, the danger you create when a huge number of independent-looking systems quietly share a single point of failure.

In this lesson: why everyone ended up in the same region; the hidden global dependency that reaches your app even when it lives somewhere else; why your carefully planned failover might not run when you need it; and the one question about your own system this should leave you asking.

Scope: the generic anatomy these failures share is drawn out next, in Anatomy of a Cascading Failure; here we stay with the pattern of one region and what it teaches.

Start with the innocent question: why is one region so much busier than the others? Amazon runs dozens of regions across the world, roughly equal siblings. Why does this one carry so much of the load?

Because it was first. us-east-1 opened in 2006, the original AWS region, and that head start compounded into gravity. It's the default almost everywhere: open the console, reach for the SDK, follow a tutorial, and unless you deliberately change it, you land in us-east-1. It's usually the cheapest, because scale drives price down and it has the most scale. And it's where new services launch first and have the most features, so if you want the newest toy, that's where it lives.

Put those together and you get a self-reinforcing pile-on. Every rational, individual decision, use the default, save a little money, get the newest features, points the same way, and the sum of a million sensible local choices is that an outsized share of the world's computing sits in one building complex in Virginia. Nobody decided this. It emerged, the way everyone crowding onto the same subway car emerges from each person just wanting the nearest door. That crowding is comfortable right up until the moment the car has a problem.

Now the mechanism that explains the impossible-sounding part, the companies that go down without running in us-east-1 at all. It comes down to a distinction AWS doesn't advertise loudly: some of its services are global, and a global service has to keep its authoritative brain somewhere. For several of the most important ones, that somewhere is us-east-1.

Consider what your app in Frankfurt actually needs from Amazon, beyond raw compute. It needs to authenticate and hand out permissions, which is IAM and its token service STS. It needs to change DNS when something moves, which is Route 53. It needs to configure its CDN, which is CloudFront. Every one of those is a global service, and the part of each that lets you make changes lives, physically, in us-east-1. Your servers can run in Frankfurt all day long, but the moment you need to assume a role, mint a credential, or repoint a DNS record, you are quietly reaching back across the ocean to Virginia.

So the dependency is invisible and one-directional in the worst way. You chose Frankfurt specifically to be independent of us-east-1, and for serving traffic you are. But threaded through your setup are these thin, easy-to-forget wires that all run to the same place, and you won't notice them until the day Virginia is on fire and you discover that your somewhere-else app can't get a credential to save its life.

There's a distinction hiding in that story worth pulling out on its own, because it's one of the most useful lenses in operations and it explains which things break in an outage and which keep working.

Every service really has two halves. The data plane is the part that uses what already exists: serving a web request, reading and writing rows that are already there, answering a DNS query for a record that's already set. The control plane is the part that changes what exists: launching a new server, creating a role, assuming a role, changing a DNS record, spinning up a distribution. Reading the phone book is data plane; printing a new edition is control plane.

Two facts about these halves decide the shape of most cloud outages. First, the data plane is built to be massively distributed and boringly reliable, because it runs constantly at enormous volume; Route 53 answering a DNS query almost never fails. The control plane is more complex, changes more often, and is more centralized, which makes it the fragile one. Second, when the control plane goes down, anything already running keeps running on the data plane, but you lose the ability to change anything. You can't launch replacement capacity, can't fail over, can't reconfigure. The lights stay on, but every switch stops working. Hold that image, because the next section is what happens when the one switch you desperately need is wired through the room that's on fire.

Here is where concentration risk stops being an abstraction and starts ending careers. Say you did everything right. You run active in us-east-1, but you're a serious shop, so you keep a warm standby in us-west-2 and a written plan: if Virginia goes down, fail over to Oregon. You even practiced it. Then the morning comes, us-east-1 is down, and you calmly open the runbook to execute the failover.

You can't. Failing over means two things: repoint your DNS from the dead region to the healthy one, and get the credentials your team and services need to operate in the new region. Repointing DNS is a Route 53 control-plane change, which runs in us-east-1. Getting credentials is IAM and STS, which run in us-east-1. Both calls hang, because the region that serves them is the region you're trying to escape. This isn't hypothetical, it's exactly what happened to real, multi-region-ready teams in the 2025 outage: they had the standby, they had the plan, and they sat helpless because the mechanism of escape depended on the thing they were escaping. If that circular shape feels familiar, it should, it's the same trap that locked Facebook's engineers out of their own network in Facebook, 2021: The BGP Self-Lockout, just wearing a cloud provider's uniform.

The lesson underneath is brutal and simple: a failover that depends on the failed region is not a failover. A recovery plan that has to make control-plane calls into us-east-1 in order to escape us-east-1 is a plan that works in every rehearsal and fails in the one performance that matters. The console below drops you into exactly this. Build a stack, flip Virginia off, and try to survive it, first the naive way, then the way that actually works.

None of this is new, which is the unsettling part. The same region has failed the same shape of failure for the better part of a decade, and each time the blast radius was measured in the internet, not a company.

In 2017, an engineer removing a few servers from an S3 billing system fat-fingered a single number in the command and took out far more than intended. S3 in us-east-1 went dark for hours, and because a staggering number of sites store their images, files, and assets there, a huge chunk of the web simply stopped rendering. In 2020 it was Kinesis, the thread-limit cascade you just studied. In 2021, an internal-network scaling event congested the control plane and knocked services and the AWS console sideways. And in 2025, a race condition in DynamoDB's DNS automation wrote an empty DNS record for its us-east-1 endpoint, so nothing could find the database, which cascaded into EC2 launches and Lambda and a long list of consumer apps, from Snapchat to Signal to Ring, for the better part of a day.

And running through nearly every one of these is the same dark little joke, the recurring motif of this whole part of the course: the status page couldn't be updated, because the tool that updates it depended on the thing that was down. In 2017 the health dashboard's own status icons were served from the S3 that had failed, so it sat there glowing green while the internet burned. Kinesis took out the dashboard through Cognito. It's the self-lockout again, one level up: even the I'm sorry we're down sign is wired through the same fragile region.

Now we can name the thing precisely, in the language of Availability & the Nines. When you put two copies of a service behind a load balancer and call it redundant, you're making a bet about independence: the whole point of two copies is that they won't fail at the same time, so the chance of both being down is the small chance of one, squared. Two servers that are each up 99.9% of the time give you six nines together, but only if their failures are independent.

Concentration quietly deletes that independence. Put both copies in us-east-1, or, more insidiously, let both depend on a global service whose control plane is in us-east-1, and their failures are now correlated: the same regional event takes them both at once. Your beautiful six-nines math collapses back to the reliability of the single region they share. Redundancy that shares a failure domain is not redundancy, it's the same bet written twice. us-east-1 has become a single point of failure for a frightening slice of the internet, exactly the thing Single Point of Failure — and Redundancy, the Antidote warned you to hunt for, hiding in plain sight behind the word global.

Zoom out one more level and it gets genuinely uncomfortable. Every individual company made a reasonable call to use the popular default region. But the sum of all those reasonable calls is a monoculture: an internet where one region's bad morning is everyone's bad morning, all at once, because we all unknowingly planted in the same field. That's concentration risk in one sentence, everyone optimizing locally, concentrating risk globally, and only finding out how correlated they were when the correlation fires.

You can't move Amazon's IAM out of Virginia, and for most teams going fully multi-region isn't worth the cost. So the goal isn't to eliminate concentration risk, it's to know where yours is and stop it from taking you down when the region hiccups. A few concrete moves, in rough order of return on effort.

Get off the shared control plane where you can. Use the regional endpoints for STS instead of the global one, so authentication in your region doesn't route through Virginia. Cache credentials so a brief control-plane blip doesn't lock you out. Small, unglamorous changes that quietly cut wires you didn't know you had.

Design for static stability. This is the big one, and it's a principle straight from Amazon's own reliability playbook: build so your system holds its last-known-good state and keeps serving even when the control plane is gone. Pre-provision your standby capacity so you never have to launch anything mid-outage. Wire your failover to a health check that flips traffic automatically on the data plane, the routing idea from Global Load Balancing: GeoDNS & Anycast, rather than a human making a control-plane API call at 4 a.m. A statically stable system doesn't need the switch, because it was already flipped.

Know your real blast radius, and decide on purpose. Map your hard dependencies, including the third-party services you rely on, because half of them sit in us-east-1 too, so a vendor you thought was separate is one more wire to Virginia. Then make an honest decision: for a hobby project, accepting us-east-1's risk is completely rational. For a payments system, it is not, and the multi-region cost of Multi-Region Patterns and the isolation of Cell-Based Architecture & Deployment Stamps are the price of not sharing fate with half the internet. The sin isn't concentrating. The sin is concentrating by accident and discovering it during the outage.

Reason through this one before you read the answer. Your company runs a genuinely multi-region setup: the app and database are active in us-east-1 with a warm standby in us-west-2, and you've tested failover in a drill and it worked. One morning us-east-1 has a major outage. Your app servers in us-west-2 are healthy and serving fine, but your users still can't log in, and your on-call engineer can't get the failover to complete. Both apps were up. What broke, and what's the fix?

Work it out, then check yourself:

• What broke the logins: authentication. If your app authenticates users or services through the global STS endpoint (or an identity flow that leans on IAM), those calls route to us-east-1, which is down, so healthy app servers in Oregon still can't mint or verify credentials. The compute was never the problem.
• What broke the failover: completing it needed a Route 53 control-plane change to repoint DNS and IAM/STS to grant access, both in us-east-1. The escape route ran through the burning building.
• The fix: switch to regional STS endpoints so auth stays in-region; make the failover statically stable by pre-provisioning the standby and using a Route 53 health-check failover that flips automatically on the data plane, with no runtime control-plane call. Then the same us-east-1 outage leaves your Oregon stack serving and logging users in, untouched.
• The tell to remember: whenever your recovery plan contains the words and then we change or and then we launch or and then we log in to, ask which region that action runs in. If it's the region you're recovering from, you don't have a plan, you have a rehearsal.

Concentration risk breeds comfortable half-truths. Each one hides a real exposure.

• Myth: multi-AZ makes me safe. Availability Zones protect you from a data-center failure, not a regional one. AZs in a region share the regional control plane and the global services in us-east-1, so a regional or global-control-plane outage takes all your zones at once. Multi-AZ is not multi-region.
• Myth: my app runs in Frankfurt, so a us-east-1 outage can't touch me. It can. IAM and STS for auth, Route 53 for DNS changes, CloudFront for your CDN, and any global-table or us-east-1-hosted dependency all reach back to Virginia. Running elsewhere protects your data plane, not your control plane.
• Myth: just go multi-cloud and you're immune. Multi-cloud roughly doubles your operational surface and cost, and you often still share fate, the same DNS provider, the same CDN, the same third-party SaaS that itself lives in us-east-1. Independence has to be verified end to end, not assumed from a logo count.
• Myth: it's purely AWS's fault. AWS owns the bug that started each outage, sure. But concentration is a choice you make: other regions and regional endpoints exist, and most teams accept us-east-1's risk for the convenience. Own your half of the dependency.
• Myth: the 2025 outage was just a DNS problem. The empty DNS record was the first symptom; the root cause was a race condition in the DNS automation. And the real lesson isn't DNS at all, it's that one service, in one region, resolving badly could darken a chunk of the world, because of how much leans on it.

• us-east-1 is a hidden single point of failure for much of the internet. It's first, default, cheapest, and most featured, so an outsized share of the world piled in, and its bad mornings become everyone's.
• The global control plane reaches you even when your app doesn't run there. IAM, STS, Route 53, and CloudFront keep the part that changes things in us-east-1, so an app in Frankfurt still authenticates and repoints DNS through Virginia.
• Control plane fails while data plane survives. In an outage, what's already running keeps running, but you lose the ability to launch, change, or fail over, because the control plane is the fragile, centralized half.
• A failover that depends on the failed region is not a failover. If completing your escape needs Route 53 and IAM calls into the region you're escaping, your plan works in every drill and dies in the real event.
• Concentration risk is correlated failure. Redundant copies that share a failure domain, a region or a global control plane, aren't independent, so your availability math collapses to the reliability of the thing they share.
• The fix is static stability and honesty. Use regional endpoints, pre-provision, wire health-check failover on the data plane, map your real dependencies including your vendors, and decide on purpose which risks you accept.

Three outages, three different triggers, and by now you can feel the shared skeleton underneath them all, a small fault, an amplifier, a dependency nobody mapped, a recovery path that shared fate with the failure. That skeleton has a name and a playbook, and pulling it out into the open is exactly what comes next, in Anatomy of a Cascading Failure.