Home› Blog› GCP Architecture Series #16 — Requesting a Quota Increase, and Designing So You Do Not Have To…
GCP Architecture GCP Architecture Series

GCP Architecture Series #16 — Requesting a Quota Increase, and Designing So You Do Not Have To

A quota increase is the most common answer to a capacity problem on Google Cloud and the least reliable one. It is a request, not a setting: it is reviewed by someone, it can be refused, it arrives on nobody's schedule, and it must generally be made per project — so the fix for a launch on Friday is not a form submitted on Friday.

Aug 29, 2026 12 min read
Verified against current vendor documentation on 29 August 2026. Pricing, limits and API behaviour were checked against the official docs on that date. Cloud services change fast — if you are reading this much later, treat the specifics as a starting point and re-check the linked sources.

Business Challenge

The request itself takes about ninety seconds to submit. Everything difficult about quota increases happens either before that or after it.

1
"We'll raise the quota on the morning of the launch"

A quota adjustment is not a setting you change; it is a request somebody reviews. Google states that Cloud Quotas adjustment requests are subject to review, that a request requiring review generates an email acknowledging receipt, and that a second email afterwards tells you whether it was approved. No timeframe is published for the step in between, and approval is not promised.

Correct approach

Treat quota as lead time, not configuration. Raise it when the capacity plan is written, not when the capacity is needed — and design the launch so that a refusal is survivable rather than fatal.

2
"Raise it once at the organization and be done"

That is available for decreases and largely not for increases. Google is explicit: in most cases, quota increase adjustments must be made at the project level, and only a limited number of products support organization-level increases. Decreases are the generous direction — those can be requested for project-, organization- and folder-level quotas.

Correct approach

Expect to ask per project, and automate it rather than repeating it. The Cloud Quotas API can clone quota configurations from project to project, which is the difference between a new environment being a form-filling exercise and being a script.

3
"The adjuster is on, so we are covered"

Partly, and with two documented holes. The quota adjuster only submits requests to increase a value and never attempts to lower one; and for quotas that carry a manual quota cap, it does not submit requests at all. It also needs a sufficient volume of historical usage data to judge when to ask, so the newest project — the one most likely to be surprised — is the one it can help least.

Correct approach

Enable it, then write down which quotas it is not covering. A cap set for cost control is invisible to the team relying on the automation, and nothing reconciles the two.

4
"Submit everything in one big request"

Google's own guidance points the other way: to reduce review time, group quota adjustment requests by product and area. A single submission mixing GPUs, API rate limits and storage is one request that cannot clear until its slowest component does.

Correct approach

Split by product and area so each lands with the team that can decide it. Batch for convenience only where the batch is homogeneous.

Architecture

There are three ways a quota value changes on Google Cloud, and they are not variations on one mechanism — they differ in who initiates, what is reviewed, and which direction they can move.

Diagram: the three ways a Google Cloud quota value changes, the roles and review each requires, and the four architectural moves that remove the need to request an increase
Three routes to a new quota value, what each requires, and the four designs that make the question moot.

Who is allowed to ask

Two roles divide reading from asking. Quota Viewer (roles/servicemanagement.quotaViewer) sees values and usage. Quota Administrator (roles/servicemanagement.quotaAdmin) requests adjustments. The quota adjuster needs its own permissions, cloudquotas.quotas.update and cloudquotas.quotas.get.

The split is worth honouring rather than collapsing. A quota value is a commercial commitment as much as a technical one, and the ability to read one is needed by everybody who operates the platform while the ability to raise one is not.

The three routes

RouteDirectionReviewedScope
Console or API request Up or down Increases are subject to review; you get an email on receipt and another with the decision. Increases generally project-level only. Decreases at project, folder or organization.
Quota adjuster Up only Submits on your behalf when peak usage approaches the value. Project via the console; folder and organization through the REST API or gcloud CLI.
Quota preference in code Up or down Same review as a console request. Per dimension combination. Cloneable between projects.

The request itself is thin. You enter the quota value you want in the New value field, and if a Request description field appears — which it does for larger increases — you enter a description. That description is the only place a human reviewer learns why the number is what it is, and it is the only part of the form you can actually do well.

A preference is created and updated, never deleted

Deleting a QuotaPreference is not supported. That has a direct consequence for anyone expressing quotas in infrastructure code: destroying the resource does not return the quota to its default, and a mental model borrowed from ordinary resource lifecycles will be wrong here. Returning to a default means setting the default explicitly. QuotaInfo, by contrast, is read-only — it reports what a quota is, and cannot change it.

What the adjuster is actually doing

The quota adjuster observes resource consumption and proactively submits adjustment requests on your behalf, checking whether peak usage has approached the quota value over a specified duration. Two properties make it worth enabling and two make it insufficient on its own.

  • It follows the platform. When a service adds or expands adjuster support for its quotas, the adjuster automatically monitors and adjusts those newly supported quotas — so coverage grows without anybody revisiting a list.
  • It is one-directional. It only ever increases. Nothing in it reclaims quota from a project whose usage has fallen, which means it ratchets: values drift upward over the life of a project and never back.
  • A manual cap disables it silently. For quotas carrying a manual quota cap it submits nothing at all.
  • It needs history. Sufficient historical usage data is a prerequisite for judging when to ask, so a new project gets the least benefit.
The cap and the adjuster point in opposite directions

A manual quota cap is a sensible cost guardrail — it stops a runaway workload consuming an unbounded amount of something expensive. The quota adjuster is a sensible availability guardrail — it stops a growing workload hitting a ceiling unnoticed. Applying both to the same quota does not give you both: the cap wins, and the adjuster stops submitting for it. Nothing warns you, because from each control's own point of view it is working correctly. Decide per quota which risk you are managing, and record the decision somewhere the other team reads.

Why This Architecture Holds Up

A quota increase is the weakest link in a capacity plan because it is the only part that depends on somebody else's calendar. Four designs reduce how often you need one, and three of them are Google's own recommendations for a different problem.

1. Spread across projects, because the boundary is real

Project-level quotas restrict usage within one project, and using the resource in one project does not affect available quota in another. That is an isolation guarantee, and it is usable as a capacity strategy rather than only as a blast radius: Google's own advice for reducing concurrent operations is, in as many words, to split up your applications across multiple projects.

This is the move with the largest effect and the highest cost. More projects means more billing links, more IAM, more of everything covered earlier in this series. Reach for it when a workload is genuinely separable, not to dodge a form.

2. Spread across regions, because regional quota is not project quota

Regional quotas are not a subset of project quotas. A workload that can run in two regions has two independent allowances, and the second one requires no request at all. Where the architecture already wants regional redundancy, the quota headroom is a free consequence of a decision made for other reasons — which is the best kind.

3. Ask for less, by making the client behave

Rate quotas and concurrent operation limits are usually a client problem wearing a capacity costume. Since system limits cannot be modified, Google's recommended practices for reducing concurrent operations are the fix, and every one of them is a change on your side of the wire:

  • Wait for operations to be done before starting new ones.
  • Rely on error codes, not error messages — which matters more than it sounds, because a rate quota and a concurrent operations limit share the reason string rateLimitExceeded.
  • Minimize client-side retries to preserve API rate limits, avoiding short polling and using bursting sparingly.
  • Always make your calls in a retry loop with exponential backoff, and use a client-side rate limiter.

A team that does these four things needs a smaller rate quota than a team that does not, for identical work. No form achieves that.

4. Ask early, from a metric rather than an incident

The pattern Google documents is to track usage and request an increase when usage is over 80% — read the current value from QuotaInfo, read usage from the Cloud Monitoring API, and update the quota preference when the threshold is crossed. Because serviceruntime.googleapis.com/quota/limit is itself a time series, that comparison is a ratio and survives the ceiling changing.

This is the whole game in one sentence: the request that succeeds comfortably is the one submitted while nothing is wrong. A request submitted during an incident is competing with the incident for the same people's attention, and it is subject to exactly the same review.

Decreases are a design tool, not an admission

Because decreases can be requested at project, folder and organization level, a quota is usable as an organization-wide ceiling on something expensive — TPUs, GPUs, large machine families — in a way an increase cannot be. Lowering a quota deliberately, on a folder that should never need the capacity, is one of the few controls that acts before the spend rather than reporting it afterwards. It is the same mechanism as an increase pointed the other way, and it is reviewed far less anxiously.

Key Architecture Decisions

DecisionChoose thisBecause
When to request At capacity planning, not at launch Requests are subject to review with no published turnaround, and approval is not promised.
Where to request Per project, and script it Increases must generally be made at project level; the API can clone configurations between projects.
How to batch Group by product and area Google's stated way to reduce review time; a mixed request waits for its slowest part.
The description field Write it properly It is the only part of the form a reviewer reads and the only part you control.
Quota adjuster Enable, then list what it misses It never lowers a value and skips any quota with a manual cap.
Caps and the adjuster together Pick one per quota, deliberately A manual cap silently stops the adjuster submitting for that quota.
New projects Do not rely on the adjuster It needs a sufficient volume of historical usage data, which a new project does not have.
Rate limit pressure Fix the client first Backoff, rate limiting, waiting for operations and less polling reduce the quota you need for the same work.
Capacity headroom A second region before a bigger number Regional quotas are not a subset of project quotas, so a second region is a second allowance.
Alerting A ratio against quota/limit, firing near 80% The documented pattern, and a ratio survives the ceiling being raised.
Capping spend Request a decrease at folder level Decreases are available at project, folder and organization scope, unlike increases.
Quotas in Terraform Never rely on destroy Deleting a QuotaPreference is not supported; returning to a default means setting it.

Closing Thought

The quota increase form is the most-used capacity tool on Google Cloud and the only one that cannot be tested. Everything else in an architecture can be exercised before it matters — a failover, a scale-out, a restore. A quota request can only be submitted for real, once, at the moment you need it, and then waited on.

Which is the argument for arranging not to depend on it. Not because the process is unreasonable — a cloud that granted every request instantly would be a cloud with no capacity planning at all — but because a dependency you cannot rehearse belongs at the edge of a design rather than in the middle of one. Ask early, ask per product, let the adjuster handle the routine ratchet, and spend the real effort on the four things that mean a refusal costs you a week of headroom instead of a launch.

Next in this series

#17 leaves quotas for a pair of systems that look interchangeable and are not: labels and tags — where each is applied, which one policy can read, and which one your billing export can tell you was inherited rather than set.

Topics: GCP Architecture GCP Architecture Series

Comments

How was your experience?
Your feedback helps improve this site.
PoorExcellent