SALES: 1-800-867-1380
5 out of 7 rated this helpful - Rate this topic

Windows Azure Shared Caching FAQ

Updated: February 28, 2014

What is Windows Azure Caching?

Windows Azure Cache is a distributed, in-memory cache that you can use to accelerate the performance and scale of your cloud applications built on Windows Azure and SQL Database. Cache is often used to keep frequently queried data in-memory close to the application itself, which both reduces overhead on the database tier and also eliminates unnecessary network latency.

ASP.NET developers can use Cache without code changes, as prebuilt session state and output caching providers enable you to activate with simple configuration changes. Cache capabilities are also directly available using a simple API for even more flexible and customized application use. At runtime, Cache transparently distributes ASP.NET session/output cache data or .NET Framework objects stored in the cache across the elastic, scale-out infrastructure.

For more information, see Cache.

Is Windows Azure Shared Caching a new offering?

No. Windows Azure Shared Caching is a new way of describing the existing multitenant service on Windows Azure. This service had previously been referred to as the Cache Service. The new terminology, Shared Caching, is designed to highlight the fact that backend Cache servers host multiple, isolated caches for multiple users. This distinguishes the service from the new In-Role Cache that supports hosting Cache services on Windows Azure roles that are private to a cloud service deployment. For more information about the differences, see How does Shared Caching differ from Caching on Windows Azure roles?.

What is the provisioning model for Windows Azure Shared Caching?

Because it is delivered as a true service, Shared Caching has a very simple provisioning model. There is no complex infrastructure to install, set up, or manage. The service performs these functions for you. There are only two things to configure: the data that you want to store and how large a cache you need. As the needs of your application grow or decrease, you can dynamically change the size of the elastic cache based on your needs.

How do I purchase Windows Azure Shared Caching?

Please note Windows Azure Shared Caching will be retired no later than August 29, 2014. In addition the Silverlight Portal used to manage this service will be decommissioned on March 31, 2014. Current Shared Caching users will receive communications on how to manage their shared caches if they choose to continue using this service after that date. For more information about migrating from Shared Caching to Cache Service (Preview), see Migrate from Shared Caching to Windows Azure Cache Service (Preview).

You can sign up to use Windows Azure Shared Caching through the Windows Azure Management Portal. For step-by-step instructions, see How to: Create a Cache (Windows Azure Shared Caching).

If you are signed up to one of the Windows Azure Platform offers, you might be eligible to get the 128MB cache option for free for a limited time depending on the specific offer. You can find more details on the Windows Azure Platform Offers page.

The regular prices of the different cache size are the following:

  • 128-MB cache for $45.00/month

  • 256-MB cache for $55.00/month

  • 512-MB cache for $75.00/month

  • 1-GB cache for $110.00month

  • 2-GB cache for $180.00/month

  • 4-GB cache for $325.00/month

What are the advantages of using Caching vs. hosting my own caching solution on Windows Azure?

Consistent with other Windows Azure Platform services, Shared Caching provides a true Platform as a Service (PaaS) model in which the cost and complexity of installing, configuring, and managing the infrastructure is hidden from you. All you do is provision and configure the service. This means that the total cost of ownership can be lower over the lifetime of your application. The table shown here summarizes several advantages to a service vs. a hosted do-it-yourself solution:


  Shared Caching Hosted Do-it-Yourself

Dedicated memory

With Shared Caching, you are guaranteed the complete cache size at all times.

With a hosted caching solution, you can only use a part of the instance memory. Part of the memory is consumed by the operating system and other running processes.

Ease of use

Shared Caching handles of all the service details. All you have to do is use it.

With a hosted caching solution, you are responsible for installation and configuration in addition to ongoing management and maintenance.


Because Shared Caching is distributed, it can scale with the demand of your applications. You visit the portal and increase the memory size.

With a hosted caching solution, your application scale is limited by the capacity of the compute instance that hosts your cache. You must manually add and prepare additional instances.

Service Level Agreement (SLA)

We promise uptime and availability of the service in our SLA.

With a hosted caching solution, you are not guaranteed any uptime.

What if I need a different size cache or bigger size cache than the options that you are providing?

You can sign up and provision more than one cache. A combination of caches adds up to sizes that differ from those that are provided out-of-the-box. It is up to you to select the most cost effective option for your needs.

Can I change the cache size after I signed up and provision it?

Yes. You can upgrade or downgrade the cache size that you signed up for after you start to use the cache. If you upgrade to a bigger size cache, existing data in the cache remains intact. If you downgrade, the cache eviction policy removes the least recently accessed data in the cache if necessary.

From a cost perspective, the service is billed monthly based on the cache size you are signed up for. But the charge is calculated on a daily basis. When upgrading or downgrading between cache sizes, you are charged for that month according to the portion of days you were signed up for each cache size.

For example, consider if you were signed up for the 128MB ($45/month) cache for 10 days of the month, and then upgraded to the 256MB ($55/month) cache size for the rest of the 20 days during that month. You pay the total of 45/(10/30) + 55/(20/30) = $51.67 for that month.

What type of data can I store in the cache?

You can store any kind of data in the cache. The only requirement is that the data is serializable. This includes but is not limited to:

  • Common Language Runtime (CLR) objects

  • Rows

  • XML

  • Binary data

You can programmatically interact with the cache by using the simple .NET Framework API. You can also configure the cache as a provider for ASP.NET session state and page output.

How does Windows Azure Shared Caching relate to on-premises AppFabric Caching?

They are built on the same underlying technology platform. Windows Azure Shared Caching is a service that you can use on Windows Azure. For Windows Azure Shared Caching, Microsoft has created the entire underlying cache infrastructure for you and automated the provisioning and management of the cache on Windows Azure). For more information, see About Windows Azure Shared Caching.

Does Windows Azure Shared Caching have any usage quotas?

Once you provision a cache of a certain size, Windows Azure Shared Caching limits the amount data you put in the cache to that size. If you try to put more data into the cache than the size you provisioned, Shared Caching automatically removes data to make space. The data deletion process is asynchronous and follows the least recently used (LRU) policy. The process also runs in a controlled manner to achieve maximum efficiency. This intermittent process means your application might temporarily have more data in the cache than the size for which you signed up. But the system will soon correct the situation and delete data from your cache to keep your cache size within the provisioned size.

As with other services in the Windows Azure platform, in order to make sure there is fair usage of resources, the service might enforce limitations based on the number of transactions being made against the cache, the total bandwidth being consumed, or the number of concurrent connections used. If you exceed the limitations enforced by the service, your application receives an exception that specifies the exceeded quota limit.

The following table provides general guidance that can help you plan your usage of the service. This guidance is a high-level estimate and is subject to revision in the future.


Cache Size Transactions Per Hour Bandwidth MB Per Hour Concurrent Connections

128 MB




256 MB




512 MB




1 GB




2 GB




4 GB




For a detailed explanation of these quotas and how to plan properly for Cache, see Capacity Planning for Caching in Windows Azure.

How does Shared Caching differ from Caching on Windows Azure roles?

In-Role Cache on Windows Azure Cache introduces a new ability to host Cache within your Windows Azure roles. The cache is distributed across the instances of the role that hosts the cache. The main difference from Shared Caching is that role-based In-Role Cache is private to your hosted service. With Shared Caching, Cache is offered as a multitenant service. As a result, role-based In-Role Cache does not have the quotas that a shared service must have. The size of the cache depends on several variables. First, the size is dependent on the number of running instances of the role that has In-Role Cache enabled. It is also dependent on the size of those virtual machines and the percentage of memory that is devoted to In-Role Cache on the role. In-Role Cache on Windows Azure roles supports additional features, such as high availability, regions, notifications, and multiple named caches. Because it is part of your cloud service, In-Role Cache on roles should also have improved performance over Shared Caching.

For more information on the differences, see Overview of Caching in Windows Azure.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

© 2014 Microsoft. All rights reserved.