AWS Service Quotas and Limits cheat sheet · AWS

1.Every Service Has Quotas

AWS looks unlimited and is not. Every service defines maximum values for its resources, actions and items, and your account starts at a default for each one. Some of those defaults can be raised on request; others cannot be changed at all. Knowing which is which for the services you use is the difference between a capacity problem you planned for and an outage.

Key features

AWS defines a service quota as the maximum value for the resources, actions and items in an account; each service sets its own defaults
Quotas may apply per account or per Region, and the quota description says which — VPCs per Region is Region-based, IAM roles per account is account-based
Some quotas are adjustable and some are not; the Service Quotas console shows an "Adjustable" column per quota
An applied quota is an override or increase above the AWS default value for a specific quota
A global quota is applied at account level and can only be increased from US East (N. Virginia) in the standard AWS partition
A quota increase request is reviewed and may be approved, denied, or partially approved — it is not guaranteed and not instant

The vocabulary, and why each term matters

The vocabulary, and why each term matters
Term	Meaning	Why you care
Service quota	The maximum resources or operations for an account or Region	It is the real ceiling, whatever the marketing says
Default value	The initial quota value AWS establishes	Where a brand new account starts — often far below production need
Adjustable value	A quota value that can be increased	Determines whether the fix is a request or a redesign
Applied quota	The updated value after an increase	What is actually enforced today — check it, do not assume the default
Usage	Resources or operations currently in use	The numerator
Utilization	Usage as a percentage of the quota	The number worth alarming on
Global quota	Applied at account level, present in all Regions	Increases are requested only from us-east-1 in the standard partition

Default, applied, and the ceiling you cannot move

Usage is what you consume; utilization is that as a percentage of the quota. The default is a starting point, the applied quota is where you have raised it to, and a hard quota cannot be moved at all.

Signature

default → (adjustable?) → applied quota · usage ÷ quota = utilization · global quotas raised from us-east-1

Every service sets quotas, per account or per Region, and your account starts at a default that may already have been overridden. Split every quota you depend on into adjustable and not: adjustable ones are a request to file early, and non-adjustable ones are design inputs that no request will move.

2.Monitoring Utilization and Requesting Increases Early

A quota you are not watching is a quota you will discover by hitting it. Service Quotas shows utilization — usage as a percentage of the quota — and supports CloudWatch alarms on quotas that report it. An alarm at seventy percent gives you the weeks a review needs; no alarm gives you an incident.

Key features

Service Quotas can create a CloudWatch alarm on a quota, with a threshold you choose, to notify you when you approach the quota value
Utilization only appears for a quota you are actively using, and CloudWatch alarms are offered only for quotas that support them
The console shows current resource utilization as a graph once the account has been active for a period
Service Quotas Automatic Management can monitor quota usage and notify you before you run out of your allocated quota
An increase is requested per quota, per Region — except global quotas, which are requested from us-east-1 in the standard partition
Increases take time to review, process and approve, so the request has to be made before the capacity is needed

What to watch, and where each signal comes from

What to watch, and where each signal comes from
Signal	Source	What it tells you
Quota utilization	Service Quotas console and CloudWatch alarms	How close you are, as a percentage that survives increases
Throttling metrics	The service's own metrics — for example Lambda `Throttles`	You already crossed a limit; this is a symptom, not a warning
Error codes in logs	Application logs and CloudTrail	`ThrottlingException`, `LimitExceededException`, `TooManyRequestsException`
Applied quota values	`get-service-quota` per quota code	The value actually enforced for this account today
Increase history	`list-requested-service-quota-change-history`	What has been raised before, and how long approvals took
Automatic management	Service Quotas Automatic Management	AWS monitoring usage and notifying you before you run out

Where the alarm goes, and how much runway it buys

Alarm on utilization rather than on an absolute count, and set the threshold so the remaining runway is longer than a quota review takes.

Signature

Service Quotas utilization alarm @ ~70% (warning) + service throttling alarm @ >0 (backstop)

Alarm on utilization at around seventy percent so there is runway for a review, and keep a throttling alarm as the backstop for spikes. Record the applied quota rather than the documented default, request increases weeks early, and re-check after every growth event — a quota is never a mitigation during an incident.

3.Limits Are Architecture Inputs

Some limits are numbers to raise; others are constraints that decide the shape of the design. A 15-minute function ceiling is not a capacity problem — it is a statement about what kind of work belongs in a function. Reading those constraints before drawing the architecture is cheaper than discovering them after.

Key features

Lambda functions run for at most 900 seconds and take 128 MB to 10,240 MB of memory; both are ceilings, and the timeout cannot be increased
Lambda synchronous payloads are capped at 6 MB each way and asynchronous ones at 1 MB, so large data travels as an S3 reference
A NAT gateway supports 55,000 simultaneous connections per destination per IPv4 address, and each additional IP adds another 55,000
API Gateway defaults to 10,000 requests per second while Lambda defaults to 1,000 concurrent executions — a mismatch worth resolving deliberately
A subnet's usable addresses bound how many ENIs, tasks and pods can exist in it, which is a planning decision made once and hard to change
Database connections are bounded by instance class, and every process and every Lambda execution environment holds its own

The limits that shape designs, and what each one forces

The limits that shape designs, and what each one forces
Limit	Value	What it forces
Lambda timeout	900 seconds (15 minutes), not adjustable	Long jobs go to ECS, Batch or Step Functions — not a bigger function
Lambda payload	6 MB synchronous each way, 1 MB asynchronous	Pass an S3 key, never the object
Lambda concurrency	1,000 per Region by default, adjustable	A queue between the front door and the function, or a matching increase
API Gateway throughput	10,000 rps by default, adjustable	Check it against downstream concurrency — the two defaults do not match
NAT connections	55,000 per destination per IP address	Connection reuse, extra IPs, or a VPC endpoint that avoids NAT entirely
Subnet addresses	Fixed by the CIDR you chose at creation	Size subnets for the fleet you will have, not the one you start with
Database connections	Bounded by instance class	A bounded pool, and RDS Proxy when many short-lived processes connect
SQS message size	256 KB per message	Large payloads by reference — the message points at S3
S3 object size	5 TB maximum object, 5 GB maximum single PUT	Multipart upload above 5 GB — a client feature, not a request

Raise it, or design around it

Adjustable — file a request

Lambda concurrency, API Gateway throughput, Elastic IPs, NAT gateways per AZ, VPCs per Region. Plan weeks ahead, not hours.

Fixed — a design input

Lambda 15-minute timeout, 6 MB synchronous payload, SQS 256 KB message. No request moves these; the architecture accommodates them.

Structural — chosen once, changed painfully

Subnet CIDR sizing, partition key design, Region selection. Technically changeable, practically a migration.

Derived — a consequence of your own choices

Connections per database = pool size × processes. Nobody grants this; you compute it and stay under it.

Signature

Lambda 900 s / 6 MB · NAT 55,000 per destination per IP · API GW 10,000 rps vs Lambda 1,000 concurrent · SQS 256 KB

Sort every limit into adjustable, fixed, structural, or derived. Adjustable ones are a request filed early; fixed ones such as the 15-minute Lambda timeout and the 6 MB payload write the architecture for you; structural ones like subnet sizing are chosen once; and derived ones like total database connections are yours to compute and stay under.