Auto Scaling And Reliability Design — AWS Solutions Architect (SAA-C03)
Scaling policy type must match traffic shape
Architecture requirement: maintain performance under variable load without over-provisioning. Competing choices: target tracking, step scaling, scheduled scaling, and Reserved Instance capacity. Deciding constraint: is load predictable, reactive, or spike-driven? Target tracking is the low-overhead default for smooth variable load; scheduled scaling handles known peaks; step scaling gives granular control when target tracking's responsiveness is insufficient. The exam expects you to match policy type to the described traffic pattern, not select the most configurable option.
What This Pattern Tests
The exam describes a scaling scenario and tests which auto-scaling policy type applies. Target tracking maintains a metric at a target value (simplest, best for most cases). Step scaling adds specific capacity at specific thresholds (when CPU > 70% add 2, when > 90% add 4). Scheduled scaling adds capacity on a schedule (scale up at 9am Monday, scale down at 6pm Friday). Predictive scaling uses ML to pre-scale based on patterns. The trap is using step scaling for a simple "keep CPU around 60%" requirement (target tracking is simpler) or target tracking for a known daily traffic spike (scheduled scaling pre-provisions before the spike hits).
Decision Axis
Traffic pattern determines scaling policy: steady growth = target tracking, threshold responses = step, predictable peaks = scheduled, learned patterns = predictive.
Associated Traps
Decision Rules
Whether to externalize session state to a shared cache (ElastiCache) or reroute sessions via ALB sticky sessions — the correct choice removes instance-level state affinity entirely and enables true stateless horizontal scaling; the wrong choice masks the symptom while reintroducing tight coupling per user session.
Whether to configure the Auto Scaling group health check type as ELB rather than EC2, so that application-layer failures detected by the load balancer trigger automatic instance replacement rather than leaving degraded instances in service.
Which health check type must be set on the EC2 Auto Scaling group so that application-layer failures—not just host-level failures—trigger automatic instance replacement?
Whether target tracking (autonomous threshold management against a single metric target) or step scaling (manually configured CloudWatch alarm per step band) satisfies the combined metric-normalised elastic workload and minimal-operational-overhead constraint — fixed over-provisioned capacity is disqualified by the variability and cost constraints.
Domain Coverage
Difficulty Breakdown