Azure Cache for Redis: Instance Creation & Configuration

1. Preparing for Creation: Key Decisions

Before we jump into the Azure Portal, let's quickly review the primary settings you'll need to configure. These were introduced in the last lesson, but now you'll be applying them.

• Resource Group: A logical container for your Azure resources. You should use the same resource group you've been using for this course to keep everything organized.
• Region: The Azure region where your cache will be hosted. It's a best practice to co-locate your cache and your application in the same region to minimize network latency.
• Pricing Tier (SKU): This is a critical choice.
  • Basic: Single node, no replication. Ideal for development, testing, and non-critical workloads.
  • Standard: A replicated cache with a primary and secondary node for high availability. This is the recommended minimum for production.
  • Premium & Enterprise: Offer advanced features like clustering, data persistence, and enhanced security.
• Cache Size: Determines the amount of memory available. This ranges from 250 MB to multiple terabytes, depending on the tier.

For today's exercise, we will use the Basic C0 (250 MB) tier. It's the most cost-effective option and is perfectly suited for our learning objectives.

2. Hands-On: Creating the Cache in the Azure Portal

It's time to create the resource. The most straightforward way to start is through the Azure Portal. The following reading from Microsoft Learn provides a detailed, step-by-step guide that we will follow.

As you follow the guide, use these specific settings for your new cache:

On the Basics tab:

• Subscription: Your Azure subscription.
• Resource group: Select the one you've used for previous lessons (e.g., az204-learn-rg).
• Name: Give it a globally unique DNS name. Something like az204-cache-<your-initials>-<date> is a good practice. For example: az204-cache-sa-20231027.
• Region: Choose a region close to you.
• Cache SKU: Basic.
• Cache size: C0 (250 MB Cache).

The Basics tab in the portal will look similar to this:

On the Networking tab:

• For this exercise, you can leave the Connectivity method as Public endpoint. In a production environment, you would use a Private Endpoint to ensure the cache is only accessible from within your virtual network, which is a more secure approach.

On the Advanced tab:

• Non-TLS port: Leave this disabled. For security, all client connections should use TLS encryption.
• Microsoft Entra Authentication: Leave this enabled. This is the modern, recommended approach for authentication. It allows for passwordless access using identities, which we'll explore in a later module.
• Redis version: Latest (6).

The Advanced tab will look like this, showing the authentication and version settings:

After configuring these tabs, proceed to Review + create and then Create. The deployment will take several minutes. You can monitor its progress on the deployment page.

If you'd like a quick video walkthrough of this process, the following clip provides a good visual summary.

Once the deployment is complete and the resource status shows as Running, your cache is ready to use!

3. Exploring Your New Cache Instance

With the cache provisioned, let's familiarize ourselves with its settings in the Azure Portal. Navigate to the resource you just created.

Retrieving Connection Information

To connect an application to your cache, you need two key pieces of information: the host name and an access key (connection string).

1. Host Name: On the Overview page of your cache resource, you will find the Host name. This is the DNS address of your cache (e.g., az204-cache-sa-20231027.redis.cache.windows.net).
2. Access Keys:
   • In the resource menu on the left, under Settings, select Access keys.
   • Here you will find two keys: a Primary and a Secondary. These are long-lived connection strings that grant full access to your cache. The secondary key exists to allow for key regeneration without downtime.
   • For now, copy the Primary connection string. You will need it in the next lesson.

This short video clip clearly shows where to find and copy the connection string.

Key Configuration Settings

After creation, you can still modify many settings. Let's look at one of the most important ones: memory management.

From the reading, you learned about eviction policies. When your cache runs out of memory, it needs a strategy to decide which items to remove (evict) to make space for new ones. The default policy is volatile-lru, which means it will remove the "least recently used" key among all keys that have an expiration time set. Understanding and choosing the right eviction policy is crucial for optimizing cache performance for your specific application's access patterns.

Conclusion

Congratulations! You have successfully provisioned and configured your first Azure Cache for Redis instance. You now have a running cache in the cloud, ready to be used by an application.

Key Takeaways:

• You can create an Azure Cache for Redis instance through the Azure Portal by defining its resource group, name, region, and pricing tier.
• For development and learning, the Basic tier is the most economical choice.
• Security best practices include disabling the non-TLS port and using modern authentication methods like Microsoft Entra ID.
• After creation, you can retrieve the Host name and Access Keys (connection strings), which are required for a client application to connect.
• You can configure advanced settings post-deployment, such as the memory eviction policy, to fine-tune the cache's behavior under memory pressure.

Next Steps

You've set up the infrastructure. In the next lesson, we will get into the code. We will address the learning outcome: "Connect to Azure Cache for Redis from a .NET application using the StackExchange.Redis library." You will write C# code to connect to the cache you just created, store data, and retrieve it. This is where you'll see the direct performance benefits of caching in action.