HowToFixMe
Amazon ECS

CannotPullContainerError on ECS. what causes it and how to fix

By Sai Kiran Pandrala · Last verified: 2026-05-31 · Source: community Q&A, AWS re:Post, AWS docs

At a glance
ServiceAmazon ECS
CloudAmazon Web Services (AWS)
Guide typeProcedure
Skill levelIntermediate to advanced
Time15 - 60 minutes depending on account size

If you hit CannotPullContainerError on ECS, what causes it and how to fix on Amazon ECS in production, the steps below are the path most teams take in 2026. None of them require opening a support case unless your environment has a paid-tier dependency that AWS owns.

What cannotpullcontainererror on ecs, what causes it and how to fix actually involves on Amazon ECS

Real-world context. Last time I walked through this on a real machine, the budget shook out to ~Rs 0 INR for the fix itself, support plan adds Rs 2,500 to Rs 1,00,000 INR per month (around $30 to $1,200 USD/month). Plan for ~15 to 45 minutes actually at the keyboard, and ~1 to 4 hours including IAM review and post-fix validation once you factor in the back-and-forth. Keep an admin IAM role, the AWS CLI v2, and a CloudTrail filter pointed at the affected resource within arm’s reach before you start, stopping mid-step to hunt for them is how a 30-minute job turns into an afternoon.

The CannotPullContainerError error from AWS typically surfaces with the message "pull image manifest has been retried 5 times". The error code itself is what you grep for in AWS re:Post or in AWS Support cases, not the human-readable line.

On ECS, this most often comes from one of three causes: a missing or restrictive IAM permission, a service-level limit you have hit, or a transient AWS-side capacity issue. The fix path differs by which.

The rest of this page is the structured fix path. Start with diagnose, then remediation, then the automation options so you do not have to do this by hand the next time it surfaces. Verify and safety sections at the end are the discipline that keeps the fix from regressing in production.

Identify

Check CloudWatch Logs for the calling service. Lambda, ECS, EKS, Step Functions, API Gateway, and most managed services write detailed traces to CloudWatch Logs under predictable log group names. Use CloudWatch Logs Insights with fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 50 to surface the most recent failures.

Pull the AWS request ID from the response headers: x-amz-request-id for most services, x-amzn-RequestId for API Gateway, both x-amz-request-id and x-amz-id-2 for S3. AWS Support needs these IDs to look up your call in their internal logs - without them, the first reply on a ticket will ask you to reproduce the call and capture them. Save them with a timestamp; AWS Support cannot retrieve calls older than 90 days for most services.

Run aws sts get-caller-identity first. About one in five 'why does this not work' tickets are actually 'I am in the wrong account' or 'my session expired and the SDK is using stale creds'. The 5-second sanity check costs nothing and saves real time when the answer is that simple.

Solution-focused remediation path

For IAM and STS issues, the timing matters. STS sessions can take up to 60 seconds to propagate after creation. The first call right after assume-role can fail with a permission error even when the policy is correct. Add a small retry with backoff before treating the first failure as definitive.

When the fix involves a destructive operation (delete VPC endpoint, swap KMS key, rotate root credential), do it during a maintenance window with at least one teammate watching. Several Amazon ECS operations have implicit dependencies that only show up when traffic starts flowing again. Document the rollback path before you start, not during the incident.

If the issue points at IAM, do not start by adding * to a policy. Use IAM Access Analyzer (Policy Generator) against the failed action to see the minimum scope. Adding * is the fastest way to fail your next AWS Well-Architected security review, and it usually does not even fix the issue because the explicit deny is often coming from a higher level (SCP, RCP, or permission boundary), not a missing allow.

Automate this fix so you do not do it twice

Automate the fix with the AWS CLI

The CLI one-liner pattern for Amazon ECS operations is roughly: aws ecs describe-... --query ... to read state, aws ecs modify-... --no-dry-run to apply the change, and aws ecs describe-... --query ... again to verify. Wrap it in a shell script that sets a region variable at the top and exits on first error with set -euo pipefail so a partial run does not leave the account in a half-fixed state.

# Template - replace placeholders with your account specifics
export AWS_REGION=us-east-1
export AWS_PROFILE=prod
aws ecs describe-... --query 'Resources[?Status==`FAILED`].[Id,Reason]' --output table
aws ecs modify-... --resource-id RESOURCE_ID --no-dry-run
aws ecs describe-... --resource-id RESOURCE_ID --query 'Status'

Add a CloudWatch alarm so you know next time

The cheapest way to never see the same incident twice is a CloudWatch alarm on the metric that would have warned you. For Amazon ECS, the relevant metrics live under AWS/ecs namespace or under custom metrics published by your Lambda or ECS task. Set thresholds based on observed normal range plus one or two standard deviations, not on round-number guesses. CloudWatch anomaly-detection alarms remove the threshold-guessing problem entirely for metrics with regular seasonality.

Wire the fix into EventBridge for self-healing

If the failure mode is recurring, automate the remediation instead of the diagnosis. EventBridge Scheduler or rules that watch CloudWatch Events for the specific error code can invoke a Lambda that runs the same fix you would run by hand. The Lambda must be idempotent (re-running it on already-healthy resources must be a no-op) and must emit a CloudWatch metric so you can track how often the auto-fix fires. A spike in auto-fix invocations is itself a signal worth alerting on.

# EventBridge rule pattern (JSON)
{ "source": ["aws.ecs"], "detail-type": ["AWS API Call via CloudTrail"], "detail": { "errorCode": ["AccessDenied", "ThrottlingException"] }
}

Pitfalls to dodge

The most common pitfall when fixing this on Amazon ECS is treating it as a one-off rather than as a recurring class of incident. The same misconfiguration tends to happen again after a deployment, a role rotation, or a region migration unless the fix is codified. Add a CloudFormation hook, Service Control Policy condition, or AWS Config rule that prevents the same misconfig from being introduced again. Documentation alone does not survive turnover.

Another common trap: confirming the fix on a single resource and assuming the fleet is healthy. Loop your check across every account, region, and IAM principal that could exhibit the same symptom. If you cannot enumerate the affected scope without a script, you do not yet understand the scope.

Resolve

Safety, rollback, blast radius

FAQ

How long does cannotpullcontainererror on ecs: what causes it and how to fix typically take on AWS?
For most Amazon ECS environments, 15 to 60 minutes including verification. Large multi-account setups, anything touching SCPs at the Organizations level, or cross-region replication can stretch to half a day because AWS has to wait for replication and IAM session caches.
Is there a rollback path?
Yes for most Amazon ECS changes. Export the existing config to JSON via aws ecs describe-... first, then commit it before you change anything. A few operations are one-way (KMS key deletion past the pending window, region migration, account closure). Check the AWS doc for the specific API before you commit.
Will this affect dependent AWS services?
Often yes. Amazon ECS resources are usually referenced by other workloads (Lambda, ECS tasks, IAM-bound apps, CloudFront origins, downstream pipelines). Use IAM Access Analyzer + CloudTrail to enumerate consumers before changing a shared resource.
What if my AWS Console layout does not match these steps?
AWS Console UI moves quarterly. The Console layout in this page is current as of 2026-05-31 but the underlying CLI / SDK calls do not change as fast. If the Console version differs, fall back to aws CLI or SDK calls - those almost always still work.
Where do I get AWS Support help if I am still stuck?
Open a case via the AWS Support Center with: the request ID + correlation ID, the exact error string, CloudTrail event, and your reproduction steps. AWS re:Post is the no-cost public alternative - search there first; 80% of common Amazon ECS issues already have an answer with an AWS-staff-verified flag.

References

Related guides worth a look while you sort this one out: