Service Quota
also called Service Limit
A per-account, per-region cap on how much of a resource may be used — a common and easily-avoided cause of scaling failures and DR failures.
Every cloud service has limits: instances of a type per region, IP addresses, load balancers, function concurrency, API request rates, database connections, storage volumes. Most are adjustable on request; some are hard.
The two moments they cause incidents are both predictable. During a traffic spike, when the autoscaler cannot add capacity because the account has hit its instance limit — the autoscaler is working, and the cloud is refusing. And during a regional failover, when the secondary region's quotas are far lower than the primary's because nothing has ever run there. This is the single most common pilot-light and DR failure, and checking it takes an hour.
The practices that prevent both. Inventory the quotas that matter for each critical workload and record the current usage against each. Alert on utilisation, typically at 70–80%, rather than discovering the ceiling by hitting it. Raise limits ahead of known events — quota increases are requests with lead time, not settings. And verify the DR region's quotas match the primary's, as a standing item in the DR review.
The related point: quotas are also a useful guardrail. A deliberately low concurrency limit on a non-production account is what stops a runaway loop producing a very large bill.