Skip to main content
In this lesson we’ll cover AWS Auto Scaling — what it does, how it works, and the key choices you’ll make when configuring Auto Scaling groups for Amazon EC2 instances. Imagine a bakery that bakes cupcakes to match customer demand. As more customers arrive, the bakery turns on additional ovens. When an oven reaches ~80% utilization, a new oven is switched on. When ovens sit near 20% capacity, some are turned off to save energy. AWS Auto Scaling groups provide the same behavior for EC2 instances: they add or remove instances to match demand so your application remains available and cost-effective. What you’ll learn:
  • Core Auto Scaling concepts
  • Capacity settings (min / desired / max)
  • Scaling policy types: manual, dynamic (target tracking, simple, step), and scheduled
  • Launch templates and why they’re recommended
  • Integrations with other AWS services
Core concepts and features of Auto Scaling groups
  • Scaling policies — define how the Auto Scaling group adjusts the desired capacity within its min/max bounds.
  • Auto-healing — Auto Scaling performs health checks and replaces unhealthy instances so the group maintains the desired capacity.
  • Required configuration — every Auto Scaling group must reference a launch template or a launch configuration; launch templates are recommended.
Scaling policies are typically classified into three categories: manual, dynamic, and scheduled. We’ll explain each type below. Min, Desired, and Max capacity The Auto Scaling group always attempts to maintain the desired capacity, scaling down to the minimum or up to the maximum based on your configured policies.
A presentation slide titled "Autoscaling – Manual Desired Capacity" showing three dashed containers that illustrate different autoscaling groups with their Min/Desired/Max counts and instance icons, plus scaling control icons beneath each.
Manual scaling You can change desired capacity manually using the AWS Console, CLI, or SDK. Example: if min = 2, desired = 2, max = 10, the group starts with two instances. Changing desired to 5 causes Auto Scaling to launch three additional instances to reach five. Manual scaling is simple and precise but requires human intervention and does not respond automatically to sudden traffic spikes. Auto-healing behavior If desired = 5 and two instances are marked unhealthy, Auto Scaling terminates the unhealthy instances and launches replacements so the group returns to the desired count of five. Auto-healing helps maintain availability without manual intervention. Dynamic scaling Dynamic scaling lets Auto Scaling react automatically to metric changes. The three primary dynamic scaling approaches are:
  • Target tracking scaling
  • Simple scaling
  • Step scaling
Auto Scaling commonly uses Amazon CloudWatch metrics (average CPU utilization, network in/out, Application Load Balancer request count per target, etc.) to decide when to scale.
A presentation slide titled "Autoscaling – Dynamic Scaling Policy" showing three scaling options—Target Tracking, Step, and Simple—flowing from a set of instances toward Amazon CloudWatch. A side panel lists metrics used for scaling like average CPU utilization, network in/out, and ALB request count.
Target tracking scaling Target tracking continuously adjusts capacity to keep a chosen metric near a specified target (for example, keep average CPU utilization at 50%). Example: min = 1, desired = 2, max = 5. If average CPU rises above 50% for the evaluation period, Auto Scaling launches instances until the metric returns near the target (up to the max). When CPU drops below the target, instances are terminated to reduce cost.
A slide titled "Target Tracking Scaling" showing five orange microchip icons (each half-filled green) arranged inside a dotted box with the text "Min: 1 Desired: 2 Max: 5" above them. A magenta scaling icon is centered below the chips.
Simple scaling Simple scaling uses CloudWatch alarms to trigger fixed adjustments. When the alarm fires, the Auto Scaling policy applies a pre-defined, fixed change — for example, add 2 instances when CPU > 70%, or remove 1 instance when CPU < 30%. The same fixed adjustment happens each time the alarm triggers.
A slide titled "Simple Scaling" showing three server/chip icons inside a dotted boundary connected via an autoscaling/load-balancer icon and a cloud monitoring icon to an EC2 CPU utilization vertical bar. It visually represents simple horizontal scaling and CPU monitoring for EC2 instances.
Step scaling Step scaling extends simple scaling with tiered responses depending on how far the metric deviates from thresholds. Using CloudWatch alarms you can define steps such as:
  • 60%–70%: add 2 instances
  • 70%–85%: add 3 instances
  • 85%: add 5 instances
Step scaling provides granular control to respond more aggressively when metrics are far beyond thresholds. Scale-in rules can be similarly tiered.
A diagram titled "Step Scaling" showing multiple orange CPU/instance icons inside a dashed boundary connected to a pink autoscaling/monitoring icon. To the right is a vertical EC2 CPU utilization gauge with green, yellow and red sections.
Scaling policy comparison (quick reference) Scheduled scaling Scheduled scaling runs scaling actions at predictable times. Use it when traffic patterns are known (e.g., daily peaks). You can:
  • Set the desired capacity at a specific time, or
  • Add/remove a fixed number of instances on a schedule. Scheduled actions can be one-time or recurring (cron-like).
A slide titled "Autoscaling – How Schedules Scaling Works" showing a laptop illustration on the left and three colored schedule bars on the right that list Min/Desired/Max instance counts with time ranges (8:00–10:00, 10:00–18:00, 18:00–20:00).
Launch templates (recommended) Each Auto Scaling group must reference either a launch template or a launch configuration; launch templates are preferred. A launch template defines how new instances should be configured when launched by Auto Scaling: AMI, instance type, network settings, security groups, IAM role, EBS configuration, user data scripts, tags, and more.
A slide titled "EC2 Autoscaling" showing a diagram with orange blocks on the left (EC2 AMI, Networking, Access Control, Security Group), icons in the center, and green blocks on the right (Auto-Recovery, Run EC2 Instance, Scale Instance based on policy).
Why use a launch template? Launch templates provide standardization and consistency: every instance launched by the Auto Scaling group follows the same configuration, which avoids manual errors and simplifies updates.
The image shows a laptop mockup displaying a simple website layout with a URL bar ("https://mywebsite.com"), navigation buttons (Product, Contact, Blog), and colored sections labeled Image and Text Content. It's presented as a slide titled "Why Do We Need Launch Template?".
Common elements included in a launch template
  • AMI
  • Instance type
  • EBS volume configuration
  • Security groups
  • IAM instance profile
  • Key pair (SSH key for instance access)
  • Network settings (subnets, interfaces)
  • User data scripts
  • Tags and metadata
  • Market options (On-Demand, Spot)
A slide titled "Launch Template – EC2 Common Features" showing labeled tiles with colorful icons for common EC2 settings like Access Key, Security Group, Network Configuration, Instance Type, AMI and "Many more...".
Launch template features
  • Instance configuration: define all instance-level settings and metadata.
  • Versioning: support for multiple versions so you can update templates without disrupting running instances.
  • Parameterization & overrides: use a base template and override parameters at launch time for minor variations.
  • Termination protection: reduce accidental terminations by enabling protection.
  • User data: include initialization scripts for bootstrapping instances.
  • CLI/SDK/Infrastructure-as-Code support: manage templates through console, CLI, SDKs, CloudFormation, or Terraform.
A presentation slide titled "Launch Template – Features" with a turquoise left panel. The slide shows "01 Instance Config" and a numbered list: AMI, EBS volume, Security group, IAM profile, Network settings, and Instance tag.
Launch templates are the recommended approach for Auto Scaling groups and replace legacy launch configurations. Use template versioning and parameter overrides to roll out updates safely and consistently.
Integrations Auto Scaling integrates with several AWS services to provide a complete autoscaling and observability solution:
  • Elastic Load Balancing — distribute incoming traffic across instances in the Auto Scaling group.
  • Amazon CloudWatch — collect metrics and define alarms that drive scaling policies.
  • Amazon SNS — publish notifications for scaling events (scale-out/in, instance launch/terminate).
  • IAM — grant Auto Scaling and instances necessary permissions.
  • AWS Systems Manager, AWS Auto Scaling (scaling plans), and other services can be used for more advanced automation.
By combining a launch template with the right scaling policy (manual, dynamic, or scheduled) and CloudWatch metrics/alarms, Auto Scaling groups help maintain performance and availability while optimizing costs through automated scaling and self-healing. Further reading and references

Watch Video