AWS CloudFormation stack stuck in UPDATE_ROLLBACK_FAILED

When you see this error

You're updating a CloudFormation stack. The update fails—maybe a Lambda function hits a timeout, or a new EC2 instance can't launch. CloudFormation tries to roll back to the previous state. But then you see UPDATE_ROLLBACK_FAILED in the AWS Console, and the stack sits there for hours. No progress. No clear error in the Events tab except maybe a generic "API: iam:PassRole" or "The following resource(s) failed to delete."

I've seen this most often when someone:
- Manually deleted an S3 bucket or a DynamoDB table that CloudFormation created.
- Changed IAM policies and accidentally removed the cloudformation:ContinueUpdateRollback permission.
- Tried to update a stack that had a custom resource (like a Lambda-backed resource) that no longer exists or has broken code.

Root cause in plain English

CloudFormation can't undo what it did during the update because it can't talk to the resource. Two big reasons:
1. Missing permissions — The IAM role that CloudFormation uses doesn't have the right to delete or modify the resource.
2. Orphaned resource — You or someone else deleted the resource outside of CloudFormation, so CloudFormation can't find it to roll it back.

CloudFormation is stubborn. Once it hits UPDATE_ROLLBACK_FAILED, it won't retry the rollback automatically. You have to step in and tell it to skip certain resources or fix the permissions.

The fix — step by step

Step 1: Identify what's blocking the rollback

Go to the CloudFormation console. Click your stack. Open the Events tab. Look for the last error messages. They often say something like:

Resource creation cancelled
Resource update cancelled
API: iam:PassRole User: arn:aws:iam::123456789012:role/MyRole is not authorized to perform: iam:PassRole

Write down the Logical ID of the resource that failed. You'll need it later.

Step 2: Check if the resource still exists

Open the AWS service that owns the resource (e.g., EC2, S3, DynamoDB). See if it's still there. If it's gone—someone deleted it manually—you can skip it during the rollback.

If the resource is there but the error says "not authorized", you need to fix the IAM role.

Step 3: Fix the IAM permissions (if that's the issue)

Find the IAM role that CloudFormation uses. It's usually the one listed in the stack's Execution role field. Add the missing permissions. For example, if the error is about iam:PassRole, add that action to the policy.

Don't guess the permissions. Look at the error message—it tells you exactly what action is missing. Add it. Save the policy. Wait a minute for it to propagate.

Step 4: Continue the rollback (the real fix)

Now you need to tell CloudFormation to try rolling back again. But you can also skip resources that are blocking it.

1. In the CloudFormation console, select your stack.
2. Click Stack actions -> Continue update rollback.
3. In the dialog, you'll see a box labeled Resources to skip. List the logical IDs of the resources that failed (from Step 1). Separate them with commas.
4. Check the box that says I acknowledge that this operation may skip resources.
5. Click Continue update rollback.

After you click that, CloudFormation will skip those resources and complete the rollback. You'll see UPDATE_ROLLBACK_COMPLETE in a few minutes.

Step 5: Clean up the skipped resources (if needed)

Now your stack is back to its previous state. But those skipped resources are still there—they're orphaned. CloudFormation won't manage them anymore. If you want to delete them, do it manually through the service console. Be careful—some resources you might want to keep (like an S3 bucket with data).

If you skipped a resource because it was already deleted, you're fine. Nothing to clean up.

If the stack is still stuck

Sometimes the continue rollback button doesn't work. Here's what to check.

You're using a service role without the right permissions. The IAM role itself might not have permission to call cloudformation:ContinueUpdateRollback. Yes, that's a real thing. Go to the IAM policy for that role and add:

{
  "Effect": "Allow",
  "Action": "cloudformation:ContinueUpdateRollback",
  "Resource": "*"
}

Then try again.

You have nested stacks. If your root stack has nested stacks, you might need to continue the rollback on the nested stack that's stuck, not the parent. Click into the nested stack (it looks like a stack in the console), then repeat Steps 4 and 5 on that nested stack.

You're using custom resources that call Lambda. If the Lambda function backing the custom resource is gone, you have to recreate it (with the same name) or skip the custom resource during the rollback. The skip option works most of the time.

One more thing—if the stack has been stuck for more than an hour, open an AWS support case. They can force the rollback from their side. But try the steps above first. They work 90% of the time.