I recently spun up my first Azure Managed Redis (AMR) instance. The create wizard looks simple — five tabs, a handful of checkboxes — but several of those checkboxes are one-way doors, and a couple of them will silently break your applications if you get them wrong.
This is the walkthrough I wish I'd had. Every field, what it does, and what I'd actually pick.
First, a clarification that matters: Azure Managed Redis is not the same product as Azure Cache for Redis. AMR is the newer service replacing the Enterprise tiers. A lot of the blog posts and Stack Overflow answers you'll find describe the old Premium tier behaviour, and some of it is flat-out wrong for AMR. Persistence is the big one — more on that below.
The Advanced tab (where all the interesting decisions live)
Modules
Optional Redis capabilities:
| Module | What it gives you |
|---|---|
RedisJSON |
Store and query JSON documents natively |
RedisTimeSeries |
Time-series data with downsampling |
RedisBloom |
Bloom filters, count-min sketch, top-k |
RediSearch |
Secondary indexes + vector search |
RediSearch is the one to think hardest about — it's what turns Redis into a vector store for RAG workloads.
The catch: modules can only be set at creation time. You cannot add one later without rebuilding the instance. But they also consume memory and CPU, so don't enable all four "just in case."
My pick: only what I'll use in the next quarter. If vector search is anywhere on the roadmap, tick RediSearch now.
Non-TLS access only
Leave it unchecked. Checking it opens plaintext port 6379. There is no good reason to do this in production, and Entra authentication won't work without TLS anyway.
Eviction Policy
What Redis does when memory fills up.
- No Eviction — writes start failing with OOM errors once full
- volatile-lru — evicts least-recently-used keys that have a TTL
- allkeys-lru — evicts least-recently-used keys, TTL or not
The portal defaults to No Eviction, which is the right default for a data store and the wrong one for a cache. If you're building a cache, you want it to shed cold data gracefully rather than start throwing errors at 3am.
My pick: volatile-lru for a cache. No Eviction only if losing keys is genuinely unacceptable.
High availability
Adds a replica in a second availability zone with automatic failover.
Disabling it roughly halves your cost. It also means a single node failure is total data loss with no failover. For anything production-facing, keep it Enabled.
Clustering Policy
How clients talk to the instance:
- OSS — the client discovers shards and talks to each node directly. Best throughput and latency, but needs a cluster-aware client, and multi-key operations must land in the same hash slot.
- Enterprise — a single proxy endpoint that behaves like one Redis server. Slightly higher latency, far less friction.
- Non-clustered — smaller SKUs only.
StackExchange.Redis handles OSS fine. But if you're pointing legacy code, low-code connectors, or anything you don't fully control at this instance, Enterprise will save you debugging time.
My pick: Enterprise unless I've explicitly tested OSS with every client.
Data Persistence — read this part carefully
Three options: No Persistence, RDB, AOF.
- RDB takes a point-in-time snapshot of the whole dataset on a configurable interval. Cheap in steady state. If your interval is one hour and you lose the instance at minute 59, you lose 59 minutes of writes.
- AOF appends every write operation to a log, flushed once per second. Tiny loss window, but a real throughput cost. Note that with HA enabled, AOF runs on the replica shards only — primaries have appendonly disabled to avoid the write overhead.
Now the part that surprises everyone:
In AMR, persisted data is written to a managed disk attached to the instance. The location is neither configurable nor accessible to you. There is no blob to browse. No .rdb file to download. No restore-point picker.
Persistence exists so that if a catastrophic event takes out both the primary and the replica, the instance rebuilds itself automatically. It is a self-healing mechanism, not a backup product.
Two things follow from this:
- Persistence is not a backup and not point-in-time recovery. If a buggy job writes corrupted data into Redis, the corruption gets faithfully persisted too.
- Persisted files cannot be imported into another instance. To move data between caches — or to get an actual file you can hold — you use the separate Import/Export feature, which writes RDB files to a blob container you specify. If you want real backups, script periodic exports via CLI or PowerShell on a schedule.
The old Premium tier of Azure Cache for Redis did write RDB into your own storage account. AMR does not. That's the single most common piece of stale information out there.
My pick: No Persistence for a pure cache — the data is regenerable and I'd rather have the throughput. RDB if a cold start would hammer the backing database hard enough to matter, or if I'm holding sessions and don't want to force everyone to re-authenticate after an outage.
Persistence is changeable after creation. Not a one-way door.
Customer-managed key encryption at rest
Leaving this unchecked does not mean "unencrypted."
AMR encrypts persistence data and OS disks with Microsoft-managed keys by default. The CMK option just wraps those keys with one from your own Key Vault. The difference isn't whether data at rest is encrypted — it's who controls the key material.
CMK gives you rotation control, access auditing, and the ability to revoke (which makes the instance inaccessible — that's the point for some threat models). The cost is operational: it requires a user-assigned managed identity plus a Key Vault with both purge protection and soft delete enabled. Delete that key or break the identity's access, and your instance breaks.
Also worth noting: if you chose No Persistence, there's very little at rest to encrypt in the first place.
My pick: unchecked, unless a client contract or auditor explicitly requires customer-controlled keys. It's addable later.
Defer automatic major Redis version updates (preview)
Lets you postpone major engine upgrades so they don't land in the middle of a release window. Useful if you need change control. You still have to take them eventually.
Access Keys Authentication — the one that will break your apps
This is the field most likely to cause a bad afternoon.
Unchecked means Entra ID authentication only. No access keys, no password= in a connection string. This is now AMR's default — managed identity is enabled when you create a new instance, and Microsoft is deliberately steering people off shared secrets.
If you go Entra-only, here's what's involved:
- The client acquires an Entra token (scope
https://redis.azure.com/.default) and uses it in place of the password. Username is the object ID of the principal. -
Tokens expire. The client must refresh before expiry and re-send
AUTH, or connections drop. For .NET, use theMicrosoft.Azure.StackExchangeRedispackage — don't hand-roll this. - Entra auth is TLS only.
- A valid token alone isn't enough. You must separately authorize the identity on the Redis side: Data Access Configuration → new Redis User → Data Owner / Data Contributor / Data Reader. No grant, no access.
- Entra groups aren't supported. You add individual users or service principals. For a team of any size, that's a real operational annoyance.
Use a managed identity wherever the caller runs inside Azure. A service principal / app registration is only needed for callers outside Azure. And note that the authorization is not API permissions on the app registration — there's nothing to configure on that side.
Two gotchas:
- Toggling this setting terminates all existing client connections, regardless of which auth method they were using. Do it in a window, with retry logic in place.
- On geo-replicated instances you must unlink → disable keys → relink.
My pick: tick it at creation. Get everything connected and working, migrate app-by-app to Entra, then disable keys. It's changeable post-creation — unlike modules.
Quick reference: what's a one-way door?
| Setting | Changeable later? |
|---|---|
| Modules | ❌ No — creation only |
| Clustering policy | ❌ No |
| Persistence | ✅ Yes |
| Eviction policy | ✅ Yes |
| High availability | ✅ Yes |
| CMK | ✅ Yes |
| Access keys | ✅ Yes (but kills live connections) |
| SKU / size | ✅ Yes |
After it's created: the things I wish I'd known on day one
Redis is a flat key → value store. No tables, no joins, no queries. You must know the key to get the value. Your key naming convention is your schema — something like app:entity:id:field.
TTL is the whole game. Every cache key gets an expiry, or you leak memory until eviction kicks in.
It's single-threaded. One slow command blocks every other client. Which is why:
- Never run
KEYS *in production. UseSCAN. - Never store multi-megabyte values.
-
FLUSHALLhas no undo.
Redis is not the source of truth. Your code must work correctly when the cache is completely empty. Test that path.
Watch for cache stampede. A thousand requests miss simultaneously and all hammer the database at once. Add jitter to your TTLs.
On the .NET side: ConnectionMultiplexer is a singleton. Register it once in DI. Creating one per request is the single most common Redis mistake and it will exhaust your connections. If you want the easy path, AddStackExchangeRedisCache() gives you IDistributedCache with straightforward get/set/TTL semantics.
The pattern you'll use 90% of the time is cache-aside: read from Redis, return on hit; on miss, read from the database, write to Redis with a TTL, return. Write that helper once and reuse it everywhere.
Finally, monitor these four things and alert on them: memory used %, evicted keys, cache hit ratio, and server load. Memory above 80% or evictions climbing above zero means it's time to scale or shorten your TTLs.
The short version
Don't overthink the sizing — that's changeable. Do think hard about modules and clustering policy, because those aren't. Leave access keys on until your clients are ready for Entra. And remember that persistence in AMR is self-healing, not a backup.
Top comments (0)