AWS ElastiCache vs MemoryDB: Which One Do You Actually Need?

I was setting up Redis on AWS and faced the classic question: ElastiCache or MemoryDB? After some research, the answer is surprisingly simple once you understand the core difference.

TL;DR Decision Tree

Is your data ephemeral (can be regenerated/lost)?

├── YES → ElastiCache (~$12/month for cache.t4g.micro)

└── NO → MemoryDB (~$25+/month, durable storage)

That's it. That's the whole decision.

My Use Case: Rate Limiting

For jo4.io, I need Redis for:

• Rate limiting counters (user:123:requests:minute)


• Session caching


• Temporary feature flags

If Redis dies and I lose all this data:

• Rate limit counters reset to 0 (users get a fresh minute, not a big deal)


• Sessions expire (users log in again, minor inconvenience)


• Feature flags reload from database (brief hiccup)

Verdict: ElastiCache - The data is ephemeral.

When to Use MemoryDB

MemoryDB is for when your Redis data is your source of truth:

• 
  Leaderboards/rankings that can't be recalculated


• 
  Real-time inventory where Redis IS the database


• 
  Session data you can't afford to lose (financial apps)


• 
  Message queues where losing messages means lost transactions

MemoryDB provides:

• Multi-AZ durability (data survives node failures)


• Transaction log durability (writes are persisted)


• Point-in-time recovery

Cost Comparison

For a small production workload:

MemoryDB doesn't have a micro tier, so the minimum is higher.

My ElastiCache Setup

resource "aws_elasticache_cluster" "redis" {

  cluster_id           = "jo4-prod-redis"

  engine               = "redis"

  engine_version       = "7.1"

  node_type            = "cache.t4g.micro"

  num_cache_nodes      = 1

  port                 = 6379

  parameter_group_name = "default.redis7"



  subnet_group_name    = aws_elasticache_subnet_group.redis.name

  security_group_ids   = [aws_security_group.redis.id]



  # Daily snapshot, 7 day retention (even ephemeral data is nice to have)

  snapshot_retention_limit = 7

  snapshot_window          = "02:00-03:00"

  maintenance_window       = "sun:03:00-sun:04:00"

}

The In-VPC Advantage

One thing I love about ElastiCache: no authentication needed when inside your VPC.

# application-redis.yaml

spring:

  data:

    redis:

      host: ${REDIS_HOST}

      port: ${REDIS_PORT}

      timeout: 5000

      # No password needed - security group controls access

Compare this to Redis Cloud where you need:

• Username/password


• TLS configuration


• Credential rotation


• Network connectivity to external service

In-VPC ElastiCache:

• Security group allows only your EC2 instances


• No credentials to manage


• No external network dependency


• Lower latency

Migration from Redis Cloud

If you're moving from Redis Cloud to ElastiCache:

1. 
   Update connection config - Host, port, remove auth


2. 
   Accept data loss - ElastiCache starts empty


3. 
   Ensure fail-open behavior - Your app should handle empty cache gracefully

For rate limiting and caching, this migration is trivial because the data is ephemeral anyway.

Common Mistakes

1. Using MemoryDB for Caching

Overkill. You're paying for durability you don't need.

2. Using ElastiCache for Critical Data

If you're storing shopping carts or user preferences in Redis without a database backup, use MemoryDB or rethink your architecture.

3. Single-AZ ElastiCache for Production

At minimum, use a replication group across AZs for production workloads.

4. Oversizing

Start with cache.t4g.micro. You can always scale up. Monitor your memory usage and evictions.

Decision Matrix

Summary

• 
  ElastiCache: Fast, cheap, ephemeral. Perfect for caching and rate limiting.


• 
  MemoryDB: Durable, more expensive. For when Redis is your database.

Don't overthink it. If you can regenerate the data, use ElastiCache.

Which one are you using? Share your use case in the comments!

Building jo4.io - a URL shortener with analytics. Check it out at jo4.io