ElastiCache M7g vs R7g vs C7gn: What Memory-Scaled Keyspaces Reveal
Node memory changes the test before the run starts
AWS lists these ElastiCache node types with very different memory envelopes: 6.38 GiB for M7g, 13.07 GiB for R7g, and 3.09 GiB for C7gn. The reports explicitly state that this configured memory value is used to calculate the memtier keyspace.
The implied full targets confirm the scaling. The M7g baseline resolves to about 3.722 million keys, the R7g evidence to about 7.649 million, and the C7gn evidence to about 1.805 million. Normalized by node memory, all three land between roughly 583,000 and 585,000 keys per GiB.
One client budget, three pressure outcomes
Stacked values show the minimum and maximum across three one-hour runs. They are not negative values.
The one-hour window measures time to memory pressure
C7gn reached its smaller memory-scaled target first. All three runs began evicting between 27m 18s and 28m 57s, the 27m 18s run is the earliest example. M7g reached its larger target much later: two runs started evicting at 51m 15s and 58m 59s, while the third ended at 99.89% memory without an eviction. The 51m 15s M7g run shows the earlier boundary case.
R7g finished with 30.8% to 32.4% memory headroom and zero evictions because the same client budget did not fill its much larger keyspace within the hour. That is a valid observation about this execution window. It is not proof that R7g carried the same absolute working set as M7g or C7gn with extra capacity.
Throughput ranges do not support a family ranking
The medians were 42,921 ops/s for M7g, 46,509 for R7g, and 43,351 for C7gn. The run ranges overlap heavily: M7g ran from 41,990 to 49,743 ops/s, R7g from 44,582 to 46,789, and C7gn from 41,589 to 46,270. The best M7g run exceeded every R7g and C7gn run, so the median order cannot be promoted into an architecture ranking.
Median latency is equally compressed at 0.42, 0.38, and 0.41 ms. Average latency alone does not expose that C7gn spent roughly half of each run under eviction pressure while R7g never filled its configured keyspace.
CPU and network claims remain outside this evidence
Peak engine CPU stayed between 30.7% and 39.8% across all nine runs. The relevant ElastiCache CPU, memory, eviction, and network metrics therefore do not show an engine-CPU saturation test here. C7gn also recorded the highest median total bandwidth, but there is no saturation telemetry, payload sweep, or connection-shape experiment proving that its network design produced an application benefit.
C7gn is not a Graviton3E architecture control. It changes CPU generation, family role, memory, and calculated keyspace at the same time. Any statement about Graviton3E versus Graviton3 would require those other variables to be controlled.
Two measurement contracts are still required
- True fixed workload: use the same absolute keyspace, payload distribution, command mix, worker count, and duration on every node. That answers what happens when one application working set is placed on each design.
- Calibrated fixed pressure: adjust the keyspace or execution budget separately until every node reaches a declared memory-utilization target, then repeat the measured runs. That answers how the systems behave at comparable resource pressure.
The same-memory M-series analysis and same-memory R-series analysis avoid this specific cross-family keyspace confound. A calibrated pressure experiment should follow the measurement discipline described in Designing for the Cliff.
The configuration is part of the result
The useful conclusion is not that one family wins. The fixed nine-worker budget filled the memory-scaled C7gn keyspace early, brought M7g to the boundary late, and left the larger R7g keyspace incomplete. Exposing that dependency makes the evidence more useful: it shows exactly which decision this dataset can support and which comparison must be run next.