Auto Scaling Groups (ASG)

An Auto Scaling group is a collection of EC2 instances managed as one unit for scaling and replacement. Spreading a group across several Availability Zones behind an Elastic Load Balancer is the standard way to make an EC2-based application highly available: the group replaces instances that fail their health checks, and the load balancer stops sending traffic to them in the meantime.

Defining a group

1. Choose a launch template. A launch template describes what to launch — AMI, instance type, key pair, security groups, IAM instance profile, user data, block devices. Use a launch template, not a launch configuration (see below).
2. Networking and purchasing. Pick the VPC and the subnets, one per Availability Zone. Selecting several zones is what buys the availability. A mixed-instances policy here lets one group combine On-Demand and Spot capacity across several instance types.
3. Load balancer. Register the group with a target group so new instances receive traffic automatically, and set the group to use the load balancer’s health checks as well as EC2 status checks.
4. Capacity. Set minimum, maximum and desired capacity. Minimum is the floor the group will never drop below; maximum is the ceiling that caps both cost and blast radius.
5. Notifications. An SNS topic on launch, terminate and failure events gives you somewhere to hang alerting.

Launch configurations are closed

Launch configurations were the original mechanism and are now frozen. Since 1 January 2023 Amazon EC2 Auto Scaling has added no new instance types to them; accounts created on or after 1 June 2023 cannot create one in the console; and accounts created on or after 1 October 2024 cannot create one by any method — console, API, CLI or CloudFormation. Launch templates support every Auto Scaling feature, are versioned, and are the only option for new work. AWS publishes a migration guide for groups still on the old mechanism.

Lifecycle hooks

Lifecycle hooks pause an instance in a wait state during scale-out (Pending:Wait) or scale-in (Terminating:Wait) so that something can run before the instance joins or leaves the group. A typical scale-out sequence:

1. The Auto Scaling group launches an instance.
2. The lifecycle hook holds it in the wait state.
3. User data or a Systems Manager document installs and configures the application.
4. The script verifies the application is serving correctly.
5. The instance calls complete-lifecycle-action, and the group moves it into service.

If the action is never completed the hook times out and the group applies its default result, so always emit the completion call from both the success and the failure path. The scale-in hook is the usual place to drain connections or ship logs off a doomed instance — see log collection solutions. AWS documents the full state machine under Amazon EC2 Auto Scaling instance lifecycle.

Scaling policies

Target tracking

Cruise control. You name a metric and a target value — average CPU at 50%, or requests per target on the ALB — and the group adds or removes capacity to hold it there. It is the simplest to set up and the right default for most stable workloads.

Step scaling

A staircase of responses sized to how far the metric has breached its alarm threshold, for example:

• CPU 60–70%: add 1 instance
• CPU 70–80%: add 2 instances
• CPU above 80%: add 4 instances

Step scaling gives finer control than simple scaling and does not wait out a cooldown between step adjustments, so it copes better with load that arrives in varying sizes.

Simple scaling

A single threshold triggering a single adjustment — “if CPU is above 80%, add 2 instances” — followed by a cooldown before anything else can happen. It is the oldest policy type and the easiest to get wrong: the cooldown makes it slow to respond, and a badly chosen threshold produces capacity ping-pong. Prefer target tracking or step scaling.

Warm-up and cooldown

• Instance warm-up stops a new instance from counting towards the group’s aggregated metrics until it has had time to start, which prevents a cold instance from dragging the average down and triggering another scale-out.
• Cooldown pauses further scaling activity for a set period, which limits runaway scaling from a metric that has not settled.
• The general rule is to scale out quickly and scale in slowly. Adding capacity you did not need costs money; removing capacity you did need costs an outage.

Kinds of scaling

• Reactive scaling — measure the load, then respond to it. Always a step behind, which is fine when instances start in a minute and not fine when they take ten.
• Scheduled scaling — for load you can predict from the calendar: office hours, batch windows, a known campaign. Provision before the traffic arrives.
• Predictive scaling — AWS forecasts the next 48 hours from at least 24 hours of history and provisions ahead of the curve, re-forecasting every 6 hours. It pairs with a dynamic policy rather than replacing it.