AWS Auto Scaling Groups (ASG): A Beginner's Guide
Published · Updated
An Amazon EC2 Auto Scaling Group, usually shortened to ASG, manages a logical group of EC2 instances. It launches enough instances to reach a desired capacity, can replace instances that fail configured health checks, and can change capacity through manual, scheduled, predictive, or dynamic scaling. An ASG manages compute capacity; it does not distribute user requests by itself.
AWS describes maintaining capacity and automatic scaling as the two core functions of an Auto Scaling group.
The three capacity settings
Every beginner should understand these values before creating a scaling policy:
| Setting | Meaning |
|---|---|
| Minimum capacity | The lower boundary the group should not scale below. |
| Desired capacity | The capacity the group currently tries to maintain. |
| Maximum capacity | The upper boundary the group should not scale above. |
Suppose minimum is 2, desired is 2, and maximum is 6. The group initially tries to run two instances. A scaling policy may raise desired capacity up to six or lower it no further than two. These are capacity guardrails, not a promise that six instances can handle a particular workload; load testing and monitoring must establish that.
A group can maintain desired capacity without any dynamic scaling policy. If an instance becomes unhealthy or is terminated, the ASG can launch a replacement simply to restore the desired number.
Launch templates define new instances
An ASG needs a repeatable definition for the instances it launches. A launch template can specify an AMI, instance type, security groups, storage, IAM instance profile, and user data. Launch templates support versions, which lets you create and test a new instance definition without overwriting the old one. See AWS’s launch-template documentation.
Keep bootstrapping deterministic. A new instance should become useful without a person signing in to copy a JAR or start a process. Common approaches include:
- an immutable AMI containing a versioned application artifact;
- user data that retrieves a versioned artifact from a controlled source; or
- a deployment service that rolls a known release onto the fleet.
Never put long-lived secrets or access keys in user data, an AMI, or the application artifact. Attach a least-privilege IAM role to the instance and obtain runtime configuration from a suitable managed service.
Health replacement is not the same as load balancing
By default, EC2 Auto Scaling evaluates EC2 health status. When an ASG is attached to a load balancer target group, you can also turn on Elastic Load Balancing health checks. AWS explains that this allows the ASG to replace a running instance that an attached load balancer reports as unhealthy in its load-balancer attachment guide.
Use a health-check grace period that reflects real application startup time. Without one, a slow-starting application can be declared unhealthy and replaced repeatedly. The load balancer separately decides whether a target receives traffic; the ASG decides whether fleet capacity should be replaced.
For web traffic, an ALB usually sits in front of the ASG:
Client → ALB → target group → healthy EC2 instances managed by ASG
Read the ELB beginner guide for listener, target-group, and load-balancer-family concepts.
Choose a scaling method
Manual capacity
Change desired capacity yourself. This is simple for a lab, but it does not react automatically to demand.
Scheduled scaling
Change capacity around known time windows. This fits predictable events, but a schedule cannot understand an unexpected load spike.
Target tracking
Choose a metric and target value, such as average CPU utilization or ALB request count per target. EC2 Auto Scaling creates and manages the CloudWatch alarms and adjusts capacity to keep the metric near the target. AWS recommends a target with a reasonable buffer for unexpected traffic and notes that target tracking generally scales in more gradually than it scales out. See target tracking scaling policies.
Do not copy a CPU percentage or request-count target from a tutorial into production. Measure the point at which your application approaches its latency, error-rate, CPU, memory, connection-pool, or downstream-service limits. A metric is useful only when it reflects load and changes roughly in proportion to capacity.
Step and predictive scaling
Step scaling gives more explicit control over capacity adjustments triggered by alarm breaches. Predictive scaling forecasts recurring demand from historical data. They solve different problems; neither removes the need for minimum/maximum safeguards and operational monitoring.
A safe beginner design
For an HTTP lab, start with:
- A versioned launch template that starts the application automatically.
- An ASG spanning subnets in more than one Availability Zone.
- An ALB target group attached to the ASG.
- Instance security rules that accept the application port only from the ALB security group.
- A fast, read-only application health endpoint.
- ELB health checks enabled on the ASG, with a realistic grace period.
- A conservative maximum capacity to limit surprise spend.
- Alarms for unhealthy targets, capacity changes, errors, and latency.
An ASG improves resilience only when the application and its dependencies support multiple interchangeable instances. Local sessions, files written only to one instance, database bottlenecks, and non-idempotent startup tasks can all break during replacement or scale-out.
Cost and cleanup
The ASG service coordinates capacity, but the instances and related resources it launches are billable. Load balancers, storage volumes, snapshots, data transfer, public IPv4 addresses, monitoring, and logs may also cost money. Setting desired capacity to zero may not delete the ASG, launch template, load balancer, AMI, or snapshots.
For a hands-on continuation, follow scaling a Spring Boot service with an ASG and ALB. If you have not deployed the application yet, start with the EC2 and ALB tutorial. These infrastructure foundations connect to the Cloud/AI Solutions Architect program.