ElastiCache cost optimization Valkey vs Redis is the conversation CFOs start when the cache line item sits next to RDS and nobody can explain why. A "small" cache.r7g.xlarge with a replica in another AZ, Multi-AZ automatic failover, and a reserved-instance that never got purchased will quietly match a database bill. The engine name — Redis OSS, Valkey, or Memcached — is one lever. Placement, node size, and reservation are the others.
AWS documents ElastiCache for Valkey and Redis OSS, reserved nodes, and data-tiering (ElastiCache, ElastiCache pricing). Valkey is the Linux Foundation continuation many teams are moving toward on ElastiCache; Redis OSS remains available. We pick the engine from compatibility and price, not from a blog war. Rutagon does not hold a SOC 2 report. We still keep encryption, auth, and subnet placement easy to evidence if you do.
Why the Cache Matches the Database Line
Three patterns:
- Wrong size. The working set is 4 GB. The node is 32 GB because someone copied production "for headroom" into every environment.
- Wrong topology. A replica in a second AZ is correct for failover. A replica that takes no traffic and exists "because HA" on a non-critical session cache is a second node bill. Multi-AZ has a cost. Buy it when the SLO says so.
- Cross-AZ chatter. Clients in AZ-A talking to a primary in AZ-B pay data transfer and add latency. Same-AZ placement for the hot path is a cost and a p99 win. AWS's own well-architected cost guidance treats unnecessary transfer as waste (AWS Well-Architected Cost Optimization).
Reserved nodes (or Savings Plans where they apply to the family) are the boring fourth lever. On-demand for a 24/7 cache is a choice. Make it on purpose.
ElastiCache Cost Optimization Valkey vs Redis: What We Compare
We do not migrate engines as a religion. We compare:
- API compatibility. If the app uses Redis modules or commands Valkey on ElastiCache does not offer, stay or wait. A failed cutover is more expensive than a node reservation.
- Node pricing. For the same instance class, Valkey on ElastiCache is often the cheaper engine line on the public price list. Confirm in the region you actually run.
- Gravition.
cache.r7g/c7gvs older Intel classes. Same compatibility story as Lambda Graviton. - Data-tiering. Large working sets that tolerate SSD overflow can drop memory class. Not for a hot session cache with tight p99.
resource "aws_elasticache_replication_group" "sessions" {
replication_group_id = "sessions"
description = "session cache"
engine = "valkey"
engine_version = var.engine_version
node_type = "cache.r7g.large"
num_cache_clusters = 2 # primary + replica; not 3 "for luck"
automatic_failover_enabled = true
multi_az_enabled = true
subnet_group_name = aws_elasticache_subnet_group.priv.name
at_rest_encryption_enabled = true
transit_encryption_enabled = true
snapshot_retention_limit = 3
}
Nonprod gets num_cache_clusters = 1 and a smaller node unless you are load-testing failover. Copy-paste of production topology into staging is the most common leak we find.
Related: RDS Proxy connection pooling when the real problem is the database, Aurora Serverless v2. Capability: AWS cloud infrastructure.
Same-AZ Placement Without Lying About HA
Put the primary and the application fleet in a placement you can explain. For a Multi-AZ group, AWS places replicas. Clients should use the configuration endpoint and let the cluster handle failover — not hardcode an IP in AZ-C. Cross-AZ transfer from a mis-aimed client is a silent tax.
If the cache is truly disposable (HTML fragments, feature-flag reads), a single-node Valkey in one AZ with a documented rebuild time can be the right cost. Write that SLO down. Do not call it Multi-AZ in the SOC 2 narrative if it is not.
Snapshots and backups are a separate line. A seven-day snapshot on a cache you would rather rebuild from origin is waste. A session cache that is the only copy of cart state is not a cache — it is a datastore, and it may belong on Aurora. We have that conversation before we buy a bigger node.
Migration Discipline
Engine change is a production change. We dual-run or blue/green a read path, compare hit ratio and error rate, then flip writers. Rollback is DNS/endpoint back to the old replication group we did not delete on the same day. Reserved-node commitments need a glance so you do not orphan a Redis reservation by jumping engines mid-term.
Auth tokens and RBAC users move with the engine. Do not fall back to a plaintext requirepass in a ticket. That is a credential ticket sitting inside a FinOps change.
Diagnostic
Two weeks: node inventory by env, engine, AZ, reservation coverage, hit ratio, and evictions. You get a scorecard: shrink, drop a replica, move to Valkey, or leave it alone. We do not promise a generic percent. A cache that is already r7g.large Valkey with a reservation may be fine. The one that is r5.2xlarge Redis OSS with three replicas in staging is not.
Global datastores and replica groups across regions are a product decision. They double or triple the node bill. If the SLO is regional and the second region is "for later," turn it off until later. If you need the second region, say so in the scorecard so nobody "optimizes" it during a cost week and creates an availability finding.
Parameter groups that enable every notification and slow-log destination can add operational noise; they rarely dominate the bill. Node hours dominate. Start there.
Reader endpoints for read-heavy caches can keep the primary smaller. If every command still hits the primary because the client library ignores readers, you bought a replica you do not use. We check client configuration before we add a third node "for reads."
Talk through a two-week AWS cost diagnostic →
907-841-8407 · contact@rutagon.com
Frequently Asked Questions
Is Valkey a drop-in for Redis on ElastiCache?
For common string/hash/list/sorted-set workloads, often yes. Modules and some admin commands are the break points. We test the command mix from SLOWLOG and application clients before we flip.
Should every cache be Multi-AZ?
No. Buy Multi-AZ when rebuild time or data loss violates the SLO. Session caches that can bounce users to login may not need a replica. Cart state might.
Do reserved nodes apply across Redis OSS and Valkey?
Treat reservations as engine- and family-specific until you confirm the offering in your account. We map commitments before we migrate.
Does encryption change the price much?
In-transit and at-rest are usually the correct default for an in-scope system. Do not disable encryption to chase a cache discount on a SOC 2-bound workload.
Can we use serverless ElastiCache instead?
If your access pattern is spiky and the serverless offering fits the API, model it. Steady-hot 24/7 caches often still win on reserved node-based clusters. Measure.