ElastiCache data tiering lands on r8g hardware: 5x the cache room for 52% more per hour

Published November 2, 2026

The more expensive ElastiCache node is the cheaper one. On the new data-tiering cache.r8gd.16xlarge in Europe (Spain), you pay $9.5506 an hour against $6.2833 for the memory-only cache.r8g.16xlarge. The tiered node adds 1,592.56 GiB of SSD to 378.39 GiB of usable memory. Same family, same vCPUs, roughly five times the usable cache, 52% more money, and about 71% less per usable GiB.

Data tiering reached r7gd and r8gd on October 27: r8gd (Graviton4) in Europe (Spain), r7gd (Graviton3) in Europe (Spain) and Asia Pacific (Hyderabad). If that sentence reads like a small announcement, read the region list again. The newest tiering hardware is sold in exactly two places, and most of us don’t run caches there yet.

Both node types are new to ElastiCache. Before the launch, the price list had no r7gd or r8gd row in any region, and r6gd was the only tiered family on it. The two regions are where AWS put the new hardware first.

Data tiering costs 1.52x now, not the old 1.90x

ElastiCache’s tiered nodes have always been priced as a premium over the memory-only node, then made the math work with capacity. The old deal was thin. In us-east-1, r6gd.16xlarge runs 1.90x the r6g.16xlarge rate. The new families price the SSD at 1.52x, and they’re built on bigger base nodes. Valkey on-demand, from the AWS ElastiCache offer dated 2026-10-28:

The 1.52x holds on the 2xlarge tier too, and it holds identically in both new regions. ElastiCache rounds each node rate to four decimals independently, so 1.52 is a policy, not a coincidence.

Price the capacity, not the node. ElastiCache recommends budgeting 25% of node memory for overhead, so usable memory is 75% of the headline number. On r8gd.16xlarge:

• Memory-only: 378.39 GiB usable → $0.0166 per usable GiB-hour (about $12.12 per GiB-month)
• Data tiering: 1,970.95 GiB usable → $0.0048 per usable GiB-hour (about $3.54 per GiB-month)

That’s 3.4x the usable capacity per dollar. At maximum utilization, AWS’s own wording for the older r6gd deal is “over 60% savings.” The r8g numbers come out around 71% before the first eviction.

Keys stay on the counter; the values move to the pantry

Data tiering puts a fridge and a pantry in every node. Keys always live in memory. The values are what move: when memory fills, ElastiCache evicts least-recently-used values to the local SSD by LRU, and pulls them back asynchronously before a request touches them. Find the label, then walk to the pantry to get the thing.

That’s why the discounts are conditional. The pantry only pays off when most of the data is cold. AWS’s design target is workloads that regularly access up to 20% of their dataset. A cold read costs about 300 microseconds more than a memory read on 500-byte values. Data that is bigger than 128 MiB never moves at all.

The same 1 TiB crawl fits in one node

Take AWS’s own worked example and run it on the new hardware: a 1 TiB cache, fairly static, where the clients touch the recent month. In Europe (Spain), on 16xlarge Valkey:

One node holds the whole terabyte, at 52% utilization, for $81,000 a year less. The tiered cluster also has one-third of the failure surface of the three-node version, which no price list line item will admit.

The Hyderabad r7gd route is the same story with less memory: memory-only needs four r7g.16xlarge nodes at $22.96 an hour; one r7gd.16xlarge covers it at $8.72. About 62% off.

Two regions, Valkey only, and a 20%-hot workload

Actual inventory first. r8gd is priced in one region (Spain), r7gd in two (Spain and Hyderabad). The 14 established regions where r6gd lives (every one of the big ones) still get the older deal at 1.90x. The teams most likely to want a 4 TiB cache are rarely the teams where this is sold.

Then the design gates, all from the data tiering docs:

• Valkey 7.2+ only. r7gd/r8gd have no Redis OSS row; Redis OSS data tiering stays on r6gd.
• The cluster must be a replication group.
• Values can’t exceed 128 MiB, and the value should be bigger than the key. A cache of small keys and small values gets no SSD benefit.
• maxmemory policies are limited to the LRU/LFU and noeviction set.
• Durability-enabled clusters (Valkey 9) are excluded. You can’t tier your durable store.
• Backups restore only into another tiered cluster, can’t export to S3, and you can’t shift a workload between tiered and memory-only — scaling between the two means a fresh cluster and a restore.
• Not available with ElastiCache Serverless.

The 20%-hot rule is the one that decides your bill. If your clients read most of the dataset, data tiering is a premium for a pantry you don’t use. Check your own ratio first: ElastiCache’s CurrItems metric, split by memory and SSD tier, tells you the split without guessing.

What to do

1. Look up your region before your node. Not on this list? You’re on r6gd, and the numbers above don’t apply yet.
2. Measure the hot set. Memory-vs-SSD CurrItems on a current cluster tells you whether tiering earns its keep.
3. Fit the shape. The eligible workload has big values, small keys, cold reads you can absorb at +300µs, Valkey 7.2+, and no durability requirement.
4. Price by usable capacity. The per-GiB-hour number in this post is the one to put in your model, not the node sticker price.

The tiered node costs more and is the cheaper one. AWS prices the SSD at 1.52x and then hands you five times the room; the arithmetic only breaks when the workload is too hot to use it.