How do I update a CloudFormation stack with state UPDATE_ROLLBACK_COMPLETE?

Question

Is it impossible to update a CloudFormation stack once it goes into the UPDATE_ROLLBACK_COMPLETE state? I am using CodePipeline to deploy things. I find that once a stack goes into some invalid state, many times, I have to delete the stack manually and let it recreate everything again. Is that the right way to do this?

Answer 1

If the stack is in UPDATE_ROLLBACK_COMPLETE state you should be able to update the stack again.

If the rollback failed you may need to call ContinueUpdateRollback from CloudFormation before you can update again.

If your stack is stuck in UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS you may be experiencing this issue.

Answer 2

Look into CloudFormation's stack events, there should be some error which would have caused stack update issues.

I had the same problem where status was UPDATE_ROLLBACK_COMPLETE (red font with a cross icon) and CloudFormation stack wasn't getting updated.

I had a look in CloudFormation's stack Events and there was no 'Status reason' against 'UPDATE_ROLLBACK_COMPLETE' status but when I drilled down a bit further, there was an error regarding lambda code using one of the AWS reserved keywords against the status 'UPDATE_FAILED'(screenshot attached).

After removal of keyword from lambda code it worked like a charm.

Answer 3

The answer obviously heavily depends on your specific case and the AWS resources that are involved as already mentioned by others. As an inspiration for others I had the error 'UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS' with the latest event looking like this:

Cloudformation got stuck here because the lambda function that it was trying to delete wasn't existing. I don't know why this happened but the "FileUploadLambdaFunction" was the function that I wanted to deploy for the first time on this stack and it was replacing two legacy functions which I don't use anymore.

I solved it by manually creating a Lambda Function with the same name and then deleting it again. That triggered the workflow to start again and to continue as normal.

Answer 4

It might be lambda name collisions as it was in my case. I was trying to rename a lambda and change an http method and was conflicting with the existing one. Instead, comment out the modified lambda routes in the api, deploy so that the old lambdas and routes are removed, then uncomment and redeploy again.