Operational Excellence and Automation · Topic 6 of 7
Scaling, Capacity and Automated Runbooks
Choose target tracking, step, scheduled or predictive scaling, plan capacity with Service Quotas and AWS Health, and automate patching and runbooks.
- 5 min
- Target tracking is the default; step scaling gives graded responses; scheduled scaling fits known times.
- Predictive scaling needs history, can run forecast only first, and pairs with target tracking.
- Warm pools and default instance warmup handle slow-starting instances.
What it is
A well-run workload adds and removes capacity by itself, never hits an account quota by surprise, and responds to routine events with a tested runbook instead of a person typing commands.
This page covers the scaling policy choice, the capacity limits that scaling depends on, and Systems Manager automation for patching, remediation and incident response across many accounts.
How it works
Choosing a scaling policy
| Policy | How it works | Best for |
|---|---|---|
| Target tracking | Keeps a metric near a target, such as 50 percent CPU or requests per target | Most workloads, the default choice |
| Step scaling | Adds or removes set amounts at alarm thresholds | Different responses for small and large breaches |
| Simple scaling | One adjustment, then waits for a cooldown | Legacy designs; prefer target tracking or step |
| Scheduled scaling | Changes minimum, maximum or desired capacity at set times | Known events, such as business hours or a launch |
| Predictive scaling | Forecasts load from history and launches capacity ahead of time | Recurring daily or weekly patterns with slow startup |
Predictive scaling for EC2 Auto Scaling needs at least 24 hours of history and forecasts 48 hours ahead. Start it in forecast only mode to compare forecasts with real load, then switch to forecast and scale. Predictive scaling only scales out, so combine it with target tracking to scale in and to handle unexpected spikes.
Slow-starting instances are the usual reason for predictive scaling or a warm pool of pre-initialized instances. A default instance warmup stops new instances from counting in metrics before they are ready.
Application Auto Scaling applies the same policy types to ECS services, DynamoDB provisioned capacity, Aurora replicas, Lambda provisioned concurrency and more. Scale queue workers on backlog per instance, not CPU, because CPU does not reflect waiting messages.
Health monitoring and capacity planning
Scaling fails if the account cannot launch more capacity. Treat quotas as part of capacity planning.
| Need | Tool |
|---|---|
| See and raise quotas | Service Quotas, with quota increase requests |
| Alarm before reaching a quota | CloudWatch alarms on usage metrics that Service Quotas shows against the quota |
| Same raised quotas in every new account | Service Quotas quota request template with AWS Organizations |
| Checks across many services | AWS Trusted Advisor service limit checks |
| AWS side events such as scheduled maintenance or service issues | AWS Health, with an organizational view and events in EventBridge |
AWS Health events arrive in EventBridge. A rule can notify the owning team or start a runbook, for example to replace an instance scheduled for retirement before AWS stops it.
For guaranteed capacity at a critical moment, On-Demand Capacity Reservations hold instances in a specific Availability Zone. They answer capacity risk, while Savings Plans answer price.
Automated runbooks with Systems Manager
| Task | Systems Manager capability |
|---|---|
| Multi-step operational tasks | Automation runbooks, AWS owned or custom |
| One command on many instances | Run Command with rate controls |
| Keep configuration in a desired state | State Manager associations |
| Patching on a schedule | Patch Manager with patch baselines and maintenance windows |
| Organization-wide patching | Patch policies set up through Quick Setup |
| Track and work operational issues | OpsCenter OpsItems |
| Approval before risky changes | Change Manager templates and approvals |
Automation runbooks can run across multiple accounts and Regions from a central or delegated administrator account. Each runbook step can call AWS APIs, run scripts, pause for approval, and branch on results.
Patch Manager scans or installs patches against a baseline that sets which patches are approved and after how many days. Scan first to report compliance, then install in maintenance windows with concurrency and error thresholds so one bad patch does not take down a whole fleet.
For incident response, build the steps an on-call engineer would follow as an Automation runbook, test it, and trigger it from an alarm or event. People then handle only the cases automation cannot.
How the exam asks about this
- "Traffic rises sharply every weekday at 08:00 and instances take 10 minutes to boot" -> predictive scaling, or a scheduled action, combined with target tracking.
- "New accounts keep failing launches because default quotas are too low" -> a Service Quotas quota request template applied through AWS Organizations.
- "Patch all Linux instances in every account monthly with minimal operational overhead" -> Patch Manager patch policies through Quick Setup with maintenance windows.
What to remember for the exam
- Target tracking is the default; step scaling gives graded responses; scheduled scaling fits known times.
- Predictive scaling needs history, can run forecast only first, and pairs with target tracking.
- Warm pools and default instance warmup handle slow-starting instances.
- Service Quotas usage alarms and request templates stop quotas from breaking scaling.
- AWS Health events in EventBridge can trigger automated responses.
- Systems Manager Automation, Patch Manager and State Manager turn manual tasks into rate-controlled runbooks.
Predictive scaling forecasts recurring patterns. For a one-off event with a known date, use a scheduled action, because history cannot predict an event that has never happened.
Common mistakes
Scaling queue consumers on CPU. A long queue with idle CPU means workers are not scaling. Use a backlog per instance metric with target tracking.
Ignoring account quotas. Auto Scaling stops at the quota no matter how good the policy is. Monitor usage against quotas and raise them before a peak.
Writing one-off scripts for recurring tasks. Scripts on laptops are untracked and untested. Systems Manager runbooks give logging, approvals and rate controls.
Check yourself
Which scaling policy launches capacity before a daily peak based on past load?
Predictive scaling, ideally combined with target tracking to handle unforecast spikes.
How do you make sure every new account in the organization gets higher quotas?
Use a Service Quotas quota request template associated with AWS Organizations.
What triggers a Systems Manager runbook automatically when an alarm fires?
An EventBridge rule on the alarm state change with the Automation runbook as its target.
Topic 6 of 7 in Operational Excellence and Automation
Test yourself on Operational Excellence and Automation
The full AWS SAP-C03 question bank has 850 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.