Task Role — Bedrock Access
Overview
Section titled “Overview”The Task Role
An IAM role assumed by ecs-tasks.amazonaws.com that grants the running container application-level permissions (Bedrock access in this project). is an IAM role assumed by the running container at runtime. Unlike the Task Execution Role (which handles image pulls and log writes), the Task Role grants your application the permissions it needs to interact with AWS services. In this project, the container calls Bedrock
AWS fully managed service providing foundation models for generative AI applications. to run inference on foundation models, so the Task Role includes a policy that allows bedrock:InvokeModel on the required resource ARNs.
Trust Policy
Section titled “Trust Policy”The Task Role
An IAM role assumed by ecs-tasks.amazonaws.com that grants the running container application-level permissions (Bedrock access in this project). uses the same trust relationship as the Task Execution Role — it trusts ecs-tasks.amazonaws.com with an aws:SourceAccount condition to prevent cross-account confused deputy attacks.
resource "aws_iam_role" "task" { name = "${var.name}-task"
assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Principal = { Service = "ecs-tasks.amazonaws.com" } Action = "sts:AssumeRole" Condition = { StringEquals = { "aws:SourceAccount" = data.aws_caller_identity.current.account_id } } } ] })}Bedrock IAM Policy
Section titled “Bedrock IAM Policy”The inline policy grants bedrock:InvokeModel permission on Bedrock
AWS fully managed service providing foundation models for generative AI applications. resources with two distinct ARN patterns:
resource "aws_iam_role_policy" "task_bedrock" { name = "${var.name}-bedrock" role = aws_iam_role.task.id
policy = jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Action = [ "bedrock:InvokeModel" ] Resource = [ "arn:aws:bedrock:*::foundation-model/*", "arn:aws:bedrock:*:*:inference-profile/*" ] } ] })}Why Both ARN Patterns Are Required
Section titled “Why Both ARN Patterns Are Required” Foundation Model
A pre-trained large language or multimodal model available through Amazon Bedrock. and
Inference Profile
A Bedrock configuration that specifies model parameters and routing for inference requests. use different ARN
formats in
Bedrock
AWS fully managed service providing foundation models for generative AI applications.
because they represent different resource types with different ownership models.
| Resource | ARN Pattern | Account Field | Reason |
|---|---|---|---|
| Foundation Model | arn:aws:bedrock:::foundation-model/ | Empty (no account) | Foundation models are AWS-managed global resources not owned by any customer account |
| Inference Profile | arn:aws:bedrock:::inference-profile/* | Wildcard (any account) | Inference profiles can be account-specific or cross-region, requiring the account field |
If you only include the foundation model ARN, direct InvokeModel calls using a model ID work, but requests routed through an inference profile fail with an AccessDeniedException. Including both ARN patterns ensures the application can invoke models regardless of whether the request targets a model directly or goes through an inference profile.
Role Attachment to the Express Gateway Service
Section titled “Role Attachment to the Express Gateway Service”The Task Role
An IAM role assumed by ecs-tasks.amazonaws.com that grants the running container application-level permissions (Bedrock access in this project). ARN is passed to the Express Gateway Service resource via the primary_container block, making it available to the running container as instance credentials:
resource "aws_ecs_express_gateway_service" "this" { # ...
primary_container { # ... task_role_arn = aws_iam_role.task.arn }}