Seasonal tax-deadline traffic spikes overwhelm a city’s web tier that today only upsizes to larger instance types. What scaling approach should the architect prefer for elasticity?

Seasonal tax-deadline spikes call for horizontal elasticity: an Auto Scaling group that adds web instances when CPU or request metrics climb and removes them when demand falls. That pattern lets the city pay for parade-day capacity only when citizens flood the portal, instead of permanently owning a single oversized box sized for the worst hour of the year. Horizontal Auto Scaling is the preferred elasticity approach when the stem contrasts it with vertical upsizing alone.

Keeping a single oversized instance running year-round at peak capacity fails by concept because it is pure vertical over-provisioning—expensive idle capacity most of the year and still a single failure domain. Disabling Auto Scaling and manually rebooting instances when CPU hits 100% fails because reboots do not add capacity; they interrupt service and rely on human reaction time during the tax rush. Moving the entire site into one Availability Zone to simplify vertical growth fails because collapsing to one AZ removes resilience and does nothing to create elastic horizontal capacity across demand swings.

Exam caveat: Prefer horizontal Auto Scaling for elastic web tiers under variable load; vertical scaling (bigger instance types) has hard ceilings and poor cost elasticity. Distractors that disable Auto Scaling, rely on reboots, or shrink AZ count are anti-patterns on SAA-C03.

Operational check: Confirm scaling policies use meaningful metrics (CPU, ALB request count, or custom), min/max/desired capacities cover off-peak and peak, cool-downs prevent thrash, and multi-AZ placement groups instances across failure domains. If the fleet is still one forever-huge instance, elasticity is not implemented.