Redis Caching in the Cloud: Managed vs Self-Hosted

What the Cache Is Actually For

A cache exists to stop work from happening twice. That sounds obvious, and yet most caching problems come from forgetting it and treating Redis as a general purpose datastore that happens to be quick.

The useful test is a question: if this data vanished right now, would the system still be correct? If the answer is yes, and the only consequence is slower responses while it refills, you are caching. If the answer is no, you are storing, and storing in a cache needs a different set of decisions.

Redis handles both roles, which is precisely why the line gets blurred. It is an in-memory data structure server with strings, hashes, lists, sorted sets, streams and more, and it can persist to disk. But memory is the expensive resource in any cloud, and a cache that has quietly become the only copy of something is the origin of a specific kind of bad afternoon.

Decide which role each instance plays and write it down. Session stores, rate limit counters, job queues and caches have different durability requirements, and running them on one instance with one policy serves none of them well.

Three Patterns and Their Failure Modes

Cache-aside is the default and the one most applications use. The code checks the cache, and on a miss it reads the database, writes the result back, and returns it. It is simple and tolerant: if the cache is unavailable, everything still works, more slowly.

Its weakness is the stampede. When a popular key expires, every concurrent request misses at once and all of them hit the database together. The fixes are to let one request rebuild while others serve the stale value, or to add a small random spread to expiry times so keys in a group do not all expire in the same second.

Write-through updates the cache as part of the write path, so the cache is never stale. It costs write latency and it makes the cache a dependency of writes, which is a meaningful loss of resilience.

Write-behind acknowledges the write into the cache and persists asynchronously. It is fast and it is the pattern most likely to lose data, so reserve it for things you can genuinely afford to lose, such as view counters.

Whichever you use, invalidation is where the bugs live. Prefer short expiry times over clever invalidation logic wherever correctness permits it, and include a version or a deploy identifier in key names so a release can retire an entire generation of keys without a flush.

Eviction Is a Design Decision

Redis holds data in memory, so the question of what happens when memory runs out is not an edge case. It is a configuration choice you must make explicitly.

Set maxmemory to a value below the machine's RAM, leaving headroom for the operating system and for the copy-on-write overhead that snapshotting creates. Then choose an eviction policy.

The default is noeviction, which surprises people who assumed a cache would simply discard old entries. If you are caching, say so in the configuration.

Then watch the right numbers. The hit rate tells you whether the cache is earning its keep, the evicted key count tells you whether it is too small, and memory fragmentation tells you whether the reported usage matches reality. All three are in redis-cli INFO memory and INFO stats, and they belong in your dashboards alongside everything else, as the monitoring guide sets out.

Persistence, and Whether You Want It

Two mechanisms exist and they are not alternatives so much as different trade-offs, which you can combine.

Snapshotting writes a point-in-time dump at intervals you configure. It is cheap during normal operation and restores quickly, but a crash loses everything since the last snapshot. The fork it performs to take the snapshot also briefly increases memory usage, which is the main reason to leave headroom under maxmemory.

The append-only file logs every write command and replays them on restart, with a configurable flush policy trading durability against speed. It loses far less on a crash and it makes restarts slower for large datasets.

For a pure cache, turning both off is a legitimate and often correct choice. A cache that restarts empty simply refills, and disabling persistence removes the fork pauses entirely. For a session store or a queue, enable the append-only file and understand that you are now running a database with the operational duties that implies.

The configuration options and their exact semantics are documented in the Redis persistence guide, which is worth reading before choosing rather than after an incident.

Managed Service or Your Own Instance

Self-hosting Redis is genuinely easy for a single instance. Install the package, set maxmemory and a policy, bind it to the private network, set a password, and it will run for a long time without attention. That is a real advantage over most databases and it is why so many teams do it.

The difficulty arrives with high availability. Automatic failover means Redis Sentinel or a cluster, both of which have subtleties around split brain, client library support and failover timing that repay careful reading. That is the point where a managed service stops looking like a convenience and starts looking like a sensible purchase.

The managed options are widely available: Amazon ElastiCache and MemoryDB, Azure Cache for Redis, Google Memorystore, and compatible managed caches on DigitalOcean, Linode, Scaleway and others. They give you failover, patching, backups and metrics, and they take away shell access and some configuration control.

One more factor has entered the decision recently. The licence of the original project changed, prompting the Linux Foundation fork Valkey, which several providers now offer in place of or alongside Redis. The wire protocol is the same and existing clients work, but check which engine a managed service actually runs if licensing matters to your organisation.

A practical split many teams land on: managed cache in production for the failover, self-hosted instances in staging and development where an outage is an inconvenience. An AWS account covers the first through ElastiCache, described in the ElastiCache documentation, while a DigitalOcean account offers a simpler managed caching product; the AWS and DigitalOcean comparison covers the wider difference in approach, and the general decision is unpacked in managed databases versus self-hosted.

Locking It Down

Redis was designed for a trusted network and its defaults still reflect that heritage. An exposed instance is found and abused quickly, and it has historically been a favourite target precisely because so many are left open.

• Bind to the private address only. Set bind explicitly and confirm with ss -ltnp that nothing is listening on a public interface. The private network setup is covered in private networking between cloud servers.
• Require authentication. Set a long password, or better, create per-application users with the access control list so each one can run only the commands it needs.
• Rename or disable dangerous commands. FLUSHALL, CONFIG and KEYS rarely belong in an application's vocabulary.
• Keep protected mode on unless you have deliberately arranged authentication and network isolation another way.
• Use TLS where the traffic crosses anything you do not fully control.

Never run KEYS against a production instance either. It scans the entire keyspace while blocking every other command; SCAN exists for that purpose and iterates without stopping the world.

Key Takeaways

• Decide per instance whether you are caching or storing, and configure durability to match.
• Cache-aside is the resilient default. Guard against stampedes with jittered expiry and single-flight rebuilds.
• Set maxmemory and an eviction policy explicitly. The default refuses writes rather than evicting.
• Disable persistence for a pure cache; enable the append-only file when the data has to survive a restart.
• Self-host a single instance happily, and buy a managed service when you need automatic failover.
• Bind privately, authenticate, and keep KEYS and FLUSHALL out of production.