Request AWS Service Quota Increases (2026)

Requesting AWS Service Quota Increases

You can’t provision more resources than your account is allowed to.

Let’s say you’re trying to launch an EC2 instance and get an error like InstanceLimitExceeded. Or you’re trying to create a new RDS instance and see DBInstanceLimitExceeded. These errors mean you’ve hit a limit on the number of resources you can have in a specific AWS region for your account. These limits are called "service quotas." They’re in place to prevent accidental overspending and to ensure fair usage across all AWS customers.

To see your current quotas, you’ll use the AWS Service Quotas console.

Finding Your Quotas

Navigate to the Service Quotas Console: In the AWS Management Console, search for "Service Quotas" and click on it.
Select a Service: On the left-hand navigation pane, you’ll see a list of AWS services. Click on the service you’re interested in, for example, "Amazon Elastic Compute Cloud (Amazon EC2)".
View Quotas: On the right-hand side, you’ll see a list of quotas for that service. You can filter these by name or value. Look for the specific quota that’s causing your issue (e.g., "Running On-Demand instances"). You’ll see your "Applied quota value" and your "Current usage."

Requesting an Increase

If your current usage is close to or has exceeded the applied quota value, you’ll need to request an increase.

Select the Quota: In the Service Quotas console, find the specific quota you need to increase.
Request Quota Increase: Click the "Request quota increase" button.
Enter New Value: A form will pop up. Enter the "New quota value" you require. Be realistic; requesting an astronomical number might raise flags. It’s often better to request a moderate increase and then request more later if needed.
Submit Request: Click "Submit request."

Your request will go to AWS support. They usually review and process these requests within 24 hours, though it can sometimes take longer for certain quotas or if more information is needed. You’ll receive an email notification when the request is approved or denied.

Common Quotas and Why You Might Hit Them

EC2 Instances: You might hit limits on the number of running On-Demand instances, Spot instances, or specific instance types (like m5.large or c5.xlarge). This is common when scaling up applications or during development/testing phases where you spin up many machines.
EBS Volumes: The total number of EBS volumes you can have attached to instances or provisioned in a region. This limit is often hit when deploying applications that require many separate storage volumes per instance.
RDS Instances: The number of database instances you can run. This limit is typically reached when you’re running multiple database environments for development, staging, and production, or when you have many microservices each with its own database.
VPC IP Addresses: The number of available IP addresses within a VPC (specifically, the number of primary private IPv4 addresses per network interface). This can be an issue in large, complex VPCs with many subnets and instances, especially if you’re using smaller CIDR blocks.
Load Balancers: The number of Application Load Balancers (ALBs) or Network Load Balancers (NLBs) you can provision. This limit is often hit when you have a distributed architecture with multiple services, each requiring its own load balancer.
S3 Buckets: While the number of S3 buckets is very high (3,000 per account per region by default), you might hit this if you’re using a "bucket-per-application" or "bucket-per-tenant" strategy at a massive scale.

What Happens After a Request

Once your request is approved, the "Applied quota value" in the Service Quotas console will update. You can then provision resources up to this new limit. If your request is denied, the console will usually provide a reason, and you can try resubmitting with a more appropriate value or by addressing the stated concerns.

It’s a good practice to monitor your usage against your quotas regularly, especially for services that are core to your application’s scaling. Proactive requests can prevent unexpected downtime or deployment blockers.

The next hurdle you’ll likely encounter is understanding how AWS applies these quotas at a global vs. regional level, and how some quotas are shared across services.