A county permitting portal autoscales under load, but a runaway rule once spun up hundreds of instances overnight and exhausted the cloud budget. What scaling guardrail should operations set?

Autoscaling without an upper bound can create uncontrolled cost and capacity growth when a rule misfires, a metric spikes, or traffic is not what operators expected. For a county permitting portal that serves residents and businesses, configuring a maximum instance (or replica) cap places a budgeted ceiling on horizontal scale-out so elastic growth remains possible within a planned range rather than overnight budget exhaustion. That guardrail is a civic stewardship control: taxpayer-funded cloud spend must stay predictable even when automation reacts aggressively.

Disabling all autoscaling and relying on a single oversized VM abandons elasticity and recreates a capacity cliff—either the VM is too small at peak or it wastes money at quiet hours. Removing the minimum instance count so the service can drop to zero addresses floor behavior for availability and cost during lulls; it does not stop runaway scale-out. Raising the CPU scale-out threshold until nothing ever launches effectively disables beneficial autoscaling and leaves citizens facing slow or failed permit submissions under real load.

Exam caveat: max caps, min floors, and scale thresholds solve different problems—do not treat them as interchangeable. A max protects budget and blast radius; a min protects warm capacity; thresholds tune sensitivity.

Operational check: in the autoscaling policy or orchestrator HPA/replica limits, set and document the maximum instance count, alert when utilization approaches the cap, and rehearse what on-call should do if the portal saturates at the ceiling during a filing deadline. Record the cap and rationale in the municipal change ticket so future operators inherit the budget boundary.