All cheat sheets
Computecheat sheet

Auto Scaling Groups

Match EC2 capacity to real demand automatically — target-tracking, step, and scheduled policies plus a mixed On-Demand/Spot instances policy. Running 3 instances most of the day and bursting to 10 at peak beats 10 instances 24/7 by ~56%.

Last reviewed: July 14, 2026

Prefer step by step? Take the guided Auto Scaling Groups walkthrough — free, anonymous, interactive.Have an AI assistant? Jump to the copy-paste audit prompt at the bottom of this sheet.

TL;DR: An Auto Scaling Group adds instances when demand is high and removes them when it's quiet — you set min/max/desired and scaling policies, AWS executes. The savings are structural: over-provisioning ("10 instances just in case") wastes money, under-provisioning drops traffic, and an ASG lets you run a low baseline and burst only when needed. Layer a mixed On-Demand/Spot instances policy on top and the same elasticity gets dramatically cheaper.

The numbers

  • Three knobs: min (floor, even at 3 AM), max (ceiling), desired (current target, moved automatically by policies).
  • Policy types: target tracking ("keep CPU ~50%", easiest and most common), step (graduated thresholds), scheduled (known daily patterns).
  • Core saving: 10 instances at peak but only 3 needed 80% of the time → without ASG 240 instance-hours/day; with ASG (3 × 19.2h + 10 × 4.8h) = 105.6 → ~56% less compute.
  • Cooldown default 300s prevents runaway scaling while new instances boot; ELB health checks catch app-level failures EC2 checks miss.
  • Field examples: an e-commerce site with daily peaks cut $800→$350/mo (>50%) with scheduled + target-tracking; a bursty microservices API ran 60% cheaper via request-count target tracking + a mixed On-Demand-base/Spot policy.

Do this

  1. Default to target-tracking policies (CPU, request-count-per-instance, or a custom CloudWatch metric like queue depth) — they handle most cases with minimal tuning.
  2. Add scheduled scaling for predictable patterns (scale up weekday 8 AM, down at 6 PM) and let target-tracking absorb the variance.
  3. Enable ELB health checks for web apps — an instance can be "running" per EC2 yet failing to serve traffic; ELB checks catch that and replace it.
  4. Add a mixed-instances policy for interruption-tolerant tiers — an On-Demand base for reliability plus Spot above it, with capacity-optimized allocation and diversified instance types; ASG auto-replaces reclaimed Spot.
  5. Version launch templates and spread across AZs — versioned templates give clean rollbacks; multi-AZ gives HA for free.

Gotchas

  • Cooldowns matter — without them, an ASG can launch instance after instance while the first ones are still booting and CPU is still high; the 300s default gives metrics time to settle.
  • EC2 health checks miss application failures — use ELB checks behind a load balancer.
  • A too-low max caps you during real spikes; a too-high min wastes money at idle — size both to observed patterns, not fear.
  • Lifecycle hooks are the escape hatch for graceful connection draining or config pulls on launch/terminate.

Skip this if

  • The workload is genuinely flat 24/7 — an ASG still gives HA (auto-replacement), but the elasticity savings are small; commit the steady baseline with Reserved Instances or Savings Plans instead.
  • You want guaranteed capacity with no interruption risk — skip the Spot mix and run On-Demand. For interruption-tolerant burst capacity, pair with Spot Instances; for dev/test that's idle off-hours, EC2 Instance Scheduling is the simpler lever; for advanced multi-pool provisioning, EC2 Fleet.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account's Auto Scaling Groups for cost and
elasticity. Use the AWS CLI with READ-ONLY credentials. Do not create,
modify, or delete anything — report findings and recommended (unapplied)
fixes only.

1. Inventory: aws autoscaling describe-auto-scaling-groups — min/max/
   desired, launch template, scaling policies, health-check type, and
   mixed-instances policy (On-Demand vs Spot split). Flag fixed-size ASGs
   (min==max==desired) that could scale.
2. Over-provisioning: pull CloudWatch GroupInServiceInstances +
   per-instance CPU/request metrics over 30 days; flag ASGs whose desired
   rarely moves off a high floor while utilization is low.
3. Policy fit: recommend target-tracking for unpredictable load,
   scheduled for known patterns, step for graduated response; flag EC2-
   only health checks where ELB checks would catch app failures.
4. Spot opportunity: for interruption-tolerant tiers, recommend a mixed-
   instances policy (On-Demand base + Spot above) with capacity-optimized
   allocation and diversified instance types.

Report a table: ASG | min/max/desired | policy | health check | Spot? |
recommendation | est. $/mo saved. Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The Auto Scaling Groups walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough

More Compute cheat sheets

Amazon Lightsail

AWS with the training wheels on: fixed-price monthly bundles ($3.50–$40) that roll compute, storage, and data transfer into one predictable number. The right tool for WordPress, dev environments, and small apps — and the wrong one past ~16 GB RAM.

AWS Batch with Spot

Run batch and data-processing jobs at 70–85% off On-Demand by letting AWS Batch handle Spot interruptions for you — diversified pools, capacity-optimized allocation, and automatic retries. Set min_vcpus=0 and pick the right allocation strategy.

AWS Compute Optimizer

Free ML-driven rightsizing for EC2, Auto Scaling Groups, EBS, Lambda, and Fargate — reads CloudWatch metrics over 14 days and hands you specific downsizes with dollar figures and a performance-risk rating. Enable it, install the agent for memory, act monthly.

AWS Graviton-based Instances

Switch from x86 to AWS's ARM-based Graviton chips for up to 40% better price-performance — often a single config change. Lambda arm64 is a one-field flip; containers are a base-image swap; the savings compound every hour, forever.