Auto Scaling on AWS

“Auto Scaling” on AWS names three separate services. They are frequently conflated, and the distinction matters because they are configured in different places and cover different resources.

Service	What it covers
AWS Auto Scaling	A single console and scaling-plan abstraction across resource types, with predictive scaling. Useful for viewing and planning scaling across an application as a whole.
Amazon EC2 Auto Scaling	EC2 instances, through Auto Scaling groups. The service that actually launches and terminates instances.
Application Auto Scaling	Everything that is not EC2 — DynamoDB, ECS, Aurora replicas, Lambda provisioned concurrency, SageMaker endpoints, EMR, Spot Fleet and others — behind one API.

AWS Auto Scaling

A layer above the other two. It presents a unified view of scaling across the resources that make up an application, offers scaling strategies expressed in business terms (optimise for availability, for cost, or a balance), and is where predictive scaling is configured and its forecasts reviewed.

Application Auto Scaling

An API-based service that consolidates the scaling capability of many AWS services behind a single interface, so that DynamoDB tables, ECS services and EMR clusters are all scaled the same way. It supports three policy types:

Policy	What it does	Example
Target tracking	Adds or removes capacity to hold a chosen metric near a target value	Keep ECS service CPU utilisation at or below 70%
Step scaling	Adjusts capacity by defined amounts at defined metric thresholds	Increase the Spot Fleet by 20% for each additional 10,000 connections on the load balancer
Scheduled	Changes capacity at a set time, day or date	Raise a DynamoDB table’s provisioned read capacity every Monday at 08:00

Amazon EC2 Auto Scaling

An Auto Scaling group is a set of EC2 instances managed as one unit. The group holds a minimum, maximum and desired capacity, spreads instances across the Availability Zones you nominate, runs health checks, replaces instances that fail them, and applies whatever scaling policies you attach.

For the mechanics of EC2 Auto Scaling — the policy types, cooldown and warm-up, lifecycle hooks and the group creation steps — see Auto Scaling Groups (ASG), which is the canonical page for them. Two things belong here because they are architectural rather than operational.

Operating modes

A group is doing one of four things at any moment, and it is worth being explicit about which:

Maintain. Fixed desired capacity, no scaling policies. The group exists purely to replace failed instances — which is a legitimate and often overlooked configuration.
Manual. Capacity changed by an operator or a deployment tool.
Scheduled. Capacity changed on a calendar, for known patterns.
Dynamic. Capacity changed in response to metrics, optionally combined with predictive scaling, which uses machine learning over historical load to forecast demand and provision ahead of it rather than after it.

Predictive scaling can run in forecast-only mode first, so you can compare its forecast against actual load before letting it act.

Launch templates, not launch configurations

An Auto Scaling group is defined by a launch template: the AMI, instance type or types, key pair, security groups, IAM instance profile, block device mapping and network settings. Launch templates are versioned, support mixed instance types and Spot allocation strategies, and are the only option that continues to gain features.

Launch configurations are legacy and, for most accounts, unusable. AWS stopped supporting new EC2 instance types in launch configurations on 1 January 2023; 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 at all — console, API, CLI or CloudFormation. If existing infrastructure code still creates launch configurations, migrating it is not optional housekeeping; it is the thing that will fail the next time it runs in a new account.

Scaling on a queue

The instructive non-CPU case: scale a worker fleet on the amount of work waiting rather than on how hard the workers are currently trying.

Use the SQS metric ApproximateNumberOfMessagesVisible divided by the running instance count — a backlog-per-instance figure — as a custom CloudWatch metric, and target-track against it. Scaling on raw queue depth alone behaves badly, because the same depth means something different with two workers than with two hundred; scaling on worker CPU is worse still, because a saturated queue and an empty one can look identical from inside the worker.