Rollbacks and User Data Practical

Rollbacks

When a CloudFormation stack fails, it enters a rollback state by default. This means all changes made by the failed stack revert. All resources are deleted if the failed stack is being created (run for the first time). For example, let’s take a CloudFormation stack that creates an EC2 instance and an RDS database. If the stack created an EC2 instance and then failed while creating an RDS database, the rollback operation will delete the EC2 instance and any other RDS resources created in the stack.

If the stack fails during an update, a rollback will delete or revert all changes made during the update and roll back to the previous working state. For example, let’s take a stack that has created a t2.micro EC2 instance and update its stack to change EC2 to t2.small and add a security group. If the stack update fails, the security group will be deleted, and the EC2 instance will be changed back to t2.micro.

When we create a stack, we have the option to turn off rollbacks. Deleting resources and reverting configuration changes made by a failed run might sound perfectly fine, but we might want to retain the failed resources for troubleshooting.

Update rollback failed

It’s possible for a rollback of a stack update operation to fail. This will result in a UPDATE_ROLLBACK_FAILED state, which means that CloudFormation was unable to roll back to the previously known working state of the infrastructure.

The primary cause of this state is updating or deleting resources created by an AWS CloudFormation stack outside of the stack (via console, CLI, or API). To fix this state in the CloudFormation stack:

• Revert the changes made to CloudFormation resources outside of the stack.
• Skip the FAILED resources and continue the rollback operation.