What Is an Auto Scaling Group in AWS? EC2 ASG Beginner's Guide, With FAQ
Published · Updated
An Auto Scaling group (ASG) in AWS is a collection of EC2 instances that Amazon EC2 Auto Scaling manages as one unit. You tell the group how many instances you want, and it launches them, replaces any that fail a health check, and, if you attach a scaling policy, adds or removes instances as load changes. In AWS’s words, an Auto Scaling group “contains a collection of EC2 instances that are treated as a logical grouping for the purposes of automatic scaling and management” (Auto Scaling groups).
AWS names two core jobs for the service: keeping the number of instances in a group steady, and scaling that number automatically. An ASG manages how much compute capacity exists. It does not spread user requests across that capacity; a load balancer does that.
What is an Auto Scaling group in AWS, with an example?
Take a small web application that normally needs two EC2 instances. You create an Auto Scaling group with a minimum of 2, a desired capacity of 2 and a maximum of 6, spread over two Availability Zones, and attach it to an Application Load Balancer.
- Day to day, the group runs two instances, one in each zone.
- An instance crashes. Its health check fails, the group terminates it and launches a fresh one from the same launch template. Nobody has to sign in to fix it.
- Traffic climbs. A target tracking policy sees average CPU rise above the target you set, raises the desired capacity to 4, and the group launches two more instances. The load balancer starts sending them requests once they pass its health check.
- Traffic falls. The policy lowers the desired capacity again, gradually, and the group terminates the extra instances. It never goes below 2 or above 6.
That is the whole idea of an ASG: you describe the fleet you want, and AWS keeps the real fleet matching that description.
Min, desired and max capacity
Every Auto Scaling group has three numbers. Understand them before you write any scaling policy.
| Setting | What it means |
|---|---|
| Minimum capacity | The group never scales below this many instances. |
| Desired capacity | The number of instances the group is trying to run right now. |
| Maximum capacity | The group never scales above this many instances. |
With minimum 2, desired 2 and maximum 6, the group starts by launching two instances. A scaling policy can move the desired capacity anywhere from 2 to 6. If a policy asks for more than the maximum, AWS caps the change at the maximum; if it asks for fewer than the minimum, AWS stops at the minimum. AWS works through both cases in its dynamic scaling guide.
Two things beginners often miss:
- An ASG with no scaling policy is still useful. By default a group has no policy and simply holds its desired capacity, replacing instances that fail (Choose your scaling method). That alone gives a single-instance app automatic recovery.
- The maximum is a guardrail, not a capacity plan. Six instances are not guaranteed to handle any particular load. Only load testing and monitoring tell you that. The maximum mainly protects you from a runaway scale-out and a surprise bill.
Launch templates, not launch configurations
An ASG needs a recipe for every instance it launches. Today that recipe is a launch template: the AMI, instance type, security groups, storage, IAM instance profile, user data and other launch settings. Launch templates are versioned, so you can create and test version 2 without overwriting version 1 (launch templates).
Older tutorials use launch configurations. Do not start with them. AWS’s launch configuration page sets out the limits:
- Since 1 January 2023, new EC2 instance types are not supported in launch configurations.
- Accounts created on or after 1 June 2023 cannot create launch configurations in the console.
- Accounts created on or after 1 October 2024 cannot create them by any method: console, API, CLI or CloudFormation.
A launch configuration also cannot be edited after creation, and mixing On-Demand and Spot purchase options in one group needs a launch template. If you inherit a group that still uses a launch configuration, AWS documents a migration path to launch templates.
Make new instances start on their own
An ASG launches instances while you are asleep, so each one must become useful without a person signing in to copy a JAR or start a process. Common approaches:
- an AMI that already contains a versioned build of the application;
- user data that downloads a versioned artifact from a controlled location and starts it as a service; or
- a deployment tool that installs a known release on each new instance.
Never put access keys or other long-lived secrets in user data, an AMI or the application package. Attach an IAM role to the instance through the launch template and read configuration from a managed secrets service at runtime.
Health checks: how an ASG decides to replace an instance
Every instance starts as Healthy and stays that way until Amazon EC2 Auto Scaling hears otherwise. AWS lists the sources that can mark an instance unhealthy: Amazon EC2 status checks, Elastic Load Balancing, VPC Lattice, Amazon EBS and custom health checks you send yourself (health checks for Auto Scaling groups). When an InService instance is found unhealthy, the group terminates it and launches a replacement from its current launch template.
EC2 status checks are always on, but they only tell you the virtual machine is running. They cannot see that your application has crashed. For a web application behind a load balancer, turn on Elastic Load Balancing health checks for the group so an instance the load balancer reports as unhealthy is also replaced (attach a load balancer to an ASG).
Set a realistic health check grace period
The grace period is how long a new instance is left alone before failed health checks can get it terminated. AWS sets it to 300 seconds when you create a group in the console, and 0 (turned off) when you create one with the CLI or an SDK (health check grace period). If your application takes four minutes to boot and the grace period is zero, the group can replace instances over and over before any of them is ready. If it is far longer than needed, broken instances stay in service longer. Measure your real startup time and set the grace period just above it.
Keep the two health systems straight: the load balancer decides whether an instance receives traffic; the Auto Scaling group decides whether an instance should be replaced.
Ways to scale an Auto Scaling group
AWS offers five ways to change, or hold, a group’s size (Choose your scaling method):
| Method | What it does | Good for |
|---|---|---|
| Fixed size | No policy; the group holds its desired capacity and replaces failures | Recovery for a steady workload |
| Manual | You change desired capacity yourself | Labs, one-off changes |
| Scheduled | Capacity changes at dates and times you set | Load you can predict exactly, such as business hours |
| Dynamic | A policy reacts to a CloudWatch metric | Load that changes when you cannot predict it |
| Predictive | AWS forecasts daily and weekly patterns from history and adds capacity ahead of them | Cyclical traffic, especially with slow-starting instances |
Dynamic scaling has three policy types: target tracking, step scaling and simple scaling. AWS “strongly recommend[s]” target tracking, and says that in most cases one target tracking policy is enough (dynamic scaling). Step scaling gives finer control over how much to add for a given alarm breach. Simple scaling makes one adjustment and then waits out a cooldown; it is the oldest of the three.
Target tracking scaling policies
Target tracking works like a thermostat. You choose a metric and a target value, and EC2 Auto Scaling creates and manages the CloudWatch alarms that add or remove instances to keep the metric near the target (target tracking policies).
Four predefined metrics are available:
ASGAverageCPUUtilization: average CPU across the groupASGAverageNetworkInandASGAverageNetworkOut: average bytes in or out per instanceALBRequestCountPerTarget: average Application Load Balancer requests per instance in the group’s target group
Choosing the metric
A target tracking metric must change in proportion to the number of instances: double the instances and the metric should roughly halve. That is why AWS says these do not work as target tracking metrics:
- the load balancer’s total
RequestCount, because adding instances does not change it; - load balancer
Latency, because it rises with load but not in proportion; and - the raw SQS queue length, unless you turn it into messages per instance.
For an HTTP application behind an ALB, ALBRequestCountPerTarget usually tracks real load more directly than CPU. For CPU-bound work, average CPU is a sensible start. AWS also recommends enabling detailed monitoring so EC2 metrics arrive every minute instead of every five minutes.
Choosing the target value
AWS’s advice is to set the target “as high as possible with a reasonable buffer for unexpected traffic increases.” Do not copy a number from a tutorial, including AWS’s own 50 percent CPU example. Load-test one instance, find where latency or errors start to climb, and set the target safely below that point. For a request-count metric, the target is the number of requests one instance should handle per minute.
What target tracking does on its own
- It scales out quickly and scales in gradually, because AWS prioritises availability. If several target tracking policies are attached, the group scales out when any one asks and scales in only when all agree.
- Do not edit or delete the CloudWatch alarms it creates. EC2 Auto Scaling owns them.
- With small groups the metric can sit some way off the target, because AWS rounds the instance count to avoid removing too much.
- It only scales out when the metric is above the target. It cannot scale out on a metric that falls as load rises.
Instance warmup and warm pools
A new instance often shows a burst of CPU while it starts, before it handles real traffic. If that burst counts toward the group’s average, the policy may scale out again for no reason. Default instance warmup tells the group how long to leave a new instance out of the metrics after it enters service. AWS says it “strongly recommend[s]” enabling it, notes it is not on by default, and suggests starting at 300 seconds if you are unsure, then tuning (default instance warmup).
A warm pool is different. It keeps pre-initialised instances, usually stopped or hibernated, beside the group so a scale-out can use them instead of booting from scratch (warm pools). It is meant for applications with exceptionally long boot times. AWS warns that creating one when it is not needed adds cost, so a beginner’s lab does not need one.
Auto Scaling groups and load balancers
For a web application the usual shape is:
Client → Application Load Balancer → target group → healthy instances launched by the ASG
When you attach a target group to the group, the ASG registers each new instance with it and deregisters instances it terminates. The load balancer spreads requests across whatever instances are registered and healthy. They solve different problems and are almost always used together: ELB distributes traffic across the instances that exist; the ASG decides how many instances exist.
This guide stays on the capacity side. For listeners, target groups and choosing between ALB, NLB and GWLB, read the Elastic Load Balancer beginner guide.
Availability Zones and updates
An Auto Scaling group belongs to one AWS Region and can span several Availability Zones in it. When you choose more than one zone, AWS distributes the desired capacity across them and keeps them balanced as the group scales (Auto Scaling groups). Use at least two zones for anything that should survive a zone problem.
Changing the launch template does not change instances that are already running; only new launches use it. To roll a new AMI, user data script or instance type across the fleet, start an instance refresh, which replaces instances in batches and can roll back (instance refresh).
A safe starter design
For a first HTTP application behind an ASG:
- A versioned launch template whose instances start the application automatically.
- An ASG spanning subnets in at least two Availability Zones.
- An ALB target group attached to the ASG, with Elastic Load Balancing health checks turned on.
- A health check grace period and default instance warmup based on measured startup time.
- Instance security group rules that accept the application port only from the load balancer’s security group.
- A fast, read-only application health endpoint for the target group to check.
- One target tracking policy, on
ALBRequestCountPerTargetor average CPU, with a target chosen from a load test. - A conservative maximum capacity, plus CloudWatch alarms on unhealthy targets, errors and latency.
An ASG only improves resilience if the application can run as several interchangeable copies. Sessions held in one instance’s memory, files written to one instance’s disk, a database that cannot take more connections, and startup scripts that are not safe to run twice all break during replacement or scale-out. Fix those before relying on scaling.
Cost and cleanup
Amazon EC2 Auto Scaling has no fee of its own. AWS states that its features “have no additional fees beyond the service fees for Amazon EC2, CloudWatch (for scaling policies), and the other AWS resources that you use” (EC2 Auto Scaling pricing). The instances it launches, their volumes, the load balancer, public IPv4 addresses, data transfer and logs are all billed as usual.
When a lab ends, delete the Auto Scaling group itself. Terminating its instances by hand does not work, because the group replaces them to restore the desired capacity. Then delete the load balancer, target group, launch template, unused AMIs and snapshots, after checking nothing else uses them.
Auto Scaling group FAQ
What is an Auto Scaling group in simple terms?
A managed group of identical EC2 instances. You set a minimum, a desired number and a maximum, and AWS keeps that many healthy instances running, replacing failures and, if you add a scaling policy, growing or shrinking the group with demand.
What does ASG stand for in AWS?
Auto Scaling group. The service that runs Auto Scaling groups is Amazon EC2 Auto Scaling.
What is the difference between an Auto Scaling group and a load balancer?
A load balancer spreads incoming requests across the instances that already exist. An Auto Scaling group changes how many instances exist and replaces unhealthy ones. Used together, the ASG registers new instances with the load balancer’s target group automatically.
What is the difference between EC2 Auto Scaling and Application Auto Scaling?
EC2 Auto Scaling scales EC2 instances through Auto Scaling groups. Application Auto Scaling scales other AWS resources, such as ECS services, DynamoDB tables, Aurora replicas and Lambda provisioned concurrency.
Should I use a launch template or a launch configuration?
A launch template. Launch configurations do not support instance types released since 2023, cannot be created at all by accounts opened on or after 1 October 2024, and cannot be edited after creation.
What happens when an instance in an ASG fails a health check?
The group marks it unhealthy, terminates it and launches a replacement from its current launch template to restore the desired capacity. With Elastic Load Balancing health checks turned on, an instance the load balancer reports as unhealthy is replaced too.
Can an Auto Scaling group scale to zero?
Yes, if its minimum capacity is 0. AWS notes that a target tracking policy on ALBRequestCountPerTarget can scale a group in to zero after a sustained period with no traffic, provided the minimum is set to 0.
Can one Auto Scaling group span several Regions?
No. A group lives in one Region and can span several Availability Zones within it. Multi-Region designs use a separate group in each Region.
Is an Auto Scaling group free?
The Auto Scaling feature itself carries no extra fee. You pay for the instances and other resources the group launches, and for CloudWatch where scaling policies use it.
Next step
To build one, follow scaling a Spring Boot service with an ASG and ALB. If you have not deployed the application yet, start with the Spring Boot on EC2 with a load balancer tutorial. These cloud architecture fundamentals are part of the Cloud/AI Solutions Architect program.