Graviton (ARM) Instances

AWS Graviton processors are CPUs (Central Processing Units, the chips that run your code) designed by AWS using the ARM64 architecture instead of the more familiar x86 architecture from Intel and AMD. The headline benefit is price-performance: for most workloads, Graviton delivers roughly 20-40% better performance per dollar than comparable x86 instances. That means you can often run the same workload faster, cheaper, or both, simply by changing the instance type. The one catch is that your software must be able to run on ARM64, so this page explains both why you should care and how to migrate safely.

What “architecture” means and why it matters

A CPU architecture is the instruction set the chip understands. For decades, servers ran on x86-64 (also called amd64), the architecture used by Intel and AMD. ARM64 (also called aarch64) is a different instruction set, originally common in phones, now widely used in servers because it is power-efficient and cheap to operate.

This matters because compiled programs are built for one architecture. An x86-64 binary (a compiled executable) will not run on an ARM64 chip and vice versa. Most modern software supports both, but you need to confirm it before you migrate.

When to use Graviton (and when not to)

Use Graviton when:

You run common server workloads: web servers, application servers, microservices, caches, databases, and batch jobs.
Your code is in an interpreted or managed language (Python, Node.js, Ruby, Java, .NET, Go). These usually “just work” because the runtime handles the architecture.
You use containers and can rebuild multi-architecture images.
You care about cost. The savings are real and require almost no code changes for most apps.

Avoid (or test carefully) when:

You depend on closed-source native binaries that ship only for x86-64 (some commercial agents, licensed drivers, or old vendor tools).
You use libraries with compiled native extensions that have no ARM64 build.
You rely on x86-specific CPU features or hand-written x86 assembly.

Gotcha: interpreted languages and containers usually run on Graviton with no changes, but native binaries, monitoring agents, and old dependencies may need rebuilding. Always test on a single Graviton instance before mass-migrating a fleet.

The Graviton instance families

Graviton instances are easy to spot: their type name contains the letter g (for Graviton). The current generation is Graviton4 (used in *8g types like m8g); Graviton3 (*7g) is still extremely common and well supported.

Instance family	Best for	Example use case
`m7g` / `m8g`	General purpose (balanced CPU and memory)	Web apps, microservices, small databases
`c7g` / `c8g`	Compute optimized (more CPU per GB of RAM)	Batch processing, encoding, high-traffic APIs
`r7g` / `r8g`	Memory optimized (more RAM per CPU)	In-memory caches, large databases
`t4g`	Burstable, cheapest entry point	Dev/test, low-traffic sites

Tip: t4g instances are a great way to try Graviton cheaply. AWS has at times offered a free trial of t4g.micro, but always check current pricing before relying on it.

How to launch a Graviton instance

The only real difference from launching any other instance is two things: you pick a g instance type, and you pick an ARM64 AMI (Amazon Machine Image, the disk template your instance boots from). An x86 AMI will not boot on Graviton.

Console steps

Open the EC2 console and choose Launch instances.
Under Application and OS Images (AMI), pick your operating system, then look for the Architecture dropdown and select 64-bit (Arm). Many AMIs (Amazon Linux 2023, Ubuntu) offer both; you must choose the Arm variant.
Under Instance type, choose a Graviton type such as m7g.large or t4g.medium.
Select your key pair, VPC/subnet, and security group as usual.
Choose Launch instance.

AWS CLI

First, find the correct ARM64 AMI. The example below fetches the latest Amazon Linux 2023 ARM64 image from the Systems Manager public parameter store, then launches an m7g.large.

# Get the latest Amazon Linux 2023 ARM64 AMI id
aws ssm get-parameters \
  --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64 \
  --query "Parameters[0].Value" \
  --output text

Output:

ami-0abcdef1234567890

# Launch a Graviton instance using that ARM64 AMI
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type m7g.large \
  --key-name my-key \
  --security-group-ids sg-0a1b2c3d \
  --subnet-id subnet-0a1b2c3d \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=graviton-web}]'

Output:

{
    "Instances": [
        {
            "InstanceId": "i-0a1b2c3d4e5f",
            "InstanceType": "m7g.large",
            "Architecture": "arm64",
            "State": { "Name": "pending" }
        }
    ]
}

Notice "Architecture": "arm64" in the result. If you accidentally paired an x86 AMI with a g instance type, run-instances fails with an error about incompatible architecture.

Testing your software before you migrate

The safe migration path is to verify, not assume. A simple checklist:

Launch one t4g instance with an ARM64 AMI.
Deploy your application and run its full test suite.
Confirm every dependency installs. For native packages, check that pip, npm, or your package manager pulls an ARM64 build, not a source build that may fail.
Confirm third-party agents (monitoring, security, logging) have ARM64 versions installed and running.
Load-test and compare metrics against your x86 baseline.

For containers, build multi-architecture images so the same tag runs everywhere:

docker buildx build --platform linux/amd64,linux/arm64 \
  -t myrepo/myapp:1.0 --push .

A quick cost example

Suppose you run an m6i.large (x86) on demand at about $0.096/hour. The equivalent m7g.large (Graviton) runs at roughly $0.0816/hour, about 15% cheaper per hour before counting Graviton’s performance gains. Over a fleet of 50 instances running 24/7, that hourly difference alone is roughly $520/month saved, and the per-request efficiency gains often push real savings higher. Prices vary by Region, so check the current rates.

Best practices

Start with a single t4g instance to validate your software cheaply before committing.
Always pick an ARM64/aarch64 AMI when using a g instance type; the two must match.
Build multi-architecture container images so you can move between x86 and Graviton without code changes.
Audit third-party agents and native dependencies for ARM64 support early; these are the usual blockers.
Use the latest generation (m8g/c8g where available) for the best price-performance, falling back to m7g/c7g for broad support.
Combine Graviton with Savings Plans or Reserved Instances to stack discounts on top of the architecture savings.
Keep your CI/CD pipeline building both architectures during migration so you can roll back instantly.