Amazon ElastiCache: An Architecture Deep-Dive

About the author: I'm Charles Sieg, a cloud architect and platform engineer who builds apps, services, and infrastructure for Fortune 1000 clients through Vantalect. If your organization is rethinking its software strategy in the age of AI-assisted engineering, let's talk.

ElastiCache looks easy. Deploy a managed cache, point your app at the endpoint, enjoy sub-millisecond reads. Then production happens. Engine selection, cluster topology, eviction policy, replication strategy, connection management, failover behavior: every one of these choices determines whether your caching layer holds up or collapses at 3 AM on a Saturday. I've spent years building and running ElastiCache clusters serving millions of requests per second. Some fronted relational databases with multi-terabyte datasets. Others were dead-simple session stores. All of them taught me something. Usually through failure first.

This is an architecture reference. If you're here to understand ElastiCache internals, scaling strategies, failure modes that blindside teams, and how to make sharp decisions about engines, topologies, and the newer serverless offering, you're in the right place.

What ElastiCache Actually Is

ElastiCache is AWS's fully managed in-memory caching service. Provisioning, patching, monitoring, failure detection, automatic failover, backup: AWS handles all of it. You focus on cache key design, eviction strategy, and wiring it into your application. Three engines: Valkey, Redis OSS, and Memcached.

It's changed a lot since 2011. Managed Memcached came first. Redis support landed in 2013, cluster mode enabled in 2016, encryption and RBAC between 2018 and 2020, data tiering on r6gd instances in 2021, ElastiCache Serverless in 2023, Valkey support in 2024. Every addition shifted how you should deploy and operate caching layers on AWS.

The Shift to Valkey

In March 2024, Redis Ltd. changed the Redis license from the permissive BSD 3-Clause to a dual SSPL/RSAL model. Cloud providers couldn't offer Redis as a managed service without a commercial agreement anymore. AWS, Google, Oracle, Ericsson, and the Linux Foundation responded by forking Redis 7.2.4 into Valkey (open-source, BSD license, under the Linux Foundation).

If you were around for the Elasticsearch/OpenSearch fork in 2021, same playbook. For ElastiCache users, the practical result is a transition. AWS now recommends Valkey for all new deployments. Pricing is 33% lower for serverless and 20% lower for node-based configurations versus Redis OSS. Valkey is wire-protocol compatible with Redis, so your existing client libraries, commands, and data structures work without modification. The Valkey project has already shipped its own innovations: I/O multi-threading in Valkey 8.0, performance improvements in 8.1, bloom filters, and vector search.

New project? Valkey. Already running Redis OSS clusters? Plan a migration but don't rush it. The transition is straightforward, and ElastiCache still supports Redis OSS.

Engine Comparison

Valkey/Redis vs. Memcached is a quick decision. Need data structures, persistence, replication, pub/sub, scripting, or serverless? Valkey. Memcached still has one edge: its native multi-threaded architecture saturates all available CPU cores without cluster mode. That said, I pick Valkey for new deployments unless I've got a specific, benchmarked reason to do otherwise.

Redis (Valkey) vs. Memcached: A Deep Comparison

These engines differ at a fundamental level. You need to understand those differences to pick the right one and to know what you're signing up for operationally.

Threading and Execution Model

Valkey/Redis runs a single-threaded event loop for command execution. Every command (GET, SET, ZADD, Lua script) runs sequentially on one CPU core. No lock contention. Deterministic latency regardless of concurrency. Recent versions moved I/O operations (network read/write, disk persistence, memory deallocation) to background threads, and Valkey 8.0 pushed this further with I/O multi-threading. Network I/O now parallelizes while command execution stays single-threaded. Throughput gains are significant.

Memcached goes the other way entirely. A pool of worker threads handles connections and processes commands concurrently. Sixteen-core node? All 16 cores execute commands simultaneously. For simple GET/SET workloads on big instances, Memcached wins on raw throughput. The catch: that assumes you're CPU-bound rather than memory-bound or network-bound. In practice, that assumption holds less often than people think.

Data Structures and Complexity

Valkey/Redis has seven primary data structures with purpose-built commands and O(1) or O(log N) operations for common access patterns. Sorted sets give you leaderboards and range queries. Streams give you durable pub/sub with consumer groups. HyperLogLog does cardinality estimation in 12 KB. Bitmaps let you store per-user feature flags in megabytes instead of gigabytes.

Memcached supports strings. That's it. Serialize your data, store it, deserialize on read. No atomic operations beyond CAS (compare-and-swap), no range queries, no aggregations, no pub/sub.

Persistence and Durability

Valkey/Redis offers two persistence mechanisms: RDB snapshots (point-in-time binary dumps) and AOF (append-only file logging). Together they let you recover from node restarts with minimal data loss. ElastiCache automates snapshot management with configurable retention up to 35 days.

Memcached has no persistence. None. Node restart means total data loss. Node failure permanently destroys every key on that node, and there's no recovery mechanism.

Replication and High Availability

Valkey/Redis supports primary/replica replication with automatic failover. Each shard can hold up to five read replicas distributed across Availability Zones. Primary fails? ElastiCache promotes a replica in 30-60 seconds.

Memcached has no replication. Each key lives on exactly one node. That node fails, every key on it vanishes instantly, and the resulting cache miss storm hammers your database.

Lua Scripting

Valkey/Redis supports server-side Lua scripting that executes atomically. Read a value, compute something, write a result: one atomic operation, zero race conditions. I've used this for rate limiting with sliding windows, conditional updates, and multi-step transactions that would otherwise need distributed locks.

Memcached? No scripting capability at all.

Architecture Internals

You need to understand how ElastiCache clusters are built before anything else. Topology, sizing, and resilience decisions all flow from this.

Cluster Components

Node Types

ElastiCache node types follow the EC2 naming convention with a cache. prefix. Getting the family right is one of the highest-leverage decisions you'll make on cost and performance.

R7g nodes deliver up to 28% more throughput and 21% better P99 latency over R6g, plus 25% higher networking bandwidth. Graviton-based instances consistently run 20-30% better price-performance than Intel equivalents.

Sizing advice: start with cache.r6g.large or cache.r7g.large for most production workloads. The r-family gives you the most memory per dollar, and memory is almost always the binding constraint. Go with m-family only when your workload is genuinely CPU-bound (heavy Lua scripting, complex sorted set operations). T-family? Dev and test only. Burstable instances will surprise you with latency spikes once CPU credits deplete. I learned that one the hard way during a load test that looked great for two hours, then fell off a cliff.

Parameter Groups

Parameter groups control engine-level behavior. Defaults work fine for development. Production needs tuning.

Subnet Groups and Network Placement

ElastiCache clusters run inside your VPC. No public endpoint, period. A subnet group defines which subnets (and therefore which AZs) receive cache nodes.

For production clusters with Multi-AZ enabled, include subnets in at least two AZs. I prefer three. ElastiCache distributes primary and replica nodes across available AZs automatically.

Your applications must be in the same VPC, a peered VPC, or connected via Transit Gateway to reach ElastiCache. No internet-facing endpoint. No NAT Gateway path. No VPC endpoint like DynamoDB or S3 have. Plan your network topology accordingly.

Cluster Mode: Disabled vs. Enabled

One of the most consequential architectural decisions you'll make with ElastiCache for Valkey/Redis. Also one of the hardest to reverse. There's no in-place migration from cluster mode disabled to enabled. You have to create a new cluster and migrate data. I've watched teams learn this the painful way.

Cluster Mode Disabled

Cluster mode disabled means a single shard: one primary node and up to five read replicas. Every node holds the entire dataset.

Simpler to operate. Makes sense when your dataset fits comfortably in a single node with growth headroom and your write throughput stays within what one primary can handle.

Cluster Mode Enabled

Cluster mode enabled partitions the keyspace across multiple shards using 16,384 hash slots. Each key maps to a slot via CRC16(key) mod 16384. Each shard owns a contiguous range of those slots.

Hash Slot Distribution and Hash Tags

ElastiCache distributes the 16,384 hash slots across shards. Three shards? Each shard typically owns roughly 5,461 slots. Rebalancing tries to distribute slots evenly, but keys aren't uniform in size. Uniform slot distribution doesn't guarantee uniform memory distribution.

Hash tags are critical for multi-key operations in cluster mode. If you need MGET, transactions, or Lua scripts across related keys, those keys must hash to the same slot. Force this by including a common substring in curly braces:

• user:{12345}:profile and user:{12345}:preferences both hash based on 12345
• They will always land on the same shard, enabling atomic multi-key operations

A mistake I see over and over: teams migrate to cluster mode enabled without planning hash tags. Applications that use MGET across unrelated keys, Lua scripts touching keys on different shards, transactions spanning arbitrary keys. They all break with CROSSSLOT errors. Silent, sudden, and completely avoidable with planning.

Resharding Operations

Cluster mode enabled lets you add or remove shards (online resharding) and rebalance hash slots while the cluster serves traffic. Resharding has real operational costs, though.

Here's what I tell every team: if there's any chance your dataset will outgrow a single node, start with cluster mode enabled from day one. Even a single-shard cluster mode enabled configuration preserves the option to add shards later. Save yourself the painful migration event down the road.

flowchart TB
  subgraph CMD["Cluster Mode Disabled"]
    direction TB
    P1[Primary Node
Full Dataset] --> R1[Replica 1]
    P1 --> R2[Replica 2]
    CE1[Primary Endpoint] --> P1
    CE2[Reader Endpoint] --> R1
    CE2 --> R2
  end
  subgraph CME["Cluster Mode Enabled"]
    direction TB
    subgraph S1["Shard 1
Slots 0-5460"]
      P3[Primary] --> R3[Replica]
    end
    subgraph S2["Shard 2
Slots 5461-10922"]
      P4[Primary] --> R4[Replica]
    end
    subgraph S3["Shard 3
Slots 10923-16383"]
      P5[Primary] --> R5[Replica]
    end
    CE3[Configuration
Endpoint] --> S1
    CE3 --> S2
    CE3 --> S3
  end

Replication and High Availability

Primary/Replica Architecture

Each shard in a Valkey/Redis replication group has one primary node and zero to five replicas. The primary handles all writes and propagates changes to replicas asynchronously. Replicas serve read traffic and stand ready for promotion if the primary fails.

Replication is async by default. Under normal conditions, lag is sub-millisecond. But there's always a window where a replica hasn't received the latest writes yet. After a failover, a small number of recent writes are gone. If your application can't tolerate any data loss for specific data, that data belongs in a different persistence layer. Full stop.

Multi-AZ with Automatic Failover

Enable Multi-AZ for every production cluster. No qualifications on this one. ElastiCache distributes primary and replica nodes across Availability Zones and automatically promotes a replica when the primary goes down.

The failover sequence looks like this:

1. ElastiCache detects the primary node is unhealthy (typically within 30-60 seconds)
2. It selects the replica with the least replication lag
3. The selected replica is promoted to primary
4. DNS is updated to point the primary endpoint to the new primary
5. Other replicas begin replicating from the new primary
6. A replacement replica is provisioned in the original AZ

Total failover time runs 30-60 seconds in most cases. It can stretch longer under heavy load or with large datasets on the promoted replica. During failover, writes to the affected shard fail. Reads from replicas keep working.

sequenceDiagram
  participant App as Application
  participant EP as Primary Endpoint
  participant P as Primary Node AZ-1
  participant R as Replica Node AZ-2

  Note over P: Primary fails
  App->>EP: Write request
  EP-->>App: Connection error

  rect rgb(255,230,230)
  Note over EP,R: Failover (30-60 seconds)
  R->>R: Promoted to Primary
  EP->>EP: DNS updated to AZ-2
  end

  App->>EP: Retry write
  EP->>R: Route to new Primary
  R-->>App: Success
  Note over P: Replacement replica
provisioned in AZ-1

Replica Lag Monitoring

Replica lag is the single most important replication health metric. It measures the delay between a write hitting the primary and that write getting applied on a replica. Watch the ReplicationLag CloudWatch metric for every replica node. Don't skip this.

Persistent high replica lag means the primary's write throughput exceeds what the replica can keep up with. Common culprits: sustained write bursts, large key operations, Lua scripts generating tons of writes, slow cross-AZ network.

Read Replicas for Read Scaling

Read replicas do two things. They're failover targets for high availability, and they scale read throughput. The reader endpoint load-balances read connections across all replicas in a shard.

For read-heavy workloads (80%+ reads), adding replicas cuts EngineCPUUtilization on the primary by offloading read traffic. Each replica handles reads independently on its own engine thread, so read throughput scales linearly with replica count.

Replicas cost money, though. Each one is a full node on your bill. If your workload is write-heavy and replicas sit underutilized for reads, you're paying for capacity that only provides HA value. One replica per shard is enough for failover. Add more only when measured read throughput actually demands it.

ElastiCache Serverless

ElastiCache Serverless launched in late 2023 with a fundamentally different operational model. No provisioning nodes, no selecting cluster topologies, no managing scaling policies. You create a serverless cache. ElastiCache handles capacity management.

Architecture

When you create a serverless cache, ElastiCache provisions multi-AZ, replicated infrastructure behind the scenes. You get a single endpoint. Compute and storage scale independently based on workload. No manual intervention.

You still specify VPC and subnet configurations for network isolation. Everything else (node management, AZ distribution, failover, patching, capacity planning) happens transparently.

ECPU Pricing Model

Serverless pricing has two dimensions.

ElastiCache Processing Units (ECPUs): Each kilobyte of data transferred (reads and writes) costs 1 ECPU. A GET returning a 3 KB value? 3 ECPUs. Simple commands on small values cost 1 ECPU.

Data storage: Charged per GB-hour based on the hourly average of data stored. Valkey serverless has a minimum data storage of 100 MB (90% lower than the 1 GB minimum for Redis OSS), which sets the floor for storage costs.

An idle Valkey serverless cache runs about $6/month.

When to Use Serverless vs. Provisioned

Choose serverless when:

• Your workload is unpredictable, spiky, or highly variable
• You want to minimize operational overhead and skip capacity planning
• You're early-stage and don't know steady-state traffic patterns yet
• Your team doesn't have deep ElastiCache operational experience
• Time to production matters more than cost optimization

Choose node-based (provisioned) when:

• Your workload is predictable and reserved instance pricing (up to 48% savings) applies
• You need fine-grained control over engine parameters
• You need data tiering (r6gd instances with SSD)
• Cost optimization at scale is the priority
• You require Memcached
• You need specific node placement across AZs

My take: start with serverless for new workloads. Monitor ECPU consumption and storage for a few weeks. If monthly spend passes $800-1,200, run the numbers on provisioned clusters with 1-year reserved instances. The crossover point is real, and I've hit it on multiple projects.

Data Tiering

Data tiering on cache.r6gd node types extends ElastiCache storage beyond DRAM by adding locally attached NVMe SSDs. For large datasets, it's one of the most impactful cost optimizations available.

Memory + SSD Architecture

The r6gd data tiering architecture is straightforward:

• Keys always stay in DRAM. Only values are candidates for tiering to SSD.
• Hot data stays in DRAM. ElastiCache tracks every item's last access time and keeps frequently accessed data in memory.
• Cold data migrates to SSD. When DRAM fills up, an LRU algorithm moves infrequently accessed values to local NVMe SSD storage.
• SSD reads are transparent. When an application requests a value sitting on SSD, ElastiCache reads it, moves it back to DRAM asynchronously, and returns it to the client.

Added latency for SSD-resident data averages about 300 microseconds (assuming 500-byte string values). That's higher than sub-100-microsecond DRAM latency, sure. Still acceptable for most applications by a wide margin.

Capacity and Cost

R6gd nodes offer 4.8x more total capacity (memory + SSD) than equivalent r6g nodes, with over 60% cost savings at maximum utilization. The largest node in a 500-node cluster mode enabled configuration? Up to 1 petabyte (500 TB with one read replica per shard).

Security on Data Tiering Nodes

All Graviton2-based nodes include always-on 256-bit encrypted DRAM. Items stored on NVMe SSDs get encrypted by default using XTS-AES-256 block cipher in a hardware module on the node. This encryption is active even if you didn't explicitly enable encryption at rest. It's a hardware-level feature of the r6gd platform.

When Data Tiering Makes Sense

Data tiering works well when your dataset is large (hundreds of GiB to TBs), only 10-20% of the data gets regular access, and you can tolerate the extra ~300 microsecond latency on cold reads.

Skip it when every read needs consistent sub-millisecond latency, when your access pattern is uniformly random with no hot/cold separation, or when your dataset fits in memory on standard nodes without breaking a sweat.

Backup and Restore

RDB Snapshots

ElastiCache for Valkey/Redis supports point-in-time snapshots using the RDB (Redis Database) format. The engine forks the process: child writes the entire dataset to a binary file while the parent keeps serving requests.

Memory overhead during snapshots: The fork uses copy-on-write semantics. Under heavy write load during a snapshot, the kernel duplicates modified memory pages, and memory usage can approach 2x the dataset size in the worst case. Run a node at 70% memory utilization, take a snapshot during a write-heavy period, and you risk hitting the memory ceiling. Evictions or OOM follow.

Keep baseline memory utilization below 50-60% on nodes taking automatic backups. Schedule backup windows during off-peak hours when write volume is lowest. I've seen teams learn this lesson only after a snapshot triggered evictions that cascaded into application errors. Not a fun page to get.

AOF Persistence

AOF (Append-Only File) persistence logs every write operation to disk. On restart, the engine replays the AOF to reconstruct the dataset. With appendfsync everysec, you lose at most 1 second of writes.

The trade-offs are real, though. AOF increases write latency (each write persists to disk), uses additional storage, and replaying a large AOF during recovery takes time. For pure caching workloads, RDB snapshots alone provide sufficient durability. AOF makes more sense when the cache stores data that's expensive to reconstruct: session state, computed aggregations, rate limiting counters. Losing even a few seconds of that data hurts.

Snapshot Export and Cross-Region Restore

ElastiCache lets you export manual snapshots to your own S3 bucket, which unlocks some useful patterns:

• Cross-region disaster recovery: Snapshot in one region, replicate the S3 object to another, restore there
• Environment seeding: Snapshot production, restore into staging with real data
• Migration: Snapshot from an old cluster, restore into a new one with different node types or cluster mode
• Long-term archival: Export snapshots to S3 for retention beyond the 35-day automatic backup limit

Security

Encryption In-Transit (TLS)

Enabling in-transit encryption activates TLS between clients and cache nodes, and between primary and replica nodes within the cluster. Sounds simple. A few things to know.

TLS overhead is real. On smaller node types (cache.t3, cache.m6g.medium), TLS handshakes and encryption eat noticeable CPU. Larger Graviton-based nodes have hardware-accelerated cryptographic engines that absorb most of the cost. Benchmark with TLS enabled before you finalize your node type. I've seen teams pick a node size based on non-TLS benchmarks, enable TLS in production, and immediately hit CPU saturation. Unpleasant surprise.

Encryption At-Rest

At-rest encryption uses AWS KMS to encrypt data on disk: RDB snapshots, AOF files, swap files. You pick the default AWS-managed key or a customer-managed CMK. Performance impact is negligible since hardware handles the encryption. Enable it for every production cluster. No reason not to.

Authentication Methods

IAM authentication is what I recommend for any new deployment on Valkey 7.2+ or Redis OSS 7.0+. No AUTH tokens to manage or rotate. It plugs into your existing IAM policies and roles, and CloudTrail gives you audit trails. One catch: the 15-minute token validity means your client library needs automatic token refresh. Most modern Redis clients handle this natively.

AUTH token rotation: If you're using AUTH tokens, ElastiCache supports two rotation strategies. ROTATE adds a new token while keeping the old one valid, so you can do rolling updates across application instances without connection failures. SET immediately replaces the old token. Always use ROTATE in production. I once watched a team use SET during a token rotation. Instantly disconnected every application instance. The incident call was... educational.

VPC Placement and Security Groups

ElastiCache clusters must reside in a VPC. Keep security group rules tight:

• Allow inbound traffic on port 6379 (Valkey/Redis) or 11211 (Memcached) only from security groups of application instances that need cache access
• Don't open cache ports to 0.0.0.0/0 or broad CIDR ranges
• Use separate security groups for different environments even if they share a VPC
• Remember: encryption in-transit and authentication must both be set at cluster creation. You can't add them later. This one bites people.

Connection Management

Connection management causes more production incidents than people expect with ElastiCache. You need to understand the engine's connection model and your application's connection lifecycle to get this right.

Connection Limits Per Node Type

Each ElastiCache node has a maximum simultaneous connection count controlled by maxclients. Default is 65,000 for most node types, but the effective limit depends on available memory since each connection consumes memory for input/output buffers.

Connection Pooling Strategies

Every application instance needs a connection pool. Creating connections per operation is wasteful, and the math on this is unforgiving. TCP handshake alone costs 1-3 ms. Add TLS and it's 3-5 ms. A Redis GET takes 0.1-0.3 ms. That's connection overhead running 10-50x the cost of the actual command.

Pool sizing guidance:

Persistent Connections and DNS Caching

DNS caching causes the most production incidents during failovers. Here's how it plays out: failover happens, ElastiCache updates the primary endpoint's DNS record (5-second TTL) to point to the promoted replica. Your application caches DNS beyond that TTL, so it keeps sending writes to the old, failed node. Writes silently fail. Or worse, they hang.

Critical mitigations:

• JVM applications: Set networkaddress.cache.ttl=5 in java.security or via java.security.Security.setProperty(). The JVM default caches DNS forever. Yes, forever. I'm not exaggerating.
• Linux systems: Configure nscd with low TTL or disable it entirely.
• Node.js: Default DNS cache honors TTL, but verify your HTTP/connection library does too.
• Python: The socket module doesn't cache DNS by default, but connection pools hold stale connections.
• All platforms: Test failover regularly using the TestFailover API. Do this before your first real failure. Not during it.

Client Library Selection

For Valkey/Redis, pick a cluster-aware client library. Here's what matters:

Libraries I've had good results with: Lettuce (Java; non-blocking, cluster-aware, connection pooling built in), redis-py (Python), ioredis (Node.js), go-redis (Go).

Eviction Policies

When ElastiCache hits its memory limit (maxmemory), the eviction policy decides what happens next.

When to Use Each

For pure caching (cache-aside pattern): allkeys-lru or allkeys-lfu. LFU is generally the better pick because it keeps frequently accessed keys even if their last access was a few seconds ago, but it requires Valkey/Redis 4.0+. LFU with the default frequency counter decay handles most workloads well.

For mixed use (cache + persistent data on the same cluster): volatile-lru or volatile-lfu. Set TTL on all cache keys. Don't set TTL on persistent data. The engine only evicts keys with a TTL, so your persistent data stays safe.

For session stores: noeviction. Silently evicting sessions means users get logged out with no explanation. Terrible user experience. Monitor DatabaseMemoryUsagePercentage aggressively and scale before memory fills.

For rate limiting: noeviction. If rate limit counters get evicted, rate limiting stops working. Your backend is now exposed to traffic storms.

For time-series data with natural expiration: volatile-ttl. Data with shorter remaining TTL (the oldest data) gets evicted first, preserving the most recent records.

Observability

Critical CloudWatch Metrics

ElastiCache publishes host-level and engine-level metrics to CloudWatch at 60-second intervals. Here are the ones I watch on every production deployment:

Here's the nuance that catches teams: EngineCPUUtilization and CPUUtilization tell you different things. A 4-core node might show 25% total CPUUtilization while EngineCPUUtilization sits at 90%. Engine thread is fully saturated. Three cores are idle. If you only alarm on CPUUtilization, you miss this completely. I've diagnosed production slowdowns where the on-call engineer kept saying "CPU looks fine" because they were looking at the wrong metric. Happens more than you'd think.

Slow Log

The Valkey/Redis slow log captures commands exceeding a configurable execution time threshold (set via slowlog-log-slower-than, default 10,000 microseconds / 10ms). Access it with SLOWLOG GET [count].

Check it regularly. It'll help you find:

• HGETALL or SMEMBERS on large collections (thousands of fields/members)
• SUNION, SINTER, SDIFF on large sets
• KEYS commands (which scan the entire keyspace; never use in production, use SCAN instead)
• Lua scripts with unexpectedly high execution time
• SORT commands on large lists
• DEL on large keys (use UNLINK instead for background deletion)

Alarms I Always Configure

Every production ElastiCache cluster I run gets these alarms at minimum:

1. DatabaseMemoryUsagePercentage > 75% (Warning). Investigate growth trend and plan scaling.
2. DatabaseMemoryUsagePercentage > 85% (Critical). Scale immediately.
3. EngineCPUUtilization > 80% (Warning). Review slow log, optimize expensive commands, or scale.
4. EngineCPUUtilization > 90% (Critical). Engine thread is saturated. Commands are queuing.
5. Evictions > 100 per 5 minutes (Warning). Memory pressure is causing data loss.
6. ReplicationLag > 5 seconds (Critical). Failover would lose multiple seconds of writes.
7. CurrConnections > 50,000 (Warning). Approaching the 65,000 default limit.
8. SwapUsage > 0 (Critical). The node is swapping. Performance is destroyed.

Cost Analysis

On-Demand vs. Reserved Pricing

ElastiCache node-based pricing follows the standard AWS model. Reserved instances save real money for predictable workloads, and you should be using them.

Reserved node options:

Serverless Pricing Comparison

For Valkey serverless (us-east-1):

Cost crossover analysis: Where exactly provisioned beats serverless depends on your access patterns. In my experience running both, the crossover falls around $800-1,200/month of serverless spend for Valkey workloads. Below that, serverless wins on operational simplicity alone. Above that, provisioned with 1-year reserved instances typically costs less.

Cost Optimization Strategies

1. Use reserved instances for stable production workloads. Even 1-year no-upfront reservations save 25%.
2. Right-size node types. If DatabaseMemoryUsagePercentage stays below 50%, you're over-provisioned. Shrink the nodes.
3. Use Graviton-based instances (r7g, m7g). 20-28% better price-performance than Intel. There's no reason to run Intel for ElastiCache anymore.
4. Use data tiering for large datasets with hot/cold access patterns. 60%+ savings versus memory-only nodes add up fast.
5. Choose Valkey over Redis OSS. 20% lower node pricing, 33% lower serverless pricing, identical functionality.
6. Scale replicas based on actual read throughput. Don't default to 5 replicas per shard. Each replica is a full node on your bill.
7. Set TTLs on every cache key. Keys without TTLs grow indefinitely, silently inflating memory and cost.
8. Use cluster mode enabled for write scaling rather than upgrading to larger (and pricier) node types.

Common Failure Modes

Memory Pressure and OOM

The failure mode I see most often. When the dataset exceeds maxmemory, the engine either evicts keys (if eviction is configured) or rejects all writes with OOM errors (if noeviction). Extreme cases? The OS OOM killer terminates the process entirely.

Prevention:

• Monitor DatabaseMemoryUsagePercentage and alarm at 75% (warning) and 85% (critical)
• Account for snapshot memory overhead; forks temporarily double memory usage
• Account for memory fragmentation; actual OS memory runs 10-20% higher than logical dataset size
• Enable activedefrag yes to reduce fragmentation over time
• Enable lazyfree-lazy-eviction yes to reduce latency spikes during eviction

Failover Detection Delay

After a primary node fails, applications keep sending requests to the dead node for 30-60 seconds while ElastiCache detects the failure and promotes a replica. Writes fail during this window. Users notice.

Mitigation:

• Set client-side connection timeouts to 1-2 seconds
• Implement retry logic with exponential backoff and jitter
• Design your application to degrade gracefully when the cache is temporarily gone
• Use circuit breakers to prevent cascading failures

DNS Caching During Failover

This one catches more teams off guard than any other failure mode. After failover, ElastiCache updates the primary endpoint's DNS record (5-second TTL) to point to the promoted replica. If your application caches DNS beyond that TTL, it keeps talking to the old node. Your app thinks the cache is down. In reality it's just talking to the wrong server.

Mitigation:

• JVM: Set networkaddress.cache.ttl=5 (the default is infinite, which is astonishing)
• Linux: Configure nscd with low TTL or disable it
• Cluster mode enabled: Use cluster-aware clients that respond to MOVED redirections
• Test failover regularly with the TestFailover API. Test it now, before you need it.

Large Keys Blocking Operations

Valkey/Redis uses single-threaded command execution. One command operating on a massive data structure blocks everything else until it's done. HGETALL on a 10 MB hash. DEL on a 100 MB sorted set. KEYS on a million-key keyspace. Any of these blocks the engine thread for tens or hundreds of milliseconds, causing timeouts across your entire application fleet.

Mitigation:

• Use UNLINK instead of DEL for large keys. UNLINK reclaims memory in a background thread.
• Use HSCAN, SSCAN, ZSCAN instead of HGETALL, SMEMBERS, ZRANGEBYLEX on large collections
• Never use KEYS in production. Use SCAN with COUNT parameter.
• Enable lazy free parameters: lazyfree-lazy-eviction, lazyfree-lazy-expire, lazyfree-lazy-server-del
• Monitor the slow log for commands exceeding 5ms

Lua Script Timeouts

Lua scripts execute atomically. No other commands run until the script completes, so a runaway script blocks the entire shard. The lua-time-limit parameter (default 5,000ms / 5 seconds) controls when the engine starts accepting SCRIPT KILL commands. It doesn't automatically kill the script, though. You have to do that yourself.

Mitigation:

• Keep Lua scripts short and bounded. No unbounded loops over large datasets.
• Test scripts against production-scale data volumes in staging
• Monitor EngineCPUUtilization for sustained 100% spikes that indicate a stuck script
• Use EVALSHA (cached compiled script) instead of EVAL (inline script) for frequently executed scripts
• Set a reasonable lua-time-limit and have runbooks for SCRIPT KILL

Cluster Mode Resharding Impact

During online resharding, the cluster migrates hash slots between shards. Keys in migrating slots experience higher latency, and multi-key operations spanning migrating and non-migrating slots fail with CROSSSLOT errors.

Mitigation:

• Schedule resharding during low-traffic windows
• Monitor latency metrics closely during the operation
• Use hash tags to co-locate related keys, so they migrate together atomically
• Avoid resharding during periods of high write throughput

Caching Patterns

Your caching pattern determines how data flows between application, cache, and database. Each one brings different consistency, latency, and complexity trade-offs.

Cache-Aside (Lazy Loading)

Most common pattern and generally the safest. Application checks the cache first. On a miss, it reads from the database, writes the result to cache with a TTL, and returns it. I use this as my default for every new project until I've got a specific reason to do otherwise.

flowchart TD
  A[Application
needs data] --> B{Check
Cache}
  B -->|Hit| C[Return
cached data]
  B -->|Miss| D[Read from
Database]
  D --> E[Write to Cache
with TTL]
  E --> F[Return data
to caller]

  style C fill:#2d7,stroke:#333
  style D fill:#e94,stroke:#333

Write-Through

Every database write is immediately followed by a cache write. Once populated, reads always hit the cache.

Write-Behind (Write-Back)

Application writes to the cache. The cache asynchronously writes to the database. The cache becomes your primary write target.

Write-behind carries real risk. I only use it when the performance benefit justifies the complexity and occasional data loss is acceptable. Analytics counters and activity aggregations? Good candidates. Financial records? Absolutely not.

Read-Through

The cache itself loads data from the database on a miss. Application only talks to the cache. ElastiCache doesn't natively support read-through, so you'll need a caching library or application-side middleware to implement it.

TTL Strategies

Set a TTL on every cache key. Even with explicit invalidation, a TTL acts as a safety net for when invalidation fails or gets delayed. I default to 1 hour for most workloads and adjust per key type based on how much staleness the application can tolerate.

Cache Stampede Prevention

A cache stampede (thundering herd) happens when a popular key expires and hundreds of concurrent requests simultaneously miss the cache and slam the database. I've been on the receiving end of these. They cause real outages.

Prevention strategies:

For high-traffic keys, I combine jittered TTLs with lock-based recomputation. Lock stops the stampede. Jitter prevents synchronized expiration across related keys. Together they handle the vast majority of scenarios.

Key Architectural Patterns

After years running ElastiCache in production, these are the patterns and decisions that matter most:

1. Choose Valkey for new deployments. API-compatible with Redis. Fully open source under the Linux Foundation. 20-33% cheaper. AWS is investing its development energy here.
2. Start with cluster mode enabled. Migrating from disabled to enabled means creating a new cluster. Start with enabled (even single-shard) and you get horizontal scalability without a migration event later.
3. Enable Multi-AZ with automatic failover for every production cluster. Cost: one replica per shard. Cost of skipping it: application degradation, database overload, customer impact during a cache outage. Not a close call.
4. Set a TTL on every key. Cache keys without TTLs accumulate silently until they trigger evictions or OOM. A TTL bounds staleness and manages memory simultaneously.
5. Monitor EngineCPUUtilization, not just CPUUtilization. For single-threaded Valkey/Redis, EngineCPUUtilization shows actual engine saturation. Overall CPUUtilization on a multi-core node hides a fully saturated engine thread behind averaged-out idle cores.
6. Fix DNS caching before your first failover. DNS caching during failover is the most common cause of extended outages after an ElastiCache node failure. Test failover with the TestFailover API in staging. Verify your application follows DNS changes within seconds.
7. Never use the KEYS command in production. Use SCAN with a COUNT parameter. KEYS blocks the engine thread for its entire execution, scanning every key. On busy clusters, this cascades into timeouts across every connected application.
8. Implement connection pooling from day one. Connection churn wastes resources on both sides, adds latency, and exhausts the node's connection limit during traffic spikes.
9. Use data tiering for large, infrequently-accessed datasets. The 60%+ cost savings on r6gd instances are real. ~300-microsecond SSD latency is acceptable for workloads with genuine hot/cold access patterns.
10. Design for cache failure. Your application must degrade gracefully when the cache is unavailable. If a cache outage becomes an application outage, you've got a design problem.

Additional Resources

• Amazon ElastiCache Developer Guide: comprehensive reference for all ElastiCache features, configuration options, and API operations
• ElastiCache for Valkey Getting Started Guide: walkthrough for creating and connecting to a Valkey cache in both serverless and node-based modes
• Database Caching Strategies Using Redis: AWS whitepaper covering cache-aside, write-through, and other caching patterns with detailed implementation guidance
• Best Practices for Sizing Your ElastiCache Clusters: AWS-published guidance on node type selection, memory sizing, and connection management
• ElastiCache CloudWatch Metrics Reference: complete list of available metrics with descriptions and recommended alarm thresholds
• ElastiCache Data Tiering Documentation: architecture details, supported node types, and performance characteristics for r6gd data tiering
• ElastiCache Security Best Practices: encryption, authentication, RBAC, IAM integration, and network isolation guidance
• Monitoring Best Practices with ElastiCache Using CloudWatch: detailed guidance on metric selection, alarm configuration, and observability patterns
• Valkey Project Documentation: upstream engine documentation, command reference, and release notes at valkey.io
• Amazon ElastiCache Pricing: current pricing for on-demand, reserved, and serverless across all regions and node types