DEV Community

Anand Rathnas
Anand Rathnas

Posted on

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

#aws #elasticache #redis #memorydb

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)
Enter fullscreen mode Exit fullscreen mode

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:

Service Node Type Monthly Cost
ElastiCache cache.t4g.micro ~$12
ElastiCache cache.t4g.small ~$24
MemoryDB db.t4g.small ~$25
MemoryDB db.r6g.large ~$200+

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"
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Use Case Service Why
Rate limiting ElastiCache Ephemeral, can regenerate
Session cache ElastiCache Can re-auth if lost
Page cache ElastiCache Can re-render if lost
Leaderboard (source of truth) MemoryDB Can't regenerate rankings
Shopping cart (no DB backup) MemoryDB User data, can't lose
Real-time inventory MemoryDB Business critical
Pub/sub messaging Depends If message loss = money loss, MemoryDB

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

Top comments (0)