CloudFormation – 4

Rollbacks on failures

  • Stack Creation Fails: (CreateStack API)
    • Default everything rolls back (gets deleted). We can look at the log OnFailure=ROLLBACK
    • Troubleshoot: Option to disable rollback and manually troubleshoot OnFailure=DO_NOTHING
    • Delete: get rid of the stack entirely, do not keep anything OnFailure DELETE
  • Stack Update Fails: (UpdateStack API)
    • The stack automatically rolls back to the previous known working state
    • Ability to see in the log what happened and error messages

Let’s use the same template file:

Now we can create a stack

but with different option:


This time we still failed to receive 1 resource signal(s)

But stack wasn’t rolled back.

When we connect to the created EC2 instance we can see the reason of an error:

For troubleshooting we need not to rollback on failure.


Nested stacks

  • Nested stacks are stacks as part of other stacks
  • They allow you to isolate repeated patterns / common components in separate stacks and call them from other stacks
  • Example:
    • Load Balancer configuration that is re-used
    • Security Group that is re-used
  • Nested stacks are considered best practice
  • To update a nested stack, always update the parent (root stack)

Consider such a cloudformation template:

As we see to TemplateURL is attached to this yaml. The URL of the attached template is

Let’s crete a stack:

Nest -> Next

Create stack

Now we have two stack created:

If we go to the output of the nested stack we have the url of created LAMP website:


If we want to delete two stacks we need to delete the parent stack:



  • When you update a stack, you need to know what changes before it happens for greater confidence
  • ChangeSets won’t say if the update will be successful


At the begining we will create simple stack

Next -> Next -> Create stack

Now let’s create change set for created stack. We will use such a tamplate

CloudFormation -> Stacks -> StackCsDemo -> Create change set


Next -> Next -> Create change set -> Create change set

Change set has not  been created yet.

We can see every changes that will be created in our stack:

You can delete or execute the change set.

Let’s execute the change set.


Retaining Data on Deletes

  • You can put a DeletionPolicy on any resource to control what happens when the CloudFormation template is deleted
  • DeletionPolicy=Retain:
    • Specify on resources to preserve / backup in case of CloudFormation deletes
    • To keep a resource, specify Retain (works for any resource / nested stack)
  • DeletionPolicy=Snapshot:
    • EBSVolume, ElastiCache Cluster, ElastiCache ReplicationGroup
    • RDS DBlnstance, RDS DBCluster, Redshift Cluster
  • DeletePolicy=Delete (default behavior):
    • Note: for AWS::RDS::DBCluster resources, the default policy is Snapshot
    • Note: to delete an S3 bucket, you need to first empty the bucket of its content

Consider such a yaml template:

Let’s go and create a stack:


Next -> Next -> Create stack

We have created EBS volume and Security Group.


Now, let’s delete the stack. As we see the Security Group MySG has not been deleted.

EBS volume has been deleted but the snapshot of the volume has been taken.


Termination Protection on Stacks

  • To prevent accidental deletes of CloudFormation templates, use Termination Protection

Let’s see this quickly. First we create a simple stack:

Now let’s enable the termination protection:

After we enable the termination protection we can not delete the stack:

As it is mentioned to delete the stack we need to disable termination policy.