skip to Main Content

What is Azure Redis Cache?

Redis Cache is a well know caching technology and you can run it in Azure as a fully managed service. Being a fully managed service, you do not need to worry about provisioning the underlying infrastructure. If you have experience with on-premises cache servers you will know how difficult it is to build a 3-node load-balanced cache or worry about patching it. So as a Managed Service it leaves you to concentrate on building solutions that require a caching service.

There are many patterns out there where a cache is important. These may include cache-Aside, write-behind, write-through, read-through and refresh ahead. Whichever pattern you decide, Azure is a great place to build out the services.

Azure Redis Cache Tiers

There are many tiers to select from, Azure gives you a great choice.

Azure Redis Cache Tiers

If you need geo-replication capability then basic and standard are not high enough for you. Naturally, as you go up the tiers, the higher the cost.

Many enterprises will opt for premium onwards where the combination of horizontal scaling, private link, data persistence and geo-replication are key requirements for projects. The underlying architecture is complex and fully built by Microsoft and looks like the below for premium tiers onwards.Azure Redic Cache Architecture

When using the premium tier, you can actually choose between 1-3 Availability zones, many will opt for 3 zones which does make sense for maximum resiliency.

Building a Redis Cache

Within the Azure Portal, find Azure Cache for Redis.

Azure Cache for Redis

Fill in the basics (the location should be where your app is):Fill in the basics

Click on the pricing details hyperlink. This is where we can select the tier you want, which we discussed in the earlier part of the blog.

Select the tiers

You can see quite a difference in pricing from 53GB cache to 120GB cache. Important note, the basic tier should never be used for production.

From a networking perspective, you will likely opt for a private link. The ability to connect with a private IP for backend applications is important. Networking

The next section is about the build.Redis version

SystemLet’s discuss this section. If you’re using the premium tier, this means you have the ability to increase shard counts. The above image shows 2 shard counts meaning 12GB cache available, this will increase costs. Obviously, the main benefit is having more GBs but it also gives you the ability to continue operations when a node is experiencing failures or is unable to communicate with the rest of the cluster allowing for more throughput capability. You can have up to 10 shards in the cluster.

Also, notice for more availability, I decide to use 3 availability zones, you can actually select 1 or 2. If you opt for a persistent storage strategy, then you need Azure Storage and ideally, you will want to access that without keys but via Managed Identity. Managed Identities are an extremely powerful concept where we no longer need to manage credentials between connecting cloud services and with no extra costs.

Data Persistence

Why would you want to persist data? If a complete hardware failure occurs and all caches are offline, we use the persistent storage to reconstruct it from the most recent snapshot, this is called RDB persistence, there is something else called AOF where all writes are saved to a log and rebuilt from that. Check out this document for an in-depth analysis of the pros and cons:

The data persistence screen is shown below.Data Persistence

Some important points regarding data persistence:

  1. You can’t enable both types, only one at a given time.
  2. Don’t forget the logged data within the storage account has associated costs assigned to it.
  3. If you are dealing with high throughput data then you will probably want your storage account to be premium tier.
  4. RDB files are backed up to storage are stored in the form of page blobs.

Now we are ready to deploy and create the cache.

Deployment in progress

You can build many different applications for your Azure Redis Cache service which includes .NET, ASP.NET, Java, Node JS, Python and even Rust apps. The prerequisites to build these apps are that you need to get the hostname, port number and access keys which you can find within the Azure portal under the settings section.

Access Keys

Please see the following example from Microsoft documentation:

You can confirm that Redis is online and running via the Redis console in Azure.webcacheas

Click it and issue the INFO command.

INFO command

Tips for Using Azure Redis Cache

Here are some general tips when using Azure Redis Cache

  1. The location of the Redis Cache service should be close to your application.
  2. Data structures within Redis mean that larger key-value sizes lead to fragmentation of memory space. And these larger memory requirements mean more network data transfer. Redis states to use 100KB maximum.
  3. Creating connections is expensive (can cause latency) so reuse connections or at least close older ones before releasing them.
    1. You should be thinking about expiration times and expiration sliding strategies.
  4. Some Redis commands are single threaded so use them with caution, for example, KEYS command may ruin performance.
  5. You need to cater for possible failover issues. An unplanned failover might happen because of hardware failure, network failure, or other unexpected outages to the primary node. Developers should use the runtime maintenance notifications on a publish/subscribe (pub/sub) channel called AzureRedisEvents. Many popular Redis client libraries support subscribing to pub/sub channels. Receiving notifications from the AzureRedisEventschannel which is usually a simple addition to your client application.
  6. Consider tweaking memory policies to improve system responsiveness. There are 3 key settings. These are called max memory policy, max memory reserved and max memory fragmentation memory-reserved. Microsoft covers these settings in depth here:


As you can see from this blog post, Azure Redis is a very mature cache technology which can be built with ease via the Azure Portal. Well-built integrations with components such as Azure Storage, private link, managed identity and support for various languages means building a cloud-native solution at a cost-effective price point is very much possible

If you’re interested in Ballard Chalmers helping you implement in Azure Redis Cache, just get in touch.



Our Azure Professional Services cover development outsourcing, consultancy, resourcing and support so that we can work with you at any point of the development lifecycle. Get support and guidance to know your development is optimised and will meet your business goals within budget.Find Out How »
Post Terms: Azure Redis Cache | cache

About the Author

Arun Sirpal, writing here as a freelance blogger, is a four-time former Data Platform MVP, specialising in Microsoft Azure and Database technology. A frequent writer, his articles have been published on SQL Server Central and Microsoft TechNet alongside his own personal website. During 2017/2018 he worked with the Microsoft SQL Server product team on testing the vNext adaptive query processing feature and other Azure product groups. Arun is a member of Microsoft’s Azure Advisors and SQL Advisors groups and frequently talks about Azure SQL Database.

Education, Membership & Awards

Arun graduated from Aston University in 2007 with a BSc (Hon) in Computer Science and Business. He went on to work as an SQL Analyst, SQL DBA and later as a Senior SQL DBA, DBA Team Lead and now Cloud Solution Architect. Alongside his professional progress, Arun became a member of the Professional Association for SQL Server. He became a Microsoft Most Valued Professional (MVP) in November 2017 and has since won it for the fourth time.

You can find Arun online at:

Back To Top
Contact us for a chat