Skip to main content
In this lesson we cover AWS MemoryDB for Redis — a managed, Redis-compatible, in-memory data store designed to act as a durable primary datastore rather than only a cache. Learn when to choose MemoryDB, how it differs from Amazon ElastiCache, and the core components, scaling and consistency characteristics, and common use cases. MemoryDB keeps your dataset in memory for microsecond reads and low single-digit millisecond writes, while providing durability through a distributed, multi‑AZ transactional log and automated snapshots. This makes it a good fit when you need Redis performance and data durability under a managed service.
Slide titled "Why do we need MemoryDB?" showing a flow diagram: a client laptop icon sends requests to server icons, which in turn communicate with an Amazon MemoryDB for Redis icon. The graphic illustrates using MemoryDB as a fast in-memory datastore between servers and applications.

​
What MemoryDB provides

  • Durable, Redis-compatible in-memory dataset with automatic multi‑AZ replication and snapshots.
  • Microsecond read latency and low single-digit millisecond writes for high-throughput, low-latency workloads.
  • Managed operational features: automatic failover, backup snapshots, parameter groups, encryption at rest and in transit, and IAM/ACL integration.
  • Simplifies architecture by replacing a separate cache + primary database pattern when Redis can be your primary store.

​
Core concepts and components

MemoryDB persists a transactional log across multiple Availability Zones and can take automatic snapshots. Because the dataset is memory-resident, restart and recovery are optimized for fast warm-up compared with disk-only stores.
A diagram of Amazon MemoryDB for Redis showing a client connecting to a MemoryDB cluster with a Primary node, Replica nodes, and a Multi‑AZ transactional log. Arrows indicate writes going to the Primary and reads served by the Replicas.

​
Consistency and scaling

  • Consistency
    • Strong consistency when reading from the primary (writes are confirmed on the primary).
    • Replicas are eventually consistent with the primary; read-after-write consistency is only guaranteed if you read from the primary.
  • Scaling
    • Read scaling: add replicas to a shard to offload read traffic.
    • Write scaling: add more shards (horizontal partitioning) to increase write capacity.
    • Vertical scaling: change node types to increase memory or CPU per node.
When designing for scale, partition keys and shard count planning are essential to balance write throughput across shards. Use replicas to horizontally scale read-heavy workloads while keeping an eye on replication lag for consistency-sensitive reads.

​
Typical use cases and benefits

  • Web & mobile applications: user sessions, profiles, feature flags, and low-latency personalization.
  • Gaming: real-time player state, leaderboards, session management, and high-concurrency updates.
  • Streaming & analytics: counters, real-time counters, and transient state for high-throughput ingest pipelines.
  • When you want Redis data structures (hashes, lists, sets, sorted sets) as a primary store with persistence and managed operations.
Choose MemoryDB when you need an in-memory, Redis-compatible data store with durability (multi‑AZ transactional logs and snapshots) and plan to use Redis as the primary datastore. Choose ElastiCache when you want a cache in front of an existing primary database and do not require the durability guarantees MemoryDB provides.
MemoryDB stores the working dataset in memory. Cost and instance sizing are important: ensure your dataset fits the chosen node types and plan for memory growth and backup retention. Also evaluate replication lag if your application requires strong read-after-write consistency and choose to route critical reads to the primary.

​
When to choose MemoryDB vs ElastiCache (quick comparison)

  • MemoryDB
    • Use when Redis is the primary data store and you require durability, multi‑AZ replication, snapshots, and managed failover.
    • Best for stateful, low-latency applications that need persistence and operational simplicity.
  • ElastiCache for Redis
    • Use when Redis is a cache tier in front of an existing durable primary database.
    • Best for simple caching patterns where durability across AZ failures and long-term persistence are not essential.

​
Summary and key takeaways

  • AWS MemoryDB for Redis is a managed, durable, in-memory, Redis-compatible primary datastore.
  • It provides microsecond reads, millisecond writes, multi‑AZ durability, automatic failover, ACLs, and encryption.
  • Scale reads with replicas and writes with additional shards; tune node types and parameter groups for performance and cost.
  • Evaluate MemoryDB when you want Redis performance with persistence guarantees; choose ElastiCache when you only need a caching layer.
A presentation slide titled "Summary MemoryDB" with a teal left panel and two numbered points describing AWS MemoryDB for Redis. The text highlights its Redis‑compatibility, durable in‑memory architecture and ultra‑low latency (microsecond reads, millisecond writes).

​
References

Watch Video