---
cuppy_hub: gcp
cuppy_path: reference/overview/quotas-and-limits-model.md
cuppy_section: docs
cuppy_doc: DTYH-EFYF
cuppy_doc_uuid: a61eb627-74c8-472d-8885-e0fae52eeed2
cuppy_permalink: https://cuppy.io/gcp/d/DTYH-EFYF
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/overview/quotas-and-limits-model
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 5b8a5c7a313c631ca272d03d04dd10965d0468425a76e2961fa410dfb5558ddc
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Quotas and system limits

## 1. The distinction, and why it decides what you do next

| | What it is | Can it change? |
|---|---|---|
| **system limit** | "fixed constraints, such as maximum file sizes or database schema limitations" | **No** — "cannot be increased or decreased" |
| **quota** | how much, or how fast, you may consume | Yes, by request |

This is the whole of the triage. A failure against a **system limit** is a design change. A failure against a
**quota** is a request, or a backoff. Reading the vendor's page to find out which one you hit is cheaper than
either guess.

## 2. The two quota types

- an **allocation quota** restricts "how much of a resource Google Cloud allocates to you" — concurrent VMs,
  addresses, disks;
- a **rate quota** restricts "the rate at which you can consume a resource" — API requests per minute.

They fail differently. An allocation quota fails at **create** time and stays failing until something is
released or the quota is raised. A rate quota fails intermittently and is answered by **truncated exponential
backoff** first and a quota request second.

## 3. The scopes a quota can attach to

project · folder · organization · user or service account · and geographically regional, zonal or global.

Two consequences:

1. **"The quota" is not one number.** The same metric can be bounded per project *and* per region. The Azure
   hub's record of this platform's own capacity model makes the same point: a refusal that names one bound
   tells you nothing about the others.
2. A per-**service-account** quota means that moving work onto a second identity can be a legitimate
   mitigation, where moving it onto a second project would not be.

## 4. The calls — this is what a document should cite instead of a number

```
gcloud quotas info ...          # read quota information and current usage
gcloud quotas preferences ...   # read and set quota preferences (requests)
```

These are beta-surface commands; `gcloud` must have its beta components available. The console equivalent is
**IAM & Admin → Quotas & System Limits**.

| To do this | Role | Permissions named |
|---|---|---|
| view quotas | Quota Viewer, `roles/servicemanagement.quotaViewer` | `serviceusage.quotas.update` |
| request an adjustment | Quota Administrator, `roles/servicemanagement.quotaAdmin` | `serviceusage.quotas.update`, `cloudquotas.quotas.update` |

*Recorded as the page states it:* the view-only role is listed against an `update` permission, which reads
oddly. The hub does not resolve it — read the roles page before relying on the viewer role being read-only.

Google also documents a **quota adjuster** that requests increases automatically as usage approaches a limit,
and **quota alerts**. For a migration, the adjuster is the difference between a cutover that stalls at 03:00
and one that does not.

## 5. The rule this hub follows, and why

**No adjustable value is typed in any document here.** Not as an example, not "as of today". A typed quota is
wrong for every project whose quota differs and wrong for every reader after the next adjustment, and the
reader cannot tell which. Every document that would need one names the call above instead.

What *is* written down: a number the vendor states as a **system limit** — Secret Manager's 64 KiB payload,
IAM's 1,500 principals per allow policy, Cloud KMS's "key rings can't be deleted". Those are facts about the
platform's shape, and each one is cited to the page that calls it fixed.

## 6. Cross-cloud

All three clouds separate "fixed" from "askable", and they are **not equally askable** — AWS publishes a table
of increases that are approved automatically, Google Cloud and Azure publish fixed identity ceilings with no
request path. The comparison, and what it does to a capacity plan, is in `guides/parity/identity.md` §3 and
`guides/parity-and-migration-method.md`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->