Scaling Compute Workloads

Capacity is a decision someone makes, and the question is whether that someone is a person watching a dashboard or a policy watching a metric. This topic covers how AWS adds and removes compute for you: the Auto Scaling group that holds a fleet at a declared size, the 5 policy types that decide what that size should be, the lifecycle controls that make a replacement safe, and how the same ideas translate when the unit of capacity is a container task or a single request.

What This Topic Covers

• The 3 capacity numbers on an Auto Scaling group, which one a scaling policy moves, and why the other 2 are clamps rather than targets
• Health check sources, the health check grace period and its different console and CLI defaults, zonal balance, the default termination policy, and what instance scale-in protection does not cover
• Target tracking, step, simple, scheduled, and predictive scaling, including which metrics target tracking cannot use and how AWS resolves several policies pointing at one group
• The difference between a cooldown period and an instance warmup, and which policy types use each
• The Auto Scaling instance lifecycle states, launch and termination lifecycle hooks, warm pools for slow-booting applications, and standby versus detach
• Instance refresh: minimum and maximum healthy percentages, checkpoints, skip matching, auto rollback, and the defaults that differ between the console and the CLI
• Application Auto Scaling for ECS services, the second scaling layer under EC2-backed clusters, EKS pod and node scaling, and Lambda concurrency

Why It Matters

Scaling questions on SOA-C03 rarely ask what an Auto Scaling group is. They hand you a symptom (the group will not grow past 12 instances, replacements are killed seconds after launch, tasks sit in PROVISIONING, a Lambda function throttles well under its concurrency limit) and expect you to name the setting responsible. That means knowing the defaults, not just the features, because most of these failures are a default nobody chose.

The same skill decides how a real incident goes. A fleet that scales 6 minutes late, a rollout that terminated instances before their replacements were ready, or a service scaling tasks onto a cluster with no room are all recoverable in minutes if you can tell which layer is misbehaving, and a long outage if you cannot.