A county’s DR runbook scales out EC2 and load balancers in a standby Region on failover day. What must be true beforehand so scale-out is not throttled?

Raising and verifying required service quotas in the DR Region before failover day is what must be true so a county ERP or civic app runbook can scale out EC2 and load balancers without being throttled. The practice works because AWS accounts have per-Region service quotas for instances, ELBs, network interfaces, and related resources; a standby Region that looks empty in peacetime may still reject a sudden surge to production scale on disaster day. Pre-approved quota increases turn DR scale-out into an engineering exercise rather than a support-ticket race while citizens wait. Verification matters: a requested increase is not useful until the console/API shows the new limit and a capacity test can launch representative resources.

Ignoring service quotas because DR Regions automatically inherit unlimited capacity on disaster declaration fails by concept—AWS does not lift quotas automatically when you declare a municipal emergency. Relying only on soft-limit emails after the outage has already started fails because quota tickets and approval latency collide with RTO; waiting until sirens are on is too late. Deleting IAM roles in the DR Region to free quota for more EC2 instances fails because IAM role counts are not a substitute currency for EC2 or ELB quotas; destroying identity posture does not grant compute headroom.

Exam caveat: quotas are necessary but not sufficient—instance type availability and reserved planning still matter during Regional stress. Operational check: inventory peak DR launch counts for EC2, ALB/NLB, EBS, and elastic IPs; submit quota increases in the standby Region; and run a scheduled scale-out drill that proves the new limits before annual tabletop exercises.