Run ECS Fargate Workloads on Graviton ARM for Lower Cost (2026)

You can run your ECS Fargate workloads on AWS Graviton ARM processors and slash your compute costs by up to 40% without changing your application code.

Let’s see this in action. Imagine you have a simple web service running in ECS Fargate.

{
  "family": "my-web-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "cpu": "1024",
  "memory": "2048",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "nginx",
      "image": "public.ecr.aws/nginx/nginx:latest",
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "essential": true
    }
  ]
}

This defines a basic Nginx container. Currently, it’s configured to run on x86 architecture. To switch to Graviton, you’ll make a subtle but crucial change in your task definition.

Here’s the Graviton-enabled task definition:

{
  "family": "my-web-app-graviton",
  "networkMode": "awsvpc",
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "cpu": "1024",
  "memory": "2048",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "runtimePlatform": {
    "cpuArchitecture": "ARM64",
    "operatingSystemFamily": "LINUX"
  },
  "containerDefinitions": [
    {
      "name": "nginx",
      "image": "public.ecr.aws/nginx/nginx:latest",
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "essential": true
    }
  ]
}

The key addition is the "runtimePlatform" block, specifically "cpuArchitecture": "ARM64". This tells Fargate to provision ARM-based underlying infrastructure for your tasks.

The problem this solves is straightforward: x86 processors are the default and, historically, the most performant option. However, for many workloads, especially those that are not CPU-bound or are designed for efficient execution, the ARM architecture offers a significantly better price-performance ratio. Graviton processors are specifically designed for cloud workloads, delivering more performance per watt and, consequently, lower costs.

Internally, when you specify "ARM64", Fargate selects underlying Nitro-based EC2 instances powered by Graviton processors. These instances are optimized for density and cost-efficiency. Your container image, if it’s a multi-architecture image (which most official images are, including Nginx), will automatically be pulled and run on the ARM64 variant. If your image is not multi-architecture, you’ll need to build and push an ARM64-compatible version.

The levers you control are primarily:

1. runtimePlatform.cpuArchitecture: This is the direct switch to ARM64.
2. Container Image: Ensure your container image is compatible. For many applications, this means using official base images (like amazonlinux:latest, ubuntu:latest, node:latest, python:latest) which are typically multi-arch. If you’re building custom images, use a multi-arch build tool like Docker Buildx and specify linux/arm64 as a target platform.
3. Task Definition CPU/Memory: You can often right-size your CPU and memory for ARM. Because Graviton offers better performance per vCPU in many cases, you might be able to use fewer vCPUs or a smaller memory footprint for the same workload, leading to even more savings.

When you switch a Fargate task definition to ARM64, Fargate will provision underlying Graviton instances. The key insight is that AWS has heavily optimized the cost of these Graviton instances. They are priced such that for a given performance level, they are cheaper than their x86 counterparts. This isn’t just a slight discount; it’s a fundamental difference in cost structure driven by the efficiency of the ARM architecture and AWS’s investment in it. The pricing difference is reflected directly in Fargate’s per-vCPU-hour and per-GB-hour rates.

Most people focus on the cpuArchitecture setting, assuming their existing images will just work. What they often miss is that for custom-built images or less common software, you must explicitly build and test an ARM64 variant. If your image only contains x86 binaries, it will fail to start on an ARM64 Fargate task, leading to frustrating debugging loops. The docker buildx build --platform linux/arm64 ... command is your friend here.

The next concept you’ll naturally explore is optimizing your ARM64 task definitions further by right-sizing CPU and memory, potentially discovering that ARM64 Graviton instances handle your workload with fewer resources than their x86 equivalents, compounding your cost savings.