Graviton Migration: 20-40% AWS Compute Cost Savings

AWS Graviton migration is one of the highest-return, lowest-risk cost optimization moves available on AWS. Graviton3-based instances (arm64 architecture) deliver comparable or better performance to equivalent x86 instances at 20–40% lower cost. For most web application workloads, API services, and container-based deployments, the migration is straightforward.

This post covers the assessment process, migration mechanics, what breaks, and what the actual savings look like.

Why Graviton Is Underused

The hesitation is architectural: Graviton uses ARM64, not x86. Teams assume they need to recompile everything, that third-party dependencies won't work, and that the migration is a major engineering project.

In practice, for modern containerized applications built with interpreted or managed runtimes, Graviton migration is a configuration change:

• Python: Zero recompilation. AWS Lambda and EC2 both support Python on arm64 natively.
• Node.js: Zero recompilation.
• Java (JVM): Zero recompilation — bytecode is architecture-agnostic.
• Go: Recompile with GOARCH=arm64. Single command, typically done in CI.
• Docker: Multi-arch images via Docker Buildx. Build arm64 image alongside x86.
• Native C/C++ extensions in Python: Needs recompile or arm64 wheel availability. Most popular packages have arm64 wheels on PyPI.

The main blocker: custom compiled code or rarely-maintained dependencies without arm64 builds.

Graviton Migration Cost Savings: The Numbers

AWS pricing comparison (us-east-1, on-demand):

Lambda pricing: arm64 functions cost 20% less than x86 at identical memory configuration.

RDS Aurora: Graviton3-based Aurora instances offer ~18–20% cost reduction vs. equivalent x86.

For a workload running $10,000/month in EC2, Graviton migration saves approximately $2,900–$4,000/month — without any other changes.

Assessment: What Can Migrate Easily

Before migrating anything, assess the stack:

Containerized workloads (ECS/EKS)

Check each container image for architecture compatibility:

# Check existing image architecture
docker inspect --format='{{.Architecture}}' <image>

# Check if arm64 variant exists on Docker Hub / ECR
docker manifest inspect <image> | grep -A2 '"platform"'

For images you build: add arm64 build step to CI pipeline. For third-party images: check Docker Hub for multi-arch tags. Most major images (nginx, postgres, redis, elasticsearch) have arm64 variants.

Lambda functions

Check runtimes and layers:

• Python 3.x, Node.js, Java: change Architectures: [arm64] in SAM/CDK/Terraform. Done.
• Custom runtimes with native extensions: assess each dependency.
• Lambda layers: check if layers have arm64 variants. AWS-managed layers do; custom layers may not.

EC2 instances

For each instance running x86:

1. List running software on the instance
2. Check if native compiled binaries exist (file /usr/bin/myapp — shows architecture)
3. For common software (nginx, postgres, redis): arm64 packages available via standard package managers
4. For custom compiled software: rebuild from source on arm64 test instance

RDS / Aurora

RDS Aurora Graviton migration is an instance class change. Aurora storage is architecture-agnostic. Migration path:

1. Create read replica with Graviton instance class
2. Monitor performance metrics for 1–2 weeks
3. Promote replica or modify primary to Graviton class in next maintenance window

Migration Playbook: Containerized Applications

This is the highest-value migration for most teams.

Step 1: Add arm64 builds to CI

# GitHub Actions example
- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3

- name: Build and push multi-arch image
  uses: docker/build-push-action@v5
  with:
    platforms: linux/amd64,linux/arm64
    push: true
    tags: ${{ env.ECR_REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

Step 2: Test arm64 image locally

# Run arm64 image on M-series Mac (arm64 native) or via QEMU
docker run --platform linux/arm64 $IMAGE_NAME:latest
# Run integration tests

Step 3: Deploy to a Graviton test environment

Create a parallel ECS task definition or EKS node group with Graviton instances. Route a percentage of traffic. Monitor for 1–2 weeks.

Step 4: Full cutover

Update your Terraform/CDK/CloudFormation to specify Graviton instance types across the environment.

# Terraform ECS task definition
resource "aws_ecs_task_definition" "app" {
  ...
  runtime_platform {
    cpu_architecture        = "ARM64"
    operating_system_family = "LINUX"
  }
}

# EKS node group
resource "aws_eks_node_group" "app" {
  ...
  instance_types = ["m7g.xlarge"]  # Graviton3
}

What Breaks

Native binary dependencies without arm64 builds: Rare in modern stacks but real. Mitigation: run a dependency audit before starting.

Old AMIs: Custom AMIs based on Amazon Linux 2 x86 need to be rebuilt for arm64. Use Amazon Linux 2023 which has native arm64 AMIs.

Third-party agents and sidecars: APM agents (Datadog, New Relic), security agents — check for arm64 support before migrating. Most major vendors have arm64 support now.

Performance regression on certain workloads: Graviton is not faster for everything. Heavy single-threaded workloads with specific x86 instruction dependencies may not see improvement. Always benchmark before committing.

What We Delivered

One production SaaS platform we manage ran the majority of its compute on x86 instances. After an arm64 assessment and migration:

• ECS services migrated to Graviton3: 28% monthly compute reduction
• Lambda functions migrated to arm64: 20% cost reduction
• Timeline: 3 weeks from assessment to full production cutover

For the infrastructure patterns behind this, see our AWS Cloud Infrastructure capability and our broader cost optimization approach in FinOps Consulting Services.

AWS also publishes Graviton migration tooling and guidance that covers language-specific considerations in depth.

Frequently Asked Questions

Is Graviton performance actually equivalent to x86?

Graviton3 performance is comparable to x86 on most web and data processing workloads, and often faster on throughput-oriented tasks due to better memory bandwidth. Single-threaded performance on CPU-bound tasks can be slightly lower. Always benchmark your specific workload — AWS has a free benchmarking tool for this.

Do we need to change our application code?

For interpreted runtimes (Python, Node.js, Ruby) and JVM-based applications (Java, Kotlin, Scala): no code changes. For Go: recompile with arm64 target. For C/C++ or Rust: recompile. For native extensions in Python: check for arm64 wheels.

Can Graviton run in the same Auto Scaling Group as x86 instances?

An ASG with mixed instance types can include both x86 and arm64 instances, but they won't share container images unless images are multi-arch. Cleaner to use separate node groups or launch templates for arm64 instances.

What about reserved instances on x86 that we've already purchased?

Existing RIs continue to apply to x86 instances. Plan Graviton migration timing around RI expiration dates to maximize savings. For active RIs, AWS Marketplace allows RI resale, though at a discount.

How does Graviton affect our Lambda cold start times?

Graviton-based Lambda functions generally have comparable or slightly faster cold start times vs. x86 at the same memory configuration — an additional benefit on top of the cost reduction.

Get a free AWS cost review → rutagon.com/contact