Skip to main content
In this lesson you’ll learn how to deploy a simple web server on Amazon EC2 and configure an Auto Scaling Group (ASG) that maintains a desired number of instances and scales out automatically under load. We use a Launch Template for instance settings, attach the ASG to an Application Load Balancer (ALB), create a target group, and implement a target-tracking scaling policy based on average CPU utilization. Key concepts covered:
  • Launch Template vs Launch Configuration
  • Auto Scaling Group basics (min / desired / max capacity)
  • Integrating an ALB and Target Group
  • Target-tracking scaling policy (average CPU)
  • Testing instance replacement and dynamic scale-out
Getting started: open the EC2 console and navigate to “Auto Scaling Groups” to create a new group.
A screenshot of the AWS EC2 console showing the "Create Auto Scaling group" page where you choose a launch template or configuration. The form includes an "Auto Scaling group name" field (filled with "web-autoscale") and a launch template selector with a "Next" button.
Create the Auto Scaling group and give it a name (for example, web-autoscale). The ASG requires either a Launch Template (recommended) or a Launch Configuration. Launch Templates provide versioning, parameter overrides, and more flexibility.
Use a Launch Template when you want version control and the ability to override settings at the ASG level (for example, instance type or user data). If you need the simplest option and don’t plan to reuse or version the configuration, a Launch Configuration can still work.
Because we don’t have a Launch Template yet, create one now — this opens a new tab where you specify the instance settings that will be used to launch EC2 instances.
A screenshot of the AWS EC2 console showing the "Launch template name and description" form filled with "myweb-template" and description "a prod webserver." A right-hand summary panel and an orange "Create launch template" button are visible.
In the launch template:
  • Provide a name (e.g., myweb-template) and description (e.g., prod web server).
  • Choose the AMI to use. If you have a custom AMI (for example, a Linux AMI with nginx preinstalled), pick it from “My AMIs / Owned by me”.
  • Select the instance type (for free-tier eligibility, choose t2.micro).
A screenshot of the AWS EC2 console showing the "Create launch template" page with an instance type dropdown (t2.nano, t2.micro, etc.) and a summary panel on the right listing the selected AMI, storage, and a "Create launch template" button. The free-tier eligibility note for t2.micro is visible.
Network and other settings in the Launch Template are optional. If you plan to reuse the template across multiple ASGs in different subnet sets, leave subnet selection blank so the ASG can pick subnets later. In this demo we:
  • Use an existing security group that allows inbound HTTP (port 80).
  • Leave subnet selection undefined in the template so the ASG can target private subnets at creation time.
  • Leave storage, tags, and advanced options at their defaults unless you have specific requirements.
After creating the Launch Template, return to the Auto Scaling Groups tab, refresh the list, and select your Launch Template and the version (default is version 1). Review the launch settings and continue to the VPC / subnet selection step.
A screenshot of the AWS EC2 Auto Scaling group configuration page showing VPC selection, chosen availability zones/subnets, and instance type/launch template details. Navigation buttons (Cancel, Skip to review, Previous, Next) are visible along the bottom.
Choose the VPC and the subnets where the ASG should launch instances. In this demo the instances are deployed to private subnets because we will front them with a public-facing load balancer (ALB). Note that some Launch Template settings (such as instance type) can be overridden at the ASG level when needed. Next, configure load balancing. Options:
  • No load balancer
  • Attach an existing load balancer
  • Create a new load balancer (recommended for web servers)
For a web server, create a new Application Load Balancer (ALB):
  • Make it internet-facing
  • Place the ALB in public subnets
  • Configure an HTTP listener on port 80
  • Create a Target Group that the ALB will forward requests to (for example, web-autoscale-1-TG)
A screenshot of the AWS EC2 Auto Scaling setup page showing the "Listeners and routing" section with Protocol HTTP, Port 80 and a new target group named "web-autoscale-1-tg." Below it are VPC Lattice integration options and sections for health checks.
Enable Elastic Load Balancing health checks for the ASG and set a health check grace period. A common default is 300 seconds to allow application startup before health checks begin.
A screenshot of the AWS EC2 Auto Scaling configuration page showing health check options, with Elastic Load Balancing health checks enabled and a health check grace period set to 300 seconds. The lower section shows additional settings and navigation buttons (Cancel, Skip to review, Previous, Next).
Configure capacity and a scaling policy. Capacity settings example: For scaling, add a target-tracking scaling policy. In this demo we set the policy to maintain average CPU utilization at 40%. This relatively low threshold demonstrates autoscaling quickly; in production choose thresholds that match your workload (often higher than 40%). The ASG will add or remove instances to keep the average CPU near the target. When ready, review and create the Auto Scaling Group. AWS will provision:
  • the Auto Scaling Group,
  • the initial EC2 instance(s),
  • the ALB,
  • the Target Group.
Once deployed, inspect the ASG details (capacity, Launch Template, network settings, and attached load balancer).
A screenshot of the AWS EC2 Auto Scaling groups console showing an Auto Scaling group named "web-autoscale." The group uses launch template "myweb-template," has desired capacity 1 (min 1, max 3), and spans availability zones us-east-1a and us-east-1b.
Check the Target Group to confirm instance registration and health check status. Instances initially show as initial and move to healthy once health checks pass.
A screenshot of the AWS EC2/Target Groups console showing the "web-autoscale-1-tg" target group. It shows one registered instance using HTTP port 80 with health status listed as initial (0 healthy).
Verify the ALB security group allows inbound HTTP and that the ALB is associated with the correct public subnets. Open the ALB DNS name in a browser to confirm the web server responds (for example: “Welcome to KodeKloud”). Testing ASG behavior
  1. Simulate instance failure:
    • Terminate the instance that the ASG created. The Auto Scaling Group will detect the drop below Desired capacity and will launch a replacement instance automatically.
A screenshot of the AWS EC2 console showing a "Terminate instance?" confirmation dialog warning that the root EBS volume will be deleted. It lists an instance ID with termination protection disabled and shows Cancel and Terminate buttons, with the EC2 navigation pane visible on the left.
  1. Monitor ASG activity:
    • Open the ASG Activity history to see entries showing instance termination and the subsequent launch of a replacement to restore desired capacity.
  2. Simulate high load to trigger scale-out:
    • Increase CPU load on the running instance to make the ASG’s target-tracking policy scale out additional instances. The configured policy aims for average CPU = 40%; when the average rises above that, the ASG will add instances up to the configured maximum (3 in this demo).
To generate CPU load, SSH to the instance and run a CPU stress tool (the commands below are example workflows):
  • SSH to the instance (example):
  • Check current CPU usage with top:
Sample (abbreviated) top output showing idle CPU before stress:
  • Run a CPU stress process (example using the stress utility):
After starting stress, top will show CPU near 100% for the stress process:
Within a short period the target-tracking policy should trigger and the ASG will scale out (increase Desired capacity) to bring average CPU closer to the 40% target. The ASG may add instances up to the configured maximum (3 in this demo).
A screenshot of the AWS EC2 Auto Scaling Groups console. It shows an auto scaling group named "web-autoscale" with target-tracking scaling enabled to maintain average CPU utilization at 40%.
After scaling completes, check the Instances view — you should see up to three instances running for the ASG. The ASG scaled up because the CPU averaged above the 40% threshold; it launched additional instances to reduce the average CPU across the group.
Screenshot of the AWS EC2 console on the Auto Scaling groups page. It shows an auto scaling group named "web-autoscale" with its launch template, capacity (min/max/desired) and recent activity history.
Clean up
  • Delete the Auto Scaling Group (this will terminate managed instances).
  • Remove the ALB and Target Group if they are no longer required.
  • Remove any other resources you created (security groups, key pairs, custom AMIs) to avoid ongoing charges.
Best practices: choose appropriate scaling thresholds and use cooldown or warm-up periods that fit your application startup characteristics. Test scaling policies in a controlled environment and always clean up resources to avoid unexpected costs.
Links and references

Watch Video