Amazon ECS IAM Roles: Task, Execution, and Container Instance Permissions – SAP-C02 Study Guide

Purpose of This Lesson

Amazon ECS uses different IAM roles for different actors in the container platform. The most important distinction is between permissions granted to the ECS host or agent, permissions granted to ECS itself during task startup, and permissions granted directly to application containers.

Understanding this separation is essential for designing least-privilege architectures and avoiding credential exposure in ECS exam scenarios.

Key Concepts

ECS container instance role

The ECS container instance role applies to EC2 instances used with the ECS EC2 launch type. The role is attached to the EC2 instance profile and is used by the ECS container agent running on that instance.

Typical responsibilities include allowing the container instance and ECS agent to:

• Communicate with the Amazon ECS control plane.
• Retrieve container images from Amazon ECR when required.
• Send container logs to Amazon CloudWatch Logs.
• Perform other agent-related AWS API operations.

AWS provides a managed policy commonly used for this purpose, but production environments should still review whether its permissions are broader than necessary.

This role belongs to the container instance, not directly to an individual task. It is not a substitute for an application task role.

ECS task role

The task role supplies temporary AWS credentials to containers running within a task. It should contain only the permissions required by the application, such as:

• Reading objects from a specific Amazon S3 bucket and prefix.
• Publishing messages to an Amazon SQS queue.
• Reading secrets from AWS Secrets Manager or parameters from AWS Systems Manager Parameter Store.
• Calling a particular DynamoDB table or Amazon Kinesis stream.

The task role is the primary mechanism for giving an application running in a container access to AWS services. It should be scoped to the application’s actual resource needs rather than granting broad permissions to the ECS host.

ECS task execution role

The task execution role is used by the ECS service, ECS container agent, or Fargate infrastructure to perform task-startup and runtime integration operations on behalf of the task.

Common uses include:

• Pulling private images from Amazon ECR.
• Sending container logs to CloudWatch Logs through the awslogs log driver.
• Retrieving referenced secrets or parameters when configured through supported ECS task-definition integrations.

The execution role is different from the task role:

• Execution role: permissions needed by ECS infrastructure to start and manage the task.
• Task role: permissions needed by the application inside the container.

Do not place application business permissions in the execution role merely because the task needs access to an AWS service.

Fargate and IAM roles

Fargate removes the need to manage ECS container instances. Consequently, there is no customer-managed EC2 container instance role for Fargate tasks.

Fargate task definitions commonly use both:

• A task execution role for image retrieval, logging, and startup integrations.
• A task role for application API calls.

The absence of customer-managed container instances does not eliminate the need for IAM role separation.

ECS infrastructure IAM role

An ECS infrastructure role allows ECS to manage infrastructure resources associated with tasks when a feature requires it. The source example is attaching Amazon EBS volumes to ECS tasks.

This role is feature-specific and should be configured when the selected ECS capability requires ECS to create, attach, or otherwise manage supporting infrastructure resources.

ECS Anywhere role

ECS Anywhere allows ECS tasks to run on customer-managed on-premises servers or virtual machines. Those external instances require an IAM role so the ECS agent can communicate with AWS services.

The external-instance role serves a purpose similar to the container instance role, but it applies to ECS Anywhere-managed external instances rather than EC2 instances in an AWS Region.

Supporting service roles

Additional IAM roles may be required when ECS integrates with other AWS services:

• CodeDeploy service role: used for ECS blue/green deployments managed by CodeDeploy.
• EventBridge invocation role: allows EventBridge to invoke ECS scheduled tasks or perform the configured target action.

These roles authorize the integrating service. They are not replacements for the task role or task execution role.

Credential isolation between tasks

ECS provides task-level credential isolation. A container can retrieve credentials for the task role associated with its own task definition, but it should not be able to retrieve the task role credentials assigned to another task.

This gives independent tasks a separate security boundary at the task-role level. However, isolation must also account for the launch type and host configuration.

Exam-Relevant Takeaways

• Use the container instance role for ECS agent and EC2-host operations with the EC2 launch type.
• Use the task role for application code running inside containers.
• Use the task execution role for ECS or Fargate operations such as pulling images and publishing logs.
• Fargate does not expose a customer-managed container instance role because AWS manages the underlying infrastructure.
• ECS Anywhere external instances need an IAM role for the external ECS agent.
• CodeDeploy and EventBridge integrations may require their own service roles.
• A task can retrieve credentials only for the task role associated with its own task definition.
• On ECS EC2, tasks may potentially access credentials exposed through the EC2 instance role. Keep that role tightly scoped and avoid placing application permissions in it.
• IAM role separation is a security and troubleshooting decision: the role must belong to the actor making the API call.

Architecture Decision Guide

Requirement	IAM role or mechanism	Primary actor
ECS agent communicates with ECS from an EC2 container instance	ECS container instance role attached through an instance profile	ECS agent on EC2
Application reads from S3 or writes to SQS	ECS task role	Containerized application
Fargate pulls a private ECR image	ECS task execution role	Fargate/ECS infrastructure
ECS sends container logs using the supported logging integration	ECS task execution role	ECS/Fargate infrastructure
ECS manages task-related infrastructure such as supported EBS resources	ECS infrastructure role	ECS service
On-premises ECS Anywhere host communicates with AWS	ECS Anywhere external-instance role	ECS agent on the external host
CodeDeploy performs an ECS blue/green deployment	CodeDeploy service role	CodeDeploy
EventBridge starts an ECS scheduled task	EventBridge invocation role	EventBridge

Practical role-selection sequence

1. Identify which component is making the AWS API call.
2. Decide whether the call occurs during task startup or from application code.
3. Assign startup and platform permissions to the execution or infrastructure role.
4. Assign business and data-access permissions to the task role.
5. For EC2 launch type, assign only agent and host-related permissions to the container instance role.
6. Review whether a service integration such as CodeDeploy or EventBridge needs a separate role.

Common Exam Traps

Confusing the task role with the execution role

A task needs to read from S3 during application execution. The correct location for that permission is the task role, not the task execution role.

Conversely, permissions to pull a private ECR image or publish logs through the ECS logging integration generally belong in the task execution role.

Assuming Fargate uses an EC2 instance role

Fargate tasks do not run on EC2 container instances that you manage. Do not select an EC2 container instance profile as the solution for granting Fargate tasks access to AWS services.

Granting application permissions to the EC2 instance role

With the EC2 launch type, broad permissions on the instance role can create an unintended exposure path for tasks running on that instance. Application access should normally be delivered through task roles with resource-level restrictions.

Treating all ECS roles as interchangeable

The role used by EventBridge to start a task, the role used by CodeDeploy to manage a deployment, and the role used by a container to access DynamoDB are authorizing different actors. Replacing one with another can fail functionally or violate least privilege.

Assuming task isolation removes all host risks

ECS task-role credentials are isolated between tasks, but EC2 launch type still involves a customer-managed shared host. Host hardening, minimal instance-role permissions, container isolation, and network controls remain important.

Real-World Engineer Notes

• Use separate task roles for separate applications or trust boundaries, even if several services currently need similar access.
• Scope data permissions to specific resources wherever possible, such as an individual S3 bucket prefix, SQS queue, or DynamoDB table.
• Review the default or AWS-managed container instance policy before using it in a tightly controlled environment.
• Avoid embedding long-lived access keys in images, environment variables, or source code. ECS task roles provide temporary credentials through the ECS credential mechanism.
• Treat the execution role as infrastructure plumbing. It should not automatically receive every permission required by the application.
• If a task cannot start, inspect execution-role permissions for ECR, CloudWatch Logs, secrets, or parameters. If a running application receives AccessDenied, inspect the task role first.
• For ECS Anywhere, secure the external host as carefully as an EC2 container instance because the host participates in the ECS control and credential workflow.
• Use CloudTrail and IAM policy analysis tools to verify which role made an API call and to identify unnecessary permissions.

Quick Reference Summary

• Container instance role: ECS agent and host operations for ECS on EC2.
• Task role: AWS permissions used by application containers.
• Task execution role: ECS/Fargate startup and integration operations.
• Infrastructure role: ECS-managed supporting resources, such as supported task storage features.
• ECS Anywhere role: Agent permissions for external on-premises instances.
• CodeDeploy role: ECS blue/green deployment operations.
• EventBridge role: Permissions for EventBridge to invoke ECS targets.
• Security rule: Keep application permissions in task roles and minimize permissions on shared host roles.

Flashcards

1. Q: What does the ECS container instance role authorize?

A: It authorizes the ECS agent on an EC2 container instance to communicate with ECS and related AWS services.

1. Q: Which role should an application use to read from Amazon S3?

A: The ECS task role.

1. Q: Which role is commonly used to pull private images from Amazon ECR?

A: The ECS task execution role.

1. Q: Which role is used to publish logs through the ECS task logging integration?

A: The ECS task execution role.

1. Q: Does Fargate require a customer-managed EC2 container instance role?

A: No. Fargate manages the underlying compute infrastructure.

1. Q: What is the purpose of the ECS task role?

A: It provides temporary AWS credentials to containers for application API calls.

1. Q: Can a container retrieve the task role credentials of an unrelated ECS task?

A: No. ECS associates credentials with the task to which the container belongs.

1. Q: What is the primary security concern with a broad EC2 instance role in ECS?

A: Tasks on the instance may potentially access credentials made available through that host role.

1. Q: Which role allows ECS Anywhere external instances to communicate with AWS?

A: The ECS Anywhere external-instance IAM role.

1. Q: Which service role may be needed for ECS blue/green deployments?

A: A CodeDeploy service role.

1. Q: Which role allows EventBridge to invoke an ECS scheduled task?

A: An EventBridge invocation role.

1. Q: Where should application-specific DynamoDB permissions be placed?

A: In the ECS task role, restricted to the required table and actions.

Practice Questions

Question 1

A company runs ECS tasks using the EC2 launch type. The application in each container must read objects from a specific S3 bucket. The ECS agent must also pull images from ECR and send logs to CloudWatch Logs. Which design follows least privilege?

A. Add S3, ECR, and CloudWatch permissions to the EC2 instance role.
B. Add all permissions to the task execution role.
C. Put S3 permissions in the task role and ECR/logging permissions in the appropriate ECS agent or task execution configuration.
D. Store an IAM access key with S3 permissions in the container image.

Correct answer: C

Explanation: Application permissions belong in the task role. Platform operations such as image retrieval and logging use the execution or host-related role appropriate to the launch type and integration. Static credentials in an image are insecure.

Question 2

A Fargate task successfully starts after pulling its image. The application then receives AccessDenied when attempting to publish a message to Amazon SQS. The execution role already has the required ECR permissions. What should be checked first?

A. The task role policy.
B. The EC2 container instance profile.
C. The CodeDeploy service role.
D. The EventBridge rule target.

Correct answer: A

Explanation: The application calls SQS from inside the container, so the permission belongs in the task role. Fargate does not use a customer-managed EC2 container instance profile.

Question 3

An administrator gives the ECS EC2 container instance role broad permissions for S3, DynamoDB, and Secrets Manager because several tasks need those services. What is the main concern?

A. ECS tasks cannot use instance roles.
B. The instance role is available only during image pulls.
C. Tasks on the host may potentially access credentials provided through the instance role.
D. Fargate will reject the instance role.

Correct answer: C

Explanation: With ECS on EC2, a broad host role can expose more permissions than intended to tasks on that instance. Application access should be moved into narrowly scoped task roles.

Question 4

A scheduled EventBridge rule must launch an ECS task. The task definition already has a valid task role and execution role, but the rule cannot invoke the task. Which permission is most likely missing?

A. Permission for the EventBridge service role to invoke the ECS target.
B. Permission for the task role to invoke EventBridge.
C. Permission for the EC2 instance role to read S3.
D. Permission for the container to assume the CodeDeploy role.

Correct answer: A

Explanation: EventBridge is the service initiating the action, so it needs an invocation role with permission to call the required ECS API operation. The task and execution roles govern the task after or during startup.

Question 5

A team is deploying an ECS service with a CodeDeploy blue/green deployment strategy. Which IAM design is appropriate?

A. Give the task role permission to perform all CodeDeploy operations.
B. Configure a CodeDeploy service role for deployment actions, while retaining separate task and execution roles.
C. Remove the task execution role because CodeDeploy replaces it.
D. Add deployment permissions to the Fargate infrastructure role.

Correct answer: B

Explanation: CodeDeploy requires a service role for its deployment operations. That role is separate from the permissions used by the application and by ECS during task startup.