ElastiCache — Failover, Serverless, and Operations

The ElastiCache overview covers Redis/Memcached/Valkey, cluster modes, and connection patterns. This file is the operational depth: failover behavior, parameter groups, ElastiCache Serverless, and the self-managed comparison.

For Redis fundamentals (data structures, persistence, clustering internals, distributed locks, cache-stampede mitigation) see ../../../09_caching/redis/ — that’s the engine-level depth; this file is the AWS-managed-service layer.

Multi-AZ failover behavior

In a replication group (cluster mode disabled or enabled) with Multi-AZ enabled:

primary (AZ-a)  →  replica (AZ-b), replica (AZ-c)
     │ fails
     ▼
ElastiCache promotes a replica to primary, updates the primary endpoint DNS

What actually happens on failover:

1. ElastiCache detects the primary failure (health checks).
2. A replica is promoted to primary.
3. The primary endpoint DNS is updated to point at the new primary.
4. Total failover time: typically under a minute (often ~15-30s).

Client implications:

• Connect via the primary endpoint, not a node IP — the endpoint follows the promotion; a hardcoded node IP does not.
• Your client must reconnect — existing connections to the old primary break. The Redis client’s reconnection logic + connection pool handle this; make sure retries are configured.
• Brief write unavailability during the promotion window. Reads from replicas can continue (against the reader endpoint).
• Replica lag means a small amount of the most-recent writes can be lost on failover — Redis replication is asynchronous. For a cache, that’s usually fine; for anything you treat as a store of record, it’s not (don’t treat ElastiCache as durable).

Without Multi-AZ, a primary failure means manual intervention and longer downtime. Enable Multi-AZ for any production replication group.

Parameter groups

A parameter group is the config bundle applied to a cluster — the ElastiCache equivalent of redis.conf. The settings that matter most:

The big one: maxmemory-policy defaults to noeviction on ElastiCache. With noeviction, once the cache fills, writes fail instead of evicting old keys. For a general-purpose cache that’s wrong — you want allkeys-lru (evict least-recently-used across all keys) or volatile-lru (evict LRU among keys with a TTL). Forgetting to change this is a classic production surprise: the cache “stops working” once it fills.

Changing a parameter group: some parameters apply immediately, others need a reboot. AWS marks which.

ElastiCache Serverless

Introduced 2023. No node type to choose, no cluster sizing — you get an endpoint and ElastiCache scales capacity automatically.

Serverless is the easy default for unpredictable workloads — you stop over-provisioning for peak. For steady high-volume production where you’ve right-sized, provisioned can be cheaper. It supports Redis/Valkey and Memcached.

Cluster mode: enabled vs disabled (recap + client impact)

• Cluster mode disabled — one shard: a single primary + up to 5 replicas. Reads scale across replicas; writes don’t scale (one primary). Multi-key operations and transactions work normally. Use until one primary can’t handle the write load.
• Cluster mode enabled — data sharded across multiple node groups (shards), each primary + replicas. Writes scale. But: multi-key operations (MGET, transactions, Lua touching multiple keys) only work if all keys are in the same hash slot — use hash tags {user123}:profile, {user123}:settings to co-locate. The client must be cluster-aware (redis.cluster.RedisCluster in redis-py).

The interview point: cluster mode enabled scales writes but constrains multi-key operations; choose it when you’ve outgrown a single primary’s write capacity, not by default.

Self-managed Redis vs ElastiCache

For most teams, ElastiCache’s operational savings outweigh the premium. Self-manage only if you need Redis modules ElastiCache doesn’t support, the absolute latest Redis version, or have very specific config needs — and have the ops capacity.

Valkey note: after Redis Inc.’s license change, AWS pushes Valkey (the open-source fork). ElastiCache for Valkey is API-compatible with Redis and AWS prices it slightly cheaper — for new clusters it’s the default unless you have a specific reason for Redis.

Operational essentials

• Connect via endpoints, not IPs — primary endpoint for writes (follows failover), reader endpoint for read scaling, configuration endpoint for cluster mode.
• Enable Multi-AZ for any production replication group.
• Set maxmemory-policy away from noeviction for a general-purpose cache.
• Encryption — in-transit (TLS) and at-rest are opt-in; enable both for anything sensitive. AUTH token or IAM auth for access control.
• Monitor — DatabaseMemoryUsagePercentage, Evictions, CacheHits/CacheMisses ratio, CurrConnections, CPUUtilization, replication lag.
• Snapshots — automated daily + manual before risky changes. Restoring creates a new cluster.
• Don’t treat it as durable — async replication means failover can lose recent writes. It’s a cache (or a tolerant-of-loss store), not a database.

Common gotchas

• maxmemory-policy: noeviction default — cache fills, writes start failing. Change it.
• Hardcoded node IP instead of the endpoint — survives nothing; failover breaks the client.
• No client reconnection logic — failover happens in <1 min but the client must reconnect; without retry config it just errors.
• Cluster mode multi-key operations across slots — fail unless co-located with hash tags.
• Treating ElastiCache as a durable store — async replication; failover can drop recent writes.
• Over-provisioning for peak — if load is spiky, Serverless avoids paying for peak 24/7.
• TLS enabled server-side but client not configured for it — connection refused.

Interview angle

• “What happens on an ElastiCache primary failure?” — with Multi-AZ: ElastiCache promotes a replica, updates the primary-endpoint DNS, total failover usually <1 min. Clients connected via the endpoint (not a node IP) reconnect to the new primary. Async replication means a small window of recent writes can be lost — fine for a cache, not for durable data.
• “The cache ‘stopped working’ when it filled up. Why?” — maxmemory-policy is noeviction by default on ElastiCache; once full, writes fail instead of evicting. Set allkeys-lru (or volatile-lru) in the parameter group.
• “ElastiCache Serverless vs provisioned?” — Serverless: no sizing, auto-scales, pay per GB-hour + requests — great for spiky/unpredictable load and dev. Provisioned: pick node types, pay per node-hour — can be cheaper for steady right-sized production.
• “Cluster mode enabled vs disabled — client impact?” — disabled: one primary (writes don’t scale), reads scale on replicas, multi-key ops work freely. Enabled: writes scale across shards, but multi-key ops need keys in the same hash slot (hash tags) and a cluster-aware client.
• “Self-managed Redis vs ElastiCache?” — ElastiCache hands you patching, automated failover, backups, and scaling for a managed premium. Self-manage only for Redis modules AWS doesn’t support, bleeding-edge versions, or specific config — and only with the ops capacity. New clusters: ElastiCache for Valkey is the default post-Redis-license-change.