Azure Redis Cache is a managed data cache for your application.
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
Azure Redis Cache offers the following Network Security Options:
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.
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.
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.
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.
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.
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 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:
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.
This tier offers an SLA and provides a replicated cache. The data is automatically replicated between the two nodes — ideal for production-level applications.
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.
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