DEV Community

Cover image for AWS ALB Scaling: Set Up Application Load Balancer with Auto Scaling Group (ASG)
Azam Akram
Azam Akram

Posted on • Originally published at solutiontoolkit.com

AWS ALB Scaling: Set Up Application Load Balancer with Auto Scaling Group (ASG)

#aws #devops #infrastructure #tutorial

In any well-architected cloud setup, managing traffic efficiently and scaling resources on demand are key to keeping your applications fast, reliable, and cost-efficient.

AWS makes this easy with two core services: the Elastic Load Balancer (ELB) for routing traffic, and Auto Scaling Groups (ASG) for automatically adjusting compute capacity as traffic changes.

The AWS Elastic Load Balancer automatically distributes incoming requests across multiple targets, such as, EC2 instances, containers, or IPs, across different Availability Zones (AZs). AWS offers several types of load balancers, including Application, Network, and Gateway Load Balancers, each suited for different scenarios.

In this guide, we’ll set up an Application Load Balancer (ALB) connected to an Auto Scaling Group (ASG) using the AWS CLI.

Our setup will dynamically launch and manage EC2 instances, organized into a Target Group, ensuring smooth load distribution and high availability.

What We'll Do

  1. Create a security group to allow necessary inbound traffic.
  2. Define a launch template with EC2 instance configuration and a user-data script to deploy a simple web server.
  3. Set up an Auto Scaling Group (ASG) to handle scaling based on demand.
  4. Create a Target Group to manage and distribute traffic.
  5. Configure an Application Load Balancer (ALB) and listener, linking it to the Target Group for seamless load balancing.

Prerequisites

Why Combine ALB with ASG?

Pairing an Application Load Balancer (ALB) with an Auto Scaling Group (ASG) gives you a scalable, cost-effective, and fault-tolerant setup. Here’s why it’s a great combo:

  1. Automatic Scaling – ASG adjusts the number of EC2 instances in real time as traffic changes.
  2. Cost Optimization – You only pay for what you use, saving costs during low-traffic hours.
  3. High Availability – ALB spreads requests across healthy instances in multiple AZs, avoiding single points of failure.
  4. Better Fault Tolerance – If one instance fails, ALB automatically routes traffic to healthy ones, ensuring smooth performance.

Let’s dive in and start building!

Step 1: Create a Security Group

Before launching EC2 instances or attaching them to a Load Balancer, we need to define a security group, which is a virtual firewall that controls inbound and outbound traffic. In this step, we’ll create a security group that allows SSH (for remote access) and HTTP (for web traffic) connections.

Run the following command to create a new security group:

aws ec2 create-security-group \
  --group-name my-test-security-group \
  --description "Security Group for My ALB" \
  --region <your-region-id>
Enter fullscreen mode Exit fullscreen mode

This command creates a security group in your specified AWS region. Next, we’ll add inbound rules that define what types of traffic are allowed to reach our EC2 instances.

aws ec2 authorize-security-group-ingress \
  --group-name my-test-security-group \
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0 \
  --region <your-region-id>
Enter fullscreen mode Exit fullscreen mode

This rule enables SSH access on port 22, allowing you to connect to the instance from your terminal or SSH client.
We use tcp as the protocol since SSH operates over the TCP layer.

Note: Allowing SSH from all IP addresses (0.0.0.0/0) is convenient for testing, but not secure for production. In real deployments, you should restrict this to your own IP or a trusted network range, for example: --cidr 203.0.113.25/32

Now we create another inbound rule to allow HTTP traffic on port 80 over TCP.

aws ec2 authorize-security-group-ingress \
  --group-name my-test-security-group \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0 \
  --region <your-region-id>
Enter fullscreen mode Exit fullscreen mode

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/ec2-security-group-console.webp"
alt="ec2-security-group-console"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Let's verify the security group in the AWS Management Console:

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/ec2-security-group-gui.webp"
alt="ec2-security-group-gui"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 2: Create a Launch Template

An AWS Launch Template is a reusable blueprint that defines the configuration settings for your EC2 instances, such as the AMI, instance type, key pair, security groups, and optional user-data scripts.

Using a launch template helps standardize instance launches and simplifies scaling operations within an Auto Scaling Group (ASG).

In this step, we’ll manually create a launch template using the AWS Management Console.

  1. Open the EC2 Dashboard in the AWS Management Console.
  2. In the left sidebar, choose Launch Templates, then click Create launch template.
  3. Enter a name, such as MyLaunchTemplate.
  4. Under Application and OS Images (Amazon Machine Image), select Amazon Linux 2023 AMI (eligible for the free tier).
  5. Choose an Instance type, e.g., t2.micro.
  6. Skip the Key pair step for now (this is fine for testing, but in production, you should always create one for SSH access).
  7. Under Network settings, select the previously created security group (my-test-security-group).
  8. Expand Advanced details and paste the following user data script to automatically install and configure a simple web server. Finally, click Create launch template. 
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd

# Get the EC2 instance's availability zone
EC2AZ=$(TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/placement/availability-zone)

# Create a simple HTML file with the availability zone info
echo '<center><h1>Hello from Web Server in Availability Zone: AZID </h1></center>' > /var/www/html/index.txt
sed "s/AZID/$EC2AZ/" /var/www/html/index.txt > /var/www/html/index.html
Enter fullscreen mode Exit fullscreen mode

This user-data script runs automatically when the instance starts. It:

  • Installs and enables the Apache (httpd) web server.
  • Fetches the Availability Zone from the instance’s metadata.
  • Displays a custom message in the browser showing the zone where the instance is running — useful when testing load balancing across multiple zones.

Note:

Every EC2 instance has access to instance metadata, which contains information like instance ID, region, IP addresses, and Availability Zone.

AWS exposes this data through a special internal endpoint — 169.254.169.254 — accessible only from within the instance.

Learn more about instance metadata in the official AWS documentation.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/launch-template.webp"
alt="launch-template"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 3: Create an Auto Scaling Group (ASG)

Now we will create an Auto Scaling group named "my-auto-scaling-group" using a launch template we previously created "MyLaunchTemplate." It sets the desired capacity to 2 instances, with a minimum of 1 and a maximum of 5 instances, distributed across two availability zones. The instances are launched in two different subnets within a Virtual Private Cloud (VPC) to ensure scalability and high availability.

aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-auto-scaling-group \
  --launch-template "LaunchTemplateName=MyLaunchTemplate" \
  --min-size 1 --max-size 5 --desired-capacity 2 \
  --availability-zones "<availability-zone-1>" "<availability-zone-2>" \
  --vpc-zone-identifier "<subnet-id-1>,<subnet-id-2>"
Enter fullscreen mode Exit fullscreen mode

Note: Replace <subnet-id-x> and <availablity-zone-x> according to your setup.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/security-group.webp"
alt="security-group"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 4: Create Target Group and Load Balancer

Create a Target Group

A Target Group defines the set of resources (such as EC2 instances) that an Application Load Balancer (ALB) routes incoming requests to. It continuously performs health checks to ensure traffic is sent only to healthy instances, improving reliability and availability.

In this step, we’ll create an HTTP-based target group named my-target-group that listens on port 80 within your VPC. This target group will later be linked to your Auto Scaling Group (ASG) so that any new instances launched by the ASG are automatically registered as targets.

aws elbv2 create-target-group \
--name my-target-group \
--protocol HTTP \
--port 80 \
--vpc-id <vpc-id>
Enter fullscreen mode Exit fullscreen mode

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/target-group.webp"
alt="target-group"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Note: Target group is created but no EC2 instances are registered yet. Instances will be registered automatically once the Auto Scaling Group is attached in a later step.

Create an Application Load Balancer (ALB)

An Application Load Balancer (ALB) intelligently distributes incoming HTTP and HTTPS traffic across multiple targets, such as EC2 instances, in one or more Availability Zones (AZs).

The following command creates an ALB named my-alb, specifying the subnets and security groups that determine where and how the load balancer operates:

aws elbv2 create-load-balancer \
--name my-alb \
--subnets <subnet-id-1> <subnet-id-2> \
--security-groups <security-group-id> \
Enter fullscreen mode Exit fullscreen mode

This command:

  • Creates an Application Load Balancer called my-alb.
  • Associates it with two subnets (usually in different Availability Zones) for high availability.
  • Applies the specified security group, which defines what inbound and outbound traffic is allowed for the load balancer.

Note: Replace <subnet-id-1>, <subnet-id-2>, and <security-group-id> with actual values from your AWS setup.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/create-load-balancer.webp"
alt="create-load-balancer"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Note: You need to note down LoadBalancerArn, which we will use in coming sections.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/load-balancer-setting.webp"
alt="load-balancer-setting"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Create a Listener and Link it to the Target Group

A Listener is a key component of an Application Load Balancer (ALB). It checks for incoming connection requests on a specific port and protocol, then forwards the traffic to a designated Target Group based on defined rules.
In this step, we’ll create an HTTP listener on port 80 for our ALB, which will route all incoming web requests to the previously created target group.

aws elbv2 create-listener \
  --load-balancer-arn <alb-arn> \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=<target-group-arn>
Enter fullscreen mode Exit fullscreen mode

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/create-listener.webp"
alt="create-listener"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Attach the Target Group to the Auto Scaling Group

The Target Group must be linked to your Auto Scaling Group (ASG) so that any instances launched by the ASG are automatically registered with the Application Load Balancer (ALB).

This ensures that traffic is distributed only to healthy, actively running instances managed by the ASG.

Use the following command to attach the target group to your Auto Scaling group named ASG1:

aws autoscaling attach-load-balancer-target-groups \
  --auto-scaling-group-name ASG1 \
  --target-group-arns <target-group-arn>
Enter fullscreen mode Exit fullscreen mode

This command:

  • Connects the specified Target Group to your ASG.
  • Ensures that new instances launched by the ASG are automatically added to the target group for load balancing.
  • Enables health checks so unhealthy instances are replaced automatically.

After this step, the Auto Scaling Group will launch two EC2 instances (based on the desired capacity you configured earlier).

Once these instances pass their health checks, they’ll be marked as healthy, and the ALB will begin routing traffic to them automatically.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/create-auto-scaling.webp"
alt="create-auto-scaling"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

We can also check the Target Group to see that both instances are healthy.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/target-group.webp"
alt="target-group"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Step 5: Testing the Load Balancer

To verify that the Application Load Balancer (ALB) is correctly distributing traffic, open the ALB Dashboard in the AWS Management Console and note down the DNS name of your ALB.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/test-elb.webp"
alt="test-elb"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Enter this ALB DNS name in your web browser.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/browser-elb-1.webp"
alt="browser-elb-1"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

Now, refresh the browser several times.

src="/static/images/blog/setup-aws-alb-with-auto-scaling-group-asg-using-aws-cli/browser-elb-2.webp"
alt="browser-elb-2"
className="mx-auto my-6 w-full rounded-lg shadow-lg"
/>

As you refresh, you’ll notice that the web page alternates between different Availability Zones (AZs). This confirms that the Application Load Balancer is intelligently distributing incoming traffic across multiple EC2 instances (targets) in different zones.

Each request may reach a different instance within the Target Group, depending on factors like health status, capacity, and routing algorithm.

In summary, this test proves that your ALB and Auto Scaling Group (ASG) are working together as intended, automatically balancing the load between multiple healthy EC2 instances.

Step 6: Deleting the Setup

Once you’ve verified that your Application Load Balancer (ALB) and Auto Scaling Group (ASG) are working correctly, it’s good practice to clean up the resources to avoid ongoing AWS charges.

Run the following commands to delete the setup:

aws elbv2 delete-load-balancer --load-balancer-arn <alb-arn>
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name ASG1 --force-delete
Enter fullscreen mode Exit fullscreen mode

These commands:

  • Remove the ALB and its associated listeners and target group.
  • Delete the Auto Scaling Group along with any EC2 instances it launched (using the --force-delete flag ensures immediate deletion).

Note: You may also want to delete other related resources such as the launch template, target group, and security group if they are no longer needed.

Conclusion

You’ve successfully set up an AWS Application Load Balancer (ALB) integrated with an Auto Scaling Group (ASG) and Target Group — all using the AWS CLI.

This architecture automatically adjusts capacity based on demand while distributing traffic evenly across multiple instances, ensuring:

  • High availability across Availability Zones,
  • Fault tolerance through automatic health checks and scaling, and
  • Cost efficiency by running only the resources you need.

With this foundation, you can now expand the setup, for example, adding HTTPS with an SSL certificate, customizing health checks, or deploying containerized workloads behind the load balancer.

Top comments (0)