Cloud Service Quotas and Limits Explained
Service quotas cap how many servers, vCPUs, IPs, and API calls an account can use. Learn why providers set them, where AWS, Google Cloud, Azure, DigitalOcean, and Hetzner show them, and how to request more.
A cloud account never has unlimited capacity. Behind every console sits a table of quotas: the maximum number of servers, vCPUs, IP addresses, volumes, API requests, or emails the account may use. Quotas are the reason a valid payment method and a working credential are not enough to launch a large fleet on day one. This guide explains what quotas are, why providers impose them, how AWS, Google Cloud, Azure, DigitalOcean, and Hetzner expose them, and how to work with them properly.
What a service quota is
A service quota (also called a limit) is a provider-set ceiling on how much of a resource a single account, project, or subscription can consume. Quotas come in two shapes. Allocation quotas cap how many of something you can have at once: running vCPUs, Droplets, servers, VPCs, floating IPs, storage volumes. Rate quotas cap how fast you can do something: API requests per second, emails per day, model inference requests per minute.
Quotas are also classed as adjustable or fixed. Adjustable quotas have a default that can be raised on request. Fixed quotas are architectural limits that no request will change, for example the maximum size of a single object in object storage. Most of the limits that affect a new account are adjustable.
- Allocation quota
- Maximum concurrent resources, such as vCPUs or servers
- Rate quota
- Maximum operations per unit of time, such as API calls per second
- Default quota
- The value a new account starts with
- Applied quota
- The value currently in force after any approved increase
Why providers impose quotas
Quotas serve three purposes. First, they protect the provider’s capacity: a region has finite hardware, and unbounded launches by one customer would starve others. Second, they limit abuse. A new account that could immediately start thousands of servers would be a magnet for cryptomining and spam, so defaults start low and rise with account history. Third, they protect you. A misconfigured autoscaler or a leaked credential can only spend up to the quota, which turns a potential disaster into a bounded bill.
This is why quota levels correlate with account age and payment record. Providers raise limits for accounts that have paid invoices on time and explained their use case, and they keep limits low for accounts they know nothing about. The quota table is, in effect, the provider’s trust score for the account.
How each provider exposes quotas
AWS
AWS centralises limits in the Service Quotas console, which lists every service, its quota names, the default value, and the applied value for your account. Most EC2 limits are expressed in vCPUs per instance family per region. Other well known limits include Elastic IP addresses per region, VPCs per region, Lambda concurrent executions, and the Amazon SES daily sending quota, which starts in a restricted sandbox until production access is approved. Increases are requested directly from the console; some are approved automatically and others are reviewed by support.
Google Cloud
Google Cloud shows quotas under IAM & Admin, filtered by service, region, and metric. Compute Engine quotas such as CPUs, persistent disk capacity, and in-use IP addresses are set per project and per region. Rate quotas for APIs are shown alongside. Increase requests go through the same page and are tied to the project’s billing account, so projects on a free trial billing account typically cannot raise certain limits until the account is upgraded.
Azure
Azure lists quotas in the subscription under Usage + quotas. The main compute limits are total regional vCPUs and a per-family vCPU limit for each region. Free trial subscriptions carry lower ceilings and exclude some VM sizes; converting to pay-as-you-go lifts those restrictions. Requests for more capacity are filed as quota requests, and Azure also lets you set alerts when usage approaches a limit.
DigitalOcean and Hetzner
Developer clouds use simpler, account-wide counts. DigitalOcean applies a Droplet limit to each account or team, along with limits on volumes, load balancers, and floating IPs; you can see the current Droplet limit in the account settings and request more through a form. Hetzner Cloud applies limits per project, including server count, volumes, primary IPs, and load balancers, listed on the project’s Limits page with a request-increase option. Marketplace labels such as “DO 10 Droplet” or “Hetzner 10 Server Account” restate exactly this number: the server-count limit the seller reports for that listing.
| Provider | Where to look | Main compute limit | Scope |
|---|---|---|---|
| AWS | Service Quotas console | On-Demand vCPUs per instance family | Per account, per region |
| Google Cloud | IAM & Admin, Quotas | CPUs | Per project, per region |
| Azure | Subscription, Usage + quotas | Total regional vCPUs and per-family vCPUs | Per subscription, per region |
| DigitalOcean | Account settings | Droplet limit | Per account or team |
| Hetzner | Project, Limits | Server limit | Per project |
Working with quotas in practice
- Read the quota before you plan. Open the quota page for the region you intend to use and note the limits for compute, IP addresses, and any managed service you rely on. Do this on the first day you hold an account.
- Request increases early and honestly. Increase requests ask for the new value and a use case. Describe the real workload, request a realistic number, and expect a review period. Large jumps from a low default are usually declined; a sequence of moderate increases as usage grows is the normal path.
- Monitor usage against the limit. AWS publishes usage metrics for many quotas in CloudWatch and flags limits in Trusted Advisor. Google Cloud exposes quota usage in Cloud Monitoring. Azure offers quota alerts. Set an alert at roughly three quarters of the limit so you have time to request more.
- Design for the limit. Autoscaling groups should have a maximum size below the quota, and deployment scripts should fail cleanly when a launch is refused rather than retrying forever.
- Remember that quotas are per region. Spreading a workload across two regions doubles the compute ceiling but also doubles the quota work.
- Stay within the terms of service. Quotas are part of the provider’s anti-abuse controls. Opening many accounts to add up their limits, or misrepresenting a use case in a request, violates the acceptable use policy and puts every account involved at risk of suspension. The only durable way to more capacity is a well-documented request on an account in good standing.
Where to go next
Listings that describe accounts by their reported vCPU tier are on the Buy AWS Accounts page. Listings described by Droplet limit are on the Buy DigitalOcean Accounts page, and listings described by server limit are on the Buy Hetzner Accounts page. In every case the label restates a limit, and the console is the source of truth.
Related reading in the Cloud Library:
- What is a vCPU? Understanding cloud compute sizing
- Cloud regions and availability zones: how to choose a location
- Amazon SES explained: sandbox, production access, and sending quotas
- Cloud acceptable use policies: what providers expect from account holders
Browse every guide in the Cloud Library, or compare two developer clouds on the Hetzner vs DigitalOcean page.