A managed cache is usually the first service a growing system adds after its database (Why cache?), and on every cloud it's a managed Valkey, Redis or Memcached. The engines are nearly identical. What differs is everything around them: whether you size nodes or pay per request, what happens when a node fails, whether data survives a restart, and, since 2024, which licence the engine is under. That last one has changed the product names on all three clouds.
This page builds on Where caches live, Cache-aside and the Redis lesson.
Side by side
| AWS | Google Cloud | Azure | Self-hosted | |
|---|---|---|---|---|
| Services | ElastiCache for Valkey, Redis OSS or Memcached; MemoryDB as a durable primary database | Memorystore for Valkey, for Redis Cluster, and for Redis; Memorystore for Memcached is deprecated | Azure Managed Redis, replacing Azure Cache for Redis | Valkey, Redis, Memcached on your own machines |
| Shapes | Serverless (one endpoint, scales itself) or node-based clusters (you pick node size, shards and replicas) | Instances and clusters | Tiers sized by memory and performance, clustered by default | Whatever you build |
| Durability | A cache by default; MemoryDB and durable node-based Valkey (9.0+) write to a Multi-AZ transaction log | Cache | Cache | Snapshots and append-only files, if you configure them |
| You pay for | Serverless: GB-hours stored and ECPUs; node-based: node-hours | Instance or node capacity | Tier and size | Machines and people |