Right, let’s talk about the one thing that will absolutely, positively stop your cloud party faster than a bill from a five-day crypto-mining bender: service quotas. You used to call them “limits,” which was a much more honest and slightly threatening term. AWS softened it to “quota,” probably after a marketing intern had a panic attack. Don’t be fooled. It’s a limit. It’s the bouncer at the club saying, “Nope, not tonight.”

These aren’t just arbitrary numbers AWS pulls from a hat to ruin your deployment script at 2 AM. They exist for two brutally practical reasons: to protect you from yourself (because yes, a bug in your code could try to spin up 10,000 c6g.16xlarge instances and you’d prefer not to sell a kidney to pay for it), and to protect AWS’s multi-tenant infrastructure from any one customer accidentally launching a Denial-of-Wallet attack on an entire region.

The Two Flavors of Quota: Soft and Hard

First, you need to know you’re dealing with two different beasts. Most quotas are soft. These are the ones you can beg, borrow, and plead to have increased. Think things like the number of running EC2 instances, the amount of EBS storage in a region, or how many VPCs you can create. Then there are hard quotas. These are immutable, carved into the stone tablets that Jeff Bezos brought down from Mount Rainier. You cannot change these. Ever. They’re usually fundamental limits of the service itself, like the maximum size of an S3 object (5 TB) or the maximum time an AWS Lambda function can run (15 minutes). Arguing with a hard limit is like arguing with the tide; you will lose, and you’ll look silly trying.

How to Actually Find Your Darn Quotas

The old Service Limits console was a masterclass in frustration. The new Service Quotas console is… better. It’s actually usable. You can search for a service, see your applied quotas, and request increases. But the real power users live in the CLI.

Let’s say you’re about to deploy a new microservice and you want to make sure you’re not going to faceplant because you can only have 250 security groups per region. Don’t guess. Check.

# List all quotas for the EC2 service in your current region
aws service-quotas list-service-quotas --service-code ec2

# But that's a firehose. Let's get specific.
# First, find the exact quota code for the thing you care about.
aws service-quotas list-aws-default-service-quotas --service-code ec2 | grep -A 5 -B 5 "Security Groups"

# Now request a specific quota increase. You'll need the quota code, service code, and the desired value.
aws service-quotas request-service-quota-increase \
    --service-code ec2 \
    --quota-code L-0EA8095F \
    --desired-value 500

This is infinitely better than fumbling around in the web console. Pro tip: script this. Make it part of your infrastructure-as-code pipeline or your pre-flight checklist for a new environment.

The Art of the Quota Increase Request

Here’s where you need a strategy. AWS support engineers are humans (mostly), and they’re reviewing thousands of these requests a day. A bad request gets denied or ignored. A good one gets approved, often automatically.

What not to do: The form has a text box. Do not just write “I need more.” That’s a fantastic way to get a polite, automated denial. You’re not ordering a coffee; you’re justifying a need for more resources in a multi-billion dollar infrastructure.

What to do: Be specific, professional, and provide a business rationale. They want to know you’re not just hoarding resources.

  • Explain the use case: “We are launching a new production workload that will utilize Auto Scaling groups spanning three Availability Zones, each with a minimum of 20 instances. Our current limit of 20 instances per region is insufficient for this architecture.”
  • Mention your architecture: “We use separate security groups per application tier for strict network segmentation, and our current limit of 250 is constraining new development.”
  • State your deployment timeline: “We are requesting this increase to complete our deployment by YYYY-MM-DD.”

I’m not joking. Write a little paragraph. It matters. For critical, high-value limits, you might even open a support ticket before making the request to chat with them. It works.

Common Pitfalls and How to Avoid Them

The biggest pitfall is assuming quotas are global. They are almost always regional. Increasing your EC2 instance limit in us-east-1 does precisely nothing for you in eu-west-1. You must request increases in every single region where you plan to operate. This catches everyone out. Everyone.

Another classic: forgetting about the root account. Some quotas, like the number of IAM roles you can create, are account-wide. But many are scoped to the region. Always, always check the region you’re in when you make the request.

Finally, plan ahead. Quota increase requests can take from a few minutes (if it’s automated) to a full business day or two (if it needs a human to review it). You do not want to be waiting on this while your CI/CD pipeline is burning red and your project manager is breathing down your neck. Make quota management a first-class citizen in your infrastructure planning. Trust me, your future self, who is not having a panic attack at 2 AM, will thank you.