AWS Auto Scaling Groups: Master Health Checks, Scaling Policies & CPU-Based Scaling Lab 2026

Introduction

Here’s the thing about Auto Scaling Groups—every junior engineer thinks they understand them until production traffic spikes at 2 AM and their instances aren’t scaling. I’ve been there. Three years ago, I watched a perfectly configured ASG refuse to scale during a flash sale because someone set the cooldown period to 15 minutes instead of 60 seconds. That incident cost the company roughly $47,000 in lost transactions.

This lab teaches you how Amazon Web Services (AWS) Auto Scaling actually works under the hood. You’ll configure an Auto Scaling Group from scratch, wire up health checks that don’t lie to you, and implement CPU-based scaling policies that respond to real load—not theoretical benchmarks.

Auto Scaling matters because modern applications don’t have predictable traffic patterns anymore. Your Monday morning looks nothing like your Friday evening. Black Friday demolishes your typical Tuesday. Without proper EC2 Auto Scaling, you’re either burning money on idle instances or watching your application crumble under load.

This lab is for engineers who’ve launched a few EC2 instances manually and are ready to graduate to infrastructure that manages itself. If you’ve ever SSH’d into a server to restart a crashed process at midnight, this lab will change how you think about reliability.

From an architect’s perspective, Auto Scaling Groups aren’t just about handling traffic spikes—they’re your first line of defense against instance failures. When an EC2 instance dies (and they will die), your ASG should replace it before your monitoring even alerts.

The most common beginner mistakes I see? Setting minimum capacity to zero (your ASG will happily scale down to nothing), ignoring health check grace periods (new instances get terminated before they finish booting), and using simple scaling when target tracking would solve the problem with half the configuration.

Lab Overview

In this hands-on lab, you’ll build a production-ready Auto Scaling Group that automatically adjusts capacity based on CPU utilization. By the end, you’ll have infrastructure that scales out when load increases and scales in when demand drops—without any manual intervention.

Skills you’ll gain:

• Creating and configuring Auto Scaling Groups via the AWS Console
• Understanding the relationship between desired, minimum, and maximum capacity
• Implementing EC2 and ELB health checks
• Configuring target tracking scaling policies
• Generating artificial load to trigger scaling events
• Interpreting ASG activity history and CloudWatch metrics

Real-world production use cases:

Web applications with variable traffic patterns, API backends serving mobile applications, batch processing systems that need burst capacity, and microservices architectures where individual services scale independently. I’ve implemented ASGs for e-commerce platforms handling 50,000 concurrent users and for internal tools serving teams of 20—the pattern works at every scale.

Auto Scaling knowledge is non-negotiable for anyone touching production AWS infrastructure. During interviews, I always ask candidates to explain what happens when an instance fails inside an ASG. The answers reveal immediately who has actually operated these systems versus who just read the documentation.

Prerequisites

Before starting this lab, confirm you have the following:

AWS Account Access:

• IAM permissions for EC2, Auto Scaling, CloudWatch, and Elastic Load Balancing
• If using an organization account, verify your IAM policies include autoscaling:* and elasticloadbalancing:* actions

Existing Resources:

• A Launch Template configured with your preferred AMI (Amazon Linux 2023 recommended)
• If you haven’t created a Launch Template, complete {Lab 3.1 — Launch Templates} first
• VPC with at least two subnets across different Availability Zones
• Security group allowing inbound SSH (port 22) and HTTP (port 80) if using a load balancer

Technical Knowledge:

• Basic EC2 instance lifecycle understanding
• Familiarity with VPC concepts (subnets, availability zones)
• Command-line comfort for optional CLI verification steps

Optional but Recommended:

• AWS CLI configured with appropriate credentials
• Session Manager access for connecting to instances without SSH keys

Step-by-Step Hands-On Lab

Step 1: Navigate to Auto Scaling Groups

Open the AWS Console and navigate to EC2 → Auto Scaling Groups in the left sidebar. You’ll find it under the “Auto Scaling” section, not directly under “Instances.”

Why this matters: Auto Scaling Groups live in the EC2 service but function as a separate control plane. They don’t manage instances directly—they manage the desired state, and AWS reconciles reality to match.

What you should see: An empty list if this is a fresh account, or existing ASGs if your team has already configured some. The interface shows Name, Desired/Min/Max capacity, and Launch Template at a glance.

Step 2: Create a New Auto Scaling Group

Click Create Auto Scaling group. Enter a descriptive name—I recommend including the environment and purpose, like prod-web-asg or dev-api-scaling-group.

Common misconfiguration: Vague names like “my-asg” or “test-1” create confusion when you’re debugging at 3 AM. Your future self will thank you for clear naming.

Step 3: Select Your Launch Template

Choose the Launch Template you created in the prerequisites. Select the latest version or a specific version if you’re testing changes.

AWS Console path: Create Auto Scaling group → Choose launch template or configuration → Select from dropdown

What you should see: Your template name, version number, and a summary showing AMI ID, instance type, and key pair.

Why this matters: The Launch Template defines what gets launched. The Auto Scaling Group defines when and how many. Separating these concerns lets you update instance configurations without touching scaling logic.

Step 4: Configure VPC and Subnets

Under “Network,” select your VPC. For Availability Zones and subnets, select at least two subnets in different AZs.

Sample configuration:

• VPC: vpc-0abc123def456 (your main VPC)
• Subnets: subnet-az1-private, subnet-az2-private

Why this matters: Spreading instances across multiple Availability Zones protects against AZ-level failures. AWS will distribute instances as evenly as possible across your selected subnets. Additionally, Auto Scaling Groups will automatically rebalance instances across Availability Zones if one AZ becomes overrepresented—for example, after a scale-in event removes instances unevenly.

Common misconfiguration: Selecting only one subnet. Your ASG will work, but you’ve eliminated the multi-AZ resilience that makes Auto Scaling valuable for reliability.

Step 5: Configure Capacity Settings

Set your capacity parameters:

• Desired capacity: 2 (the number of instances ASG will try to maintain)
• Minimum capacity: 1 (never scale below this, even during low load)
• Maximum capacity: 4 (ceiling to prevent runaway scaling costs)

Why this matters: Desired capacity is your steady-state target. Minimum prevents scaling to zero during off-hours. Maximum protects your AWS bill from infinite scaling loops.

Architect insight: For production workloads, I typically set minimum to handle your baseline traffic with some headroom. If one instance can handle 100 requests/second and your baseline is 80 requests/second, set minimum to 2—not 1.

Step 6: Configure Health Checks

This is where most ASG problems originate. Configure both health check types:

EC2 Health Checks:

• Enabled by default
• Checks if the instance is running at the hypervisor level
• Doesn’t know if your application crashed

ELB Health Checks (if using a load balancer):

• Check “Turn on Elastic Load Balancing health checks”
• Requires an attached load balancer
• Validates your application is actually responding

Health check grace period: Set to 300 seconds (5 minutes) initially.

Why this matters: New instances need time to boot, install updates, and start your application. If your grace period is too short, ASG will terminate instances before they finish initializing—creating a death loop where instances launch, get marked unhealthy, terminate, and new ones launch endlessly.

What you should see: Health check type showing “EC2” or “EC2 and ELB” depending on your selection.

Step 7: Attach Load Balancer (Optional)

If you have an existing Application Load Balancer, attach it here:

• Select “Attach to an existing load balancer”
• Choose your target group
• Enable ELB health checks

For this lab, you can skip the load balancer attachment if you’re focusing purely on CPU-based scaling behavior. We’ll cover ALB integration deeply in {Lab 3.3 — Load Balancers & Target Groups}.

Step 8: Configure Target Tracking Scaling Policy

Under “Scaling policies,” select Target tracking scaling policy.

Configuration:

• Scaling policy name: cpu-target-tracking-70
• Metric type: Average CPU utilization
• Target value: 70

What this means: ASG will add instances when average CPU across all instances exceeds 70%, and remove instances when it drops significantly below.

Why target tracking over simple scaling: Target tracking handles the math for you. It determines how many instances to add based on how far above target you are. Simple scaling requires you to define exact thresholds and instance counts—more configuration, more room for error.

Instance warmup: Set to 300 seconds. This prevents newly launched instances from skewing the average CPU metric before they’re fully loaded.

Important distinction: With target tracking policies, traditional cooldowns are largely managed automatically by AWS. Instance warmup is what really controls evaluation timing. Don’t confuse this with simple scaling cooldowns—they’re different mechanisms entirely. Target tracking handles the internal scaling logic, while instance warmup tells AWS how long to wait before including a new instance’s metrics in scaling decisions.

Step 9: Review and Create

Review all settings on the summary page. Verify:

• Correct Launch Template and version
• Multiple subnets selected
• Capacity values make sense
• Health check grace period is adequate
• Scaling policy is configured

Click Create Auto Scaling group.

What you should see: ASG creation confirmation, and within 1-2 minutes, your desired capacity number of instances launching in EC2.

Step 10: Generate CPU Load

Connect to one of your instances via Session Manager or SSH. Install and run the stress utility:

sudo yum install -y stress
stress --cpu $(nproc) --timeout 300

The $(nproc) dynamically detects available vCPUs, which prevents confusion on smaller instance types like t3.micro (2 vCPUs) where --cpu 4 wouldn’t produce expected results.

This generates 100% CPU load for 5 minutes.

What happens next: CloudWatch collects CPU metrics (1-minute granularity with detailed monitoring). After 3-5 data points above 70%, the scaling policy triggers. ASG launches additional instances.

Step 11: Observe Scale-Out and Scale-In

Monitor the ASG activity history:

Console path: EC2 → Auto Scaling Groups → [Your ASG] → Activity tab

What you should see:

• “Launching a new EC2 instance” events during high CPU
• Instance count increasing toward maximum
• After stress ends and CPU drops, “Terminating an EC2 instance” events
• Gradual return to desired capacity

The scale-in behavior is deliberately slower than scale-out. AWS assumes it’s safer to have extra capacity than to prematurely terminate instances.

Real Lab Experiences — Architect Insights

Let me share some incidents that taught me more than any documentation ever could.

The 15-Minute Cooldown Disaster: A colleague configured a 15-minute cooldown thinking it would prevent “flapping.” During a traffic spike, the ASG added one instance, then waited 15 minutes before evaluating again. Traffic kept growing. By the time the second instance launched, the first was completely overwhelmed. Lesson: cooldown periods should match your instance boot time, not arbitrary “safe” values.

The Health Check Death Spiral: I once spent four hours debugging an ASG that kept terminating instances immediately after launch. The health check grace period was 60 seconds, but the application took 90 seconds to start. Every instance was marked unhealthy before it could serve traffic. Extending the grace period to 180 seconds fixed it instantly.

The $12,000 Weekend: Without maximum capacity limits, a runaway process generating CPU load triggered infinite scaling. Monday morning revealed 47 m5.xlarge instances running since Friday night. Now I never create an ASG without a maximum capacity that makes me uncomfortable—if you actually need that many instances, you’ll notice and increase it deliberately.

Cold Start Reality: Java applications with heavy dependency injection often need 2-3 minutes before they’re truly ready. Your health check might pass (the process is running), but request latency is terrible because caches are cold and JIT compilation hasn’t optimized hot paths yet. Consider custom health checks that verify actual application readiness.

Advice for production: Start with conservative scaling policies. It’s much easier to make scaling more aggressive after observing real traffic patterns than to recover from scaling incidents.

Validation and Testing

Confirm Instances Are Running

Console verification: EC2 → Instances → Filter by your ASG tag

CLI verification:

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names your-asg-name \
  --query 'AutoScalingGroups[0].Instances[*].[InstanceId,HealthStatus,LifecycleState]' \
  --output table

Expected output: Instances showing “Healthy” and “InService” state.

Monitor CloudWatch Metrics

Console path: CloudWatch → Metrics → EC2 → By Auto Scaling Group

Key metrics to watch:

• CPUUtilization (Average)
• GroupDesiredCapacity
• GroupInServiceInstances
• GroupTotalInstances

Check ASG Activity History

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name your-asg-name \
  --max-items 10

Expected during scale-out: Activity descriptions mentioning “Launching a new EC2 instance” with successful status.

Expected during scale-in: “Terminating an EC2 instance” activities, typically 10-15 minutes after load decreases.

Troubleshooting Guide

ASG Not Scaling Out

Symptom: CPU is high, but no new instances launch.

Debugging steps:

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name your-asg-name

Check for error messages. Common causes:

• Maximum capacity already reached
• Scaling cooldown still active
• IAM permissions insufficient for launching instances
• Launch Template references deleted AMI or security group

Instances Launching and Immediately Terminating

Symptom: Constant churn—instances launch, then terminate within minutes.

Root cause: Health check grace period shorter than boot time.

Fix: Increase grace period in ASG settings. Watch instance system logs to determine actual boot time.

CPU Metrics Not Triggering Scaling

Symptom: Instances show high CPU in EC2 console, but ASG doesn’t respond.

Debugging:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=AutoScalingGroupName,Value=your-asg-name \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-01T01:00:00Z \
  --period 60 \
  --statistics Average

Verify metrics are being collected at the ASG level, not just instance level. Ensure detailed monitoring is enabled.

Health Checks Failing

aws ec2 describe-instances \
  --instance-ids i-xxxxx \
  --query 'Reservations[0].Instances[0].State'

If instance is running but marked unhealthy, check:

• Security group allows health check traffic
• Application is listening on expected port
• Health check path returns 200 status code

Wrong Subnet Selection Errors

Symptom: “We currently do not have sufficient capacity in the Availability Zone you requested.”

Fix: Add additional subnets in different AZs, or select subnet in AZ with available capacity.

AWS Best Practices — Solutions Architect Level

Security

• Use IAM roles on instances, never embedded credentials
• Launch instances in private subnets behind a load balancer
• Apply least-privilege security groups—instances shouldn’t accept direct internet traffic
• Enable IMDSv2 (Instance Metadata Service v2) in your Launch Template

Reliability

• Always select subnets in at least two Availability Zones
• Set minimum capacity to handle baseline load if one AZ fails
• Use ELB health checks when load balancer is attached—EC2 checks don’t verify application health
• Configure appropriate health check grace periods for your application startup time

Operational Excellence

• Enable CloudWatch alarms for GroupDesiredCapacity approaching GroupMaxSize
• Tag all ASG resources consistently for cost allocation and operational visibility
• Document scaling thresholds and rationale in runbooks
• Review scaling activity history weekly during initial deployment

Cost Optimization

• Right-size instance types in your Launch Template based on actual utilization
• Use appropriate cooldown periods to prevent unnecessary scaling oscillation
• Consider Spot Instances for fault-tolerant workloads with mixed instance policies
• Set maximum capacity thoughtfully—your AWS bill is the ceiling
• Understand termination policies: ASGs terminate instances based on configurable termination policies (default: oldest launch template, then oldest instance). During scale-in, knowing which instances get terminated first helps you design stateless architectures that handle this gracefully

Performance Efficiency

• Enable detailed monitoring for 1-minute CloudWatch metrics
• Use target tracking policies—they adapt to workload patterns better than step scaling
• Configure instance warmup to prevent scaling decisions based on incomplete data
• Consider predictive scaling for workloads with known traffic patterns

Tagging Strategy

aws autoscaling create-or-update-tags \
  --tags ResourceId=your-asg-name,ResourceType=auto-scaling-group,Key=Environment,Value=production,PropagateAtLaunch=true \
         ResourceId=your-asg-name,ResourceType=auto-scaling-group,Key=Application,Value=web-tier,PropagateAtLaunch=true

The PropagateAtLaunch=true ensures instances inherit ASG tags—critical for cost allocation and operational automation.

AWS Auto Scaling Interview Questions

These are actual questions I’ve asked candidates during Solutions Architect and DevOps Engineer interviews. Knowing these answers demonstrates real operational experience, not just certification knowledge.

Entry-Level Questions

Q: What happens when an EC2 instance inside an Auto Scaling Group fails?

Expected answer: The ASG detects the failure through health checks (either EC2 status checks or ELB health checks), marks the instance as unhealthy, terminates it, and automatically launches a replacement instance to maintain the desired capacity. The new instance launches in an available Availability Zone based on the ASG’s subnet configuration.

Q: What’s the difference between desired capacity, minimum capacity, and maximum capacity?

Expected answer: Minimum capacity is the floor—ASG will never scale below this number, even during zero traffic. Maximum capacity is the ceiling—ASG won’t scale beyond this regardless of demand, protecting your budget. Desired capacity is the target number ASG actively maintains; scaling policies adjust this number up or down within the min/max bounds.

Q: Why would you set minimum capacity to 2 instead of 1?

Expected answer: With minimum capacity of 1, a single instance failure leaves you with zero capacity until a replacement launches—typically 2-5 minutes of downtime. With minimum capacity of 2 across multiple AZs, one instance failure still leaves you with 50% capacity while the replacement launches. This is foundational high availability design.

Mid-Level Questions

Q: Your ASG instances keep launching and terminating in a loop. What’s happening?

Expected answer: This is typically a health check grace period misconfiguration. If the grace period (e.g., 60 seconds) is shorter than the application startup time (e.g., 90 seconds), ASG marks instances as unhealthy before they finish booting. The fix is increasing the health check grace period to exceed your application’s full initialization time.

Q: Explain the difference between simple scaling, step scaling, and target tracking policies.

Expected answer: Simple scaling adds or removes a fixed number of instances based on a single CloudWatch alarm threshold—straightforward but inflexible. Step scaling allows different scaling actions at different threshold levels (e.g., add 1 instance at 60% CPU, add 3 instances at 80% CPU). Target tracking automatically calculates how many instances to add or remove to maintain a specified metric target (e.g., 70% CPU average)—it’s self-adjusting and typically the best choice for most workloads.

Q: How does instance warmup differ from cooldown periods?

Expected answer: Cooldown periods (primarily for simple scaling) prevent any scaling activity for a specified duration after a scaling action. Instance warmup (used with target tracking and step scaling) tells ASG how long to wait before including a newly launched instance’s metrics in scaling calculations—the instance is running but its data isn’t influencing decisions yet. With target tracking, AWS manages cooldowns internally, making instance warmup the primary tuning parameter.

Senior/Architect-Level Questions

Q: How would you design an ASG for an application with known traffic patterns—high during business hours, minimal at night?

Expected answer: Combine scheduled scaling with target tracking. Use scheduled actions to increase desired capacity before business hours begin and decrease after hours end—this handles predictable patterns proactively. Layer target tracking on top to handle unexpected spikes during business hours. For even better optimization, consider predictive scaling if you have consistent historical patterns—AWS can analyze past metrics and pre-scale before demand arrives.

Q: Your team is considering mixed instance policies with Spot Instances. What are the architectural implications?

Expected answer: Mixed instance policies let you combine On-Demand and Spot Instances for cost savings (60-90% reduction for Spot). Architecturally, this requires: stateless application design (Spot can terminate with 2-minute warning), multiple instance types in your configuration to increase Spot availability, capacity rebalancing enabled to proactively replace at-risk Spot instances, and On-Demand baseline capacity for critical minimum instances. The application must handle graceful degradation—connection draining, in-flight request completion, and state externalization to services like ElastiCache or RDS.

Q: An ASG with target tracking at 70% CPU isn’t scaling, but instances show 85% CPU in CloudWatch. Debug this.

Expected answer: Check several things: First, verify the CloudWatch metrics are aggregated at the ASG level, not individual instance level—target tracking uses the ASG dimension. Second, confirm the scaling policy is attached and active, not suspended. Third, check if the ASG has reached maximum capacity—it won’t scale beyond this regardless of metrics. Fourth, examine the ASG activity history for any error messages indicating launch failures (AMI deleted, security group missing, insufficient capacity in AZ). Fifth, verify the instance warmup period hasn’t created a blind spot where recently launched instances aren’t being included yet.

Frequently Asked Questions

Conclusion and Next Lab

You’ve built an Auto Scaling Group that responds to real workload changes. More importantly, you understand why ASGs behave the way they do—the health checks, the cooldowns, the capacity calculations.

This changes how you design systems. Instead of provisioning for peak load (wasteful) or hoping traffic stays predictable (naive), you build infrastructure that adapts. Your Monday morning capacity is different from your Friday evening capacity, and that’s fine—your ASG handles it.

The mistakes this lab helps you avoid: death spirals from misconfigured health checks, runaway costs from missing maximum capacity, and application outages from cooldown periods that don’t match reality.

Next recommended lab: {Lab 3.3 — Load Balancers & Target Groups (ALB Deep Dive)}. You’ll connect your Auto Scaling Group to an Application Load Balancer, configure target groups, and implement path-based routing—completing the production-ready autoscaling architecture.

Additional Resources

• AWS Auto Scaling Documentation
• Target Tracking Scaling Policies
• Auto Scaling Instance Lifecycle
• Related post: EC2 Instance Types Deep Dive