Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon EC2 Auto Scaling policies determine when and how an Auto Scaling group (ASG) changes its desired capacity. The main policy types are:
- Target tracking scaling
- Simple scaling
- Step scaling
- Scheduled scaling
For most metric-driven scaling requirements, AWS recommends using target tracking when it fits the workload. The other policies remain useful for specialized scaling behavior, particularly scheduled capacity changes and custom step-based responses.
Key Concepts
Target Tracking Scaling
Target tracking maintains a selected CloudWatch metric near a defined target value. The ASG automatically increases or decreases capacity based on whether the metric is above or below the target.
A common example is maintaining average CPU utilization at 60%:
- The ASG currently contains four instances.
- Average CPU utilization rises to 71.5%.
- Because the observed value is above the 60% target, Auto Scaling launches additional instances.
- After the new instances complete their warm-up period, their metrics become eligible for scaling calculations.
Target tracking is conceptually similar to a thermostat: instead of defining every scaling threshold and adjustment manually, you specify the desired operating level and let Auto Scaling determine the capacity change.
Typical target metrics include:
- Average CPU utilization
- Average network traffic per instance
- Application Load Balancer request count per target, when supported by the scaling configuration
Target tracking is generally the preferred option for continuously varying demand because it automatically manages both scale-out and scale-in behavior around the target.
Instance Warm-Up
New instances require time to boot, initialize the operating system, retrieve application code, register with a load balancer, and become ready to serve traffic. During the configured instance warm-up period, their metrics are not counted in the same way as fully contributing instances for scaling decisions.
Warm-up prevents Auto Scaling from reacting prematurely to incomplete capacity. The value should reflect the actual time required for an instance to become productive, not an arbitrary delay.
Scaling policies work best with metrics available at a sufficiently short interval. The lesson emphasizes using metrics reported at approximately one-minute frequency for responsive scaling.
Simple Scaling
Simple scaling uses a CloudWatch alarm to trigger a predefined scaling adjustment. For example:
- A CloudWatch alarm is configured for average CPU utilization greater than or equal to 60%.
- CPU utilization reaches 70%.
- The alarm invokes the ASG scaling policy.
- The ASG launches the configured number of instances.
- A cooldown period—such as 300 seconds—prevents another scaling activity from starting immediately.
Simple scaling applies one fixed adjustment per alarm event. It does not automatically vary the number of instances based on how far the metric has moved beyond the threshold.
Step Scaling
Step scaling also uses CloudWatch alarm breaches, but the scaling adjustment depends on the size of the breach. This permits a more aggressive response to severe demand spikes.
For example, a policy could define different adjustments for different CPU ranges:
| Metric condition | Scaling response |
|---|---|
| CPU moderately above the alarm threshold | Add 2 instances |
| CPU substantially above the threshold | Add 4 instances |
The exact thresholds and adjustments are policy choices. The important distinction is that step scaling uses breach magnitude to select the adjustment, whereas simple scaling applies a fixed adjustment.
Scheduled Scaling
Scheduled scaling changes the ASG capacity at a known time. It is appropriate when demand follows a predictable schedule, such as:
- A business application that becomes busy at the start of each workday
- A batch-processing window that begins at a known time
- A recurring event with predictable attendance
If instances must be ready by 9:00 AM, a scheduled action could increase capacity at 8:45 AM to allow time for instance launch and initialization.
Scheduled scaling can be combined with dynamic policies. For example, scheduled scaling can provision a baseline before a known traffic surge, while target tracking handles demand above or below the forecast.
Architecture Decision Guide
| Requirement | Preferred policy | Reason |
|---|---|---|
| Keep a metric near a desired value as demand changes | Target tracking | Automatically adjusts capacity around a target |
| Apply one fixed adjustment after an alarm breach | Simple scaling | Straightforward threshold-and-adjustment behavior |
| Scale by different amounts for different breach magnitudes | Step scaling | Supports tiered responses to metric severity |
| Capacity demand is predictable by time | Scheduled scaling | Changes capacity at a specified time |
| Known traffic increase plus unpredictable variation | Scheduled plus target tracking | Scheduled action establishes baseline; dynamic policy handles variation |
Exam-Relevant Takeaways
- Target tracking is the default choice for many continuous, metric-based scaling requirements.
- Target tracking scales toward a metric target, such as ASG average CPU utilization of 60%.
- New instances generally need a warm-up period before their metrics are fully considered in scaling decisions.
- Simple scaling uses a fixed adjustment after a CloudWatch alarm breach and commonly relies on a cooldown period.
- Step scaling varies the adjustment according to the size of the alarm breach.
- Scheduled scaling is the right fit when the timing of increased or decreased capacity is known in advance.
- One-minute metric frequency supports more responsive scaling than longer reporting intervals.
- Scheduled scaling does not replace dynamic scaling when actual demand can vary unexpectedly.
Common Exam Traps
- Choosing scheduled scaling for unpredictable demand: A schedule handles known timing, not sudden unplanned load. Use a dynamic policy as well when demand is variable.
- Confusing step scaling with simple scaling: Simple scaling applies a predefined adjustment; step scaling selects an adjustment based on the breach range.
- Ignoring instance warm-up: Immediately counting newly launched instances can cause repeated, unnecessary scale-out actions while capacity is still starting.
- Assuming target tracking requires manual scale-in thresholds: Target tracking manages movement around the target rather than requiring separate manually designed thresholds for ordinary operation.
- Using a long metric interval for fast-changing traffic: Delayed metrics can make scaling react too slowly to bursts.
- Scaling only for CPU when CPU is not the bottleneck: The policy should use a metric that represents actual demand and capacity pressure for the application.
Real-World Engineer Notes
- Measure the complete readiness path when selecting warm-up: instance launch, configuration, application startup, health checks, and load balancer registration.
- A target tracking policy is only as effective as its metric. CPU utilization may be appropriate for compute-bound workloads but may not reflect queue depth, request volume, or downstream saturation.
- Scheduled scaling can reduce cold-start impact before a known demand period and may improve user experience compared with waiting for a reactive alarm.
- Do not set scheduled capacity so high that it becomes a permanent source of unnecessary cost. Use it to establish a reasonable baseline and allow dynamic policies to adjust around it.
- Scaling responsiveness depends on both metric publication frequency and application startup time. Fast alarms do not help if new instances take several minutes to become healthy.
Quick Reference Summary
- Target tracking: Maintain a metric near a target; generally preferred for dynamic demand.
- Simple scaling: One alarm breach causes one fixed adjustment, followed by a cooldown.
- Step scaling: The adjustment changes according to the size of the metric breach.
- Scheduled scaling: Change capacity at a known time.
- Warm-up: Allows new instances to become productive before their metrics influence scaling decisions.
- Metric frequency: Approximately one-minute reporting supports responsive scaling.
Flashcards
- Q: What is the main purpose of target tracking scaling?
A: To automatically adjust ASG capacity so a selected metric remains near a defined target value.
- Q: What happens when average CPU utilization exceeds a target tracking value?
A: The ASG increases capacity by launching additional instances.
- Q: Why is instance warm-up important?
A: It prevents newly launched instances from being treated as fully productive before they finish initialization.
- Q: What does simple scaling use to initiate scaling?
A: A CloudWatch alarm breach that invokes a predefined scaling adjustment.
- Q: How does step scaling differ from simple scaling?
A: Step scaling chooses the adjustment based on the size of the alarm breach; simple scaling uses a fixed adjustment.
- Q: When is scheduled scaling appropriate?
A: When increased or decreased demand occurs at a predictable time.
- Q: Why might scheduled scaling be triggered before a traffic event?
A: To allow time for instances to launch, initialize, and become healthy before demand arrives.
- Q: Which scaling policy is generally recommended for continuously changing demand when applicable?
A: Target tracking scaling.
- Q: What type of metric frequency supports responsive scaling?
A: Approximately one-minute metric reporting.
- Q: Can scheduled and dynamic scaling be used together?
A: Yes. Scheduled scaling can establish a baseline while target tracking or another dynamic policy handles unexpected variation.
Practice Questions
Question 1
An online application normally has low traffic overnight but receives a predictable surge every weekday at 9:00 AM. The architect wants instances available before users arrive and also wants the application to respond to traffic higher than forecast. Which design best meets the requirements?
A. Use only simple scaling based on CPU utilization
B. Use scheduled scaling before 9:00 AM and target tracking during the workday
C. Use only scheduled scaling and disable dynamic policies
D. Use step scaling with a single CPU threshold
Correct answer: B
Explanation: Scheduled scaling can establish capacity before the predictable surge. Target tracking can then adjust capacity when actual demand differs from the forecast.
Question 2
An ASG must maintain average CPU utilization close to 60% as application demand changes. The solution should minimize manually configured thresholds and support both scale-out and scale-in. Which policy should be selected?
A. Target tracking scaling
B. Scheduled scaling
C. Simple scaling
D. A fixed desired capacity
Correct answer: A
Explanation: Target tracking is designed to maintain a selected metric near a target and is generally preferred for this type of continuously varying workload.
Question 3
A CloudWatch alarm triggers when average CPU utilization reaches 60%. The operations team wants to add two instances for a moderate breach but four instances when utilization is substantially higher. Which scaling policy supports this behavior?
A. Simple scaling
B. Scheduled scaling
C. Step scaling
D. Target tracking with no target value
Correct answer: C
Explanation: Step scaling supports multiple adjustment levels based on the magnitude of the alarm breach. Simple scaling uses a fixed adjustment.
Question 4
An ASG launches new instances in response to high CPU. Before the instances finish initializing, the same high metric causes another scale-out action. Which configuration concern should be investigated first?
A. Whether the ASG uses a warm-up period appropriate for instance readiness
B. Whether scheduled scaling is enabled for every hour
C. Whether the load balancer has a static IP address
D. Whether the ASG uses a larger instance type instead of multiple instances
Correct answer: A
Explanation: The warm-up period prevents new instances from being counted as fully contributing before they are ready. An unsuitable or missing warm-up value can cause premature repeated scaling decisions.
Question 5
A team configures an alarm for CPU utilization above 60%. When utilization reaches 70%, it wants to launch a fixed number of instances and then prevent another scaling action for five minutes. Which policy most closely matches this requirement?
A. Simple scaling with a 300-second cooldown
B. Step scaling with multiple breach ranges
C. Scheduled scaling at five-minute intervals
D. Target tracking with no metric target
Correct answer: A
Explanation: Simple scaling uses a fixed adjustment after an alarm breach and can use a cooldown period, such as 300 seconds, before another scaling activity is permitted.