🚨 AWS Error Guide: CloudFormation 'UPDATE_ROLLBACK_FAILED' — Recover a Stuck Stack

Overview

When a CloudFormation stack update fails, CloudFormation automatically tries to roll the stack back to its last known-good state. If that rollback also fails, the stack lands in UPDATE_ROLLBACK_FAILED — a terminal, stuck state where you can neither update nor (in most cases) delete the stack until you explicitly recover it.

You see it in the stack status and events:

Stack arn:aws:cloudformation:us-east-1:REDACTED:stack/my-app/abcd is in UPDATE_ROLLBACK_FAILED state and can not be updated.

The triggering event usually reads like one of these:

The following resource(s) failed to update: [AppDatabase]. Rollback requested by user.
Resource handler returned message: "Cannot delete entity, must detach all policies first."

UPDATE_ROLLBACK_FAILED almost always means a resource could not be returned to its previous state — often because something was changed or deleted outside CloudFormation, or a dependency/permission prevented the rollback action.

Symptoms

• Stack status is UPDATE_ROLLBACK_FAILED; update-stack returns “can not be updated”.
• Stack events show one or a few resources with UPDATE_FAILED then UPDATE_ROLLBACK_FAILED.
• A resource CloudFormation manages was modified or deleted manually (drift).
• Delete attempts also fail because the stack is stuck.

aws cloudformation describe-stacks --stack-name my-app \
  --query 'Stacks[0].StackStatus' --output text

UPDATE_ROLLBACK_FAILED

Common Root Causes

1. Out-of-band (manual) changes — drift

Someone edited or deleted a managed resource in the console or CLI. During rollback CloudFormation tries to restore the previous state and finds the resource gone or altered, so the rollback step fails.

2. A resource cannot be deleted due to dependencies

Rollback tries to delete a resource created during the failed update, but it now has dependents — an IAM role with attached policies, a security group still referenced by an ENI, a non-empty S3 bucket, a subnet with running instances.

3. Insufficient permissions for the rollback action

The stack’s role (or the caller) lacks permission to perform the delete/update the rollback requires, so the corrective action itself is denied.

4. A resource stuck in an unstable state

An RDS instance mid-modification, an ASG that cannot reach its previous capacity, or an ECS service that will not stabilize blocks the rollback from completing.

5. Dependent resource in another failed state

A nested stack or a referenced resource is itself broken, so the parent rollback cannot finish.

Diagnostic Workflow

Step 1: Find exactly which resources blocked the rollback

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

The ResourceStatusReason tells you why each resource could not roll back — read it literally; it usually names the exact blocker (dependency, missing entity, permission).

Step 2: Check for drift on the failing resources

aws cloudformation detect-stack-drift --stack-name my-app
aws cloudformation describe-stack-resource-drifts --stack-name my-app \
  --stack-resource-drift-status-filters MODIFIED DELETED \
  --query 'StackResourceDrifts[].[LogicalResourceId,StackResourceDriftStatus]' --output table

DELETED or MODIFIED drift on the blocking resource confirms an out-of-band change is the root cause.

Step 3: Manually satisfy the rollback’s precondition

Based on the reason, fix what blocks the corrective action. For example, if rollback cannot delete an IAM role because policies are attached:

aws iam list-attached-role-policies --role-name <role-created-in-update>
aws iam detach-role-policy --role-name <role> --policy-arn arn:aws:iam::REDACTED:policy/<name>

Or empty an S3 bucket that rollback is trying to delete, detach an ENI from a security group, and so on — whatever the ResourceStatusReason demands.

Step 4: Continue the rollback

Once the blocker is cleared, resume:

aws cloudformation continue-update-rollback --stack-name my-app

If one resource simply cannot be reconciled, skip it so the rest of the stack can stabilize (CloudFormation then stops managing that resource’s rollback):

aws cloudformation continue-update-rollback --stack-name my-app \
  --resources-to-skip AppDatabase

Step 5: Verify the stack reached a stable state

aws cloudformation wait stack-rollback-complete --stack-name my-app
aws cloudformation describe-stacks --stack-name my-app \
  --query 'Stacks[0].StackStatus' --output text

UPDATE_ROLLBACK_COMPLETE

UPDATE_ROLLBACK_COMPLETE means the stack is unstuck and updatable again. If you skipped a resource, reconcile it (import or a follow-up change set) so template and reality match.

Example Root Cause Analysis

A stack update that renamed an IAM role failed and the automatic rollback then jammed at UPDATE_ROLLBACK_FAILED. The events pinpointed the blocker:

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

| ServiceRole | Cannot delete entity, must detach all policies first. (Service: Iam, Status Code: 409) |

During the failed update CloudFormation created a replacement role; rollback tried to delete it, but an operator had already attached an extra managed policy to it by hand, so the delete returned a 409. The out-of-band policy attachment was the root cause. The fix was to detach that policy, then continue the rollback:

aws iam list-attached-role-policies --role-name platform-iam-ServiceRole-REDACTED \
  --query 'AttachedPolicies[].PolicyArn' --output text
aws iam detach-role-policy --role-name platform-iam-ServiceRole-REDACTED \
  --policy-arn arn:aws:iam::REDACTED:policy/extra-observability
aws cloudformation continue-update-rollback --stack-name platform-iam

The stack moved to UPDATE_ROLLBACK_COMPLETE, after which a corrected change set was applied cleanly. The lasting fix was to remove console write access for the deploy role’s resources so no one could attach policies out of band again.

Prevention Best Practices

• Make CloudFormation the single source of truth; deny manual console/CLI writes to stack-managed resources so drift cannot break rollbacks.
• Run detect-stack-drift on a schedule and before every update to catch out-of-band changes early.
• Grant the stack/deployment role every permission its resources’ create and delete actions require, so rollback corrective actions are never denied.
• Test risky updates with a change set and in a staging stack first; validate that resources can be cleanly replaced.
• Empty S3 buckets and clear dependencies before updates that may need to delete those resources during rollback.
• Enable stack termination protection and use --resources-to-skip sparingly, always reconciling skipped resources afterward.

Quick Command Reference

# Which resources blocked the rollback and why
aws cloudformation describe-stack-events --stack-name <stack> \
  --query "StackEvents[?ResourceStatus=='UPDATE_ROLLBACK_FAILED'].[LogicalResourceId,ResourceStatusReason]" --output table

# Detect drift (manual out-of-band changes)
aws cloudformation detect-stack-drift --stack-name <stack>
aws cloudformation describe-stack-resource-drifts --stack-name <stack> \
  --stack-resource-drift-status-filters MODIFIED DELETED --output table

# Resume rollback after clearing the blocker
aws cloudformation continue-update-rollback --stack-name <stack>

# Resume while skipping an irreconcilable resource
aws cloudformation continue-update-rollback --stack-name <stack> --resources-to-skip <LogicalId>

# Wait for and confirm a stable state
aws cloudformation wait stack-rollback-complete --stack-name <stack>
aws cloudformation describe-stacks --stack-name <stack> --query 'Stacks[0].StackStatus' --output text

Conclusion

UPDATE_ROLLBACK_FAILED is a stuck-but-recoverable state: the automatic rollback could not restore a resource to its previous state. The usual root causes:

1. Out-of-band manual changes (drift) to a managed resource.
2. A resource that cannot be deleted because of dependencies (attached policies, non-empty buckets, referenced ENIs).
3. Insufficient permissions for the rollback’s corrective action.
4. A resource stuck mid-modification that never stabilizes.
5. A dependent or nested resource in its own failed state.

Read the exact ResourceStatusReason, clear the specific blocker it names, then continue-update-rollback (skipping only truly irreconcilable resources) until the stack reaches UPDATE_ROLLBACK_COMPLETE. Preventing drift with strict IaC ownership stops the error from recurring.