EC2 High Availability and Scalability for CloudOps

High Availability Pattern#

A production EC2 application normally runs across at least two Availability Zones:

Users
  -> Application Load Balancer
    -> Target group
      -> Auto Scaling group in AZ-a
      -> Auto Scaling group in AZ-b

The load balancer spreads traffic, health checks remove bad targets, and the Auto Scaling group replaces failed instances.

Elastic Load Balancing#

Target groups and health checks#

Target groups define where traffic goes. Health checks decide whether a target receives traffic.

Important settings:

• Protocol and port: usually HTTP 80 or HTTPS 443 for ALB targets.
• Health path: use a real endpoint such as /health, not the home page if it depends on downstream services.
• Healthy threshold: number of successful checks before traffic resumes.
• Unhealthy threshold: number of failed checks before target removal.
• Deregistration delay: connection draining time before a target is removed.

Auto Scaling Groups#

An Auto Scaling group manages capacity using a launch template and desired/min/max size.

Scaling policies#

Instance refresh#

Instance refresh rolls new launch template versions through the ASG without rebuilding the group.

Use it when you update the AMI ID, user data, instance type, security group, or IAM instance profile.

Placement Groups#

Hands-on: Application Load Balancer with Two EC2 Instances#

Goal: Put two web servers behind an ALB and confirm traffic is served only by healthy targets.

1. Launch two EC2 instances in different Availability Zones.
2. Use the nginx user data from the EC2 basics lab, but make each instance return a different hostname.
3. Create a security group for the ALB: inbound HTTP 80 from 0.0.0.0/0, outbound all traffic.
4. Update the EC2 security group to allow inbound HTTP 80 from the ALB security group.
5. Create a target group with target type Instances, protocol HTTP, port 80, and health check path /.
6. Register both instances as targets.
7. Create an internet-facing Application Load Balancer across at least two public subnets.
8. Add an HTTP 80 listener that forwards to the target group.
9. Wait until both targets are healthy.
10. Open the ALB DNS name several times and confirm both instances serve traffic.
11. Stop nginx on one instance:

sudo systemctl stop nginx

12. Watch the target become unhealthy, then confirm the ALB only routes to the healthy instance.
13. Restart nginx and confirm the instance re-enters service.

Hands-on: Auto Scaling Group Behind an ALB#

Goal: Replace individual instances with an ASG that maintains desired capacity.

1. Create a launch template using Amazon Linux 2023, t3.micro, the EC2 web security group, and nginx user data.
2. Create an Auto Scaling group from the launch template.
3. Select two or more subnets across different Availability Zones.
4. Attach the existing target group.
5. Set desired capacity 2, minimum 2, maximum 4.
6. Enable ELB health checks.
7. Create a target tracking policy for average CPU utilization at 50%.
8. Terminate one instance manually from the EC2 console.
9. Confirm the ASG launches a replacement and the target group returns to two healthy targets.
10. Clean up the ASG, launch template, target group, and load balancer.

Common SOA-C03 Exam Questions#

Q: Which load balancer supports path-based routing? Application Load Balancer.

Q: Which load balancer gives static IP addresses and handles TCP/UDP? Network Load Balancer.

Q: An ASG instance passes EC2 checks but the application is broken. What should the ASG use? Enable ELB health checks so target group health influences replacement.

Q: How do you roll a new AMI through an existing ASG? Create a new launch template version and start an instance refresh.

What to Learn Next#

1. AWS CloudWatch Monitoring - alarm on ALB, target group, and ASG metrics
2. AWS CloudFormation for CloudOps - deploy ASGs and ALBs as code
3. AWS Route 53 for CloudOps - add DNS failover and health checks