What Actually Happens During a Cloud Outage?
Servers fail, networks break, and data centers can have problems. So how does cloud architecture keep applications running anyway?
We hear phrases like:
“AWS is down.”
“The cloud is having an outage.”
And suddenly, websites stop loading, apps throw errors, payments fail, and half the internet seems to be complaining at once.
Which raises an interesting question:
If the cloud is supposed to be reliable, how does it go down at all?
And when something does fail, why do some applications disappear completely while others continue working as if nothing happened?
The answer starts with understanding that “the cloud” isn't one giant computer.
The Cloud Is Physical
It's easy to imagine cloud computing as something abstract.
But underneath services such as databases, virtual machines and storage are very real things:
servers, disks, network equipment, cables, power systems and data centers.
And physical infrastructure can fail.
A server can crash.
A network device can malfunction.
Power can be interrupted.
Software deployments can introduce bugs.
Human configuration errors can happen.
The goal of cloud architecture isn't to somehow create infrastructure that never fails.
It's to design systems that can survive when something inevitably does.
One Server Is a Problem
Imagine your entire application runs on one server.
1
2
3
4
5
6
7
Users
|
v
Server
|
v
DatabaseEverything works beautifully.
Until that server dies.
Now there is nowhere for incoming requests to go.
This is called a single point of failure -> one component whose failure can take down the entire system.
So we add redundancy.
1
2
3
┌── Server 1
Users → Load Balancer
└── Server 2If Server 1 fails, traffic can potentially be sent to Server 2.
We've made the system more resilient.
But there's another problem.
What if both servers are sitting in the same data center?
What If the Entire Data Center Has a Problem?
Putting ten servers in one building doesn't protect you from a failure affecting that building.
That's where the idea of failure domains becomes important.
In AWS, infrastructure is organized into Regions and Availability Zones (AZs).
A Region represents a geographic area, while a Region contains multiple Availability Zones consisting of separate infrastructure.
Instead of placing everything in one location, an application can be designed across multiple AZs.
Conceptually:
1
2
3
┌── Availability Zone A
Users → Traffic ┤
└── Availability Zone BIf infrastructure in one zone experiences a problem, workloads in another zone may continue serving users.
But notice the important word:
may.
Simply using AWS doesn't automatically make an application highly available.
The application has to be designed for failure.
Your Application Can Still Ruin Everything
Imagine your application servers run across multiple Availability Zones.
Great.
But your application depends on one database deployed in one location.
1
2
3
4
5
6
AZ-A AZ-B
Server 1 Server 2
\ /
\ /
└── Database ───┘If that database becomes unavailable, both application servers may become useless.
You removed one single point of failure and accidentally kept another.
The same can happen with networking, storage, authentication services or other dependencies.
This is why high availability isn't just:
“Run two servers.”
It's about understanding the entire dependency chain.
What Happens When Something Fails?
Suppose one application instance becomes unhealthy.
A resilient architecture might detect this through health checks.
The system can then stop sending new traffic to the unhealthy instance and route requests toward healthy ones.
If capacity drops too much, additional instances may be launched.
The user might never know anything happened.
That's one of the fascinating parts of distributed infrastructure:
Failures can happen constantly without necessarily becoming outages.
An outage happens when the system can no longer successfully absorb those failures.
But What If an Entire Region Fails?
Now we're moving to a much larger failure scenario.
Some critical applications are designed to operate across multiple geographic Regions.
Conceptually:
1
2
3
┌── Region A
Users ───────┤
└── Region BIf Region A experiences a severe outage, traffic may be redirected toward Region B.
Sounds perfect.
So why doesn't everyone simply run everything in five Regions?
Because resilience has a cost.
More infrastructure can mean:
- more complexity,
- more data replication,
- more networking,
- more operational work,
- more difficult consistency problems,
- and, of course, more money.
An application used by twenty people probably doesn't need the same disaster-recovery architecture as a global financial platform.
Reliability Is a Design Decision
This was the part I found most interesting.
Cloud providers can give us the building blocks for resilient systems.
Multiple Availability Zones.
Multiple Regions.
Load balancing.
Auto scaling.
Replication.
Backups.
Health monitoring.
But having those tools available doesn't automatically make an application resilient.
Architecture still matters.
You have to decide:
What can fail?
What happens when it does?
How quickly should the system recover?
How much downtime can we tolerate?
How much are we willing to spend preventing it?
“Never Fail” Isn't Really the Goal
At first, I thought highly reliable infrastructure meant trying to prevent every possible failure.
But distributed systems make a different assumption:
Things will fail. Design accordingly.
Servers will crash.
Networks will behave strangely.
Software will contain bugs.
Infrastructure will occasionally become unavailable.
A resilient system isn't necessarily one where nothing ever breaks.
It's one where something can break without everything breaking with it.
And that's probably the most interesting thing about cloud outages.
When an application stays online during an infrastructure failure, it's not because nothing went wrong.
Sometimes, it's because something did go wrong and the architecture was ready for it.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article