Windows Azure Web Sites – Quotas, Scaling, and Pricing

It hasn’t been easy making the transition from a consultant to someone that for lack of a better explanation is a cross between pre-sales and technical support. But I’ve come to love two aspects of this job. First off, I get to talk to many different people and I’m constantly learning as much from their questions as I’m helping teach them about the platform. Secondly, when not talking with partners about the platform, I’m digging up answers to questions. This gives me the perfect excuse… er… reason to dig into some of the features and learn more about them. I had to do this as a consultant, but the issue there is that since I’d be asked to do this by paying clients, they would own the results. But now I do this work on behalf of Microsoft, it’s much easier to share these findings with the community (providing it doesn’t violate non-disclosure agreements of course). And since this blog has always been a way for me to document things so I can refer back to them, it’s a perfect opportunity to start sharing this research.

Today’s topic is Windows Azure Web Sites quotas and pricing. Currently we (Microsoft) doesn’t IMHO do a very good job of making this information real clear. Some of it is available over on the pricing page, but for the rest you’ve got to dig it out of blog posts or from the Web Site dashboard’s usage overview details in the management portal. So I decided it was time to consolidate a few things.

Usage Quotas

A key aspect of the use of any service is to understand the limits. And nowhere is this truer then the often complex/confusing world of cloud computing services. But when someone slaps a “free” in front of a service, we tend to forget this. Well here I am to remind you. Windows Azure Web Sites has several dials that we need to be aware of when selecting the level/scale of Windows Azure Web Sites (Free, Shared, and Reserved).

File System/Storage: This is the total amount of space you have to store your site and content. There’s no timeframe on this one. If you reach the quota limit, you simply can’t write any new content to the system.

Egress Bandwidth: This is the amount of content that is served up by your web site. If you exceed this quota, your site will be temporarily suspended (no further requests) until the quota timeframe (1 day) resets.

CPU Time: This is the amount of time that is spent processing requests for your web site. Like the bandwidth quota, if you exceed the quota, your site will be temporarily suspended until the quota timeframe resets. There are two quota timeframes, a 5 minute limit, and a daily limit.

Memory: is the amount of RAM that the site can use at one shot (there’s no timeframe). If you exceed the quota, a long running or abusive process will be terminated. And if this occurs often enough, your site may be suspended. Which is pretty good encouragement to rethink that process.

Database: There’s also up to 20mb for database support for your related database (MySQL or Windows Azure SQL Database currently). I can’t find any details but I’m hoping/guessing this will work much like the File Storage quota.

Now for the real meat of this. What are the quotas for each tier? For that I’ve created the following table.

Quota Resource

Free Tier

Shared Tier

(per web site)

Reserved Tier

(up to 100 sites)

File Storage 1024mb for all sites 1024mb 10gb
Egrees Bandwidth 165mb/day per datacenter, 5gb per region Pay as you go, not included in base price Pay as you go, not included in base price
CPU Time 1hr/day, 2.5 minutes of every 5 4hrs/day, 2.5 minutes of every 5 N/A
Memory 1024mb/hr 512mb/hr N/A
Database 20mb 20mb N/A

Now there’s an important but slightly confusing “but” to the free tier. At that level, you get a daily limit egress bandwidth quota per sub-region (aka datacenter), but there’s also a regional (US, EU, Asia) limit (5GB). The regional limit is the sum total off all web sites you’re hosting that is shared with any other services. So if you’re also using Blob storage to serve up images from your site that will count against your “free” 5 GB. But when you move to the shared/reserved tier, there’s no limit, but you pay for every gigabyte that leaves the datacenter.

Monitoring Usage

Now the next logical question is how you monitor the resources your sites are using. Fortunately, the most recent update to Windows Azure portal has a dashboard that provides a quick glance as how much you’re using of each quota. This displays just below usage grid on the “Dashboard” panel of the web site.

At a glance you can tell where you on any quotas which also makes it convenient for you to predict your usage. Run some common scenarios and see what they do to your numbers and extrapolate from there.

You can also configure the site for diagnostics (again via the management portal). This allows you to take the various performance indicators and save them to Windows Azure Storage. From there you can download the files and set up automated monitors to alert you to problems. Just keep in mind that turning this on will consume resources and incur additional charges.

Fortunately, there’s a pretty good article we’ve published on Monitoring Windows Azure Web Sites.

Scaling & Pricing

Now that we’ve covered your usage quotas and how to monitor your usage, it’s important to understand how we can scale the capacity of our web sites and the impact this has on pricing.

Scaling our web site is pretty straight forward. We go can go from the Free Tier, to Shared, to Reserved using the management portal. Select the web site, click on the level, and then save to “scale” your site. But before you do that, you will want to understand the pricing impacts.

At the Free tier, we get up to 10 web sites. When we move a web site to shared, we will pay $0.02 per hour for each web site (at general availability). Now that this point, I can mix and match free (10 per sub-region/datacenter) and shared (100 per sub-region/datacenter) web sites. But things get a bit trickier when we move to reserved. A reserved web site is a dedicated virtual machine for your needs. When you move a web site within a region to the reserved tier, all web sites in that same sub-region/datacenter (up to the limit of 100) will also be moved to reserved.

Now this might seem a bit confusing until you realize that at the reserved tier, you’re paying for the virtual machine and not an individual web site. So it makes sense to have all your sites hosted on that instance, maximizing your investment. Furthermore, if you are running enough shared tier web sites, it may be more cost effective to run them as reserved.

Back to scaling, if you scale back down to the free or shared tiers, the other sites will revert back to their old states. For example, let’s assume you have two web sites one at the free tier, one at the shared tier. I scale the free web site up to reserved and now both sites are reserved. If I scale the original free tier site back to free, the other site returns to shared. If I opted to scale the original shared site back to shared or free, then the original free site returns to its previous free tier. So it’s important when dealing with reserved sites that you remember what tier they were at previously.

The tiers are not our only option for scaling our web sites. We also have a slider labelled instance count if we are running a Shared or Reserved site. When running at the shared tier, this slider will change the number of processing threads that are servicing the web site allowing us between 1 and 6 threads. Of course, it we increase the threads, there’s a greater risk of hitting our cpu usage quota. But this adjustment could come in real handy if we’re experiencing a short term spike in traffic. Running at the reserved tier, the slider increases the number of virtual machine instances we (and subsequently our cost). This option allows us to run up to 10 reserved instances.

Also at the reserved tier, we can increase the size of our virtual machine. By default, our reserved instance will be a “small” giving us a single cpu core and 1.75 GB of memory at a cost of $0.12/hr. We can increase the size to “Medium” and even “Large” with each size increase doubling our resources and the price per hour ($0.24 and $0.48 respectively). This cost will be per virtual machine instance, so if I have opted to run 3 instances, take my cost per hour for the size and multiple it by 3.

So what’s next?

This pretty much hits the limits of what we can do with scaling web sites. But fortunately we’re running on a platform that’s built for scale. So it’s just a hop, skip, and jump from Web Sites to Windows Azure Cloud Services (Platform as a Service) or Windows Azure Virtual Machines (Infrastructure as a service). But that’s an article for another day. J

18 Responses to Windows Azure Web Sites – Quotas, Scaling, and Pricing

  1. pm says:

    So, is it correct to say that two shared websites have 4hr per day of cputime EACH while two free websites have 1hr per day of cputime in TOTAL?

  2. RobinPS says:

    I’m using an Umbraco website on as a shared website on Azure. My memory usage has been exceeding the 512 MB limit a few times yesterday, making the website become suspended. I’ve had appr 2000 visitors in a few hours. Do you know if this is normal for a website with these number of visitors? And second, in this scenario will it have effect to add extra instances? Or isn’t adding instances a solution for exceeding the memory limit? Thanks a lot!

    • Brent says:

      I haven’t used Umbraco, so I can’t really speak to “is this usual”. As for adding more instances, that’s only available at the reserved tier. At the shared tier, you can add more threads, but that only potentially addresses throughput if your thread bound and increasing threads does NOT allow you to go above the quotas.

      • RobinPS says:

        Thanks for your reply! In shared mode I have the option to add more instances. Do you mean that adding more instances here only means adding more threads? What does that mean exactly?

      • Brent says:

        The text is misleading here. Hover your mouse over the ‘?’ icon to the right of the field in the management portal. You see that in free/shared, you’re increasing the process/thread count but when you’re at reserved, its actually increasing the vm instance count.

      • RobinPS says:

        You’re right, in shared mode the “?” tells I will increase the number of processes. Thanks for your explanation. What is the advantage of increasing the number of processes/threads? When should you do that?

      • Brent says:

        I can’t say with 100% certainty, but its my understanding that this allows you to overcome issues with short bursts in activity, such as spikes in traffic or occasionally running background processes (say a background index generation). By having more available processes, these tasks can run with less context switching. However, increasing the counts has (to my knowledge) no impact on your quota limits. Think of like it like having a bigger engine in your car but still limited to a fixed amount of fuel.

      • RobinPS says:

        Thanks for your explanation!

  3. what about High Availability? on the free/shared mode do I get HA? On reserved mode, do I have to run 2+ instances to get HA?

    • Brent says:

      For HA, I’d refer you to the SLA. Which since web sites (as of when I’m writing this) are still in preview, there is none. But even then, note that if you scale out at the reserved tier, that’s only scaling out the front end, not the database. If you truly need HA, I would likely recommend leveraging PaaS or IaaS cloud services. The per core/hour charges are comparable and you have greater ability to control your business continuity plans.

  4. Jignesh says:

    What about need of more file system space. e.g. my site has feature to load static contents. Like my site is learning management system where administrator will upload static learning contents for users to access. So, eventually my site grows. I can not use blob storage here due to technical limitation of inter-communication between website and the contents being loaded.

    So, i need to go for website and uploading to the folder under website. This will increase the file system usage. I may want more than 10 GB even. Is there any way to have that?

    • Brent says:

      I would suggest you explore putting those files into Windows Azure blob storage providing they are not executable files/scripts. This approach offloads some of the work from your Web Site by letting Azure storage serve up those content requests. Thus allowing you to stay below your compute/memory quotas. There would of course be a small increase in charges due to now using the storage service. But even 100gb of storage (10x your current limit) is less than $10/month not counting applicable bandwidth charges for serving up that content.

  5. Brilliant post – really appreciate the way you simplified the explanation of costings…. somehow this is much harder than actually writing the app in the first place!

  6. Hi Brent,

    I have more than one website and found that both are to be under total limit of 10 GB. Like i can not have one website with 10 gb space and other website with other 10 GB space… please confirm and let me know how to overcome this limitation.

    I am using for learning management system where learning contents are of huge size and those can not be on blob as it has scripting inside to communicate with core website engine

    is there any way we can have more than 10 gb.. it will be ok if i have per website 10 gb limit… but not on total 10 gb across all websites. We are ok to pay for more space if there is any option for the same.

  7. Can file system usage on Azure websites be monitored? I don’t see a means of creating an endpoint for it and/or a metric for it.

    • Brent says:

      I was playing with this a year ago and found a little documented API that would allow you to capture some of these metrics. However, the challenge is that the file system is for the web plan, not individual sites. So it has limited use IMHO. I tried to find a link to the docs again, but haven’t had much luck.

      • hi Brent thanks for looking. Good point about the file system quota being at the plan level not the site level. However I actually think that makes monitoring the space *even more important*, since running out will impact all sites on the plan as opposed to individual sites. Just occurred to me – I wonder if DriveInfo.AvailableFreeSpace against the Azure website D: drive would work. Then it could be periodically monitored via webjob or other.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: