Cloud Quota & Limits Reference
Machine-readable reference of default service quotas and hard limits for AWS/GCP/Azure (Lambda, SQS, S3, RDS, Cloud Run, Functions, Service Bus) labelled soft vs hard. The numbers models hallucinate.
📄 Product Preview
Try the interactive reader and demo tools below, or get the full product with all content unlocked.
📖 Interactive Reader (Free Preview) 📦 Download Free Sample📁 File Structure 7 files
📖 Documentation Preview README excerpt
Cloud Service Quota & Limits Reference
A machine-readable reference of default service quotas and hard limits for AWS,
GCP, and Azure — the numbers agents and engineers routinely guess wrong. "How many
Lambda concurrent executions by default? What's the max SQS message size? RDS
connection cap? VPCs per region?" This ships those as structured JSON you can load,
diff, and check against, plus a guide on which limits are soft (raise via support)
vs hard (architect around).
Cloud providers change quotas over time and many are account/region specific.
This is a reference baseline (documented defaults at time of authoring) to
plan against — always confirm the live value in your account's quota console
before a production decision. Each entry notes soft vs hard.
Why this is worth buying vs asking a model
LLMs confidently hallucinate specific numbers ("Lambda allows 10,000 concurrent
by default" — it's 1,000 unburstable default in many regions). Being wrong here
causes real outages and failed capacity plans. This is curated, structured, and
labelled soft/hard so you can trust and automate against it.
What's inside
data/aws-limits.json— common EC2/Lambda/S3/SQS/RDS/DynamoDB/API-GW/VPC limits.data/gcp-limits.json— Compute/Cloud Run/Cloud SQL/Pub-Sub/GCS limits.data/azure-limits.json— VM/Functions/Storage/Service-Bus/SQL limits.SOFT-VS-HARD.md— which to plan around vs request an increase for, and how.data/schema.json— the JSON shape, so you can validate/extend it.
Use it
# e.g. check your planned concurrency against the default
python3 -c "import json; d=json.load(open('data/aws-limits.json')); \
print(d['lambda']['concurrent_executions'])"
Each entry: { value, unit, scope, soft|hard, note }.
Requirements
None. JSON — load from any language.
License
MIT.
📄 Content Sample SOFT-VS-HARD.md
Soft vs Hard Limits — how to react to each
Soft limits (default quotas)
Raise them via the provider's quota/support flow. Plan for lead time.
- AWS: Service Quotas console → request increase (some auto-approve, big ones
go to support; can take hours–days). Common ones to pre-raise: Lambda
concurrency, vCPU per region, API Gateway throttle, SES sending.
- GCP: IAM & Admin → Quotas → edit; some need a support case.
- Azure: Subscription → Usage + quotas → request increase (vCPU quotas are the
usual blocker — the 20-core default bites large deploys).
Rule: if a launch needs more than the default, request the increase weeks
ahead. A quota denied at launch time is an outage you scheduled.
Hard limits (architectural)
Cannot be raised — design around them.
- Message size caps (SQS 256KB, Pub/Sub 10MB) → store payload in object storage,
pass a pointer.
- API Gateway 29s / sync request timeouts → switch long work to async (queue + poll
or webhook).
- Item size (DynamoDB 400KB) → split items or offload large attributes.
- Single-object write rate (GCS 1/s sustained) → shard keys.
Rule: hard limits should shape your architecture from day one; discovering one
in production means a rewrite.
For agents
When planning capacity or generating IaC, load the JSON, check the planned value
against the default, and: if over a soft limit → emit a "request quota increase"
task; if over a hard limit → flag an architecture change. Never assume the number.