Fix AWS EC2 "Instance Limit / vCPU Quota Exceeded" Error

The error means the vCPUs (virtual processor slices) you just asked for, added to the vCPUs already running in that Region, would go past a quota AWS set on your account. Fix it in the Service Quotas console: pick the same Region, filter for On-Demand, open the quota for your instance family (usually Standard), and request a higher value. The surprise: you can hit this with nothing running, because quotas count vCPUs, not servers, and a documented default of 5 can't hold even one 8-vCPU m5.2xlarge.

Jake found this out the expensive way. He had promised a customer a demo of a small repair-tracking app for his phone shop, started a server that morning, and the launch failed on the very first click. By the time he found the right screen it was Saturday evening, the customer had wandered off, and the afternoon was gone. Nothing was broken. AWS was doing exactly what it is built to do. Ethan's first words on the phone were: "Relax. You don't have a broken server. You don't have a server at all yet. You have a ceiling, and you just bumped your head on it."

This walkthrough goes in the order you should actually try things. First, work out which message you have. Then confirm which quota bucket it belongs to, free up or shrink whatever you can for nothing, and only then ask AWS for a bigger quota, in the console or with the AWS CLI (the command-line tool). After that come the awkward cases: a request that sits there, a denial, Spot Instances, GPU families that start at zero, and errors that look like quota problems but aren't. Every setting name and command below comes from AWS's own documentation, not from hands-on testing, and where the documentation says nothing, the post says so.

Which error are you actually looking at?

AWS words this problem in several ways, depending on whether you launched from the console, ran a command, or watched another AWS service launch instances for you. The wording tells you which bucket of quotas to open, so match your message to a row before you touch any setting.

Read the number in the message before anything else. In a VcpuLimitExceeded message, "your current vCPU limit of N" is the ceiling for that instance family. A 0 means the family is off for you until you request it; AWS's documentation lists a default of 0 for every On-Demand family except Standard. A small number, like 5, means the family is on but the ceiling is low. Those two situations feel identical when the launch fails, and they are handled the same way, but the second one is easier to spot in advance.

"Instance bucket" in that message is just AWS's phrase for the quota group your instance type belongs to. An m5 and a t3 share one bucket. A g5 lives in a different one. We'll map the buckets in the next section.

One more thing about that message: it may still point you to an old contact form. The current EC2 documentation sends you to the Service Quotas console instead, and that's the route this post uses.

Jake didn't love that. "So the error tells me to fill in a form, and you're telling me to ignore it?"

Ethan: "I'm telling you the front door moved. Same building. Read the number first, the Region second, and only then open a console tab. The message is a receipt, not a verdict."

Why AWS counts vCPUs instead of instances

When you create an AWS account, AWS sets default quotas on your resources, and it also calls them limits. They are set per Region, and a Region is one of the separate AWS locations you choose from the selector in the console's top bar. If a request would push you over a quota, the request fails. That's the entire mechanism, and AWS's EC2 documentation describes it in almost those words.

Here is the twist. For On-Demand Instances, the normal pay-by-the-second kind (the documentation says you pay only for seconds in the running state, with a 60-second minimum), the quota isn't counted in servers. It's counted in vCPUs. A vCPU, short for virtual central processing unit, is one slice of processor power assigned to your instance. Bigger instance types get more of them. AWS's own examples: an m5.2xlarge uses 8 vCPUs and a c5.4xlarge uses 16.

Think of a small restaurant with five chairs. It doesn't count parties; it counts chairs. A party of eight can't be seated even when the place is empty. Your account is that restaurant, with five chairs in the Standard bucket, and an m5.2xlarge is a party of eight. Nobody is sitting there, and the host still says no.

Ethan's take: "People hear 'instance limit' and count servers on their fingers. Count chairs instead. Total vCPUs is the only number the system does arithmetic on."

And there isn't one giant quota either. AWS keeps one quota per group of instance families, and the letters at the start of the instance type decide the group. An m5.2xlarge starts with m, so it counts against Standard. A g4dn.xlarge starts with g, so it counts against G and VT. AWS's documentation lists these On-Demand quotas, with the defaults it publishes:

Two things about that table. First, all ten are marked adjustable, which means AWS lets you ask for more. Second, the "default" is what AWS starts you with, not necessarily what you have today. AWS says EC2 automatically increases your On-Demand quotas based on your usage, and you can also request an increase yourself. The number that governs your launches right now is the Applied quota value in the Service Quotas console. Numbers you'll see quoted in older posts and forum threads vary, and none of them matter as much as that one column on your own account.

What counts against the quota? Only instances in the running path. AWS states that instances in the pending, stopping, stopped, and hibernated states do not count. There is one sneaky exception: Capacity Reservations count toward your On-Demand quotas even when they're unused. A Capacity Reservation is a hold you place so AWS keeps compute available for you, and it takes chairs whether or not anyone sits in them.

Step zero: see what you're using and what you're allowed

Don't request anything yet. Two minutes of looking saves you from asking for the wrong quota, in the wrong Region, for the wrong number, which is the most common way a quota request goes nowhere.

1. Note the Region. Look at the Region in your error, your command, or the console's top bar at the moment the launch failed. Quotas are per Region, so this decides everything that follows.
2. Open Service Quotas. Search "Service Quotas" in the console search bar. AWS's documentation points to the EC2 page under console.aws.amazon.com/servicequotas/home/services/ec2/quotas/. Make sure the Region selector still shows the Region from step 1.
3. Filter. If you arrive through the service list, choose AWS services, then Amazon Elastic Compute Cloud (Amazon EC2), then View quotas. In the filter field, type On-Demand.
4. Read the Applied quota value column. AWS documents this as the maximum number of vCPUs for each On-Demand quota type on your account. Find the row that matches your instance family. This is your ceiling.
5. Find your instance type's vCPU count. In the EC2 console, choose Instance types in the navigation pane and read the vCPUs column. For a quick sanity check, remember AWS's examples: m5.2xlarge is 8, c5.4xlarge is 16, g4dn.xlarge is 4.
6. Add up what is already running in that bucket. Count the vCPUs of every running instance in the same family group, in that Region. AWS's Trusted Advisor console also has a Service limits page that shows quota information, and the Service Quotas console can show utilization beneath the quota description for quotas that support alarms.
7. Do the comparison. If running vCPUs plus the new instance's vCPUs is larger than the Applied quota value, you've found your error.

If your instance would fit, meaning the arithmetic says you're under the ceiling, stop and reread the error. It may be one of the look-alikes covered later in this post, or it may be a Spot request, which is counted separately.

Ethan: "Check the Region first. Seriously. Half the people who write in have a lovely, freshly approved quota sitting in a Region they never launch in."

The cheapest fixes: free up vCPUs or shrink the request

Asking AWS for more room is free, but it isn't instant. If you need something running now, these fixes cost nothing and don't wait on anyone. They're listed from gentlest to most drastic.

1. Pick a smaller instance type. Because the quota counts vCPUs, one step down in size can be the difference between launching and not. With a Standard ceiling of 5 vCPUs, a 2-vCPU size fits twice and an 8-vCPU size doesn't fit at all. AWS's launch troubleshooting notes that instance types can be changed later, so starting smaller doesn't lock you in.

2. Launch fewer instances at once. If you asked for four and the arithmetic only allows three, ask for three. It sounds obvious, but a launch template or script with a "count" field is easy to forget about.

3. Stop instances you aren't using. A stopped instance doesn't count toward On-Demand quotas, and neither do instances in the stopping or hibernated states. Read the box below before you lean on this one.

4. Terminate instances that are truly finished. Terminating is permanent. Depending on how the instance was set up, attached volumes can be deleted with it, so confirm nothing in there is unsaved before you press the button. It's the most drastic of the free options, which is why it's the last of the instance-level fixes.

5. Cancel leftover Spot requests if the error is about Spot. Open requests count against the Spot quota, as covered below.

6. Release Capacity Reservations you don't need. Since unused reservations still count toward the On-Demand quota, an old reservation can quietly eat chairs. If you booked compute ahead of a project that never started, look here.

7. Launch in another Region. Quotas are per Region, so a different Region may have room you haven't used. Treat this as a genuine trade-off, though. Where your instance runs decides where its data lives and how far it sits from your users, so don't hop Regions casually just to dodge a ceiling.

Jake tried to be clever here. "Can't I just make five small instances instead of one big one?" Ethan shook his head: "Same chairs. Five 1-vCPU seats or one 5-vCPU seat, the restaurant counts chairs, not tables." The only thing that beats the ceiling is a smaller total or a higher ceiling.

How many vCPUs to ask for (the arithmetic nobody shows you)

The request form asks for a "new value" (the Service Quotas guide calls the field Increase quota value, and the EC2 guide calls it Change quota value). That value is the new total ceiling, not the extra amount you want. AWS states that the new value must be greater than the current value. So if you're allowed 5 and want room for 8 more, you enter 13, not 8.

AWS's own guidance on sizing is short: add the vCPUs you use, plus the vCPUs you plan to use, plus a buffer of 10-30%. It also points out that all the Standard families (A, C, D, H, I, M, R, T, Z) share one quota, so you count usage across all of them together. Here is how that plays out:

A small note on that fourth row. AWS's own article that walks through this exact example says to request "at least 178." The addition comes to 176. Either works, because you're going to add a buffer anyway, but if you're checking the sum against AWS's page and it doesn't match, that's why.

There's one more trick in AWS's guidance that saves people from filing the same request twice. You can switch between instance types within one quota category without a new request, as long as you stay below the applied quota. If you're experimenting with different sizes, request enough for the largest single thing you plan to run, not the sum of all your experiments. And in the request's use case description, name the instance types and say whether you'll run them in parallel or one at a time. AWS specifically recommends that for a test-across-types scenario.

Ethan: "Don't ask for 1,000 vCPUs because you got excited. Ask for what the project needs, add a cushion, and come back when the project grows. A quota is a conversation, not a lottery ticket."

Request the increase in the console, step by step

This is the main event. You've done the arithmetic, so the request itself takes a couple of minutes. One thing to know about labels: AWS's EC2 guide says Request quota increase, while the Service Quotas guide says Request increase at account-level. They describe the same action from different pages, so if your screen shows one and this post says the other, you're in the right place.

1. Sign in to the AWS Management Console and open the Service Quotas console.
2. Select the Region from the navigation bar at the top of the screen. Set it to the Region where your launch failed, not your favorite Region.
3. In the navigation pane, choose AWS services, then choose Amazon Elastic Compute Cloud (Amazon EC2) and View quotas.
4. In the filter field, type On-Demand to narrow the list to the running On-Demand quotas.
5. Choose the quota that matches your instance family, such as Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances. If the quota is adjustable (all of the On-Demand vCPU quotas are), the request button is available.
6. Choose Request quota increase (or Request increase at account-level, depending on the screen).
7. For the new value field, enter the new total from your arithmetic. It must be higher than the current Applied quota value.
8. Choose Request.
9. To watch it, choose Dashboard in the navigation pane, or open the service's Request history tab. Choose the status to open the request receipt.

The initial status is Pending. After it changes to Quota requested, you'll see a case number with Support, and choosing that number opens the ticket. When the request is resolved in your favor, the Applied quota value for that quota is set to the new number. Then, and only then, retry your launch.

A few practical details that trip people up.

You must repeat it per Region. AWS is direct about this: EC2 quotas apply to one Region, and you need a separate request for each Region that needs more. Approved in one Region tells you nothing about the next.

Account-level versus resource-level. The Service Quotas console offers two request styles. Account-level applies to quotas that cover the whole account, and the vCPU quotas here are the kind you'll request that way. Resource-level exists for quotas tied to a specific resource, and AWS's example is the instances-per-domain quota in OpenSearch Service. For EC2 vCPUs, you won't need to think about it.

Permissions can block you. If the console refuses the request with an access message, your IAM identity (the user or role you signed in as) may lack Service Quotas permissions. AWS documents that requesting through the CLI needs you to allow Service Quotas to create a support case on your behalf, either by attaching the AWS managed policy ServiceQuotasFullAccess or by adding iam:CreateServiceLinkedRole to your policy. If you're not the account owner, this is a message to your administrator, not something to work around.

The Support Center route also exists. AWS's documentation for some EC2-related quotas, like EC2 Fleet target capacity and EBS volume limits, describes opening a case from the Support Center Create case form, choosing Service limit increase, picking the Region, entering the new limit value, and adding a use case description. For the On-Demand vCPU quotas, AWS's EC2 guide points you at the Service Quotas console, so that's the route to prefer.

The AWS CLI route (for scripts and impatient people)

The AWS CLI is a text tool: instead of clicking through the console, you type commands into a terminal. It's handy when you manage several Regions, several accounts, or when you'd rather have a repeatable record of what you asked for. Everything below uses the service-quotas commands AWS documents.

First, the permission point again. AWS says CLI requests need Service Quotas to be able to open a support case for you, which you grant with the ServiceQuotasFullAccess managed policy or by adding iam:CreateServiceLinkedRole to your existing policy.

Every quota has a quota code, and the request needs it. Good news: AWS's On-Demand documentation links each quota by its code, so you already saw them in the table above. The one most people need is L-1216C47A for Standard. To list your EC2 quotas and see the codes and current values for yourself:

aws service-quotas list-service-quotas \
    --service-code ec2 \
    --region us-east-1

The output is long, since it lists every EC2 quota. Look for the entry whose name starts with "Running On-Demand" and read its QuotaCode and Value. Then submit the request with the operation AWS calls RequestServiceQuotaIncrease:

aws service-quotas request-service-quota-increase \
    --service-code ec2 \
    --quota-code L-1216C47A \
    --desired-value 64 \
    --region us-east-1

Replace 64 with your own number from the arithmetic section, and replace the Region with yours. If the command succeeds, the response includes a Status field, which will show PENDING at first. To check on it afterward, AWS documents three operations: GetRequestedServiceQuotaChange, ListRequestedServiceQuotaChangeHistory, and ListRequestedServiceQuotaChangeHistoryByQuota. In the CLI, the middle one looks like this:

aws service-quotas list-requested-service-quota-change-history \
    --quota-applied-at-level ALL \
    --region us-east-1

Same as the console, the CLI request ends up as a Support case for larger increases. A success message from the command means the request was accepted for processing, not that the quota has changed. The quota changes when the Applied quota value shows the new number.

Ethan: "Use the console for your first request so you can see what the form is asking. Use the CLI when you have three Regions to do and a short attention span."

What the status words mean (and how long to wait)

You'll see a handful of statuses in the console and in CLI output. They're plainer than they look, and reading them correctly stops you from panicking on a Pending request or celebrating a Case closed too early.

In the CLI, the same statuses come back as uppercase words such as PENDING, CASE_OPENED, APPROVED, DENIED, and CASE_CLOSED. The console keeps open requests and requests closed in the last year in its history.

How long does it take? Here's the honest answer: AWS's documentation doesn't publish a turnaround time, so any number you see elsewhere is a guess. What the Service Quotas guide does say is that smaller increases are usually approved automatically, that larger requests are submitted to Support and take time to review, process, approve, and deploy, and that quota increase requests don't receive priority support. If you have something urgent, or your request is denied, AWS says to contact Support.

Practically, that means don't schedule a customer demo for an hour after you click Request. It's like a parcel courier: you can refresh the tracking page as often as you like and it won't arrive faster. File early, and meanwhile use a smaller instance or another Region so the work isn't stuck waiting on the answer.

Spot Instances have their own quota (and it counts requests, not just instances)

A Spot Instance is AWS's spare capacity sold at a discount. The trade-off is that AWS can take it back when it needs the capacity for regular customers, so Spot suits work that can be interrupted. Spot has its own set of vCPU quotas, listed in a separate table from the On-Demand ones. That means a raise on the On-Demand Standard quota doesn't help a Spot launch, and a Spot raise doesn't help an On-Demand launch.

AWS's documented Spot quota names are All Standard (A, C, D, H, I, M, R, T, Z) Spot Instance Requests (default 5), plus separate ones for G and VT, Inf, F, DL, Trn, X, All P4, P3 and P2, and All P5, each defaulting to 0. Same rule as before: the Applied quota value on your account is what counts.

The part that trips people up is the word requests. AWS says Spot quotas are managed in vCPUs that your running Spot Instances are using or will use once open Spot Instance requests are fulfilled. And here's the catch: if you terminate Spot Instances but don't cancel the Spot requests behind them, the requests keep counting against your quota until EC2 detects the terminations and closes them. That explains the confusing version of the error, where you have no Spot Instances running and still see "Max spot instance count exceeded."

So the Spot fix order is:

First, cancel stale or leftover Spot requests. Second, check the arithmetic against the vCPU size of what you asked for. A default Standard Spot quota of 5 can't hold an 8-vCPU type such as a t2.2xlarge, even with nothing running, which is the same restaurant problem in a different room. Third, if you really need more, request an increase for the matching Spot quota in the Service Quotas console. AWS says explicitly that receiving the Max spot instance count exceeded error is a reason to request one.

If you use EC2 Fleet or Spot Fleet, note that fleets have their own target-capacity quotas, which AWS documents separately and which you raise through the Support Center Service limit increase form, choosing EC2 Fleet as the limit type. A fleet can fail for that reason even when your vCPU quota looks fine.

Jake's version of the problem came from the shop's holiday sale. He wanted cheap Spot capacity for a few nights and asked for "a lot," which was fine, but he asked for the G family Spot quota and then launched an On-Demand GPU instance. "It's the same letter, why doesn't it work?" Ethan's reply was one line: "Different table, different chairs."

GPU and other families that start at zero

If your message says "current vCPU limit of 0," you're almost certainly launching from a specialty family. A GPU (graphics processing unit) instance is a server with a graphics card attached, popular for machine learning and for running local large language models. AWS's documentation lists a default of 0 for G and VT, P, DL, F, Inf, Trn, X, HPC, and High Memory. Zero isn't a rejection of you, it's just that those families start off, and you switch them on by asking.

The letters do the sorting. g4dn.xlarge and g5.xlarge start with g, so they draw from Running On-Demand G and VT instances. AWS gives g4dn.xlarge as 4 vCPUs, and g5.xlarge is also 4 vCPUs (with 1 GPU). So to launch even one, you need at least 4 vCPUs in that quota, which means asking for a value of 4 or more, and preferably a bit above the biggest thing you'll run.

A few things worth knowing before you file:

Match On-Demand with On-Demand. If you'll launch normal instances, request Running On-Demand G and VT instances. If you'll use Spot, that's All G and VT Spot Instance Requests. AWS keeps them in separate tables, and requesting one does nothing for the other. This mix-up shows up in AWS's community forum regularly, in the form of "I got my quota approved and it still says 0."

Name your instance types in the request. AWS's guidance for tests across types is to list the instance types in the use case description and say whether you'll run them together or one at a time. It helps the reviewer understand why the number is what it is.

Approval isn't a guarantee of capacity. A higher quota gives you the right to launch. It doesn't guarantee AWS has the hardware free at that moment. If you get InsufficientInstanceCapacity after your quota is approved, that's a different problem with different fixes, covered next.

Watch the running clock. AWS bills On-Demand instances by the second while they're running, with a 60-second minimum. GPU instances are the kind you decide the stop time for before you press launch.

Ethan: "If your plan is to test a local model for an afternoon, ask for the smallest GPU quota that fits it, use it, shut it off. I've watched people request a giant GPU quota, forget the instance, and wake up angry at a bill. The quota didn't do that. The forgetting did."

When the request is denied, stuck, or only partly approved

Most requests for ordinary Standard capacity go through, but not all of them, and it helps to know what to do when yours doesn't. The most important thing is what AWS says outright: Support can approve, deny, or partially approve a request. A partial approval isn't a failure. Check the Applied quota value, because you may have gotten less than you asked for and still more than you had.

Here's the escalation ladder, from least effort to most:

1. Read the case, not just the status. When the status shows Quota requested, there's a case number. Open it. The Case closed status especially means the answer is in the correspondence, and AWS tells you to read it.
2. Check that you asked for the right thing. Was it the right Region? The right family (Standard versus G and VT versus Spot)? Was the value a new total, higher than the current one? A perfectly reasonable request for the wrong quota looks like a silent failure.
3. Add context in the case. Name the instance types you plan to run and whether they'll run in parallel or one at a time. For an unusual family, a sentence about what you're building gives the reviewer something to approve.
4. Ask for less. If a large jump wasn't approved, a smaller step you can justify may be. AWS says smaller increases are usually approved automatically, and larger requests are the ones that go to Support for review. You can request more later once the first amount is in use.
5. Contact Support. AWS's advice for an urgent request, or a denied one, is to contact Support. Be aware the same note says requests don't receive priority support, so this improves your information, not your place in line.
6. Work around it while you wait. Use a smaller instance, free vCPUs from the cheap-fixes list, or launch in a Region where you have room.

What I can't tell you is why a particular request was denied. AWS's documentation doesn't explain its decision criteria, and there's no button in this post that overrules a Support decision. What you can do is make the next request clearer and smaller, and keep the work moving in the meantime. Opening several duplicate requests for the same quota doesn't appear in the documentation as a way to move faster, and one clean request with a single case to follow is easier to track than three.

Errors that look like quota problems but aren't

This section saves people the most time, because a raised quota fixes none of these. If you increased your vCPU quota, you're approved, and the launch still fails, look here before filing another request.

A word on the capacity error, since it's the one people confuse with quotas most often. Think of a tea shop that has run out of samosas at four in the afternoon. Your wallet is fine, the shop is open, and it still can't hand you one right now. AWS's advice matches the real-world one: wait a few minutes, try a smaller order, or pick something similar. It's about what AWS has available at that moment, so no quota request will fix it.

The instance that vanishes right after starting deserves its own note. It leaves the pending state and goes straight to terminated, which feels like a quota problem because the launch "failed." AWS lists exceeded EBS volume limits as one of the reasons. The fastest way to know is the State transition reason on the instance's first tab in the EC2 console, or the StateReason element in the describe-instances output.

Ethan: "Read the exact words of the error. They're annoyingly specific, and that's a gift. If it says vCPU, it's a quota. If it says capacity, it's AWS's shelf. If it says authorized, it's your keys."

When another service launches the instances for you

Plenty of people meet this error without ever clicking Launch instance. Services such as Auto Scaling (which adds and removes instances automatically), Elastic Beanstalk, and AWS ParallelCluster start EC2 instances on your behalf, and they run into the same quotas you do. The error shows up in that service's own events or logs instead of the EC2 console, which makes it look like a different problem.

AWS's ParallelCluster documentation is a good example. It says a VcpuLimitExceeded error can appear in slurm_resume.log when a job fails to run, or in clustermgtd.log when a cluster fails to create. Its advice is the same as everything here: check the vCPU limits on your account for the specific instance type you're using, and if you see zero or fewer vCPUs than you're requesting, request an increase.

Two habits help with these. First, find the instance type that the service is actually launching. It's whatever your launch template, cluster configuration, or environment settings say, not what you assumed. Second, multiply. If a cluster scales out to ten nodes and each node is a 16-vCPU type, that's 160 vCPUs of quota needed, not 16. The total across all nodes is what the bucket counts, and that surprise is the reason scaling groups fail at 2 a.m. instead of at setup time.

Stop it from happening again: alarms and Automatic Management

AWS's own advice on quotas is to plan ahead: its EC2 guide says to request any quota increases in advance of the time you'll need them. That sounds like a nag, but the reason is practical. You can't schedule the answer, so the only time to ask is before the launch matters. Here are the tools AWS gives you to see the ceiling coming.

CloudWatch alarms on a quota. Amazon CloudWatch is AWS's monitoring service, and Service Quotas integrates with it so you can watch EC2 usage against your quotas and set alarms that warn you when you approach one. In the Service Quotas console, open a quota that supports alarms, and if it has utilization data you'll see it beneath the quota description. Under CloudWatch alarms, choose Create, pick a threshold, and give the alarm a name that's unique in your account. Not every quota supports this, so if you don't see the section, that quota doesn't offer alarms.

Trusted Advisor's Service limits page. AWS lists this in its EC2 documentation as another place to view your quotas. It's a handy second view when you'd rather look at a list than build an alarm.

Service Quotas Automatic Management. This is the newer option. AWS describes it as monitoring your quota usage and notifying you before you run out. Notifications go out at 80% and 95% utilization, through channels such as the AWS Console Mobile Application, email, or Slack, and you can also see them in the AWS Health dashboard or subscribe through Amazon EventBridge for automation. It has two modes: Notify Only, and Notify and Auto-Adjust, where AWS can file a quota increase request for you. Only quotas with usage metrics can be monitored, and only some adjustable quotas support auto-adjustment.

Now a caution, because the documentation pulls in two directions. AWS's User Guide describes both modes. Its API reference for the update operation, on the other hand, says that currently only Notify Only is available. Rather than guess which page is more current, look in the Automatic Management section of the Service Quotas console. It shows the quotas and options your own account actually supports.

If you manage several accounts under an AWS Organization, the Service Quotas API also includes quota request templates, which apply a set of increase requests to new accounts in the organization. That's worth a look for anyone who keeps hitting the same default ceiling on every new account.

Ethan: "An alarm at 80% costs you nothing and turns a Saturday emergency into a Tuesday chore. Set it once, forget about it, and let it nag you on the day you'd otherwise be stuck."

What a bigger quota does and doesn't cost

Money questions deserve a plain answer. The quota pages describe no charge for raising a quota. What you pay for is running instances: AWS says On-Demand pricing is per second while an instance is in the running state, with a 60-second minimum, at a fixed price per second listed on the EC2 On-Demand pricing page. That statement covers the instance's running time. Anything attached to it has its own pricing, so read the pricing pages for those separately.

The real risk is different. A quota is also a guardrail. AWS's own 2019 description says the limits protect you from unintentional spending or abuse. When you raise the ceiling far above what you use, you also raise how much a mistake can cost. A script with a loop bug, a scaling group with the wrong maximum, or a forgotten test cluster can launch right up to the new limit.

The sensible way to hold both ideas is the one AWS already recommends: ask for what you use plus what you plan to use plus a 10-30% buffer, not a dramatic round number. Pair that with the alarms from the last section, and make a habit of looking at what is running before you leave for the weekend.

Jake now files the request the week before a demo instead of the morning of, sets one alarm, and picks the smallest instance that fits the job. His ceiling is higher than it was, but he treats it as a limit he's grown into rather than a number to max out. Ethan says that's the most boring plan available, and he means it as praise.

Frequently asked questions

What does the EC2 vCPU limit exceeded error actually mean?

It means that launching this instance would push the total vCPUs running in that Region, within that instance family's bucket, above your Applied quota value. AWS's documentation says the request then fails. The fix is to reduce usage, choose a smaller instance, or request a higher quota for that family in the Service Quotas console, in the same Region where the launch failed.

What is the default vCPU quota on a new AWS account?

AWS's documentation lists a default of 5 vCPUs for Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances, and 0 for the other On-Demand families such as G and VT and P. EC2 also raises On-Demand quotas automatically based on your usage, so the number that matters is the Applied quota value shown on your own account in the Service Quotas console.

Is InstanceLimitExceeded the same thing as VcpuLimitExceeded?

Both point to an EC2 quota and are handled the same way. AWS documents InstanceLimitExceeded, with the message "Your quota allows for 0 more running instance(s)," as reaching your limit on running On-Demand Instances in a Region, including when you restart a stopped instance. VcpuLimitExceeded names the vCPU limit for the instance bucket your instance type belongs to. In both cases you request an increase in the Service Quotas console.

How do I request an EC2 vCPU quota increase?

Open the Service Quotas console, select the Region, choose AWS services, then Amazon EC2, and filter for On-Demand. Choose the quota for your instance family, choose Request quota increase (or Request increase at account-level), enter a new value higher than the current one, and choose Request. Track it under Dashboard or Request history. You can also use the AWS CLI with the request-service-quota-increase command.

How long does an EC2 quota increase take?

AWS's documentation doesn't publish a fixed time. It says smaller increases are usually approved automatically, while larger requests go to Support and take time to review, process, approve, and deploy. It also says quota increase requests don't receive priority support. Plan for the request to take a while, and don't tie a launch date to a same-day approval.

Does raising my EC2 quota cost money?

The quota documentation describes no fee for raising a quota. You pay for On-Demand Instances by the second while they are in the running state, with a 60-second minimum. A higher quota does raise how much could be launched by mistake, so request what you need plus a 10-30% buffer, and set alarms so you notice usage climbing.

Do stopped instances count toward my vCPU quota?

No. AWS states that instances in the pending, stopping, stopped, and hibernated states do not count toward On-Demand Instance quotas. One exception matters: Capacity Reservations count toward your On-Demand quotas even when they are unused. Also remember that a stopped instance needs room again when you start it.

Why does starting a stopped instance fail with a quota error?

AWS documents InstanceLimitExceeded for launching a new instance or restarting a stopped instance. A stopped instance doesn't count against your quota, but once it starts it counts again. If other running instances have used the room in the meantime, the start can fail until you free up vCPUs or raise the quota.

Do I have to request the increase in every Region?

Yes. AWS says Amazon EC2 service quotas apply to only one Region, so you must submit a separate request for each Region that needs more capacity. A quota approved in one Region doesn't carry over to another, so always confirm the Region selector in the console before you request or launch.

My quota request says Pending or Quota requested. What happens next?

Pending means the request is under review by AWS. Quota requested means a support case was opened, and the case number appears; choosing it opens the ticket. When the request is resolved and approved, the Applied quota value changes to the new number. Retry your launch after you see it. Follow the case for updates if it takes time.

What if my quota increase is denied or only partly approved?

AWS says Support can approve, deny, or partially approve a request. Check the Applied quota value, since a partial approval may already be enough. If it was denied, read the case, confirm the Region and quota were correct, and consider a smaller request with a clear use case. AWS advises contacting Support for urgent or denied requests, though requests don't receive priority support.

How many vCPUs should I ask for?

AWS's guidance is to add the vCPUs you use, plus the vCPUs you plan to use, plus a buffer of 10-30%. Enter the new total, not the extra amount. For example, 64 running Standard vCPUs plus 112 for new instances is 176, and a 10-30% buffer puts the request between about 194 and 229.

Why do I get Max spot instance count exceeded with no Spot Instances running?

Spot quotas count running Spot Instances plus vCPUs for open Spot requests. AWS says that if you terminate Spot Instances without canceling the requests, those requests keep counting until EC2 detects the terminations and closes them. Also, a default Standard Spot quota of 5 can't fit an 8-vCPU instance type. Cancel stale requests, then request a Spot quota increase if needed.

Why is my GPU quota 0, and how do I launch a g4dn or g5 instance?

AWS's documentation lists a default of 0 for Running On-Demand G and VT instances, which covers g-family types such as g4dn.xlarge (4 vCPUs) and g5.xlarge (4 vCPUs). Request an increase for Running On-Demand G and VT instances to at least the vCPUs of the largest instance you'll run. Spot uses a separate quota, All G and VT Spot Instance Requests.

Can I request an EC2 quota increase from the AWS CLI?

Yes. Your identity needs permission for Service Quotas to create a support case on your behalf, using the ServiceQuotasFullAccess managed policy or iam:CreateServiceLinkedRole. Then run aws service-quotas request-service-quota-increase with the service code ec2, the quota code (L-1216C47A for Standard), and the desired value. Check progress with the list-requested-service-quota-change-history command.

How do I get warned before I hit the limit again?

Set a CloudWatch alarm from the Service Quotas console on quotas that support it, and look at the Service limits page in Trusted Advisor. You can also turn on Service Quotas Automatic Management, which AWS describes as sending notifications at 80% and 95% utilization. Its Auto-Adjust mode can request increases for you, but check your console to see which modes your account offers.

Revision note. Written September 2026. Default values, quota names, console labels, and the Automatic Management options can change, so if your screen looks different from this post, trust the Applied quota value on your own account and the current AWS documentation. If you've been staring at that red error message wondering what you did wrong, you did nothing wrong, and this one really is fixable.