High availability design patterns in AWS - Mini Project: Build & Apply

High Availability Design Patterns with AWS

📖 Scenario: You are working as a cloud architect for a small online store. The store wants to make sure their website stays online even if one server fails. You will build a simple AWS setup that uses high availability design patterns to keep the website running smoothly.

🎯 Goal: Build an AWS infrastructure using an Elastic Load Balancer (ELB) and two EC2 instances in different Availability Zones to ensure high availability for the website.

📋 What You'll Learn

Create two EC2 instances in different Availability Zones

Create an Elastic Load Balancer that distributes traffic to both instances

Configure health checks for the load balancer

Ensure the setup is simple and follows AWS best practices for high availability

💡 Why This Matters

🌍 Real World

High availability design patterns are essential for websites and applications that must stay online without interruption, even if some servers fail.

💼 Career

Cloud architects and DevOps engineers use these patterns daily to design resilient and scalable cloud infrastructures.

1

Create two EC2 instances in different Availability Zones

Create two EC2 instances named web_server_1 and web_server_2. Place web_server_1 in Availability Zone us-east-1a and web_server_2 in Availability Zone us-east-1b. Use the Amazon Linux 2 AMI and instance type t3.micro for both.

AWS

# Your code here to create two EC2 instances named web_server_1 and web_server_2 in us-east-1a and us-east-1b respectively

Hint

Use the aws_instance resource twice with different availability_zone values.

2

Create an Elastic Load Balancer

Create an Elastic Load Balancer named web_elb that listens on port 80 and forwards traffic to the EC2 instances. Use the application load balancer type and place it in Availability Zones us-east-1a and us-east-1b.

AWS

resource "aws_instance" "web_server_1" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = "t3.micro"
  availability_zone = "us-east-1a"
  tags = {
    Name = "web_server_1"
  }
}

resource "aws_instance" "web_server_2" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = "t3.micro"
  availability_zone = "us-east-1b"
  tags = {
    Name = "web_server_2"
  }
}

# Your code here to create an application load balancer named web_elb listening on port 80 in us-east-1a and us-east-1b

Hint

Use aws_lb for the load balancer and aws_lb_listener for the listener on port 80.

3

Create a target group and register EC2 instances

Create a target group named web_tg for the load balancer that uses port 80 and protocol HTTP. Register both web_server_1 and web_server_2 instances as targets in this group.

AWS

resource "aws_instance" "web_server_1" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = "t3.micro"
  availability_zone = "us-east-1a"
  tags = {
    Name = "web_server_1"
  }
}

resource "aws_instance" "web_server_2" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = "t3.micro"
  availability_zone = "us-east-1b"
  tags = {
    Name = "web_server_2"
  }
}

resource "aws_lb" "web_elb" {
  name               = "web_elb"
  internal           = false
  load_balancer_type = "application"
  subnets            = ["subnet-12345678a", "subnet-12345678b"]
  enable_deletion_protection = false
}

resource "aws_lb_listener" "web_listener" {
  load_balancer_arn = aws_lb.web_elb.arn
  port              = 80
  protocol          = "HTTP"
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web_tg.arn
  }
}

# Your code here to create a target group named web_tg and register web_server_1 and web_server_2 as targets

Hint

Use aws_lb_target_group to create the target group and aws_lb_target_group_attachment to register each instance.

4

Configure health checks for the load balancer

Add a health check configuration to the target group web_tg that checks the root path / every 30 seconds with a timeout of 5 seconds. Set healthy threshold to 2 and unhealthy threshold to 2.

AWS

resource "aws_instance" "web_server_1" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = "t3.micro"
  availability_zone = "us-east-1a"
  tags = {
    Name = "web_server_1"
  }
}

resource "aws_instance" "web_server_2" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = "t3.micro"
  availability_zone = "us-east-1b"
  tags = {
    Name = "web_server_2"
  }
}

resource "aws_lb" "web_elb" {
  name               = "web_elb"
  internal           = false
  load_balancer_type = "application"
  subnets            = ["subnet-12345678a", "subnet-12345678b"]
  enable_deletion_protection = false
}

resource "aws_lb_target_group" "web_tg" {
  name     = "web_tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = "vpc-12345678"
  # Your code here to configure health checks
}

resource "aws_lb_target_group_attachment" "web_server_1_attachment" {
  target_group_arn = aws_lb_target_group.web_tg.arn
  target_id        = aws_instance.web_server_1.id
  port             = 80
}

resource "aws_lb_target_group_attachment" "web_server_2_attachment" {
  target_group_arn = aws_lb_target_group.web_tg.arn
  target_id        = aws_instance.web_server_2.id
  port             = 80
}

resource "aws_lb_listener" "web_listener" {
  load_balancer_arn = aws_lb.web_elb.arn
  port              = 80
  protocol          = "HTTP"
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web_tg.arn
  }
}

Hint

Inside the aws_lb_target_group resource, add a health_check block with the specified settings.

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