SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Cloud New Added 9 September 2026

AWS ECS: CannotPullContainerError, pull image manifest has been retried

The task could not fetch its image, and the reason is far more often networking than permissions: a task in a private subnet with no NAT gateway and no VPC endpoints cannot reach ECR at all. A task in a public subnet still needs assignPublicIp turned on before it has a route out.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# The precise reason is recorded on the stopped task
aws ecs describe-tasks --cluster prod --tasks <id> \
  --query 'tasks[0].{reason:stoppedReason,containers:containers[].reason}'

# Private subnets need endpoints, or a NAT gateway
aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-123 \
  --query 'VpcEndpoints[].ServiceName'
# ecr.api, ecr.dkr, logs, and an S3 gateway endpoint for the layers

# Fargate in a public subnet must be told to take a public IP
"networkConfiguration": {"awsvpcConfiguration": {"assignPublicIp": "ENABLED"}}

# Only then check the execution role
aws iam simulate-principal-policy --policy-source-arn <execRoleArn> \
  --action-names ecr:GetAuthorizationToken ecr:BatchGetImage

How to diagnose Cloud errors

Cloud provider errors are overwhelmingly one of two things: IAM (the caller is not permitted, or the credentials are not the ones you think) or quota (the account limit was reached). Providers deliberately return the same vague AccessDenied for a missing permission, a deny in a boundary or SCP, and a resource policy that excludes you, so the fix begins with identifying which identity made the call.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Confirm the identity first: aws sts get-caller-identity, az account show, or gcloud auth list. An unexpectedly large share of AccessDenied errors are the right policy on the wrong principal.
  2. Use the provider's policy simulator (IAM Policy Simulator, gcloud policy-troubleshoot) rather than reading policy JSON. It accounts for boundaries, SCPs and resource policies that are invisible in a single document.
  3. Check CloudTrail / Activity Log / Cloud Audit Logs for the denied call. The log entry names the exact action and resource ARN, which the client-side error usually omits.
  4. For quota errors, look up the current limit and the current usage before requesting an increase: many quotas are per-region and per-account, and the resource you think is idle may be counted.
  5. Verify the region. A resource that "does not exist" very often exists in a different region than the one your CLI profile defaults to.

Tools worth reaching for

  • aws sts get-caller-identity
  • IAM Policy Simulator
  • gcloud policy-troubleshoot
  • CloudTrail / Activity Log

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

docs.aws.amazon.com

Related Cloud errors

See all 25 Cloud errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.