Three different problems
| Problem | Example | Fix |
|---|---|---|
| Adjustable quota | Running On-Demand Standard instances (vCPU), Elastic IPs, Lambda concurrency | Request an increase |
| Fixed limit | Some API payload sizes, per-resource limits | Design around it |
| Capacity | InsufficientInstanceCapacity for a type in an AZ | More instance types/AZs, capacity reservations |
1. Inventory dependencies
For each platform or big event (migration wave, launch, DR failover), list the quotas you'll consume:
| Area | Examples |
|---|---|
| EC2 | On-Demand vCPU per instance family group, Spot vCPU, EIPs, EBS storage per volume type |
| Networking | VPCs per region, interface endpoints per VPC, NAT gateways per AZ, TGW attachments, routes per table |
| Containers | EKS clusters, nodes per managed node group, Fargate concurrent tasks |
| Serverless | Lambda concurrent executions, API Gateway throttles, Step Functions state transitions |
| Data | RDS instances, DB storage, DynamoDB table/account throughput limits |
| AI/ML | Bedrock tokens/requests per minute per model, SageMaker instance quotas |
2. See current values and usage
aws service-quotas list-service-quotas --service-code ec2 \
--query 'Quotas[?contains(QuotaName, `On-Demand`)].[QuotaName,QuotaCode,Value]' --output table
aws service-quotas get-service-quota --service-code lambda --quota-code L-B99A9384
Many quotas publish CloudWatch usage metrics (AWS/Usage namespace). Create alarms at ~80% of quota, either in the Service Quotas console or with CloudWatch using SERVICE_QUOTA() metric math. Trusted Advisor's service limits checks complement this.
3. Request ahead of need
aws service-quotas request-service-quota-increase --service-code ec2 --quota-code L-1216C47A --desired-value 512
aws service-quotas list-requested-service-quota-change-history --service-code ec2 --output table
- Include peak + DR failover headroom in both primary and DR regions.
- Quota request templates (Organizations) automatically request increases for new accounts created in the org, which suits account vending.
- Large increases can take time and may need a business justification. Don't leave them to go-live week.
4. Capacity, not quota
When you see InsufficientInstanceCapacity:
- Allow more instance types (ASG mixed instances, Karpenter flexibility) and all AZs.
- On-Demand Capacity Reservations for critical workloads and DR failover targets (billed whether used or not; Savings Plans/RIs can apply).
- Capacity Blocks for ML to reserve GPU instances for a defined future period.
- Consider regions with better availability of scarce types.
5. Design around fixed limits
| Pressure | Design response |
|---|---|
| Account-level limits per workload | Account per workload/environment (account vending) |
| Lambda account concurrency shared by all functions | Reserved concurrency for critical functions; separate accounts for noisy workloads |
| API throttling on control-plane calls | Backoff and caching; avoid polling Describe APIs in loops |
| VPC route table and SG rule limits | Prefix lists, TGW route summarisation |
6. Make it a gate
Design reviews and go-live checklists include: quotas listed, usage alarms in place, increases approved in primary and DR regions, capacity strategy for scarce types. Keep the evidence (command output, case IDs).
Warning
DR plans often assume the DR region has the same quotas as production. New or rarely used regions start with defaults. Request DR quotas when you build the DR environment, not during the disaster.
Checklist
- Quota, fixed limit and capacity dependencies listed
- Usage alarms at ~80%
- Increases requested for primary and DR, with headroom
- Quota request templates for new accounts
- Capacity reservations / ML capacity blocks where justified
- Gate in design reviews and go-lives