10.3.1.5 ECR ECS EKS Integration

ECR ECS EKS integration refers to how AWS's container orchestration services — ECS and EKS — can pull images directly from ECR using the same underlying AWS IAM permissions already governing the rest of that infrastructure, without requiring a separately managed registry credential.

How ECS Pulls From ECR

An ECS task definition references an ECR image directly, with the underlying compute resources authenticating to ECR automatically using their assigned IAM role.

{
  "containerDefinitions": [
    {
      "name": "api",
      "image": "123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:2.3.0"
    }
  ]
}

As long as the task's execution role has appropriate ECR pull permissions, this image is retrieved without any separate, manually configured registry credential.

How EKS Pulls From ECR

A Kubernetes pod running on EKS similarly relies on the underlying node's (or a more granularly scoped service account's) IAM permissions to pull from ECR.

spec:
  containers:
    - name: api
      image: 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:2.3.0

Why This Integration Removes a Common Source of Friction

Without this native integration, deploying to ECS or EKS would require separately managing and periodically refreshing registry credentials specifically for pulling images, an additional operational burden this integration avoids entirely.

aws ecr get-login-password

This kind of manual authentication step becomes largely unnecessary for compute resources already running with appropriate IAM permissions within the same AWS account.

Granting the Necessary IAM Permissions for This Integration to Work

The underlying compute role still needs to be explicitly granted appropriate ECR pull permissions for this seamless integration to actually function.

{
  "Effect": "Allow",
  "Action": ["ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage"],
  "Resource": "*"
}

Why ECR ECS EKS Integration Matters

This native integration significantly simplifies operating containerized workloads on AWS, removing what would otherwise be a recurring need to manage registry authentication separately from the rest of the infrastructure's existing identity and access management.