AWS Graviton

AWS Graviton is the family of 64-bit ARM processors that AWS designs and installs in its own instances, so an instance type carrying a g after its generation number executes the ARM64 instruction set instead of x86-64. Teams meet the term when a service moves onto those instances and every artifact it ships, from container images to compiled binaries, has to be produced for arm64.

A Graviton instance carries no x86-64 translation layer. Whatever a service ships is either compiled for arm64 or emulated at a cost in speed, which is why Graviton usually surfaces as a build question before it surfaces as an operations question.

Definition

Graviton processors are designed by Annapurna Labs, an AWS subsidiary, and are built on Arm Neoverse cores. They are sold only as the CPU behind particular AWS instance types rather than as parts, so the term names a processor family and, by extension, the set of instance shapes that use it (AWS Graviton, checked on 2026-08-13). To a compiler, a package manager, or a container registry, a Graviton instance is an ARM64 Linux machine like any other.

Four generations have shipped so far. AWS keeps the current generation and the full instance family list on the page linked above, and older families are retired over time.

Reading the instance type name

The processor is visible in the instance type string, which AWS assembles from four parts (EC2 instance type naming conventions, checked on 2026-08-13). Taking m7gd.2xlarge apart:

Position matters when reading the letters. A g among the attribute letters names the processor, while a g in the leading position names an accelerated computing family and leaves the CPU architecture unstated. The safest check is the architecture recorded against the AMI or the launch template rather than the letters alone.

What ARM64 means to a build

One architecture goes by two names across tooling, which accounts for most of the confusion in build scripts. The Linux kernel and RPM-based distributions report aarch64, while Docker, Go, and Debian-family distributions write arm64. Both refer to the same instruction set, and an artifact tagged with one runs on a machine reporting the other.

Interpreted code moves between the two without a rebuild. Native code does not, and native code hides inside dependency trees: a Python wheel, a Node native addon, and a JVM library with a bundled shared object all pin an architecture inside an artifact that otherwise looks portable. AWS maintains language-by-language porting notes in the open source aws-graviton-getting-started repository.

Example

A service runs as a container on ARM64 instances, so its GitHub Actions workflow has to publish a linux/arm64 image. This workflow builds on GitHub's hosted ARM64 Linux runner, whose label is ubuntu-24.04-arm (GitHub-hosted runners reference, checked on 2026-08-13), then reads back the architecture the registry recorded.

name: publish
on:
  push:
    branches: [main]

jobs:
  image:
    runs-on: ubuntu-24.04-arm
    steps:
      - uses: actions/checkout@v4
      - run: uname -m
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - uses: docker/build-push-action@v6
        with:
          context: .
          platforms: linux/arm64
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

      - name: Confirm the published architecture
        run: |
          docker buildx imagetools inspect \
            ghcr.io/${{ github.repository }}:${{ github.sha }}

The uname -m step prints aarch64, which confirms the machine before anything is compiled. The inspect step ends the run with the platform the registry holds:

Name:      ghcr.io/example/app:9c1f2ab
MediaType: application/vnd.oci.image.manifest.v1+json
Digest:    sha256:5c8d1a2b3e4f50617283940a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e

Manifests:
  Platform:  linux/arm64

Two properties of that workflow are worth naming. The compiler runs on the same architecture the service deploys to, so an #ifdef guarding an x86 intrinsic, a dependency with no aarch64 wheel, or a test that depends on x86 memory ordering fails in the pull request instead of after deploy. And the published artifact is checked rather than assumed, because a platforms value dropped during a refactor produces an amd64 image that passes every build step and then fails at startup on the instance with exec format error.

The same build runs on an x64 machine by adding docker/setup-qemu-action@v3 before the buildx step and keeping platforms: linux/arm64. Every instruction in the build then goes through emulation, which lengthens compile-heavy steps and breaks a handful of toolchains outright, so emulation is the fallback when no ARM64 machine is available rather than the default.

When the same service also deploys to x86-64 hosts, the workflow builds each architecture and joins the results into one manifest list, so a single tag serves both. The job that produces the ARM64 half still belongs on an ARM64 machine for the reasons above.

Related Terms

• Building for Graviton targets on GitHub Actions: moving the build and test jobs of a pipeline that deploys to Graviton onto native ARM64 machines, with the image and path differences to expect.
• Linux ARM64 runners for GitHub Actions jobs: the ARM64 runner labels, machine sizes, and images available to a workflow.
• Instance type, and how the name encodes processor and size: the rest of the naming scheme the table above pulls apart.
• AWS Graviton: the upstream generation list and the instance families built on each one.
• EC2 instance type naming conventions: the family letters, generation numbers, and attribute letters in full.
• WarpBuild cloud runner documentation: the runner labels available for x64 and ARM64 GitHub Actions jobs.
• WarpBuild AWS BYOC configuration: the AWS account prerequisites for running GitHub Actions jobs on instances in your own account.
• WarpBuild pricing: per minute rates by runner type.