☁️ Day 6: What Happens When the Cloud Fails?
Learn how redundancy, high availability, and fault tolerance help cloud applications handle failures. Explore how multi-server and multi-AZ architectures keep applications resilient when something goes wrong.
Series: Cloud Computing (24 articles)
- …
- 7☁️ Day 6: What Happens When the Cloud Fails? This article
☁️ Day 6/30: What Happens When the Cloud Fails?
Designing for High Availability, Redundancy & Fault Tolerance
Yesterday, we answered an important question:
Where does our cloud application actually live?
We explored AWS Regions and Availability Zones and saw that our application doesn't simply exist in some mysterious "cloud." It runs on real infrastructure organized into locations designed to provide isolation and resilience.
But now that we know where our application lives, there is another question every cloud architect must ask:
What happens when something goes wrong?
Because here's the uncomfortable truth about technology:
Failures happen.
A server can stop responding.
A network connection can fail.
An Availability Zone can experience an incident.
And when that happens, the real question isn't:
"Can our system fail?"
It's:
"What happens to our users when something fails?"
That's where today's architecture journey begins.
🚨 Let's Start With a Real-World Scenario
Imagine we're building a college examination registration portal.
On a normal day, maybe a few hundred students are using it.
Our architecture looks simple:
1
2
3
4
5
👩🎓 Students
↓
🖥️ Application
↓
🗄️ Database
Everything works.
Students log in.
They register for exams.
They download their documents.
The database stores their information.
Perfect.
But then comes exam registration day.
Suddenly, thousands of students open the portal at almost the same time.
And then...
💥 The application server crashes.
What happens now?
If our entire application depends on that one server, the portal may become unavailable.
This brings us to our first important concept.
🧱 The Single Point of Failure
A Single Point of Failure (SPOF) is a component whose failure can cause an important part of the system—or the whole system—to become unavailable.
Think about a restaurant with only one chef.
1
2
3
4
5
🍽️ Customers
↓
👨🍳 ONE CHEF
↓
Kitchen
What happens if that chef suddenly becomes unavailable?
The restaurant has a problem.
The issue isn't necessarily that the chef is unreliable.
The issue is that everything depends on one component.
Cloud architectures can have the same problem.
1
2
3
4
5
👥 Users
↓
🖥️ ONE SERVER
↓
🗄️ Database
If that server fails, the application may stop serving users.
💡 Cloud Architect's Question
Instead of asking:
"How do I make this one server impossible to fail?"
A cloud architect asks:
"How do I design the system so that the failure of one component doesn't bring everything down?"
That change in thinking is extremely important.
🔄 The Solution: Redundancy
One way to reduce dependence on a single component is redundancy.
Instead of having one application server, we can have multiple servers.
1
2
3
4
5
👥 Users
↓
⚖️ Load Balancer
↙ ↘
🖥️ Server 1 🖥️ Server 2
Now imagine Server 1 fails.
The second server can still be available to handle requests, depending on how the architecture is configured.
AWS Elastic Load Balancing can distribute incoming traffic across multiple targets and monitor their health, routing traffic to healthy targets.
So instead of:
1
2
3
4
5
One server
↓
One failure
↓
Potential outage
we move toward:
1
2
3
4
5
Multiple servers
↓
One server fails
↓
Healthy server(s) continue serving
This is the basic idea behind redundancy.
🧠 But Is Having Two Servers Enough?
Not necessarily.
Remember what we learned yesterday about Availability Zones?
An AWS Region contains multiple Availability Zones designed with physical separation and independent infrastructure.
So imagine we put both application servers in the same Availability Zone:
1
2
3
4
5
6
Region
│
AZ-1
┌────┴────┐
↓ ↓
Server 1 Server 2
What if the problem affects that entire Availability Zone?
Both servers could potentially be affected.
So we've removed one single point of failure, but created another dependency:
Both servers depend on the same failure boundary.
This is where our Day 5 knowledge becomes useful.
🌍 From One Location to Multiple Availability Zones
We can distribute our application across Availability Zones:
1
2
3
4
5
6
7
8
9
10
11
👥 USERS
↓
⚖️ Load Balancer
↙ ↘
↓ ↓
AZ-1 AZ-2
🖥️ App Server 🖥️ App Server
\ /
\ /
↓ ↓
🗄️ Database
Now we have introduced another layer of resilience.
If one Availability Zone experiences an issue, resources in another Availability Zone can potentially continue serving the workload.
AWS recommends distributing production workloads across multiple Availability Zones to reduce the impact of failures affecting a single AZ.
The architectural progression looks like this:
1
2
3
4
5
6
7
ONE SERVER
↓
Multiple Servers
↓
Multiple Availability Zones
↓
More resilient architecture
Notice something important:
We didn't just add more servers because "more is better."
We added redundancy because we identified a failure scenario and designed around it.
That's how a cloud architect thinks.
🟢 What Is High Availability?
Now we can give a name to the goal we're trying to achieve.
High Availability (HA)
High availability means designing a system so that it can continue providing its service when individual components experience failures.
It does not mean:
"The application can never go down."
That's an important distinction.
High availability is about reducing the impact of failures and reducing downtime, not magically eliminating every possible failure.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
Without redundancy:
Server fails
↓
Application affected ❌
With redundancy:
Server 1 fails
↓
Server 2 remains available
↓
Application can continue serving users ✅
The exact behavior depends on how the architecture and services are configured.
🛡️ What About Fault Tolerance?
You may now be thinking:
"Isn't that the same thing?"
They're closely related, but let's keep the distinction simple.
High Availability
The goal is to minimize downtime and keep the service available when components fail.
Fault Tolerance
The system is designed to continue operating despite certain failures.
Think about an airplane.
If one system experiences a failure, other systems may be designed to keep critical functions operating.
The aircraft hasn't become "failure-proof."
Instead, it has been designed so that certain failures don't immediately stop the entire system.
Cloud architecture uses the same fundamental idea:
Don't assume that everything will always work. Design for what happens when something doesn't.
🏗️ Let's Upgrade Our College Portal
Let's return to our original application.
Version 1 — Simple
1
2
3
4
5
👩🎓 Students
↓
🖥️ Application Server
↓
🗄️ Database
Problem:
One application server = potential single point of failure.
Version 2 — Redundant Servers
1
2
3
4
5
6
7
8
👩🎓 Students
↓
⚖️ Load Balancer
↙ ↘
🖥️ Server 1 🖥️ Server 2
\ /
\ /
🗄️ Database
Better.
But what if both servers depend on the same Availability Zone?
Version 3 — Multi-AZ Architecture
1
2
3
4
5
6
7
8
9
10
11
12
👩🎓
Students
↓
⚖️ Load Balancer
↙ ↘
↓ ↓
AZ-1 AZ-2
🖥️ App Server 🖥️ App Server
\ /
\ /
\ /
🗄️ Database
Now we're thinking about failure boundaries, not just individual servers.
AWS's reliability guidance recommends using multiple Availability Zones for production workloads when appropriate, with compute and data distributed according to the workload's resilience requirements.
🎯 Real-World Example: Exam Registration Day
Let's make this practical.
Normal day
1
2
3
500 users
↓
Application
Everything is comfortable.
Registration day
1
2
3
20,000 users
↓
Application
Now the system has to handle much more traffic.
But imagine something else happens:
One application server becomes unhealthy.
With a properly configured load-balanced architecture, traffic can be directed toward healthy targets rather than continuing to send requests to an unhealthy target.
That's the kind of problem resilient architecture is designed to address.
And notice the progression of our thinking:
Day 3: What does the application look like?
Day 5: Where does it live?
Day 6: What happens when part of it fails?
We're slowly moving from "How does it work?" to "How do I design it to keep working?"
🧠 Think Like a Cloud Architect
Let's test your architecture thinking.
Scenario
Your college registration portal currently has:
1
2
3
4
5
Users
↓
One Application Server
↓
Database
The application server fails during registration.
Which design would better reduce the impact of that failure?
A.
Use one much larger server.
B.
Use multiple application servers behind a load balancer.
C.
Store more PDFs in object storage.
🤔 Think before revealing the answer...
✅ Answer: B
Multiple application servers can provide redundancy, while a load balancer can distribute requests and stop routing traffic to unhealthy registered targets.
But remember:
Adding multiple servers alone doesn't automatically create high availability.
You also need to consider:
- Where those servers are located
- Whether the load balancer is resilient
- Whether the database can handle failure
- Whether data is replicated appropriately
- Whether your application has other hidden single points of failure
That's why architecture is more than adding more servers.
🖼️ Visual Story — From Fragile to Resilient
This is the visual I would use as the main image for today's article.
Image Title:
From Single Server to Multi-AZ Architecture
Left side:
1
2
3
4
5
6
7
8
9
👥 Users
↓
🖥️ One Server
↓
🗄️ Database
❌ Server failure
↓
Potential outage
Right side:
1
2
3
4
5
6
7
8
9
10
11
12
13
👥 Users
↓
⚖️ Load Balancer
↙ ↘
AZ-1 AZ-2
🖥️ Server 🖥️ Server
\ /
\ /
🗄️ Database
✅ Redundancy
✅ Failure isolation
✅ Higher availability
Why this visual works
The reader doesn't need a long definition.
They can see the architectural evolution:
One dependency → redundancy → multiple failure boundaries.
🏗️ Your Turn: Design for Failure
Here's today's architecture challenge.
Start with:
1
2
3
4
5
👥 Users
↓
🖥️ Application Server
↓
🗄️ Database
Your job:
Redesign this architecture so that the failure of one application server doesn't immediately make the application unavailable.
💡 Hint 1
You probably don't want only one application server.
💡 Hint 2
Something needs to decide where incoming requests should go.
💡 Hint 3
Think back to yesterday's lesson about Availability Zones.
Now draw your own architecture before looking at the solution.
🔍 One Possible Direction
Your thinking could lead toward:
1
2
3
4
5
6
7
8
9
10
👥 Users
↓
⚖️ Load Balancer
↙ ↘
↓ ↓
AZ-1 AZ-2
🖥️ Server 🖥️ Server
\ /
\ /
🗄️ Database
But this is only the beginning.
A real production architecture also needs to consider the resilience of every important dependency, including data storage, networking, and other services.
AWS's Well-Architected guidance emphasizes that avoiding single points of failure applies beyond just compute resources; workload data and other components also need appropriate resilience.
💡 What I Learned Today
Cloud architecture isn't about assuming that everything will work perfectly.
It's about asking:
"What happens if this component fails?"
Then designing the system so that a single failure has a limited impact.
Today we introduced three important ideas:
Redundancy → Have alternatives available.
High Availability → Reduce downtime and keep services available when possible.
Fault Tolerance → Design the system to continue operating through certain failures.
And most importantly:
A resilient architecture doesn't eliminate failure. It prepares for it.
☁️ Day 6/30 — Cloud Computing & Cloud Architecture Challenge
Yesterday, we asked:
Where does our application live?
Today, we asked:
What happens when part of it fails?
Tomorrow, we're going one level deeper.
We've been casually drawing boxes called "servers."
But what exactly is a server in the cloud?
Is it a physical machine?
A virtual machine?
How can one physical machine run multiple virtual servers?
And why is virtualization one of the technologies that made modern cloud computing possible?
🚀 Day 7:
Virtual Machines & Virtualization — What Actually Runs Our Application?
# cloudformation-resources# cloud-adoption-framework# cloud-networking# cloud-operations# cloud-concepts
Series: Cloud Computing (24 articles)
- …
- 7☁️ Day 6: What Happens When the Cloud Fails? This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article