A citizen portal must handle lunchtime spikes and quiet nights. Leadership proposes one very large EC2 instance. What cost-and-elasticity guidance should the architect give?
Select an answer to reveal the explanation.
Short Explanation
One mega-server is a snowplow left idling in July—great at noon rush, wasteful at 2 a.m. Smaller instances behind Auto Scaling grow for the lunch spike and shrink when the portal naps.
Full Explanation
Preferring horizontal scaling with an Auto Scaling group of smaller instances is the correct cost-and-elasticity guidance for a citizen portal with lunchtime spikes and quiet nights, because capacity (and cost) can rise for the noon rush and shrink overnight instead of paying continuously for one vertically oversized machine. Municipal portals rarely have flat load; elasticity matches civic traffic patterns. Vertically scaling to the largest instance and disabling Auto Scaling forever fails because a single mega-instance bills for peak capacity through quiet hours and removes the mechanism that tracks demand. Buying a single Reserved Dedicated Host and ignoring traffic patterns fails by locking spend into inflexible tenancy without responding to diurnal spikes and troughs. Replacing the portal with client-side JavaScript so no servers are ever needed for APIs fails conceptually: browsers cannot replace required server-side APIs, authorization, and data access controls for a citizen portal. Exam caveat: variable public portals favor horizontal ASG elasticity over one large vertical instance, Dedicated Host lock-in, or client-only fantasies. Operational check: place the portal behind a load balancer with an ASG of right-sized instances; scale on CPU/request metrics for lunch peaks; verify night scale-in; load-test; and compare monthly cost to the former always-max vertical proposal before council commits budget.