High availability design patterns in AWS - Step-by-Step Execution

Process Flow - High availability design patterns

Start: User Request

↓

Route to Load Balancer

↓

Distribute to Multiple Instances

↓

Health Check on Instances

↓

Instance Healthy?

No→Remove from Pool

Yes↓

Serve Request

↓

Monitor & Auto-Recover

↓

End: Request Served

User requests go through a load balancer that distributes traffic to healthy instances, ensuring continuous service by monitoring and replacing unhealthy ones.

Execution Sample

AWS

User sends request
Load balancer receives request
Load balancer checks instance health
Routes request to healthy instance
Instance serves request
Monitor detects failure
Auto-recovery replaces failed instance

This flow shows how a request is handled in a high availability setup with load balancing and health checks.

Process Table

Step	Action	Condition/Check	Result	Next Step
1	User sends request	N/A	Request received by load balancer	Route to load balancer
2	Load balancer receives request	N/A	Ready to distribute	Check instance health
3	Load balancer checks instance health	Instance A healthy?	Yes	Route to Instance A
4	Load balancer checks instance health	Instance B healthy?	No	Remove Instance B from pool
5	Route request to Instance A	N/A	Instance A serves request	Monitor instances
6	Monitor detects failure	Instance B failed?	Yes	Auto-recover Instance B
7	Auto-recover Instance B	N/A	Instance B replaced and healthy	Add Instance B back to pool
8	Add Instance B back to pool	N/A	Pool restored	Ready for next request
9	End	N/A	Request served successfully	Stop

💡 Request served successfully after routing to healthy instances and recovering failed ones

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 6	After Step 7	Final
Instance A Health	Unknown	Healthy	Healthy	Healthy	Healthy	Healthy
Instance B Health	Unknown	Healthy	Unhealthy	Failed	Healthy	Healthy
Load Balancer Pool	Empty	Includes A and B	Includes A only	Includes A only	Includes A and B	Includes A and B

Key Moments - 3 Insights

Why does the load balancer remove an instance from the pool?

Because the health check shows the instance is unhealthy (see step 4 in execution_table), removing it prevents sending requests to a failing server.

How does auto-recovery help maintain availability?

Auto-recovery replaces failed instances automatically (step 7), restoring the pool to full capacity and ensuring requests can be served without interruption.

What happens if all instances fail health checks?

The load balancer has no healthy targets to route requests to, causing service disruption until instances recover or are replaced.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is Instance B removed from the load balancer pool?

A Step 3

B Step 6

C Step 4

D Step 7

💡 Hint

Check the 'Result' column for removal actions in execution_table row 4.

According to variable_tracker, what is the health status of Instance B after step 7?

A Healthy

B Unhealthy

C Failed

D Recovering

💡 Hint

Look at the 'Instance B Health' row under 'After Step 7' in variable_tracker.

If the load balancer did not perform health checks, what would likely happen?

A Load balancer would remove all instances

B Requests might be sent to unhealthy instances causing failures

C Auto-recovery would not be triggered

D Requests would be evenly distributed without issue

💡 Hint

Refer to the importance of health checks in execution_table steps 3 and 4.

Concept Snapshot

High availability design uses load balancers to distribute traffic
Health checks monitor instance status and remove unhealthy ones
Auto-recovery replaces failed instances automatically
This ensures continuous service despite failures
Key components: Load balancer, health checks, multiple instances, auto-recovery

Full Transcript

High availability design patterns in AWS involve routing user requests through a load balancer that distributes traffic to multiple instances. The load balancer performs health checks to ensure only healthy instances receive traffic. If an instance fails, it is removed from the pool to prevent failed requests. Monitoring detects failures and triggers auto-recovery to replace unhealthy instances. This cycle maintains continuous service availability by handling failures transparently. The process starts with a user request, routes through the load balancer, checks instance health, serves the request from a healthy instance, monitors for failures, and recovers failed instances automatically.

Practice

1. What is the main goal of a high availability design pattern in AWS?

easy

A. To reduce the cost of cloud resources

B. To keep the application running even if some parts fail

C. To increase the speed of the application only

D. To limit the number of users accessing the app

Solution

1. Step 1: Understand high availability concept

   High availability means designing systems to stay online and functional despite failures.

2. Step 2: Match goal with options

   Only To keep the application running even if some parts fail describes keeping the app running during failures, which is the goal.

3. Final Answer:

   To keep the application running even if some parts fail -> Option B

4. Quick Check:

   High availability = keep running despite failures [OK]

Hint: High availability means no downtime during failures [OK]

Common Mistakes:

• Confusing cost reduction with availability
• Thinking speed alone defines high availability
• Assuming limiting users improves availability

2. Which AWS service is commonly used to distribute incoming traffic across multiple instances for high availability?

easy

A. Amazon S3

B. AWS Lambda

C. Amazon RDS

D. Elastic Load Balancer (ELB)

Solution

1. Step 1: Identify service for traffic distribution

   Elastic Load Balancer (ELB) distributes traffic to multiple instances to avoid single points of failure.

2. Step 2: Eliminate other options

   Amazon S3 stores files, RDS is a database, Lambda runs code; none distribute traffic.

3. Final Answer:

   Elastic Load Balancer (ELB) -> Option D

4. Quick Check:

   Traffic distribution = ELB [OK]

Hint: Load balancers spread traffic to keep apps available [OK]

Common Mistakes:

• Choosing storage or compute services instead of load balancer
• Confusing Lambda with traffic distribution
• Selecting database services for traffic handling

3. Consider this AWS setup: An application runs in two Availability Zones (AZs) behind an Elastic Load Balancer. If one AZ fails, what happens to the app availability?

medium

A. The app slows down but stays available in the failed AZ

B. The app becomes completely unavailable

C. The app continues running using the healthy AZ

D. The app automatically scales down to zero instances

Solution

1. Step 1: Understand multi-AZ deployment

   Running in multiple AZs means if one AZ fails, others can serve traffic.

2. Step 2: Analyze ELB behavior

   ELB routes traffic only to healthy instances, so app stays available in the healthy AZ.

3. Final Answer:

   The app continues running using the healthy AZ -> Option C

4. Quick Check:

   Multi-AZ + ELB = app stays available [OK]

Hint: Multi-AZ with ELB keeps app running if one AZ fails [OK]

Common Mistakes:

• Assuming total outage if one AZ fails
• Thinking app slows but serves from failed AZ
• Believing app scales down automatically on failure

4. You configured an Auto Scaling group with minimum 2 instances across two AZs, but during a failure, only one instance is running. What is the likely issue?

medium

A. Auto Scaling group is not set to replace unhealthy instances

B. Load balancer is misconfigured to route traffic

C. Instances are launched in the same AZ only

D. Security groups block instance communication

Solution

1. Step 1: Check Auto Scaling group settings

   Auto Scaling must replace unhealthy instances to maintain minimum capacity.

2. Step 2: Understand failure impact

   If replacement is disabled, failed instance won't be replaced, causing fewer running instances.

3. Final Answer:

   Auto Scaling group is not set to replace unhealthy instances -> Option A

4. Quick Check:

   Auto Scaling replaces unhealthy = maintain capacity [OK]

Hint: Auto Scaling must replace failed instances to keep count [OK]

Common Mistakes:

• Blaming load balancer for instance count
• Assuming instances launched only in one AZ
• Thinking security groups affect instance count

5. You want to design a highly available web app on AWS that stays online even if an entire region fails. Which combination should you use?

hard

A. Deploy instances in multiple regions with Route 53 latency-based routing and health checks

B. Deploy instances in multiple AZs within one region and use an Elastic Load Balancer

C. Use a single instance in one AZ with Auto Scaling enabled

D. Deploy instances in one AZ and use Amazon S3 for static content

Solution

1. Step 1: Understand region failure scope

   Multi-AZ protects against AZ failure, but not entire region failure.

2. Step 2: Choose multi-region design

   Deploying in multiple regions with Route 53 routing and health checks ensures availability if one region fails.

3. Final Answer:

   Deploy instances in multiple regions with Route 53 latency-based routing and health checks -> Option A

4. Quick Check:

   Multi-region + Route 53 = survive region failure [OK]

Hint: Multi-region with Route 53 handles region failures [OK]

Common Mistakes:

• Thinking multi-AZ covers region failure
• Relying on single instance with Auto Scaling
• Ignoring DNS routing for multi-region failover