« Cloud Storage Tools | Main | Subscription and Service Administration in Windows Azure »

January 04, 2010

Windows Azure Role Instance Limits Explained

In preparation for the Windows Azure Commercial Launch new limits for role instances were introduced. Those differ from the currently available Customer Technology Preview (CTP) limits, and may impact the way you deploy and configure your hosted services or storage accounts in Windows Azure.

This article explains what the relationship between the number of hosted services, number of roles, number of instances, VM (Virtual Machine) size and deployments is (for more details on the VM sizes visit Configuring Virtual Machine Size on MSDN). Additionally you will get an overview of what the limits for storage accounts are.

If you have already encountered issues with your deployments you should follow the guidelines below to calculate your needs and call Windows Azure Support team for assistance.

Here is a brief overview of the current and future limits imposed on your services in Windows Azure.


before Dec. 10th 2009

after Dec. 10th 2009

after Jan. 4th 2010


Token (CTP)

Token (CTP)

Token (non-billing country)

Paying subscription

Deployment Slots





Hosted Services





Roles per 





Instances per Role



no limit

no limit

VM CPU Cores

no limit




Storage Accounts






CTP Program Limits

CTP program was free, but in order to participate you were required to request a token. One token entitled you to the following deployments:

  • 2 deployment slots (1 production and 1 staging)
  • 1 hosted service
  • 5 roles per deployment
  • 2 instances per role

In total this allowed you to have up to 20 instances deployed for free. Additional to that you were entitled to have up to 2 storage accounts, 50GB each.

If you were lucky to get additional CTP tokens you could “stack” those and easily double (or triple, quadruple etc.) the limits above.

The size of the VM was not considered into account when calculating the CTP limits. What this means is that you can configure your roles to be deployed on extra large VMs (8 CPU cores, 15 GB RAM, and 2TB local storage), and still deploy 20 instances for free, making it 160 CPU cores in total.

In summary the CTP program was a good way to consume large amount of resources for free.

Commercial Launch Limits

However, getting those free resource is not possible anymore. The new limits are already fact, and starting January 4th those will be different for customers who use tokens and customers who convert their subscription to billing. Those will be calculated using weighted formula that takes into account the size of the VM too. The weighted formula counts the number of CPU cores you use for your hosted service and limits your usage based on this number.

If you happen to be in a country that is not provisioned for billing for Windows Azure you will still be able to use tokens and deploy your application on Windows Azure. Of course those tokens will be controlled much more strictly than until now, and the corresponding limits will be consistently enforced.

What the numbers above mean? Don’t be mislead by the number 20 for Hosted Services. Theoretically you will be able to create so many, however you will hit the limit of VM CPU cores much earlier. Here is how this works.

Imagine you create Hosted Service with two roles in it, and each role has one instance with Small VM Size (1 CPU core). The math is as follows:


1 hosted service x 2 roles x 1 instance x 1 CPU core = 2 CPU cores


You have already used 2 out of your 8 allowed CPU cores with just one instance. If you decide to replace the VM size with Large one  (4 CPU cores) you will reach the limit:


1 hosted service x 2 roles x 1 instance x 4 CPU core = 8 CPU cores


Thus you can easily reach or exceed the limit with only one Hosted Service.

The other number you should be careful with is the number of roles per deployment. You are entitled with up to 5 of those independent of the type (Web or Worker). Imagine you design your service to have 5 roles with 1 instance on a small VM each (not very redundant but this is for the purpose of illustration only). Imagine also that you want to use the staging environment for your pre-production tests, and you want to mimic exactly your production environment. If you have already your previous version deployed in your production slot, you will exceed the limit of VM CPU Cores when you try to deploy your new version on the staging slot (assuming you have limit of 8 CPU cores):


Prod Deployment = 5 roles x 1 instance x 1 CPU core = 5 CPU cores

Stage Deployment = 5 roles x 1 instance x 1 CPU core = 5 CPU cores

Total = 10 CPU cores


One thing to remember is that stacking tokens will not increase your limit as it will just increase the number of allowed Hosted Services but not the number of CPU cores you are entitled to. However stacking tokens will still give you more storage accounts. Of course this may change in the future.

Because the goal is to convert CTP users to paying users, billing subscription will have higher limits for compute, which is set to 20 by default. Also billing users will be able to call Windows Azure Support team, and request increase of their limit as long as they provide enough business justification and money guarantee.

Errors Thrown When Exceeding the Limit

If you happen to exceed the limit of VM CPU cores you will be presented with the following error in Windows Azure Portal:


The subscription policy count for resource was exceeded. Please visit the Accounts tab to learn how to increase your resource quota Dr. Watson Diagnostic ID: 89ac8ae2-c5a8-48ae-a7d6-751db6bdf22a


Windows Azure limit exceeded error

Similar error will be returned from the Service Management API.

Keep in mind that you will receive the above error in the following cases:

  • When you try to re-deploy your service (change the number of roles or the size of the VMs in csdef, or if your current usage is higher than the limit)
  • When you try to increase the number of instances for your service (in cscfg), which can also be part of the upgrade

If you happen to exceed the limit of roles per deployment you will receive the following error:


Unsupported number of roles Dr. Watson Diagnostic ID: 5cbd9c72-3f27-4f31-a54f-bfb100b92516


This error you will only receive if you try to re-deploy your hosted service.

Your service will not not impacted if you try to run or suspend it. If you already have running service that exceeds the limits above it will not be impacted either, but you need to make sure that you request increase of your limits before your next deployment.

One more thing is that stopped services count towards the limits. Stopping your application on staging will not help you if you want to increase the count on your production service; you will need to completely delete your staging deployment in order to free up some slots.

What is next?

All customers who reside in the billing countries will be required to migrate their CTP subscription to a billing one in January 2010. One thing you need to be aware of though is that during the migration process the limits will be reset to the above mentioned ones.

The best approach you can take is to wait until January and migrate your CTP subscription to a billing one first, and then request increase of your limit if you need to. Thus your service will continue to run uninterrupted. Of course you can do this only of you don’t plan any deployments that exceed the limits before January.

At some point of time after February 1st 2010 all CTP tokens in the billing countries will be evicted. Even when evicted you may be able to continue to run your service, but you will be prevented to do any deployments and upgrades.

More Resources

Additional information about the limits is available on RemyP’s blog and in BradC’s talks from PDC09.

Storage Quotas and Core Allocation on Windows Azure[RemyP’s Blog]

New role instance allocation[RemyP’s Blog]

Windows Azure Blob and Drive Deep Dive[Brad Calder]

Building Scalable and Reliable Applications with Windows Azure[Brad Calder]




Feed You can follow this conversation by subscribing to the comment feed for this post.

Post a comment

Comments are moderated, and will not appear on this weblog until the author has approved them.

If you have a TypeKey or TypePad account, please Sign In