Azure Redis Cache

Azure Redis Cache is a high-throughput, low-latency, secure managed service based on the open-source in-memory Redis Cache.

It is commonly deployed in front of databases or storage as a way to speed up data access for applications or servers.

Protocol: TCP

Port: 6379 or 6380 (SSL)

Server name: {unique name}.redis.cache.windows.net

• Watch out for data loss. Never rely on a key being present. It may have expired or been evicted.
• Set expiry times to manage the content lifetime.
• Add jitter to spread database load that is varying the expiry time to spread the load on origin.
• Avoid caching large objects and consider breaking them down into smaller separate objects.
• Host Redis in the same region as the application
• As a security best practice, do not enable non-SSL port connection as all data that will pass through that connection would not be encrypted.

Azure Redis Cache offers the following Network Security Options:

• Public Endpoint is an internet-facing endpoint with a firewall
• Resource Inside the VNET with the Premium Redis Cache option

At this point, Redis Cache is not offering service or private endpoints.

Proper firewall configuration is critical, especially for basic or standard Azure Redis caches because they have public endpoints and are reachable through the internet.

Authentication

Shared keys are used to connect to Redis Cache. Shared, and there is no identity authentication.

Shared keys are like the root password of the cache. There are always two active keys.

Shared Keys need to be stored securely as they provide full access to the cache, like using Azure Key Vault.

Data Encryption

Encryption in Transit

Encryption in Transit is the security of the messages sent between the application and the cache itself. The transport-level security is provided by TLS, and out-of-the-box Redis uses TLS 1.2 but also supports TLS 1.1 for compatibility purposes. HTTP connections are disabled by default as this is not recommended.

Encryption at Rest

In-memory data is not encrypted, so Redis encryption is not implemented and is not supported on Azure.

With premiums tiers, the data can be persistent and backed up to an Azure Storage account. For this data at rest, encryption is enabled and by default uses Microsoft-managed keys.

Azure Redis Cache supports storing data in various formats. It supports data structures like Strings, Lists, Sets, and Hashes.

• Strings: Redis strings are binary safe and allow them to store any type of data with serialization. The maximum allowed string length is 512MB. It provides some useful commands like Incr, Desr, Append, GetRange, SetRange, and other useful commands.
• Lists: Lists are lists of Strings, sorted by insertion order. It allows adding elements at the beginning or end of the list. It supports constant time insertion and deletion of elements near the beginning or end of the list, even with many millions of inserted items.
• Sets: These are also lists of Strings. The unique feature of sets is that they don’t allow duplicate values. There are two types of sets: Ordered and Unordered Sets.
• Hashes: Hashes are objects containing multiple fields. The object allows storing as many fields as required.

Redis CLI

The Redis Command Line interface is a very popular command-line tool that is used to connect to Redis Cache and do several management operations.

Redis-benchmark utility

The Redis-benchmark utility is a special tool available through the Redis CLI that simulates some load on a Redis Cache instance. It runs a set of tests against the instance, simulating a number of connected clients, and gives a way to ensure that the cache is provisioned at the correct scale.

Redis-benchmark -q -n 10000

It is recommended to create a virtual machine that contains the Redis CLI and execute it from there.

stunnel

stunnel is a simple utility that will take non-SSL connections and tunnel them through SSL so that a tool like Redis CLI, which does not natively support SSL, can still connect through an SSL endpoint.

The Azure Redis Cache offers the following pricing tiers with different features, performance, and budgets:

Basic

The Basic cache is a single node cache that is ideal for development/test and non-critical workloads. There’s no SLA (Service Level Agreement is Microsoft’s commitment for uptime and connectivity). The basic tier has different options to choose from C0 to C6. The lowest option is C0, and this is in a shared infrastructure. Everything above C0 provides dedicated service, i.e., this does not share infrastructure with other customers.

• Minimal feature set
• A single node
• No SLA
• Development and test

Standard

This tier offers an SLA and provides a replicated cache. The data is automatically replicated between the two nodes — ideal for production-level applications.

• 2 Replicated nodes (primary-secondary pair)
• 99.9% availability
• 53 GB of memory
• 20000 clients

Premium

The Premium tier has all the standard features and, also, it provides better performance, bigger workloads, enhanced security, and disaster recovery. Backups and Snapshots and can be created and restored in case of failures. It also offers Redis Persistence, which persists data stored inside the cache. It also provides a Redis Cluster, which automatically shares data across multiple Redis nodes. Hence this allows creating workloads of bigger memory sizes and get better performance. It also offers support for Azure Virtual Networks, which gives the ability to isolate the cache by using subnets, access control policies, and other features.

• Redis cluster
• Low latency
• 99.95% availability
• 40000 clients

Enterprise

• The full Redis feature set
• 99.99% availability

Enterprise Flash

• Fast non-volatile storage

Several enhancements have been made to the passive geo-replication functionality offered on the Premium tier of Azure Cache for Redis. New metrics are available for you to better track the health and status of your geo-replication link, including statistics around the amount of data that is waiting to be replicated. With this feature, you can now initiate a failover between geo-primary and geo-replica caches with a single click or CLI command, eliminating the hassle of manually unlinking and relinking caches. A global cache URL is also now offered that will automatically update your DNS records after geo-failovers are triggered, allowing your application to only manage one cache address. 

Source: Public preview: Improved passive geo-replication for Azure Cache for Redis