Cloud Service Quotas: Avoid Hitting Limits

Some cloud outages have nothing to do with failing hardware or bad code. A deployment fails because the account cannot create more instances. Autoscaling stops adding capacity during a traffic peak. A new environment in another region cannot launch because limits there are lower than expected. These are quota problems. Cloud service quotas are the maximum amounts of resources or requests an account can use for each service, and they exist to protect both the provider and customers from runaway usage. They are easy to ignore until one is reached at the worst possible moment. This guide explains how quotas work, where they tend to cause trouble and how to track usage and request increases before they become an incident.

What cloud service quotas are

Every major cloud provider applies quotas. AWS documentation explains that each account has default quotas, formerly referred to as limits, for each AWS service; that unless otherwise noted, each quota is specific to a region; and that you can request increases for some quotas, but not all quotas can be increased (AWS: service quotas). Other providers use similar concepts, sometimes with different names.

Quotas typically cover things such as:

• Number of virtual machines, CPUs or GPUs in a region
• Number of IP addresses, load balancers or networks
• Database instances, storage volumes and snapshots
• API request rates to management and service endpoints
• Concurrent executions of serverless functions

Why quotas cause outages

Quota problems tend to appear at awkward times:

• Traffic peaks: autoscaling needs more capacity than the quota allows
• Disaster recovery: a standby region has lower quotas than the primary
• New projects: a fresh account or region starts with defaults lower than expected
• Batch jobs: large processing runs hit concurrency or request rate limits
• Gradual growth: usage creeps up until a routine deployment fails

Because quotas are often region-specific, a setup that works in one region can fail in another.

Find out which quotas apply

Start by listing the services and regions you use, then review the quotas that matter most for each. Providers offer consoles and APIs for viewing current quotas and, for many services, current usage. Focus first on:

• Compute capacity in each region you use
• Networking resources such as IP addresses and load balancers
• Database and storage resources
• Serverless concurrency and API rate limits
• Anything your disaster recovery plan depends on in a second region

Document the quota, current usage, expected peak and owner for each.

Track usage against quotas

Knowing the quota is not enough; you need to see how close you are. Set up monitoring that compares usage with quotas for important resources, using provider tools where available. Review trends monthly so you can see growth coming rather than discovering it during an incident. Include quota headroom in regular capacity reviews alongside cost and performance, so all three are discussed together.

Alert before you hit the limit

Set alerts at sensible thresholds, such as when usage passes a set share of a quota. Route alerts to someone who can act, with enough lead time to request an increase. An alert that fires only when the quota is reached gives no time to respond.

Request increases in advance

Where quotas can be raised, request increases before you need them. Providers may take time to review requests, especially for large increases or scarce resources. Plan ahead for:

• Product launches and marketing campaigns
• Seasonal peaks
• New regions or environments
• Disaster recovery tests and failover capacity

Keep a record of requests, approvals and new values so the team knows what has been agreed.

Worked example: a quota register

The table below is a hypothetical quota register for a business application running in two regions. The figures are illustrative, not real provider defaults.

Service and resourceRegionQuotaNormal usageExpected peakActionVirtual CPUs for application serversPrimary20080160Monitor; alert above 70%Virtual CPUs for application serversRecovery640160 during failoverRequest increase before DR testPublic IP addressesPrimary1068MonitorServerless concurrent executionsPrimary1,000300900 during month-end jobsRequest increase; spread jobsManaged database instancesPrimary201214Monitor

In this hypothetical case, the recovery region would fail to provide enough capacity during a failover, which is exactly the kind of gap a register reveals.

Design to stay within quotas

Some quota pressure can be reduced through design:

• Spread batch jobs over time rather than running everything at once
• Use queues to smooth bursts of work
• Clean up unused resources, such as old snapshots, idle IP addresses and test environments
• Reuse connections and cache results to reduce API calls
• Choose larger resources where that reduces counts against per-resource quotas

Separate environments carefully

Testing, staging and production often share an account or project to save effort. That means a heavy load test or a forgotten test cluster can use up quota that production needs. Where practical, separate production into its own account or project so its quotas are not consumed by other work. If environments must share, agree limits for non-production use and monitor them.

Assign clear ownership

Quotas fall between teams: developers create resources, operations teams watch systems and finance watches bills. Make one person or team responsible for the quota register, alerts and increase requests. Include quota checks in launch checklists, so every new service or region has its limits reviewed before it goes live.

Handle quota errors gracefully

Applications and automation should expect occasional quota or rate limit errors. When an API call is throttled, retry with backoff rather than immediately repeating the request. Make deployment pipelines report quota errors clearly so engineers know the cause. Our guide to API quota management covers handling rate limits and quotas in third-party APIs, and many of the same techniques apply to cloud service APIs.

Include quotas in disaster recovery planning

A recovery plan that depends on launching resources in another region must account for that region's quotas. Check them during planning, request increases if needed and confirm them during recovery tests. Otherwise, the plan may fail at the moment it matters most.

Review quotas as part of architecture changes

When adding a service, moving to a new region or changing scaling settings, review the related quotas as part of the design. Our guide to cloud architecture consulting covers how capacity planning fits into wider cloud design.

Frequently Asked Questions

What are cloud service quotas?

They are the maximum amounts of resources or requests an account can use for each cloud service, often set per region.

Can cloud service quotas be increased?

Many can. AWS, for example, says you can request increases for some quotas, but not all quotas can be increased.

Why do quotas cause outages?

Because autoscaling, deployments, batch jobs or disaster recovery can need more resources than the quota allows, causing requests to fail.

How do you avoid hitting quotas?

Track usage against quotas, alert well before limits, request increases ahead of planned peaks and design workloads to smooth demand.

Keep capacity limits from surprising you

We review cloud quotas, set up usage monitoring and plan capacity for peaks and recovery. See our custom app development services, or talk to us about cloud service quotas.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.