Quota Quagmire: Why Azure Functions’ Broken Quota Experience Is Chasing Customers to AWS

Azure Functions should be the easiest way for customers to start with serverless on Azure. It should be a frictionless, welcoming introduction to the platform. Instead, what should be a simple “click, deploy, test, iterate” journey turns into a Kafkaesque maze of opaque quota errors, confusing support workflows, and absurd forms that demand impossible-to-fill fields.

If Microsoft is serious about growing Azure Functions usage and capturing serverless mindshare from AWS Lambda, this experience needs to be fixed immediately. Here’s how it breaks down in practice — and why it’s so unacceptable.

Diagnosing Cryptic Quota Failures

In my Terraform test harness for Azure Functions, I aimed to provision Consumption and Premium Function App Service Plans in West US 3. Instead of iterating quickly, I was blocked by these cryptic errors:

Error: Failed to create App Service Plan.
The operation could not be completed due to quota limitations.
Location: West US 3
Resource Type: Dynamic VMs
Current Limit: 0
Current Usage: 0
Required for Deployment: 0
Suggested New Limit: 0
Note: If you experience multiple scaling operations failing, you may need to request a higher quota limit than currently displayed.

this is what i got for premium plans:

Error: Failed to create App Service Plan.
The operation could not be completed due to quota limitations.
Location: West US 3
Resource Type: ElasticPremium VMs
Current Limit: 0
Current Usage: 0
Required for Deployment: 0
Suggested New Limit: 0
Note: If you experience multiple scaling operations failing, you may need to request a higher quota limit than currently displayed.

Both errors point to zero available quota, block Terraform provisioning, and are labeled as “Unauthorized” despite being quota issues.

The difference lies in the SKU type: Consumption Plan triggers a Dynamic VMs quota message, while Premium Plan triggers an ElasticPremium VMs quota message.

Despite showing “Unauthorized,” these are quota failures: Consumption Plans trigger a Dynamic VMs message, while Premium Plans trigger an ElasticPremium VMs message. Zero quota available, zero clarity, and Terraform is dead in the water.

Submitting a Support Request for Quota

So, like many customers, I try to submit a quota increase request. There is supposedly a self-service portal, but “App Service” (under which Azure Functions sits) doesn’t appear, nor does “Function Apps.” A new user wouldn’t know to guess “Web App (Windows and Linux)” just to move forward.

There is a self service portal for requesting quota. However Resource Providers have to “opt-in”.

As you can see “App Service” which Azure Functions is a sub-category of, does not exist.

If I am completely new to the platform I wouldn’t know that I’d probably just search for “Function Apps” or something like that.

Again, I come up empty! So what gives? What recourse do I have? Yes. Alas, I have to open a Support Ticket.

Clicking “Create a support request” leads me down this path:

If I select “Service and subscription limits (quotas):

I am a bit thrown off because usually a “Blue Button” indicates the next action. Here I have find find this white button that looks rather passive. Now I am creating a new support request. first I select “Azure Services”

I have to select “Service and subscription limits (quotas)” even though the error I get appears to be a technical error at first glance.

Again, I am back to the Quota drop down where Azure Functions is nowhere to be found. How confusing.

Luckily App Service is there — but again, if I am new to Azure and new to Azure Functions, how the heck am I supposed to know that? Pure insanity.

Ok. So I select “Web App (Windows and Linux)” even though I am working with Azure Functions thinking its the closest thing to what I am trying to do. Now I have to enter details about my request.

But wait, what’s this? The quota request wants things specific to App Service — not Azure Functions.

If I am using Azure Functions Consumption or Premium plans I don’t even want to request “VMs”. Why would I be requesting “VMs” for a “Serverless” service. I get it, Premium Azure Functions hosting plans do have the concept of “reserved capacity” and it is measured in “instances” of EP1 and EP2 but still. Very confusing.

The last straw? I can’t even fill in the required field “App Service Plan” because i LiTERaLlY Can’t prOVisION one wITHouT QUOtA!!! The rage is starting to build.

What customer would put themselves through this? They would just go sign up for AWS and start using Lambda. For real.

Oh wait, Just kidding, that little red asterix is just kidding around. Apparently, “Response not found” is an acceptable input for this field!!! Oh, my sides.

So I have to go submit a quota request for a Service I am not using for quota I don’t actually want. Riiight.

The Response from Support

I got this response from support:

As I understand the issue, you’re seeking quota for West US 3 and have applied via your quota page. Does this sound correct or should we clarify further?

As your case came in via one of the automated quota systems, please forgive me if you’re aware of the below information. Give it a read-through if you can, at the bottom is the information I need to open a request for Microsoft.Web quota, which is what you actually need.

Unfortunately Azure has been operating near capacity for almost 2 years. Popular demand for app services has been high and each time a data center is expanded and taken off capacity limitation, it returns to capacity limitation within just a few months.

The initial recommendation is to use another region if at all possible. It’s just the simplest way to get around quota restrictions. The recommended regions that have no restrictions right now are West US 1, Central US 1, and Canada Central. You should be able to deploy to those regions without issue.

However, if you have a requirement that your deployment occur in West US 3, I may be able to apply for quota on your behalf. I will caution you now that the capacity team that makes these decisions with input from the data center team does not always approve non-enterprise quota requests and often rejects them. So there isn’t a guarantee of quota approval and the decision is out of my hands.

At any rate, if another region doesn’t work for you, all I need to apply for you to get into your desired region is the following form filled out and/or what I’ve filled in confirmed:

If I want to stick with US West 3 I guess I have to file a TPS report.

Why couldn’t this just be in the Quota Request process? better yet, why doesn’t Azure Functions just show up in my Quota dashboard in the Azure Portal? Why do I even need to submit a Customer Support Request and then wait for a response only to fill out the actual questionairre and wait for customer support’s response?

Here is the list of fields they want me to fill out in response.

• Is this for an ASE or for Public cloud?
• Requested Number of Additional App Instances
• Requested SKUs
• OS Type, Linux or Windows?
• Resource Group (potentially unnecessary but if you know)
• Justification for not using an alternate region (this is important)
• Is this a Functions request: Yes/No
• If yes, Functions Tier: Consumption or Premium
• If yes, Functions Memory Size

What customer would put themselves through this? They would just go sign up for AWS and start using Lambda. For real.

Conclusion: Eliminate Toil or Lose the Market

What did I do? I changed my region to “Canada Central” and the quota issue went away.

Azure Functions should be an introductory Azure experience, but if new customers hit this wall, they will leave for greener — or oranger — pastures. This is not a minor inconvenience; it is a major competitive disadvantage that stifles adoption and erodes trust in Azure’s promise of simplicity and scalability.

If we want to win market share from AWS Lambda, we need to fix this now. We need clear, actionable quota error messages, intuitive self-service quota workflows, and automatic onboarding for Azure Functions capacity management. Customers should never have to file a TPS report just to use serverless. This is a call to eliminate toil and replace it with the seamless developer experience Azure Functions deserves.