Non-Graviton ElastiCache Node on Eligible Workload

Loïc Fournier

CER:

CER-0146

Service Category

Databases

Cloud Provider

AWS

Service Name

AWS ElastiCache

Inefficiency Type

Suboptimal Instance Family Selection

Explanation

Many Redis and Memcached clusters still use legacy x86-based node types (e.g., cache.r5, cache.m5) even though Graviton-based alternatives are available. In-memory workloads tend to be highly compatible with Graviton due to their simplicity and reliance on standard CPU and memory usage patterns.Unless constrained by architecture-specific extensions or strict compliance requirements, most ElastiCache clusters can be transitioned with no application-level changes. Failing to migrate to Graviton results in unnecessary compute spend and missed opportunities to improve cache efficiency.

Relevant Billing Model

ElastiCache is billed hourly per node, based on:

Node type and size
Engine and region

Graviton node types typically deliver up to 40% lower cost for equivalent performance compared to x86.

Detection

Enumerate all ElastiCache clusters and identify those using x86-based families
Cross-check with cache.*g instance types available in the region and engine
Confirm that clusters have no known architecture-specific dependencies
Analyze memory and CPU usage patterns to validate fit with Graviton

Remediation

Switch node types to cache.r6g, cache.m6g, or cache.t4g equivalents
Update provisioning logic to default to Graviton families for new clusters
Pilot in non-prod or lower-tier environments to validate behavior and latency
Incorporate architecture reviews into ElastiCache lifecycle and scaling workflows

Relevant Documentation

Submit Feedback