Amazon ElastiCache – Consider Using Graviton Instances

The Amazon ElastiCache Graviton policy flags ElastiCache nodes on x86 types such as cache.m5 and recommends the AWS Graviton equivalent, such as cache.m6g. Graviton nodes cost less per hour than x86 nodes with the same vCPU count and memory. AWS reports up to 45% better price/performance than previous generation nodes. Apply this policy to any aws_elasticache_cluster or aws_elasticache_replication_group whose node_type has a Graviton equivalent.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Amazon ElastiCache bills each node by the hour for as long as the cluster runs. Cache clusters usually run around the clock, so the hourly node rate becomes a fixed monthly cost.

AWS Graviton processors are Arm-based CPUs designed by AWS. Amazon ElastiCache added Graviton2 node types (m6g and r6g) in October 2020, and later added t4g and the Graviton3-based m7g and r7g.

For the same size, a Graviton node matches the x86 node on vCPU count and memory. A cache.m6g.xlarge and a cache.m5.xlarge both have 4 vCPUs and 12.93 GiB of memory.

Applications reach Amazon ElastiCache over the network, so the processor architecture is invisible to client code. This is why the Graviton switch is one of the lowest-effort cost changes available for a cache tier.

Potential Savings

The Amazon ElastiCache Graviton policy saves money because the Graviton node costs less per hour than the x86 node it replaces.

Monthly figures assume 730 hours at US East (N. Virginia) on-demand rates for Redis OSS and Memcached. Prices vary by region, engine, and purchase option.

Moving one cache.m5.xlarge node to cache.m6g.xlarge saves about $10 per month, or roughly $120 per year. A replication group with one primary and two replicas triples that saving, because every node in the group changes type.

The per-node saving is modest on its own. The case for Graviton combines a lower hourly rate with better price/performance. That combination can let a team run the same load on fewer or smaller nodes.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Amazon ElastiCache replication group on an x86 node type, and the corrected configuration on Graviton.

Non-compliant configuration: Redis OSS replication group on cache.m5

resource "aws_elasticache_replication_group" "sessions" {
  replication_group_id       = "sessions"
  description                = "Session store"
  engine                     = "redis"
  engine_version             = "7.1"
  node_type                  = "cache.m5.xlarge"
  num_cache_clusters         = 3
  automatic_failover_enabled = true
  parameter_group_name       = "default.redis7"
  port                       = 6379
  subnet_group_name          = aws_elasticache_subnet_group.cache.name
  security_group_ids         = [aws_security_group.cache.id]
}

resource "aws_elasticache_replication_group" "sessions" {
  replication_group_id       = "sessions"
  description                = "Session store"
  engine                     = "redis"
  engine_version             = "7.1"
  node_type                  = "cache.m5.xlarge"
  num_cache_clusters         = 3
  automatic_failover_enabled = true
  parameter_group_name       = "default.redis7"
  port                       = 6379
  subnet_group_name          = aws_elasticache_subnet_group.cache.name
  security_group_ids         = [aws_security_group.cache.id]
}

resource "aws_elasticache_replication_group" "sessions" {
  replication_group_id       = "sessions"
  description                = "Session store"
  engine                     = "redis"
  engine_version             = "7.1"
  node_type                  = "cache.m5.xlarge"
  num_cache_clusters         = 3
  automatic_failover_enabled = true
  parameter_group_name       = "default.redis7"
  port                       = 6379
  subnet_group_name          = aws_elasticache_subnet_group.cache.name
  security_group_ids         = [aws_security_group.cache.id]
}

This configuration pays the x86 hourly rate on three nodes for the same vCPU count and memory a Graviton node provides at a lower price. This is a common source of wasted spend in cache tiers built before Graviton nodes were available.

Compliant configuration: Redis OSS replication group on cache.m6g

resource "aws_elasticache_replication_group" "sessions" {
  replication_group_id       = "sessions"
  description                = "Session store"
  engine                     = "redis"
  engine_version             = "7.1"
  node_type                  = "cache.m6g.xlarge"
  num_cache_clusters         = 3
  automatic_failover_enabled = true
  parameter_group_name       = "default.redis7"
  port                       = 6379
  subnet_group_name          = aws_elasticache_subnet_group.cache.name
  security_group_ids         = [aws_security_group.cache.id]
  apply_immediately          = false
}

resource "aws_elasticache_replication_group" "sessions" {
  replication_group_id       = "sessions"
  description                = "Session store"
  engine                     = "redis"
  engine_version             = "7.1"
  node_type                  = "cache.m6g.xlarge"
  num_cache_clusters         = 3
  automatic_failover_enabled = true
  parameter_group_name       = "default.redis7"
  port                       = 6379
  subnet_group_name          = aws_elasticache_subnet_group.cache.name
  security_group_ids         = [aws_security_group.cache.id]
  apply_immediately          = false
}

resource "aws_elasticache_replication_group" "sessions" {
  replication_group_id       = "sessions"
  description                = "Session store"
  engine                     = "redis"
  engine_version             = "7.1"
  node_type                  = "cache.m6g.xlarge"
  num_cache_clusters         = 3
  automatic_failover_enabled = true
  parameter_group_name       = "default.redis7"
  port                       = 6379
  subnet_group_name          = aws_elasticache_subnet_group.cache.name
  security_group_ids         = [aws_security_group.cache.id]
  apply_immediately          = false
}

The only functional change is the node_type value. Setting apply_immediately = false defers the modification to the replication group's next maintenance window instead of applying it as soon as Terraform runs.

The same fix applies to a Memcached cluster defined with aws_elasticache_cluster:

resource "aws_elasticache_cluster" "catalog" {
  cluster_id           = "catalog-cache"
  engine               = "memcached"
  node_type            = "cache.m6g.large" # previously "cache.m5.large"
  num_cache_nodes      = 2
  parameter_group_name = "default.memcached1.6"
  port                 = 11211
}

resource "aws_elasticache_cluster" "catalog" {
  cluster_id           = "catalog-cache"
  engine               = "memcached"
  node_type            = "cache.m6g.large" # previously "cache.m5.large"
  num_cache_nodes      = 2
  parameter_group_name = "default.memcached1.6"
  port                 = 11211
}

resource "aws_elasticache_cluster" "catalog" {
  cluster_id           = "catalog-cache"
  engine               = "memcached"
  node_type            = "cache.m6g.large" # previously "cache.m5.large"
  num_cache_nodes      = 2
  parameter_group_name = "default.memcached1.6"
  port                 = 11211
}

Step-by-Step Fix Instructions

1. Search Terraform code for node_type values on aws_elasticache_cluster and aws_elasticache_replication_group resources that use x86 families such as cache.m5, cache.r5, or cache.t3.

2. Check shared modules, .tfvars files, and variable defaults. The node type often sits in a variable "node_type"default rather than the resource block.

3. Confirm the engine version meets the Graviton minimum. AWS lists Redis OSS 5.0.6 for m6g and r6g, Redis OSS 6.2 for m7g and r7g, Valkey 7.2, and Memcached 1.5.16.

4. Pick the Graviton node with the same size suffix, for example cache.m5.xlarge to cache.m6g.xlarge, or cache.r5.large to cache.r6g.large.

5. Change the node_type value and run terraform plan. Confirm the plan shows an in-place update to node_type, not a resource replacement.

6. Apply the change to a non-production Amazon ElastiCache cluster first and watch latency, CPU, and eviction metrics in Amazon CloudWatch.

7. Roll the change to production during a maintenance window.

8. Add Infracost to CI/CD so new x86 node types are flagged in pull requests before they merge.

Best Practices

• Default new Amazon ElastiCache clusters to Graviton node types in shared Terraform modules, and require a stated reason to use an x86 node type.

• Migrate non-production and read-heavy caches first. These carry the least risk if a client or engine issue appears.

• Review reserved nodes before migrating. A reserved node purchased for an x86 family does not cover Graviton node usage, so time the switch with the reservation end date.

• Upgrade older Redis OSS engine versions before or alongside the node change, since Graviton node types have minimum engine versions.

• Evaluate Valkey as a separate cost lever. AWS prices node-based Valkey 20% lower than Redis OSS, on top of the Graviton rate.

• This policy targets node type only. Right-sizing an over-provisioned cache is a separate decision that often saves more than the architecture change.

Tools and Scripts

How does Infracost detect x86 Amazon ElastiCache node types automatically?

The Amazon ElastiCache Graviton policy is available in Infracost, including in the free trial. Enable FinOps policies in Infracost Cloud and run Infracost in CI/CD. Each pull request that adds or changes an ElastiCache resource with an x86 node type then gets a finding in the PR comment.

The same Infracost pull request comment shows the estimated monthly cost of the change. Reviewers see what a cache.m5.xlarge replication group costs before it merges, not on next month's AWS bill.

Engineers can dismiss a finding in the pull request with a reason, for example a client that has not been validated on Arm. FinOps teams can see those dismissals and the reasons behind them.

Infracost Cloud also tracks the percentage of issues fixed, the open issues that remain, and the new issues prevented in pull requests. This lets platform and FinOps teams burn down existing x86 ElastiCache nodes over time and report measurable progress.

To find x86 Amazon ElastiCache node types in a Terraform codebase:

grep -rnE 'cache\.(m5|r5|t3|m4|r4|t2)\.[0-9]*x?(large|medium|small|micro)' --include="*.tf" --include="*.tfvars"

grep -rnE 'cache\.(m5|r5|t3|m4|r4|t2)\.[0-9]*x?(large|medium|small|micro)' --include="*.tf" --include="*.tfvars"

grep -rnE 'cache\.(m5|r5|t3|m4|r4|t2)\.[0-9]*x?(large|medium|small|micro)' --include="*.tf" --include="*.tfvars"

To list running Amazon ElastiCache clusters and their node types with the AWS CLI:

aws elasticache describe-cache-clusters \
  --query "CacheClusters[].{id:CacheClusterId,type:CacheNodeType,engine:Engine,version:EngineVersion}" \
  --output

aws elasticache describe-cache-clusters \
  --query "CacheClusters[].{id:CacheClusterId,type:CacheNodeType,engine:Engine,version:EngineVersion}" \
  --output

aws elasticache describe-cache-clusters \
  --query "CacheClusters[].{id:CacheClusterId,type:CacheNodeType,engine:Engine,version:EngineVersion}" \
  --output

If a cluster is managed by Terraform, change node_type in code rather than in the AWS console. Otherwise the next terraform apply sets the old node type again.

Examples of Impact

Savings from the Amazon ElastiCache Graviton policy scale with node count, because the code change per resource is one attribute.

Illustrative example: a session store replication group. A platform team runs a Redis OSS replication group with three cache.m5.xlarge nodes. Moving to cache.m6g.xlarge cuts on-demand cost by about $30 per month, roughly $370 per year, with no client code changes.

Illustrative example: a multi-environment cache fleet. A team runs 30 cache.r5.large nodes across development, staging, and production. Switching all of them to cache.r6g.large saves about $220 per month at US East on-demand rates, and the non-production nodes become a low-risk first step.

(These are illustrative scenarios, not specific customer accounts.)

Considerations and Caveats

The Amazon ElastiCache Graviton switch is low risk for most caches, but engine versions and reservations are where it goes wrong.

• Minimum engine versions. m6g and r6g nodes require Redis OSS 5.0.6 or later, and m7g and r7g require Redis OSS 6.2. All of these Graviton node types support Valkey 7.2 and Memcached 1.5.16 or later. Older clusters need an engine upgrade first.

• Modest per-node saving. At US East on-demand rates, m6g and r6g nodes cost about 4.5% less than m5 and r5. Larger savings come from fleet size and from running fewer nodes.

• Reserved nodes do not move. Reserved nodes bought for an x86 family keep billing until they expire, even after the cluster moves to Graviton.

• Brief disruption is possible. A node type change modifies the running cluster. Test on non-production clusters and apply in a maintenance window.

• Provider-specific. This policy targets Amazon ElastiCache through the aws Terraform provider. Other managed caches do not offer AWS Graviton nodes.

Related Policies and Concepts

• Amazon ElastiCache - consider using latest generation nodes for r family nodes: the generation upgrade for memory-optimized ElastiCache nodes, often paired with a Graviton move.

• Amazon ElastiCache - consider using latest generation nodes for t family nodes: the burstable-node equivalent, where cache.t4g is the Graviton option.

• Amazon ElastiCache - consider upgrading Redis version to avoid extended support costs: an engine upgrade is often needed before a Graviton switch.

• Amazon RDS - consider using Graviton instances: the same Graviton cost change applied to aws_db_instanceclasses such as db.m6g.

• AWS EC2 - consider using Graviton instances: the Compute-group policy for moving x86 EC2 instances to Arm-based Graviton types.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Amazon ElastiCache Graviton policy is supported in Infracost and available in the free trial. Infracost flags ElastiCache resources that use x86 node types in pull request comments. The team can then switch the node type before merge.

Can this policy be customized?

Yes. Teams choose which Infracost policies are enabled in Infracost Cloud, including the Amazon ElastiCache Graviton policy. Engineers can also dismiss a specific finding with a stated reason, such as an untested client library. FinOps teams can review that reason.

Does Infracost automatically fix violations?

No. Infracost reports each Amazon ElastiCache node type that has a Graviton equivalent and shows the cost of the change in the pull request. Changing the node_type value and testing the workload on the new node type is a decision the team makes and applies.

Is this policy cloud-agnostic?

No. The Amazon ElastiCache Graviton policy targets Amazon ElastiCache through the aws Terraform provider. Azure Cache for Redis and Google Cloud Memorystore have their own tiers and resource names, and neither uses AWS Graviton processors.

Do applications need code changes to use Amazon ElastiCache Graviton nodes?

Usually not. Applications connect to Amazon ElastiCache over the network, so client code is not compiled for the node's processor. The Amazon ElastiCache engine version must still meet the Graviton minimum. AWS lists Redis OSS 5.0.6 for m6g and r6g, and Redis OSS 6.2 for m7g and r7g.

Does changing the Amazon ElastiCache node type cause downtime?

It can cause a brief disruption. Amazon ElastiCache applies a node type change as a modification of the existing cluster. The impact depends on the engine and topology. Test the change on a non-production Amazon ElastiCache cluster and apply it in a maintenance window.

How often should I review Amazon ElastiCache node types?

Teams running Infracost in CI/CD get an Amazon ElastiCache Graviton check on every pull request that touches an ElastiCache resource. For clusters already running, a quarterly review of Amazon ElastiCache node types is a reasonable cadence for most teams.