Yesterday, the internet had a bad day — and so did millions of users and businesses around the world. On October 20, 2025, Amazon Web Services (AWS) experienced a major outage that disrupted everything from streaming platforms and smart homes to enterprise apps and financial services.
This wasn’t just another technical hiccup. It was a stark reminder of how fragile the modern internet can be when so much of it depends on a handful of companies.
What Happened
The issue began in the US-EAST-1 region — AWS’s most popular and densely used zone. According to Reuters, a problem with internal load balancing and DNS resolution cascaded through multiple AWS services. The result: apps and websites couldn’t connect to the servers they relied on.
Among those affected were McDonald’s, Apple Music, Microsoft 365, Alexa, and countless others. For several hours, essential services ground to a halt until AWS engineers restored connectivity and gradually lifted resource launch restrictions.
Why This Is a Big Deal
1. A Single Point of Failure
Many assume “the cloud” is inherently redundant. But if your redundancy lives entirely within one provider — or worse, one region — it’s not really redundant. When US-EAST-1 sneezes, the internet catches a cold.
2. Market Concentration
A small number of cloud providers — AWS, Microsoft Azure, Google Cloud — host the majority of the internet’s infrastructure. That means a single technical issue or configuration error can have global consequences. The Guardian called this outage a “wake-up call” for over-centralized tech ecosystems.
3. Real-World Consequences
This wasn’t just about broken websites. Smart home devices failed, business operations froze, and customers couldn’t access digital banking tools. The outage exposed how deeply integrated cloud systems are into our daily lives.
4. Transparency and Accountability
When one company’s infrastructure outage affects the global economy, it raises questions: Should these systems be treated as critical infrastructure? Should they face stricter transparency or redundancy regulations?
What Developers and Businesses Can Learn
A. Don’t Put Everything in One Basket
Consider multi-cloud or hybrid cloud strategies. Even a small secondary backup provider can make a huge difference.
B. Think in Regions, Not Just Servers
Deploy across multiple geographic regions. AWS regions can and do fail — sometimes catastrophically.
C. Map Your Dependencies
List all the services your stack relies on: DNS, S3, load balancers, CDNs. Know what happens if each one disappears.
D. Build for Failure
Assume downtime will happen. Automate backups, build health checks, and design your architecture for graceful degradation.
E. Communicate Transparently
If your service depends on AWS (or any third-party provider), have a crisis communication plan. Users appreciate honesty more than silence.
The Bigger Picture
The “cloud” once symbolized infinite scalability and resilience. Yesterday, it reminded us that it’s still made of physical servers, networks, and human mistakes — all controlled by a few companies.
AWS isn’t evil. It’s brilliant, efficient, and the backbone of the internet as we know it. But the more we depend on a single entity, the more we gamble with the internet’s stability.
Maybe the next evolution of cloud computing isn’t just about AI and automation — it’s about decentralization.
👋
Thanks for reading — I’m Marxon, a web developer exploring how AI reshapes the way we build, manage, and think about technology.
If you enjoyed this post, follow me here on dev.to
for more reflections like this — and join me on X
(just started recently!) where I share shorter thoughts, experiments, and behind-the-scenes ideas.
Let’s keep building — thoughtfully. 🚀
Top comments (10)
This article serves as a powerful and timely 'wake-up call' regarding the risks of cloud centralization and single points of failure like US-EAST-1. The emphasis on multi-region deployment and mapping dependencies offers concrete, actionable takeaways for all developers.
Thank you, I really appreciate that!
That was exactly the goal — not to point fingers, but to spark awareness about how fragile centralized systems can be, and to remind developers that we do have tools and design choices to reduce that risk.
Glad to hear the takeaway landed that way!
Marxon, this was a fantastic take on the subject. Thanks for sharing
You post is giving mixed signals. On the one hand you plead for more cloud companies. And on the other hand you want us to give them more money to create redundancy.
The reason why there are only a few worldwide cloud companies is because investing in infrastructure is expensive. What people are calling the cloud is at the core owning datacenters.
The alternative is finding a host company in each region you want your website/application to work at it's peak level. The downside is having multiple bills, creating your own deployment system and monitoring.
The problem as I see it is people calling AWS the backbone of the internet. That would be the equivalent of saying you can only make websites and apps with React.
It is not because it is popular it is the only solution.
Great points — and I actually agree with most of what you said.
My goal wasn’t to “plead for more cloud companies” and “spend more money* at the same time, but to highlight how our current dependency structure creates systemic risk.
Redundancy doesn’t always mean paying for two full AWS accounts or spinning up a second global provider — sometimes it’s about architectural independence: decoupling DNS, using multi-region failovers, or even using a smaller regional host for fallback.
You’re absolutely right that the core problem is how we think about “the cloud.” It’s not a magical abstraction — it’s still data centers, networks, and people. My point was that when one of those few providers becomes so deeply embedded into the digital economy, a single outage starts to look like a global event.
And I love your analogy — AWS isn’t the internet, just like React isn’t the only way to build apps. It’s dominant because it’s convenient, not because it’s irreplaceable.
How are you not spending more money if you use multi-region failovers? The cost will be less than running multiple regions all of the time, but it is still an extra cost to run the minimum services.
For smaller regional hosts, why would you do that if the platform provides multi-region failovers? Like I mentioned before, to do that you need your own monitoring system. So people just stay with the big platforms, and pay more.
The other thing is those compagnies have so many people using their platforms, they can make their services much cheaper than any regional hosting company. It is the local grocery store against the supermarkets on the internet.
Decentralization is not the solution for the problem.
That big American apps stopped working should not be seen as a global event because of AWS structure, but more as failure of the app to store data locally.
In the Reuters article they mention London and Tokyo, why are they hosting their apps on US servers? Did they forget to change the region?
There is a lot more going than just the AWS outage. But it is easy to blame the big company.
Totally fair points — and I think this is where nuance really matters.
Yes, multi-region failovers cost money. But the question isn’t “should everyone double their AWS bill”, it’s “how can we design systems that degrade gracefully instead of collapsing entirely.”
Sometimes that’s as simple as caching critical data locally, decoupling DNS, or designing fallback flows that don’t depend on one specific endpoint.
I also agree that AWS offers economies of scale smaller hosts can’t match — that’s exactly why the ecosystem is so centralized. But the risk isn’t just financial; it’s systemic. If everyone optimizes for cost and convenience, we end up with a few massive choke points that can take down half the internet when they hiccup.
And yes, many companies should have configured their regions differently. But even so, the outage shows how deeply intertwined those “American apps” are with a single provider’s infrastructure. It’s not about blaming AWS — it’s about recognizing how fragile the overall structure has become.
There is no if, that is the reality.
The problem is that the companies that have the money to build a better infrastructure don't do it, because the mentality is to solve the problems when they occur.
Big companies are so far from reality there are situations where they place cost cutting against hurting people or in a more extreme case people dying.
For smaller companies there is the mitigating factor to work within a certain budget, but then the choice is between redundancy and features. It is not only up to developers to make that decision.
It is not the internet that is down, it are the apps that stop working. As a developer you should understand the difference.
When people are cutting internet lines that is when the structure is getting damaged.
Totally agree — that’s a very fair distinction. When I said “half the internet goes down,” it was more a reflection of user perception than literal infrastructure collapse. You’re absolutely right that what really fails are the apps and services sitting on top of the network.
And I completely get your point about companies choosing to “fix it later.” That mentality is often rooted in short-term economics — especially when reliability doesn’t directly translate into visible revenue.
My argument isn’t that decentralization magically fixes everything, but that the mentality needs to shift: reliability shouldn’t be an afterthought, even if it costs a bit more. Because when the apps people rely on daily stop working, users don’t blame “architecture” — they lose trust.