A city recreation registration API sees heavy weekday traffic but almost none on weekends, yet the same peak capacity stays running Saturday and Sunday. What scaling approach best cuts idle cost?
Select an answer to reveal the explanation.
Short Explanation
Leaving weekday rush-hour buses running empty on Sunday still burns fuel. Scale in when demand drops so you are not paying peak rates for quiet hours.
Full Explanation
Elastic scale-in reduces running capacity when metrics or schedules show sustained low demand, which is a primary cost-optimization lever for predictable quiet periods such as weekends on a city recreation registration API. Scheduling or triggering scale-in so weekend fleets shrink to match near-zero traffic stops the municipality from paying peak weekday rates for idle Saturday and Sunday capacity while still preserving the ability to scale out when weekday demand returns. Aligning capacity with demand is responsible stewardship of public cloud budgets.
Pinning every node to a reserved dedicated host that cannot be released locks in spend and removes the very elasticity that would reclaim idle capacity. Doubling the weekday maximum so weekends inherit even larger pools amplifies waste rather than cutting it. Converting weekend traffic to a cold DR site that stays powered on confuses disaster-recovery posture with routine demand shaping and typically increases, rather than decreases, always-on cost.
Exam caveat: scale-in is not the same as disaster failover; weekend idle cost is an elasticity and scheduling problem. Also distinguish scheduled scale-in from reactive scale-in—both can work if quiet periods are predictable.
Operational check: review weekend utilization and billing for the recreation API, implement a schedule or metric-based scale-in policy, verify that Monday morning scale-out meets SLA before peak registration opens, and document the quiet-hour profile in the civic operations runbook. Re-check after seasonal program enrollment changes demand patterns.