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

Source: Dev.to

This article was originally published on Jo4 Blog.

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)

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 (e.g., 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

MemoryDB doesn’t have a micro tier, so the minimum cost 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

Compared to Redis Cloud, which requires:

• Username/password
• TLS configuration
• Credential rotation
• Network connectivity to an external service

With In‑VPC ElastiCache you get:

• Security group‑restricted access only for 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, and remove auth.
2. Accept data loss – ElastiCache starts empty.
3. Ensure fail‑open behavior – your app should handle an 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 store shopping carts or user preferences in Redis without a database backup, switch to MemoryDB or rethink the 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 memory usage and evictions.

Decision Matrix

Summary

• ElastiCache: Fast, cheap, ephemeral. Perfect for caching and rate limiting.
• MemoryDB: Durable, more expensive. Ideal when Redis is your primary database.

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

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