A city tax portal sees seasonal filing spikes and runs a stateless EC2 web fleet behind a load balancer. How should compute scale to meet request demand?

A city tax portal with seasonal filing spikes and a stateless EC2 web fleet should scale horizontally with demand. EC2 Auto Scaling policies that add and remove instances based on request count (or comparable demand metrics) grow capacity when citizens flood the site and shrink it afterward, while the load balancer distributes traffic across healthy instances. That elastic, metric-driven scale-out pattern is the Task 3.2 high-performing compute answer for seasonal municipal web load. Vertically resizing one EC2 instance once per year based on last year’s peak fails because static vertical planning cannot track intra-season spikes, creates a single large failure domain, and ignores horizontal elasticity behind the load balancer. Disabling the load balancer and pinning traffic to a fixed pair of instances fails conceptually by removing distribution and Auto Scaling’s ability to absorb surge, guaranteeing overload when filings exceed two boxes. Scheduling a single Spot interruption to shrink the fleet during peak hours fails because deliberately reducing capacity at peak is the opposite of meeting request demand and invites citizen-facing outages. Exam caveat: Auto Scaling needs healthy AMIs or launch templates, proper cooldowns, and metric selection—request count is one valid signal, but mis-tuned thresholds can thrash or lag. Operational check: attach scaling policies to the ASG using request or target-tracking metrics, load-test a filing-day spike, confirm new instances register with the load balancer before taking traffic, and verify scale-in does not drop in-flight sessions abruptly.