DELETE_FAILED

WHAT IT MEANS

What this error means

DELETE_FAILED appears in two places: as a resource status during a stack delete or rollback, and as the final stack status once any resource fails to delete. The stack is now stuck until the blocker is resolved. The usual blockers, in rough order of frequency:

• A non-empty S3 bucket. S3 refuses to delete buckets containing objects (including old object versions in versioned buckets).
• A Lambda ENI still detaching. VPC-attached functions leave network interfaces that can take a while to release; security groups and subnets they touch cannot delete until then.
• A nested stack in its own failed state. The parent reports DELETE_FAILED; the real reason is inside the child stack's events.
• Cross-stack dependencies. Another stack imports an Export from this one; CloudFormation refuses to delete the resource backing it.
• Missing delete permissions. The identity that can create a resource cannot necessarily delete it.
• ECR repositories with images, non-empty EFS file systems, and similar "not empty" refusals from other services.

FIX

How to fix it

1. Get the exact status reason first:

   aws cloudformation describe-stack-events --stack-name YOUR_STACK \
     --query "StackEvents[?ResourceStatus=='DELETE_FAILED'].[LogicalResourceId,ResourceStatusReason]" \
     --output table

   Preserve it before changing anything — retries overwrite the event history's usefulness.
2. Resolve the named blocker deliberately. Empty the bucket (including versions and delete markers), wait for or detach the network interface, open the nested stack's events and fix that failure, or remove the import in the dependent stack. Do not reach for force-delete as the first move.
3. Retry the delete. Many ENI-related failures pass on a plain retry ten minutes later.
4. If a resource should survive the stack, retain it explicitly on the retry — this skips deletion for that resource and lets the rest of the stack go:

   aws cloudformation delete-stack --stack-name YOUR_STACK \
     --retain-resources LOGICAL_ID

   --retain-resources only works on a stack already in DELETE_FAILED, and the retained resource becomes unmanaged — you own its lifecycle afterwards.
5. If the delete was refused outright with a termination-protection message, that is a deliberate safeguard, not a failure — find out why protection was enabled before disabling it.

AUTOMATE THE TRIAGE

Diagnose this automatically

SAM Doctor recognizes DELETE_FAILED, the IAM-role deletion blocker, and the termination-protection refusal as distinct findings, each with its own next check. Runs locally; no AWS access, no log upload.

python -m pip install sam-doctor
sam-doctor diagnose deployment.log --format markdown

RELATED

Related errors

• ROLLBACK_COMPLETE state and can not be updated — the delete is often step two of recovering from this.
• Rate exceeded (Throttling) — mass-deleting many stacks at once triggers this instead.
• InsufficientCapabilitiesException — the redeploy after cleanup can stop here next.