Deploy a container on AWS Graviton processors with Amazon ECS Managed Instances
Introduction
Set up IAM roles and an Arm-compatible task definition
Create a capacity provider for Graviton-based instances
Run a container as an Amazon ECS task on AWS Graviton
Clean up AWS resources
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Introductory
Reading time:  1 hr
Last updated:  02 Oct 2026
Skill level:
  Introductory
Reading time:
  1 hr
Last updated:
  02 Oct 2026
Author:Anupras Mohapatra, Arm
Arm IP:Neoverse
Tags: Containers and Virtualization AWS Graviton Linux Amazon ECS
Author:
  • Anupras Mohapatra, Arm
Arm IP:
Neoverse
Tags:
Containers and Virtualization AWS Graviton Linux Amazon ECS

Who is this for?

This is an introductory topic for developers who want to deploy containers on AWS Graviton processors with Amazon Elastic Container Service (ECS) using Amazon ECS Managed Instances.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Create an Amazon ECS cluster for ECS Managed Instances.
  • Create a capacity provider that selects Arm-based instances powered by AWS Graviton.
  • Create and run an Arm-compatible Amazon ECS task, and verify that it runs on AWS Graviton-based compute.

Prerequisites

Before starting, you will need the following:

  • An AWS account with permissions to create AWS IAM roles and access Amazon ECS
  • A VPC with public subnets and a security group that allows inbound traffic on port 80
  • The AWS CLI installed on your development machine

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll deploy an NGINX container on Amazon ECS Managed Instances and verify that it runs on AWS Graviton-based compute. First, you’ll create the required IAM roles and register a task definition for the ARM64 architecture. You’ll then create a cluster and capacity provider that filters for Amazon CPUs, run a standalone task, and verify the selected instance type. Finally, you’ll clean up the AWS resources that you created.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
Why do I need both an ARM64 task definition and a CPU manufacturer filter?
You need to set runtimePlatform.cpuArchitecture to ARM64 in your task definition so that your task uses an Arm-compatible runtime. You need a CPU manufacturer filter so that Amazon ECS selects AWS Graviton-based instance types.
Which CPU manufacturer value selects Graviton-based instances with the AWS CLI?
Set cpuManufacturers to amazon-web-services in the capacity provider’s instance requirements. This value corresponds to the Amazon option in the console.
How do I know that my task ran on Graviton?
Check the backing container instance’s type in the Amazon ECS console or with the AWS CLI. Confirm that its family name contains g, such as m6g or c6g, which indicates that it’s based on an AWS Graviton processor.
Should I run a standalone task or create a service to test placement?
To test placement, run a standalone task. A service is better suited for when you need Amazon ECS to maintain a desired task count, replace failed tasks, or integrate with a load balancer.
Why doesn't my task have its own public IP address?
For test purposes, the task uses the host network mode, so it uses the instance’s public IP address. If that instance has no public IP address, confirm that its subnet automatically assigns public IPv4 addresses.
Next