Cargando...
Cargando...
Multi-AZ transactional memory database with Redis API compatibility and true durability
Amazon MemoryDB for Redis is a fully managed, Redis-compatible, durable, in-memory database service purpose-built for ultra-fast performance with microsecond read and single-digit millisecond write latency. Unlike ElastiCache for Redis (which is a cache), MemoryDB stores your entire dataset in memory while persisting it durably across a Multi-AZ transactional log, making it safe to use as your primary database. It supports the full Redis API, data structures, and commands, enabling a drop-in replacement for Redis workloads that require both speed and durability.
To serve as a durable, primary database (not just a cache) for applications that require ultra-low latency Redis-compatible access with strong consistency and data persistence guarantees across multiple Availability Zones.
Use When
Avoid When
Multi-AZ Transactional Log (Durability)
Every write is persisted to a distributed transactional log across multiple AZs before acknowledgment — the core differentiator from ElastiCache
Redis API Compatibility
Supports Redis data structures, commands, Lua scripting, pub/sub, streams, and sorted sets
Automatic Failover
Promotes a replica to primary automatically with no data loss due to the durable log
Encryption at Rest (KMS)
Enabled by default using AWS KMS
Encryption in Transit (TLS)
Supported for all client connections
Automated Snapshots & Backups
Up to 35-day retention, point-in-time recovery capability
Manual Snapshots
Can be retained indefinitely
Redis ACLs (Access Control Lists)
Fine-grained user-level access control
VPC Deployment
Required — no public endpoint option
CloudWatch Metrics & Monitoring
Full integration with CloudWatch for performance and operational monitoring
CloudTrail Integration
API calls logged for audit and compliance
Cluster Mode (Sharding)
Always enabled; horizontal scaling via shards
Read Replicas
Replicas per shard for read scaling and high availability
Online Scaling (Scale-out/in)
Add or remove shards and replicas with minimal disruption
Cross-Region Replication
MemoryDB does not natively support active-active cross-region replication; use application-level replication or Global Datastore is an ElastiCache feature, not MemoryDB
Serverless / Auto-scaling capacity
MemoryDB requires node type selection; it is not serverless — you choose instance types (r6g, r7g families)
IAM Authentication
Supports IAM-based authentication in addition to Redis ACLs
Microservices Primary Data Store
high freqContainerized microservices use MemoryDB as their primary durable data store for session data, user profiles, or real-time counters — replacing the need for a separate relational DB for low-latency key-value access
Serverless Real-Time State Management
high freqLambda functions read/write application state (e.g., rate limiting counters, idempotency keys, distributed locks) to MemoryDB — combining serverless compute with durable in-memory state
Compliance Monitoring and Audit
high freqCloudWatch monitors MemoryDB performance metrics (cache hits, replication lag, CPU); CloudTrail logs all management API calls for audit trails — critical for regulated industries tested in DEA-C01 and DOP-C02
Secure Credential Management
high freqRedis ACL user credentials stored and rotated in Secrets Manager; applications retrieve credentials dynamically — eliminates hardcoded passwords and supports automated rotation for compliance
Private Network Access
high freqMemoryDB deployed in private VPC subnets; access controlled via Security Groups; no public endpoints — aligns with defense-in-depth security architecture tested across all four certifications
Low-Latency API Response Cache with Durability
medium freqAPI Gateway + Lambda architecture uses MemoryDB to store computed results durably — unlike ElastiCache, data survives failures without cache warming, reducing cold-start latency spikes
Real-Time Leaderboard / Stream Processing State
medium freqKinesis consumers update sorted sets in MemoryDB for real-time leaderboards or aggregations; MemoryDB's durability ensures rankings survive node failures without reprocessing the stream
MemoryDB is a PRIMARY DATABASE, not a cache. When a question describes needing Redis API compatibility WITH durability and data persistence, choose MemoryDB over ElastiCache. The keyword triggers are: 'durable', 'no data loss', 'primary store', 'survive failures'.
Multi-AZ durability in MemoryDB is ALWAYS ON and non-optional. Every write is persisted to a Multi-AZ transactional log before the client receives an acknowledgment. This is the architectural mechanism that makes MemoryDB a true database, not just a cache. Exam questions testing 'which service guarantees no data loss on node failure' should be answered with MemoryDB.
For DEA-C01 and DOP-C02 security questions: MemoryDB supports encryption at rest (KMS, enabled by default), encryption in transit (TLS), Redis ACLs for fine-grained access control, VPC-only deployment, and CloudTrail logging. This combination makes it suitable for regulated workloads — mention all four controls together when answering compliance architecture questions.
MemoryDB = Durable Primary Database with Redis API. ElastiCache = Cache. When the scenario says 'no data loss' + 'Redis compatible' + 'primary store' → always choose MemoryDB. This single distinction resolves the majority of MemoryDB exam questions.
Multi-AZ transactional log is the MECHANISM of durability — every write is persisted across AZs before acknowledgment. This is always on, cannot be disabled, and is what makes MemoryDB a true database. Exam questions testing 'how does MemoryDB guarantee durability' → answer is the Multi-AZ transactional log.
Security stack for compliance questions (DEA-C01, DOP-C02): MemoryDB = KMS encryption at rest (default) + TLS in transit + Redis ACLs + VPC-only + CloudTrail audit logging. All five controls together make it suitable for regulated workloads.
MemoryDB ALWAYS runs in cluster mode (sharding is always enabled). This means multi-key commands that span multiple slots (e.g., MGET with keys in different hash slots) require hash tags to work correctly. Exam scenarios about migrating from non-cluster Redis to MemoryDB should flag this as a migration consideration.
MemoryDB supports automated snapshots with up to 35-day retention — the same as RDS/Aurora. This is a deliberate signal that MemoryDB is positioned as a database, not a cache. If an exam question asks which in-memory service supports point-in-time recovery with up to 35-day retention, the answer is MemoryDB.
Cost trade-off: MemoryDB costs MORE than ElastiCache for Redis because of the durability infrastructure. For CLF-C02 pricing questions, understand that the premium is justified by the Multi-AZ transactional log. If the use case is pure caching where occasional data loss is acceptable, ElastiCache is more cost-effective.
MemoryDB does NOT support Global Datastore (cross-region replication) — that is an ElastiCache for Redis feature. If a question requires multi-region active-active Redis, ElastiCache with Global Datastore is the answer, not MemoryDB.
For DVA-C02: When building applications with MemoryDB, use the Redis client libraries (redis-py, Jedis, ioredis) in cluster mode. MemoryDB is not serverless — you must select node instance types. Use Secrets Manager + Redis ACLs for credential management, never hardcode passwords.
Common Mistake
MemoryDB for Redis is just a durable version of ElastiCache for Redis — they are essentially the same service with different settings.
Correct
MemoryDB and ElastiCache are architecturally distinct services with different use cases. ElastiCache is designed as a cache (data loss on failure is acceptable, lower cost, optional Multi-AZ). MemoryDB is designed as a primary database (no data loss guaranteed, mandatory Multi-AZ transactional log, higher cost, 35-day backups). Using ElastiCache as a primary database is an anti-pattern; MemoryDB solves this properly.
This is the #1 exam trap. Questions will present scenarios where a team 'uses ElastiCache as their primary store' and ask how to improve durability — the correct answer is migrate to MemoryDB, not just enable ElastiCache Multi-AZ.
Common Mistake
Because MemoryDB is in-memory, it will lose all data if the cluster fails, just like Redis.
Correct
MemoryDB persists every write to a distributed Multi-AZ transactional log BEFORE acknowledging the write to the client. This means data is durable even if all nodes in the cluster fail simultaneously. The data is recovered from the transactional log on restart — this is fundamentally different from vanilla Redis or ElastiCache.
Candidates confuse 'in-memory' with 'non-durable.' MemoryDB proves these are independent properties. The exam tests this by asking: 'Which service provides Redis-compatible in-memory performance WITH durability guarantees?'
Common Mistake
ElastiCache Global Datastore provides cross-region replication for MemoryDB clusters.
Correct
Global Datastore is an ElastiCache for Redis feature ONLY. MemoryDB does not support Global Datastore. MemoryDB's durability is Multi-AZ within a single region. For cross-region Redis-compatible replication, you must use ElastiCache with Global Datastore, not MemoryDB.
Candidates mix up features between the two Redis-compatible services. This is tested in architecture questions asking about multi-region disaster recovery with Redis.
Common Mistake
MemoryDB is serverless and automatically scales capacity based on demand, similar to DynamoDB on-demand mode.
Correct
MemoryDB is NOT serverless. You must provision specific node instance types (e.g., r6g.large, r7g.xlarge) and pay per node-hour. Scaling requires adding shards or changing node types. DynamoDB on-demand and Aurora Serverless v2 are the AWS in-database serverless options — MemoryDB is not in that category.
The 'fully managed' label is confused with 'serverless.' MemoryDB is fully managed (AWS handles patching, backups, failover) but not serverless (you provision capacity). This distinction appears in cost optimization and architecture design questions.
Common Mistake
MemoryDB can be accessed over the public internet like a standard database endpoint.
Correct
MemoryDB clusters are VPC-only. There are no public endpoints. All access must come from within the VPC (or via VPC peering, Transit Gateway, or PrivateLink). This is a security enforcement, not a configuration choice.
Candidates designing public-facing architectures sometimes forget that MemoryDB requires VPC-based access patterns. This is tested in network security and architecture design questions.
DURABLE REDIS = MemoryDB: Think 'Memory + DB' — the 'DB' suffix is the hint that this is a Database, not just a memory cache. ElastiCache has no 'DB' in the name because it's a Cache.
The 3 Ds of MemoryDB: Durable (Multi-AZ log), Database (primary store), Drop-in (Redis API compatible). If a scenario needs all 3 Ds, choose MemoryDB.
MemoryDB vs ElastiCache decision tree: 'Can I afford to lose this data?' → YES = ElastiCache (cheaper cache), NO = MemoryDB (durable database). Simple as that.
35-day retention = Database grade. Remember: RDS = 35 days, Aurora = 35 days, MemoryDB = 35 days. They're all in the 'real database' club. ElastiCache is NOT in this club.
CertAI Tutor · DEA-C01, DOP-C02, CLF-C02, DVA-C02 · 2026-02-21
In the Same Category
Comparisons