Cutting Amazon ECS Costs by Migrating to Graviton

No matter which launch type you're on, EC2 or Fargate, the starting point is identical: build your container as a multi-architecture image so a single tag runs on both x86 and ARM64. Once the image runs anywhere, the migration boils down to two things, steering which architecture your tasks land on and pacing how fast you move traffic from one to the other.

ECS on EC2

With the EC2 launch type, the architecture your task runs on is ultimately decided by the instances in your cluster. If you leave runtimePlatform.cpuArchitecture unset in the task definition, ECS doesn't force a particular architecture. It simply places the task wherever there's suitable capacity, which means the mix of instances behind your cluster determines what your tasks actually run on.

That gives you a clean lever for a gradual rollout: capacity providers. Rather than flipping the whole service at once, back the service with two capacity providers, one fronting an x86 Auto Scaling group and another fronting a Graviton group. By assigning weights to each provider, you control the proportion of new tasks that land on ARM versus x86. Start with a small slice of traffic on Graviton, watch your metrics, and increase the Graviton weight step by step as confidence grows. If something looks wrong, you dial the weight back down. This turns a risky one-shot migration into a controlled, reversible ramp.

ECS on Fargate

Fargate behaves differently because there's no cluster of instances you manage. Here the task definition itself decides the architecture, and the default matters: if you don't set runtimePlatform.cpuArchitecture, Fargate provisions the task as x86. In other words, you don't drift onto Graviton by accident. To move a Fargate workload to ARM, you have to declare ARM64 explicitly in the task definition.

There are two common ways to actually make the switch. The straightforward approach is to register the ARM64 task definition and run an update-service, which performs a rolling replacement of the running tasks. If you want a more cautious, side-by-side comparison before committing, use a blue/green deployment instead. That lets you stand up the Graviton version alongside the existing x86 version and shift traffic over gradually, giving you a canary-style validation window and a fast rollback if the new version misbehaves.

The Common Thread

Regardless of launch type, the shape of a safe migration is the same. The container image stays multi-architecture so it runs identically on either processor family, and the real work is controlling how traffic moves from x86 to Graviton. On EC2 you steer that shift through weighted capacity providers; on Fargate you do it through a rolling update-service or a blue/green traffic shift. Both approaches let you validate Graviton against real load before you fully commit, so you capture the cost savings without betting the whole service on a single cutover.

Further Reading

For AWS guidance on running ARM workloads on ECS, see the documentation on 64-bit ARM workloads on Amazon ECS and the RuntimePlatform API reference.