AWS ECS clarifies task execution roles
- AWS documentation says Amazon ECS uses two distinct IAM roles: a task execution role for agent startup actions and a task role for application runtime access. - Amazon says the execution role lets ECS or Fargate pull images, send logs and fetch referenced secrets, while task-role credentials are delivered to containers. - AWS publishes separate ECS IAM role guides in its developer documentation, including task-role, execution-role and security best-practice pages.
Amazon Web Services draws a hard line in Amazon ECS between the role that starts a container and the role the application uses after it is running. In ECS task definitions, the “task execution role” is for the ECS container agent or AWS Fargate agent to pull images, push logs and retrieve referenced secrets or parameters, while the “task role” is for code inside the container to call AWS services such as S3 or DynamoDB. AWS documents the split in separate ECS developer guide pages and says the permissions are used by different actors at different stages of a task’s life cycle. ### Which ECS role is actually used before the app starts? AWS says the task execution role is assumed by the ECS container and Fargate agents, not by the application itself. The company’s ECS documentation lists common execution-role uses such as pulling private images from Amazon ECR, sending container logs to CloudWatch Logs with the `awslogs` driver, using private registry authentication, and retrieving secrets from AWS Secrets Manager or parameters from Systems Manager Parameter Store that are referenced by the task definition. (docs.aws.amazon.com) Amazon also says the execution role can vary by workload. The ECS guide notes that teams can create multiple task execution roles for different purposes and services in the same account, rather than using one broad role everywhere. ### What changes once the container is already running? AWS says the task role is the identity delivered to containers at runtime. In the ECS task IAM role guide, Amazon says permissions in that role are “vended to containers running in the task,” and are intended for application code that needs to access AWS services. (docs.aws.amazon.com) The documentation uses services such as Amazon S3 as the example and says those permissions are not used by the ECS or Fargate agents. That distinction matters in one common edge case. AWS says if application code inside the container needs to call Amazon ECR APIs directly, those permissions belong in the task role, even though image pulling for task startup is handled through the execution role. ### Where do teams usually get this wrong? AWS says the roles should be kept separate and scoped narrowly. In its ECS IAM best-practices page, Amazon recommends creating separate roles instead of sharing them, and says assigning each task its own role aligns with least-privilege access and gives more granular control over actions and resources. (docs.aws.amazon.com) A frequent mistake is to put application permissions into the execution role because the task fails before startup, or to give the task role broad access because it is easier than tracing which service calls the app actually makes. (docs.aws.amazon.com) AWS’s documentation points the other way: startup permissions for the platform belong in the execution role, and runtime permissions for business logic belong in the task role. (docs.aws.amazon.com) ### What is the least-privilege version of this setup? AWS’s ECS security guidance says separate roles let operators grant only the permissions a specific task needs. In practice, that means an execution role limited to image pulls, log delivery and referenced secret retrieval, and a task role limited to the exact API actions and resources the application uses. Amazon’s broader ECS IAM overview says the required roles depend on launch type and features such as scheduled tasks, blue-green deployments or attached infrastructure resources. (docs.aws.amazon.com) That leaves teams with more than two IAM decisions in larger deployments, but the core split remains the same: platform bootstrapping on one role, application access on another. ### Where should readers look next in AWS’s own docs? (docs.aws.amazon.com) AWS maintains separate ECS developer guide pages for the task execution IAM role, the task IAM role, and ECS IAM security best practices. Those documents list required permissions by feature and are the primary references for updating task definitions and IAM policies in production environments. (docs.aws.amazon.com 1) (docs.aws.amazon.com 2)
