DEV Community

Cover image for 🚀 AWS 144: Scaling for Success - High Availability with ASG and ALB
Hritik Raj
Hritik Raj

Posted on

🚀 AWS 144: Scaling for Success - High Availability with ASG and ALB

#aws #ec2 #loadbalancer #100daysofcloud

🌐 Building Resilience: Auto Scaling and Load Balancing in AWS

Hey Cloud Architects 👋

AWS Architecture

Welcome to Day 44 of the #100DaysOfCloud Challenge!
Today, we are moving into the realm of High Availability (HA). No more single-point-of-failure servers! We are setting up a self-healing infrastructure where an Application Load Balancer (ALB) distributes traffic and an Auto Scaling Group (ASG) monitors our server health and CPU load to scale up or down automatically.

This task is part of my hands-on practice on the KodeKloud Engineer platform, focusing on real-world infrastructure scaling.

🎯 Objective

  • Create a Launch Template with a User Data script to auto-install Nginx.
  • Provision an Application Load Balancer (ALB) with a dedicated Target Group.
  • Configure an Auto Scaling Group (ASG) with a Target Tracking Policy (50% CPU).
  • Verify end-to-end traffic flow from the ALB DNS to the Nginx instances.

💡 The Power of Elasticity

Elasticity is the ability to grow or shrink infrastructure resources dynamically. By using ASG and ALB, we ensure that if a server dies, a new one takes its place, and if traffic surges, we add more capacity instantly.

🔹 Key Concepts

  • Launch Template: A blueprint for your instances (AMI, Instance Type, User Data).
  • Target Group: A logical grouping of EC2 instances that receive traffic from the Load Balancer.
  • Health Checks: The ALB periodically pings instances; if one fails, it stops sending traffic and the ASG replaces it.
  • Target Tracking Policy: Scales the group based on a specific metric (like maintaining an average 50% CPU utilization).

🛠️ Step-by-Step: Infrastructure Workflow

🔹 Phase A: Create the Launch Template

The Launch Template defines what we are launching.

  • Name: devops-launch-template.
  • AMI: Amazon Linux 2.
  • Instance Type: t2.micro.
  • Security Group: Allow HTTP (Port 80) from anywhere.
  • User Data: 
  #!/bin/bash
  amazon-linux-extras install nginx1 -y
  systemctl start nginx
  systemctl enable nginx
Enter fullscreen mode Exit fullscreen mode

🔹 Phase B: Load Balancer & Target Group Setup

The ALB acts as the "front door" for all incoming traffic.

  • Target Group: Create devops-tg (Target type: Instances, Port 80).

  • Load Balancer: Create devops-alb (Application Load Balancer).

  • Listeners: HTTP on Port 80, forwarding to devops-tg.

  • Subnets: Select at least two Public Subnets in different AZs.

🔹 Phase C: Auto Scaling Group Configuration

The ASG manages the number of instances running.

  • Name: devops-asg.
  • Launch Template: devops-launch-template.
  • Group Size: * Desired: 1
  • Minimum: 1
  • Maximum: 2
  • Scaling Policy: Target Tracking (Metric: Average CPU Utilization, Target: 50%).

  • Integration: Attach to the existing Load Balancer Target Group devops-tg.

🔹 Phase D: Verification

  • ALB DNS: Copy the DNS Name of devops-alb from the console.

  • Browser Test: Paste the DNS into your browser. If you see the "Welcome to nginx!" page, the traffic is successfully passing through the ALB to your ASG-managed instance.

✅ Verify Success

  • Auto Scaling: Ensure at least 1 instance is in "InService" state.
  • Target Group Health: Check the devops-tg targets tab to see the instance marked as Healthy.
  • URL Accessibility: The ALB DNS resolves correctly to the Nginx landing page.

📝 Key Takeaways

  • 🚀 User Data Automation: Bootstrapping Nginx via script ensures every new instance scaled by ASG is ready to serve traffic immediately.
  • 🛡️ Cross-AZ Availability: Distributing the ALB across multiple AZs ensures the Load Balancer itself remains available even if one AZ goes down.
  • 📦 Metric Scaling: Target tracking policies are much easier to manage than manual step scaling policies.

🚫 Common Mistakes

  • Missing User Data: If you forget the script, the instances will launch, but the ALB health check will fail because Nginx isn't running.
  • Security Group Conflict: Ensure the EC2 Security Group allows traffic from the ALB Security Group.
  • Single Subnet ALB: AWS requires at least two subnets in different availability zones for an ALB.

🌟 Final Thoughts

By integrating ASG and ALB, you have built a system that is not only scalable but also highly resilient. This architecture is the foundation of modern production environments, ensuring a seamless experience for users regardless of traffic load or server health.

🌟 Practice Like a Pro

Ready to build your own elastic architectures? Practice here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

Top comments (0)