Creating and Configuring Azure Cache for Redis Instances

What is Azure Cache for Redis?

At its core, Azure Cache for Redis is a managed, in-memory data store based on the popular open-source software, Redis (which stands for REmote DIctionary Server). Because the data lives in memory rather than on disk, read and write operations are extremely fast, offering very low latency and high throughput. This makes it ideal for a variety of performance-critical scenarios.

Your extensive experience building software means you've likely encountered performance bottlenecks, often related to frequent or complex database queries. A cache acts as a high-speed buffer for frequently accessed data, reducing the load on your primary database.

To get a solid overview of Azure Cache for Redis and its benefits, watch the introductory part of the following video.

As the video mentions, common use cases beyond simple data caching include:

• Session State Storage: Storing user session data for web applications.
• Job & Message Queuing: Acting as a lightweight message broker.
• Real-time Analytics: Processing real-time data streams.

Tiers and Key Configuration Options

Azure Cache for Redis is offered in several tiers, each providing different levels of performance, features, and availability. Choosing the right tier is crucial as it impacts cost and capabilities.

• Basic: A single-node cache with no SLA. Best for development, testing, and non-critical workloads.
• Standard: A two-node (primary/replica) setup providing high availability with an SLA. This is the recommended minimum for production.
• Premium: Builds on the Standard tier with advanced features like data persistence (snapshotting to storage), clustering (sharding data across multiple nodes for higher throughput), and enhanced security with VNet integration.
• Enterprise / Enterprise Flash: These higher-end tiers are built on Redis Enterprise software and offer powerful capabilities like active geo-replication and additional Redis modules (e.g., RediSearch, RedisJSON).

The following video from John Savill offers a deeper technical dive into the architecture and configuration options, which will be valuable for your understanding.

When you create a cache instance, you must configure several key options. Many of these, like the SKU and networking model, cannot be easily changed later.

• SKU and Size: Determines the memory, CPU, network bandwidth, and available features.
• Networking: You can expose the cache via a public IP or, for better security, a Private Endpoint within a Virtual Network. As we saw with other services, private endpoints are the recommended practice for production.
• High Availability (HA): The Standard tier automatically provides a replicated node in a different fault domain for HA. In the Premium tier, you can use Availability Zones for even greater resilience.
• Data Persistence (Premium/Enterprise): You can configure the cache to periodically save its data to Azure Storage. This protects against data loss if the cache nodes restart. You can choose between:
  • RDB (Redis Database): Point-in-time snapshots.
  • AOF (Append Only File): Saves every write operation, offering better durability.

Creating a Cache Instance: Azure Portal

The most straightforward way to create your first cache is through the Azure Portal. The portal provides a guided, step-by-step UI for configuring all the necessary settings.

The image below shows the initial creation screen, where you define the basic properties of your cache.

For a complete guide, please review the official Microsoft documentation.

Creating a Cache Instance: Azure CLI

Given your experience with Azure DevOps, you'll find the Azure CLI to be a powerful and efficient way to manage resources. Creating an Azure Cache for Redis instance is a single command. This is a common task in automated deployment scripts.

The following article provides a concise example of using the Azure CLI.

Here is a typical az redis create command structure:

az redis create \
    --resource-group YourResourceGroup \
    --name YourUniqueCacheName \
    --location "East US" \
    --sku Standard \
    --vm-size c1

This command creates a Standard tier cache of size C1 (1 GB).

Retrieving Connection Information

Once your cache instance is deployed, your application needs a way to connect to it. The primary methods are:

1. Access Keys: A connection string that includes a password-like key.
2. Microsoft Entra Authentication: The more secure, passwordless method that leverages managed identities or service principals, similar to what you implemented for Key Vault.

For now, we'll focus on access keys, as they are simple to use for initial development and testing. You will learn how to retrieve these keys from the portal.

You'll notice the connection string has a format like: YourCacheName.redis.cache.windows.net:6380,password=...,ssl=True,.... This contains the host, port, and access key needed for authentication.

Conclusion

In this lesson, you've taken the first step into performance optimization with Azure Cache for Redis. You now have a solid understanding of what it is, the different service tiers available, and, most importantly, how to provision an instance using both the Azure Portal and the Azure CLI.

Key takeaways include:

• Azure Cache for Redis is a managed, in-memory key-value store that significantly improves application performance and scalability.
• The service is offered in Basic, Standard, and Premium/Enterprise tiers, each with increasing features like high availability, data persistence, and clustering.
• You can create a cache instance using the visual workflow of the Azure Portal or the scriptable Azure CLI.
• After creation, you can retrieve access keys (connection strings) to allow your applications to connect to the cache.

In our next lesson, we will put this newly created cache instance to use. You will learn how to perform basic cache operations—specifically setting, getting, and deleting data—programmatically from a .NET application using the Azure SDK.