AWS Service Quotas Explained: Check Limits, Increase Quotas, Avoid Errors

Simple explanation

Every AWS service has built-in caps on how much you can use. These caps are called service quotas. Some limit how many resources you can create (like the number of VPCs in a Region). Others limit how fast you can call an API (like requests per second to EC2).

You will also see the term service limits in older AWS documentation, blog posts, and error messages. “Service limits” and “service quotas” mean the same thing. AWS renamed them to “service quotas” in 2019 when it launched the Service Quotas console, but the older term is still widely used.

How AWS service quotas work

Default quota vs applied quota

The default quota is the starting value AWS assigns when you create an account. The applied quota is the actual limit currently in effect for your account. If you have never requested an increase, these two values are the same. After an approved increase, the applied quota is higher than the default.

Adjustable vs non-adjustable quotas

Adjustable quotas (sometimes called soft limits) can be increased by submitting a request. Most quotas you encounter in practice are adjustable. Non-adjustable quotas (hard limits) are fixed and cannot be changed regardless of business justification. The Service Quotas console marks each quota clearly.

Account-level, Region-level, and resource-level quotas

Most quotas are scoped per account per Region. For example, the VPC quota applies independently in each Region. Reaching the limit in us-east-1 does not affect eu-west-1. A few quotas are global (per account regardless of Region), such as IAM roles or S3 general-purpose buckets. Some quotas apply at the resource level, like the number of tags per resource or the maximum size of an IAM policy.

Resource counts vs request-rate limits

Resource quotas cap how many of something you can have at once (VPCs, EC2 vCPUs, Lambda functions). Rate quotas cap how many API calls you can make per second (DescribeInstances calls, GetRole requests). Both types appear in the Service Quotas console, but they cause different kinds of failures and require different responses.

How to check your current quotas

Using the console

The fastest way to browse your quotas:

1. Open the Service Quotas console.
2. Select AWS services in the left navigation.
3. Search for or select the service you want to inspect (for example, Amazon EC2).
4. Browse the list of quotas. Each entry shows the quota name, applied value, default value, and whether it is adjustable.

Using the CLI

The AWS CLI is better for scripting and quick lookups. You can also use AWS CloudShell if you do not have the CLI installed locally. The commands below walk through a logical discovery flow: start broad, then narrow down to the specific quota you need.

# Step 1: List services available in Service Quotas
aws service-quotas list-services \
  --query 'Services[*].{Code:ServiceCode,Name:ServiceName}' \
  --output table

# Step 2: List all quotas for a specific service (e.g., EC2)
aws service-quotas list-service-quotas \
  --service-code ec2 \
  --query 'Quotas[*].{Name:QuotaName,Code:QuotaCode,Value:Value,Adjustable:Adjustable}' \
  --output table

# Step 3: Filter to find a specific quota by name
# This example searches for On-Demand vCPU quotas
aws service-quotas list-service-quotas \
  --service-code ec2 \
  --query "Quotas[?contains(QuotaName,'On-Demand')].{Name:QuotaName,Code:QuotaCode,Value:Value}" \
  --output table

# Step 4: Get full details for a specific quota using its code
# Use the QuotaCode value from Step 3
aws service-quotas get-service-quota \
  --service-code ec2 \
  --quota-code L-1216C47A

Lambda concurrency quotas

Lambda has a concurrency model worth understanding separately. The account-level concurrency quota caps the total number of Lambda function instances running simultaneously across all functions in a Region. For a deeper look at how Lambda scales under load, see the Lambda Scaling Behaviour guide.

• Account concurrency: total simultaneous executions across all functions in a Region. The default varies. Established accounts typically have 1,000, but newer accounts may start lower.
• Reserved concurrency: a portion of the account limit you reserve for a specific function. Guarantees capacity for that function but also caps it.
• Provisioned concurrency: pre-warmed execution environments that eliminate cold starts. Has its own quota separate from the account concurrency limit.

# Check your Lambda concurrency limits
aws lambda get-account-settings \
  --query '{TotalConcurrency:AccountLimit.ConcurrentExecutions,UnreservedConcurrency:AccountLimit.UnreservedConcurrentExecutions}'

How quota increases work

Most quotas are adjustable. You request an increase through the Service Quotas console or CLI. What happens next depends on the size of the request.

• Small, routine increases are often approved automatically within minutes. AWS has automated approval for common quotas within certain thresholds.
• Larger increases go through a manual review. AWS may ask for business justification. Approval typically takes one to several business days.
• Urgent requests do not get priority treatment. There is no “rush” option. If you need higher quotas for a launch, request them at least one to two weeks in advance.

# Request an increase (example: increase EC2 On-Demand Standard vCPUs)
# Use the quota code you discovered with list-service-quotas
aws service-quotas request-service-quota-increase \
  --service-code ec2 \
  --quota-code L-1216C47A \
  --desired-value 128

# Check the status of pending requests for a service
aws service-quotas list-requested-service-quota-changes-by-service \
  --service-code ec2 \
  --query 'RequestedQuotas[*].{Quota:QuotaName,Requested:DesiredValue,Status:Status}' \
  --output table

Monitoring quota usage

The Service Quotas service integrates with Amazon CloudWatch. For supported services, AWS publishes usage metrics in the AWS/Usage namespace. You can create alarms that fire when usage approaches your applied quota.

Setting up a quota usage alarm

The easiest path is through the Service Quotas console: find the quota, click Create CloudWatch alarm, and set a percentage threshold. To do the same thing from the CLI:

# Create a CloudWatch alarm when EC2 On-Demand vCPU usage reaches a threshold.
# Replace the --threshold value with ~80% of your applied quota.
# Replace the SNS ARN with your own notification topic.
aws cloudwatch put-metric-alarm \
  --alarm-name ec2-vcpu-quota-warning \
  --alarm-description "EC2 On-Demand vCPU usage approaching quota" \
  --namespace AWS/Usage \
  --metric-name ResourceCount \
  --dimensions \
    Name=Service,Value=EC2 \
    Name=Resource,Value=vCPU \
    Name=Type,Value=Resource \
    Name=Class,Value=Standard/OnDemand \
  --statistic Maximum \
  --period 300 \
  --evaluation-periods 1 \
  --threshold 80 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:quota-alerts

When to use this

Check and plan around service quotas in these situations:

• Before a production launch. Review quotas for every service your application depends on. A quota-related failure during launch is entirely preventable.
• Before scaling EC2, Lambda, or EKS. Scaling plans often exceed default vCPU, concurrency, or node group quotas. Check limits before you auto-scale into a wall.
• When creating multiple environments, accounts, or VPCs. Dev, staging, and production environments in the same Region share the same quotas. The default of 5 VPCs per Region fills up quickly in multi-environment setups.
• When automation starts failing with throttling or limit errors. If Terraform, CDK, or a CI/CD pipeline fails with LimitExceededException or ThrottlingException, a quota or rate limit is the likely cause.
• Before load testing or migration. Load tests can push usage past quota limits rapidly. Request increases before the test, not during it.
• When enabling a new service or expanding to a new Region. New Regions start at default quotas even if you have higher applied quotas elsewhere.

AWS service quotas vs throttling vs billing controls

These three concepts are related but solve different problems. Confusing them leads to the wrong fix.

Service quotas and API throttling are both enforced by AWS and will block actions when exceeded. Billing controls (AWS Budgets) are informational only. They alert you but do not prevent resource creation or stop running services. You need all three working together: quotas to prevent accidental over-provisioning, throttling retries to handle API rate limits gracefully, and billing alerts to catch cost surprises.