# Cloudformation Resource Creation and Deletion Order

In this post, I will try to test experimentally and understand the order in which CloudFormation resources are created, updated and deleted. I will explore 3 different approaches, with and without CloudFormation resource dependencies, and finally nested stacks with dependencies.

### Scenarios

These are the 3 scenarios:

* Without dependencies between CloudFormation resources,
    
* with dependencies between CloudFormation resources using the `DependsOn` attribute (or the equivalent syntax in CDK), and finally
    
* by placing resources in nested stacks and enforcing dependencies at the nested stack level.
    

### Experimental setup

The complete code used in this experiment can be found in this [AWS CDK project on github](https://github.com/codiply/cloudformation-dependencies-test).

I am using [CloudFormation custom resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html) that allow me to run custom code and record the exact time a resource was created/updated/deleted. I record this information in an [Amazon Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) database.

The project contains a [core stack,](https://github.com/codiply/cloudformation-dependencies-test/blob/main/stacks/core.py) that defines the Timestream database and the custom resource provider. The [lambda function of the custom resource provider](https://github.com/codiply/cloudformation-dependencies-test/blob/main/assets/custom-resource-provider-lambda/handler.py) handles the create/update/delete events for the custom resources and records the following information in the database

* Time of event
    
* The name of the resource
    
* The version of the resource (this is an attribute that I change to trigger an update)
    
* The type of the operation (create, update, delete)
    
* The approach, i.e. one of the 3 scenarios mentioned above
    

This is a sample of records in the database

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672159870600/3c94478a-13e3-4323-8de4-ec5c8b3b4cff.png align="center")

In the CDK project, apart from the core stack, I create [one stack for every approach](https://github.com/codiply/cloudformation-dependencies-test/tree/main/stacks). Each stack creates a configurable amount of custom resources, this number is set to 10.

These are all the stacks created by the project. If you deployed my code and you see many nested stacks with long names, flip the switch "View nested" to off to see only non-nested stacks.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672211496696/a217c55a-d1d7-4b50-bdf4-a76c6706aaae.png align="center")

The experiment has 3 phases

* Deploy all stacks: trigger the **creation** of resources
    
* Increment the version number and deploy again: trigger the **update** of resources
    
* Delete the stacks from the CloudFormation console: trigger the **deletion** of resources
    

In the last step, I do not delete the core stack yet. The core stack contains the Database with the collected data.

## The results

It is time for the data to speak!

### Scenario 1: Without dependencies

In this scenario, we do not enforce any dependencies between the resources.

The resources are created in no particular order, they are created in parallel.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672133042139/9fa49c8a-9a90-41c9-b56a-021a1dc56066.png align="center")

I increment the version of the resources, which triggers an update. The updates happen in no particular order.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672133062381/928610ee-11f8-44d5-babe-4941f33bb58a.png align="center")

Finally, I delete the specific stack and the resources are deleted in parallel in no particular order.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672133082949/5dd0bca4-0cfc-4df2-9506-9615750726ea.png align="center")

### Scenario 2: With dependencies

In this scenario, we use the [DependsOn attribute](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-dependson.html)

```yaml
Resources:
  Resource2:
    ...
  Resource1:
    ...
    DependsOn: Resource2
```

or in CDK the equivalent is

```python
resource1.node.add_dependency(resource2)
```

Specifically, in our example, we create a chain of dependencies where `resource-(n+1)` depends on `resource-n` .

As we see in the data, the resources are created one by one in order from `resource-1` to `resource-10`.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672133103139/d36551d3-b08c-4c64-bfd3-a7b5aa2a1a6e.png align="center")

The update is done in the same order from `resource-1` to `resource-10`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672133119054/b54cda16-9439-4fa7-880f-2aba9a1f9d08.png align="center")

while the deletion is performed in reverse order, i.e. starting with the last resource created `resource-10` and finishing with `resource-1` .

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672133128524/7d1f6c59-58bd-457c-bfb0-ac3cab041ae1.png align="center")

## Scenario 3: Nested stacks with dependencies

In this scenario, I place the resources within [nested stacks](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-nested-stacks.html). Nested stacks would usually contain several resources, but in this example, I only place a single resource per nested stack.

I create a similar chain of dependencies with scenario 2, but this time at the nested stack level. In CloudFormation this is done with the same `DependsOn` attribute (a nested stack is just another resource in the parent stack).

In CDK, this is done like this

```python
nested_stack1.add_dependency(nested_stack2)
```

See [here](https://github.com/codiply/cloudformation-dependencies-test/blob/main/stacks/with_nested_stacks.py) for the complete code of stack, including how to create nested stack with CDK.

Nested stacks are useful if your main CloudFormation stack is hitting one of the limits, e.g. size of the template or the number of resources per template.

Similarly to scenario 2, the resources are created in order from `resource-1` to `resource-10`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672133172292/0f0373d4-1cd3-421b-8541-b60e04b75e46.png align="center")

Update of resources happens in the same order they have been created

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672133182059/9b8fae9f-5ce1-44b5-9614-4dde8c04db91.png align="center")

and deletion happens in the reverse order, i.e. starting with the last resource created `resource-10`.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1672133194322/c47b2964-ec11-4bbe-b7c1-757187bd4738.png align="center")

## Summary of results

In this post, I tested experimentally the order of creation/update/deletion of resources in CloudFormation.

When no dependencies are defined between resources, operations happen in parallel in no specific order.

Next, I defined dependencies using the `DependsOn` attribute with 2 different approaches: dependencies at resource-level, or dependencies between nested stacks containing the resources.

When `A <- B <- C <- D` (`B` depends on `A`, `C` depends on `B` , ...), then in both approaches

* Resources are **created** in order `A`, `B`, `C`, `D`
    
* Resources are **updated** in order `A`, `B`, `C`, `D`
    
* Resources are **deleted** in order `D`, `C`, `B`, `A`