Introduction

Handling unpredictable web traffic spikes while maintaining operational cost efficiency is a major infrastructure challenge. Running fixed EC2 instance capacity leads to either application downtime during high traffic or wasted cloud expenditure during idle hours. Fortunately, AWS Auto Scaling resolves this problem by automatically adjusting compute capacity based on real-time resource utilization.

In this step-by-step practical tutorial, we will build an automated elastic architecture. Specifically, we will configure an AWS Launch Template, provision an Auto Scaling Group across multiple Availability Zones, set up a Target Tracking Scaling Policy based on CPU load, and trigger automated scale-out events using a Linux stress testing tool.

Prerequisites

• AWS Account 
• Basic knowledge of AWS EC2 Instance

Step 1: Create an Amazon EC2 Launch Template

First, create an EC2 Launch Template to define the base OS, hardware, and access configuration for all scaled instances:

• Navigate directly to EC2 Dashboard > Launch Templates > Create Launch Template.
• Enter a descriptive template name (for example, Autoscaling-Template).
• Under Application and OS Images (AMI), select Ubuntu Server 24.04 LTS (or Amazon Linux 2023).
• Choose Instance Type: t2.micro (Free Tier eligible).
• Select your existing Key Pair for SSH access.
• Under Network Settings, create a Security Group allowing Port 22 (SSH) for management and Port 80 (HTTP) for web traffic.
• Finally, click Create Launch Template.

Step 2: Configure and Provision the Auto Scaling Group (ASG)

After defining the instance blueprint, configure the Auto Scaling Group to manage compute elasticity across multiple subnets:

• Navigate to EC2 > Auto Scaling Groups > Create Auto Scaling Group.
• Select your newly created Autoscaling-Template.
• Click Next.
• Choose your default VPC and select at least two Subnets in different Availability Zones (e.g., us-east-1a and us-east-1b) to ensure high availability.
• Click Next.
• Under Group Size, configure capacity constraints:
  • Desired Capacity: 1
  • Minimum Capacity: 1
  • Maximum Capacity: 3
• Under Scaling Policies, choose Target Tracking Scaling Policy.
• Set Metric Type: Average CPU Utilization, and specify Target Value: 50%. Consequently, AWS will launch new instances whenever average CPU usage exceeds 50%.
• Review your configuration and click Create Auto Scaling Group.

Step 3: Simulate High CPU Load and Verify Automated Scale-Out

To test whether the policy triggers scaling events, SSH into the running instance and run a CPU stress tool:

• Obtain the Public IP of the provisioned EC2 instance from the EC2 Dashboard.
• SSH into the instance using your terminal:

ssh -i "your-key.pem" ubuntu@YOUR_PUBLIC_IP
    

• Next, update package indexes and install the stress benchmark utility:

# For Ubuntu Server OS:
sudo apt update && sudo apt install -y stress

# (Note: If using Amazon Linux OS, run: sudo yum install -y stress instead)
    

• Run the stress command to simulate heavy multi-core CPU load for 5 minutes:

stress --cpu 2 --timeout 300
    

• Within 3 to 5 minutes, monitor the EC2 Dashboard and ASG Activity History. You will observe AWS automatically launching a second EC2 instance to balance the workload.

Step 4: Terminate Resources to Avoid Unexpected Cloud Costs

Once you have verified the scale-out event, clean up resources to prevent recurring charges:

• First, delete the Auto Scaling Group (this automatically terminates all managed instances).
• Next, delete the Launch Template.
• Finally, remove any unneeded Security Groups or Key Pairs created for this lab.

Production Auto Scaling Design Principles:

• Cooldown Periods & Warmups: Default instance warmup periods prevent ASG from over-provisioning instances before newly launched nodes fully initialize.
• Stateless Architecture: Ensure application code does not store local session files on individual EC2 disks. Use shared external services like Amazon ElastiCache (Redis) for user sessions and Amazon S3 / RDS for persistent storage.

Production Troubleshooting: Common AWS Auto Scaling Issues

Elastic compute groups rely on CloudWatch metrics to trigger actions. Use the diagnostic matrix below to resolve scaling failures fast:

Error 1: Auto Scaling Group Fails to Launch Instances (Capacity Reached)

• The Error Log (ASG Activity History):

Launching a new EC2 instance: status Failed. You have reached your quota for maximum number of EC2 instances.
    

• The Root Cause: Your AWS account hit its vCPU service quota limit in the selected AWS region, or the specified instance type (t2.micro) is unavailable in a specific Availability Zone.
• The Fix: Request a service quota increase via AWS Service Quotas, or configure your Launch Template to use flexible instance types (e.g., allowing both t2.micro and t3.micro).

Error 2: High CPU Load Induced But ASG Does Not Scale Out

• The Error Log: CPU usage stays above 80% on the single instance, but the Auto Scaling Group remains at 1 instance.
• The Root Cause: The stress command execution duration was too short, or the CloudWatch alarm evaluation period (typically 3 consecutive minutes) has not elapsed yet.
• The Fix: Ensure your stress command runs for at least 5 to 10 minutes (stress --cpu 2 --timeout 600). Additionally, inspect CloudWatch Alarms to verify if the CPU metric alarm state has transitioned to In Alarm.

Error 3: Package Installation Fails (command not found: yum or apt-get)

• The Error Log (Terminal):

sudo: yum: command not found
    

• The Root Cause: Attempting to run RedHat/Fedora package manager commands (yum) on a Debian/Ubuntu OS environment.
• The Fix: Always verify your Linux distribution beforehand. Use sudo apt update && sudo apt install -y stress for Ubuntu, and sudo yum install -y stress for Amazon Linux.