AWS Auto Scaling Setup: EC2 Groups, Policies, and Best Practices
Published on · Updated on
Reworked the guide around EC2 Auto Scaling groups, corrected AWS service distinctions and scaling guidance, and added setup and troubleshooting steps.
Amazon EC2 Auto Scaling adjusts the number of EC2 instances in an Auto Scaling group to match demand, maintain a chosen baseline, or replace unhealthy instances. This guide walks through a practical EC2 setup and explains how to choose scaling policies, set health checks and warmup, and investigate failed scaling actions.
AWS uses similar names for separate scaling services. For EC2 virtual machines, use Amazon EC2 Auto Scaling. For supported resources such as ECS service desired count, Lambda provisioned concurrency, DynamoDB provisioned capacity, and Aurora read replica count, use Application Auto Scaling or the scaling controls in the resource's own service.
AWS Auto Scaling scaling plans remain available for collections of supported resources; they are not a universal way to scale every AWS resource. AWS recommends configuring predictive policies on the scaling resource itself when predictive scaling is your only reason to use a scaling plan, because native policies offer additional capabilities.
For Amazon EKS, pod and node scaling use EKS and Kubernetes mechanisms such as EKS Auto Mode, Karpenter, or Cluster Autoscaler; an EC2 Auto Scaling group alone is not a recipe for scaling application pods. RDS storage autoscaling is also a database-level setting, separate from EC2 Auto Scaling.
Amazon EC2 Auto Scaling basics
An Auto Scaling group (ASG) is a set of EC2 instances managed as one unit. The group keeps its desired capacity running, replaces instances it identifies as unhealthy, and can change its desired capacity in response to scaling policies or scheduled actions. Policies normally adjust desired capacity within the group's minimum and maximum settings; those settings do not guarantee that AWS can launch the requested instances if a launch fails or capacity is unavailable.
| Term | What it controls |
|---|---|
| Minimum capacity | The lowest desired capacity allowed by automatic scaling. |
| Desired capacity | The group's target number of instances, set by you or a scaling action. |
| Maximum capacity | The configured upper bound for desired capacity in a simple instance-count group. |
| Launch template | A versioned EC2 instance definition used when the group launches or replaces an instance. |
| Scaling policy | A rule that adjusts desired capacity in response to a metric or forecast. Scheduled actions set capacity at specified times. |
There are a few exceptions to the normal maximum: Capacity Rebalancing can temporarily exceed it, and weighted groups may overshoot it to fulfill a whole instance. Predictive scaling can also be explicitly configured to raise the maximum; that increased limit remains until you change it.
An ASG scales out by launching more instances and scales in by terminating instances. It does not resize an existing instance vertically. If your application cannot run on additional interchangeable instances, scaling the group alone will not make it scale horizontally.
Set up an EC2 Auto Scaling group
Before using automatic scaling, make sure the application can start on a replacement instance and safely handle instances being added or removed. Web services commonly place an Application Load Balancer target group in front of the group; see our Elastic Load Balancing setup guide for target group setup.
1. Create a launch template
A launch template describes how EC2 should launch an instance. Choose an AMI that contains, or can install, the application; an instance type that suits its measured resource needs; and the required storage, network interfaces, security groups, and instance profile. Use an instance profile for permissions the application needs from the instance. EC2 Auto Scaling uses its service-linked role for actions it performs on your behalf, and AWS normally creates that role when you first create a group if your IAM permissions allow it.
Prefer launch templates for new groups. They support versions and newer EC2 capabilities. Launch configurations are a legacy option: AWS no longer supports new instance types in them, and accounts created on or after October 1, 2024 cannot create new launch configurations. See AWS's launch template guide and launch configuration limitations.
2. Create the group and set capacity bounds
- In the EC2 console, open Auto Scaling Groups and choose Create Auto Scaling group.
- Select the launch template and version, then choose the VPC and subnets where instances may launch. For availability across a zone failure, use subnets in multiple Availability Zones and maintain enough capacity to serve the workload if a zone becomes unavailable.
- Set minimum, desired, and maximum capacity based on the service's tested baseline, expected load, and account quotas. Keep the maximum high enough for the intended burst, while treating it as an explicit cost and capacity limit.
- For a web service, attach the load balancer target group. EC2 Auto Scaling registers new instances with the group and deregisters instances it removes.
- Review health check types and the health check grace period. Set the grace period to cover the time the application actually needs to initialize and pass its load balancer checks.
- Review the launch template, networking, capacity limits, and any scaling options, then create the group.
AWS's first Auto Scaling group tutorial shows this flow in the console. A service-linked role is separate from the instance profile: avoid creating a broad IAM role for the group when the service-linked role and a narrowly scoped application instance profile cover the required actions.
After the group is ready, select it and open Automatic scaling > Dynamic scaling policies > Create dynamic scaling policy. Keep Target tracking scaling, choose a metric that tracks useful work per instance, and set the target from load tests and observed saturation; if you use ALB request count per target, select its target group as well. Set instance warmup from measured startup and metric-stabilization time, then create the policy and test it with representative load. See AWS's target tracking policy setup.
3. Configure health checks and warmup
EC2 Auto Scaling always uses EC2 instance status checks. You can also enable Elastic Load Balancing health checks so the group can replace an instance that the load balancer reports as unhealthy. An unhealthy in-service instance is replaced using the group's current launch settings.
The health check grace period gives a newly in-service instance time to initialize before the group acts on additional health-check results. It is not protection from every failure: an instance that stops running can still be marked unhealthy and replaced. The default instance warmup has a different job: it keeps a new instance's early metrics out of the group's scaling calculations and, for target tracking and step scaling, blocks policy scale-in while the new instance warms up. Set each using measured startup, readiness, and metric-stabilization time rather than one universal duration. AWS recommends configuring default warmup for target tracking and step scaling.
Where an instance handles ongoing requests or work, allow time for load balancer connection draining or use a lifecycle hook to finish or hand off work during termination. Health checks decide whether an instance is healthy; termination handling gives the application a chance to stop cleanly.
Choose a scaling policy that matches the workload
Start with a metric that reflects work the application can serve, then test how quickly new instances become useful. There is no universal CPU threshold or target value: choose one from load tests, observed saturation, response-time objectives, and the headroom your workload needs.
| Method | Use it when | What it does |
|---|---|---|
| Target tracking | A metric rises or falls roughly in proportion to per-instance load, such as average CPU utilization or ALB requests per target. | Maintains a chosen metric target. EC2 Auto Scaling creates and manages the associated CloudWatch alarms. |
| Step scaling | You need different capacity changes for different CloudWatch alarm breach ranges. | Applies configured adjustments when a CloudWatch alarm breaches its threshold. |
| Scheduled action | Demand has a known schedule, such as business hours. | Changes capacity at specified times. It can complement dynamic policies. |
| Predictive scaling policy | The workload has recurring daily or weekly patterns and enough history to forecast them. | Forecasts capacity and can launch instances before expected demand; dynamic scaling can respond to changes the forecast misses. |
For a first policy on a web or worker group, target tracking is usually the simplest fit when a supported metric tracks workload per instance. AWS recommends it over simple scaling for proportional changes such as average CPU or requests per target. Use step scaling when you need explicit responses to different alarm breaches; it requires CloudWatch alarms that you manage. Simple scaling is still supported, but it pauses later simple scaling actions during cooldowns and is not the usual starting point for new policies. See AWS's guidance on dynamic scaling, target tracking, and step and simple scaling.
Select metrics that track useful work
- For a web tier behind an Application Load Balancer, consider request count per target. For compute-bound work, average CPU can be suitable if added instances actually reduce per-instance CPU.
- For queue workers, consider backlog per available worker or another metric that relates queued work to how quickly the group drains it. Use step scaling or a custom metric when a built-in target-tracking metric does not represent the work.
- Memory is not an EC2 metric by default. Collect operating-system memory metrics with the CloudWatch agent before using them in a scaling policy.
- Check application signals as well as instance utilization: response time, error rate, rejected work, or queue age can reveal that more instances are not solving the actual bottleneck.
Predictive scaling for recurring demand
For predictive scaling, begin in forecast-only mode and compare its forecast with actual workload. EC2 Auto Scaling requires at least 24 hours of metric history to start forecasting; AWS says forecasts are more effective with two full weeks. Predictive policies scale out in advance, while dynamic policies can handle additional changes and scale in. Configure warmup so forecasted capacity has time to become ready. See how predictive scaling works.
Spread capacity and plan for failure
Choose subnets in multiple Availability Zones so EC2 Auto Scaling can distribute the group across them. That distribution reduces dependence on one zone, but it does not make the application highly available by itself. The application, load balancer, data stores, minimum capacity, and dependencies also need to tolerate a zone loss.
Set the minimum to the capacity you need available during normal operation, not just the smallest number of instances that can start. The group can replace an instance or add capacity only when its launch configuration, subnet address space, service quotas, and available EC2 capacity allow it.
Termination, Spot capacity, and cost controls
When a scale-in action occurs, EC2 Auto Scaling chooses which eligible instance to terminate according to its termination policy. The default policy takes Availability Zone balance into account and generally prefers instances with older configurations. If a specific instance must remain, use scale-in protection carefully; if work must complete before shutdown, use an application-aware handoff such as a lifecycle hook. A termination policy does not replace graceful shutdown or guarantee which instance is removed first. See termination policy behavior.
Spot Instances can lower compute cost for fault-tolerant work, but EC2 may interrupt them as capacity or market conditions change. A group attempts to replace interrupted Spot Instances to maintain desired capacity, but it cannot guarantee another Spot instance is available. Use a mix of compatible instance types and Availability Zones; for interruption-sensitive work, consider the price-capacity-optimized allocation strategy and Capacity Rebalancing. Make jobs checkpointable and able to resume. AWS recommends leaving the optional maximum Spot price unset: setting a cap below On-Demand pricing can prevent launches and increase interruptions. See AWS's Spot allocation strategy, Spot maximum price guidance, and Capacity Rebalancing documentation.
For steady baseline usage, compare On-Demand, Savings Plans, or applicable Reserved Instance coverage using your actual usage and commitment needs. Scaling policies manage capacity; they do not determine whether a long-term commitment is cost-effective. Review instance, storage, load balancer, data transfer, and monitoring costs together, then check whether scale-in returns the expected capacity after demand falls.
Monitor scaling and validate behavior
Watch the group's desired, minimum, maximum, and in-service capacity alongside the application metric that drives scaling. For web tiers, review target health and the load balancer's request and latency metrics. For operating-system memory or application-level signals, publish the required metrics explicitly.
EC2 instance monitoring is five-minute by default; detailed instance monitoring provides one-minute metrics and has additional charges. Auto Scaling group metrics are available at one-minute granularity at no additional charge, but you must enable group metric collection. See AWS's instance monitoring guide and Auto Scaling group metrics guide.
Exercise the policy under representative load before relying on it. Confirm that a scale-out creates usable capacity before the application reaches its limit, and that scale-in does not reduce capacity below what the workload needs. Verify the forecast and policy actions separately when testing predictive scaling.
Troubleshoot common problems
Start with the Auto Scaling group's Activity history. It records scaling attempts and includes specific launch or termination errors. Then trace the issue to the matching part of the setup:
| Symptom | What to check |
|---|---|
| No scale-out activity | Check the policy's metric and state, attached CloudWatch alarm for step scaling, policy configuration, suspended group processes, desired capacity, and maximum. Target tracking creates its own alarms; don't edit those alarms directly. |
| Scale-out starts but instances do not launch | Read the activity error. Check the launch template version, AMI and instance compatibility, required IAM permissions, EC2 capacity, service quotas, and free IP addresses in the selected subnets. |
| Instances launch but targets stay unhealthy | Check target group health-check path, port, protocol and expected response; security-group paths; application startup logs; and whether the health check grace period covers actual initialization. |
| Repeated or oscillating scaling | Check whether the metric reflects work per instance, whether warmup matches metric stabilization time, whether the target has enough headroom, and whether another policy or scheduled action is changing desired capacity. |
| Scale-in removes capacity needed by the application | Review the minimum, target and metric trend, termination policy, scale-in protection, load balancer deregistration delay, and lifecycle hooks for work that must drain or finish. |
A group can keep its desired capacity only when replacement instances can launch successfully. If capacity is blocked by a quota, unsupported launch template choice, exhausted subnet, or unavailable instance pool, fix that launch constraint or adjust the supported capacity mix; increasing the maximum alone will not resolve every launch error. AWS's EC2 Auto Scaling troubleshooting guide explains how to retrieve activity errors and their causes.
FAQs
Which AWS Auto Scaling service should I configure?
Use Amazon EC2 Auto Scaling for EC2 instances in an Auto Scaling group. Use Application Auto Scaling for supported service capacity such as ECS task counts, DynamoDB throughput, or Lambda capacity dimensions. AWS Auto Scaling scaling plans coordinate supported resources across a plan; use the resource's native scaling policy when you need a capability that plans do not provide.
Does EC2 Auto Scaling change an instance's size?
No. It changes the number of EC2 instances by launching or terminating instances. To change instance type, update the launch template and replace or refresh instances through a planned rollout.
Why did my Auto Scaling group not launch instances?
Read the group's Activity history first. It identifies whether a policy did not trigger, the group reached a capacity limit, or a launch failed because of the template, permissions, quota, subnet, or instance capacity. Correct the reported cause, then confirm the group's desired and in-service capacity recover.
Should I use a cooldown or instance warmup?
For target tracking and step scaling, configure the group's default instance warmup from observed time to initialize and stabilize metrics. Cooldowns are specifically used by simple scaling policies to pause later scaling actions. The health check grace period controls when additional health results can trigger replacement after an instance enters service, so do not treat these settings as interchangeable.