AWS Service Quotas: Finding and Requesting Limits
I recently worked through AWS Service Quotas and found a few things that weren't obvious at first. Here's how I check quotas, identify adjustable limits, and request increases.
I recently started checking AWS Service Quotas before creating resources, and I realized that finding and increasing a quota is not always as straightforward as it looks.
Here is the process I use now.
Start with Service Quotas
When I want to check a limit for an AWS service, I open AWS Service Quotas and search for the service. For example, if I am working with ECS, I search for Amazon Elastic Container Service and look through the available quotas.
Each quota normally shows information such as:
- The quota name
- Applied quota value
- AWS default value
- Whether the quota is adjustable
The important part is the Applied quota value. This is the value currently applicable to my account.
Not every quota can be increased
One thing I noticed is that some quotas are adjustable while others are not.
If a quota is adjustable, I can select it and choose "Request increase at account level".
If it is not adjustable, there is no quota increase request option. In that case, I don't try to force an increase—I first check whether the limit actually affects what I am trying to build.
This distinction is useful because I initially expected every limit to have a simple "increase" option.
What if the quota I need isn't listed?
If I cannot find a particular resource limit in Service Quotas, I don't immediately assume that there is no limit. Service Quotas only shows quotas that AWS exposes through the service.
So my approach is:
- Search for the AWS service.
- Look through the available quotas.
- Check whether the resource or limit I care about is actually listed.
- If it is listed and adjustable, request an increase if necessary.
- If it is listed but not adjustable, I leave it alone unless I have a specific problem.
- If it isn't listed, I investigate that particular service/resource separately instead of submitting a random quota request.
This helped me avoid treating every AWS limit as if it were the same type of quota.
Requesting a quota increase
When I find an adjustable quota that I actually need to increase, the process is fairly simple. I select the quota and choose "Request increase at account level". I then enter the value I need and submit the request. After submitting it, I can check Request history to see the status of the request.
I would recommend requesting a realistic value rather than simply choosing a very large number. There is no benefit in increasing a quota that I am unlikely to use.
An unexpected limitation: pending requests
While checking quotas, I also ran into a message that I wasn't expecting: "Quota increase request limit reached"
The message explained that I had to wait until one of my pending quota requests was closed before creating another request. This is something worth knowing before submitting increases for every quota that looks useful.
I now treat quota requests as something to prioritize rather than something to submit immediately.
What does a quota value of 0 mean?
I also came across quotas with an applied value of 0. A value of 0 caught my attention because it can look like the service is completely unavailable.
But the important question is whether that quota is adjustable?
If it is adjustable, I can request an increase. If it isn't adjustable, I need to understand what that particular quota represents and whether it actually affects my use case.
So I don't treat 0 by itself as a reason to panic or immediately switch services.
My approach now
After going through this process, I use a simple rule: Check first. Request only when necessary.
I don't increase every adjustable quota just because AWS gives me the option.
For each service, I first ask:
- Is this quota relevant to what I'm building?
- What is the current applied value?
- Is it adjustable?
- Do I actually expect to hit the limit?
- Is there already a pending quota request?
This makes the preparation process much more manageable. AWS has a lot of services and each service can have many quotas. It is easy to spend time requesting increases that will never be needed.
For me, checking the quotas first has become a small but useful part of preparing an AWS environment—especially before starting anything that will create resources or scale across multiple services.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article