Terraform Fargate task definition requesting execution role
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
For ECS on Fargate, the execution role and the task role solve different problems, and mixing them up is a common cause of confusing Terraform and ECS errors. The execution role is used by ECS itself to pull images and publish logs. The task role is assumed by the application code inside the running container. If a Fargate task definition is “requesting execution role,” the usual fix is to define execution_role_arn correctly and attach the expected permissions.
What The Execution Role Is For
The execution role is used by the ECS agent and platform on your behalf for operations such as:
- pulling container images from ECR,
- sending container logs to CloudWatch,
- retrieving secrets or parameters referenced in task startup configuration.
This is not the same as the role your application uses when it calls AWS APIs at runtime.
The Terraform Field You Need
In Terraform, the ECS task definition usually looks like this:
If you omit execution_role_arn in cases where Fargate needs it, ECS may reject the task definition or fail to start the task properly.
Create The Execution Role In Terraform
You need an IAM role that ECS tasks can assume.
Then attach the standard execution policy.
That managed policy covers the common baseline for ECR pulls and CloudWatch Logs.
Execution Role Versus Task Role
This distinction is worth repeating because it causes a lot of confusion.
- '
execution_role_arn: used by ECS and Fargate infrastructure during task startup and platform-managed operations.' - '
task_role_arn: used by the application code inside the container after it is running.'
If your container needs to read from S3 at runtime, that permission belongs on the task role, not on the execution role. If the task needs to pull from ECR, that belongs on the execution role.
Why Fargate Commonly Needs It
Fargate abstracts away the host instance, so platform-managed steps such as image retrieval and log initialization rely heavily on that execution role. That is why Fargate tasks often surface this configuration issue quickly.
In older examples or EC2-backed ECS examples, the role separation may look less obvious, which is why copied configurations often break when moved to Fargate.
A Good Validation Checklist
If task definition registration or startup is failing, check:
- '
execution_role_arnexists,' - the role trust policy allows
ecs-tasks.amazonaws.com, - the managed execution policy is attached,
- '
task_role_arnis not being confused with the execution role,' - referenced logs, secrets, and image sources match the permissions actually granted.
That checklist catches most role-related issues.
Common Pitfalls
- Using
task_role_arnand thinking it replacesexecution_role_arn. - Creating the role but forgetting the
ecs-tasks.amazonaws.comtrust relationship. - Forgetting the standard managed execution policy attachment.
- Putting application runtime permissions on the execution role instead of the task role.
- Reusing an EC2 ECS example and assuming the same role expectations apply cleanly to Fargate.
Summary
- Fargate task definitions often need an
execution_role_arnso ECS can pull images and publish logs. - The execution role is different from the application’s task role.
- In Terraform, define the role, trust policy, and policy attachment explicitly.
- Use the execution role for ECS platform operations and the task role for app AWS API access.
- When ECS complains about execution role requirements, the fix is usually role definition, trust, or permission alignment.
Related reading
- Terraform, getting output from null_resource, local-exec and the AWS CLI
- Terraform How to migrate state between projects?
- Terraform kubernetes_config_map --from-env-file
- Terraform lookup AWS region
- Terraform, ignore_changes and sub-blocks
- Terraform kubectl provider error failed to create kubernetes rest client for read of resource
- terraform output Google Kubernetes cluster inggress load balancer ip
- terraform reference existing s3 bucket and dynamo table

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.