In this video, we'll be talking about how CloudFormation works internally and how it handles the inputs we give it.

It's important to know that a stack is effectively a state machine inside of CloudFormation. Let's talk about how this works when you perform a create, update, and delete stack action in CloudFormation.

When you create a template in CloudFormation, the service will take the template that you provided and then change that template and the parameters into a stack. CloudFormation is acting as a transition function during the create operation. It takes one thing, in this case, a template, and turns it into something else, which is a stack here.

When you update a template, CloudFormation will take the new template with the updates, the parameters, and the existing stack, and then turn that into a new stack with all of your updates present.

And when you delete a template, CloudFormation will transform the existing stack into, well, nothing. The stack and all the resources you provisioned through the stack will be deleted.

So, why is this important? Well, it helps us to understand the service and how it works. This way, we're not treating it as some magical process, but to think of it as taking input and running that input through the CloudFormation service itself as a function to receive output.

Now, of course, the input and output look different based on whether you're performing a create, update, or delete action, but the functionality is the same, at the end of the day. This functionality is what makes these services so beneficial. CloudFormation will read our JSON and YAML templates, understand the dependencies between each resource in the system, and then invokes the transition function for each resource in the stack, until the very last resource is created.

So, when I trigger a create stack operation in CloudFormation, it first figures out from the templates the appropriate resource to create first. Ideally, it would start with a resource that does not depend on any other resources in the stack. It will create that resource by doing a signal of the create to the resource. It then creates the next resource in the template that depends on that resource, and so on.

There are some optimizations where CloudFormation will create two resources in parallel if that is appropriate, and they don't have any dependencies on each other. Same for update and delete.

CloudFormation resources themselves also follow a very similar life cycle to stacks, having create, update, and delete actions.

Similar to the stack create function, when CloudFormation creates a resource, we go from a user-defined list of properties through some logic and produce a new resource in the create cycle.

In the update cycle, we see that we take some user-defined properties, as well as the previous state, feed it into some custom logic, and we see another fresh resource.

And again, delete is almost identical to the stack life cycle in that there is a resource, some logic that it runs through, and then nothing. So, the flow is the function will take the defined properties, operate over those with some logic, and then produce or destroy actual resources.

The create action within a resource is invoked whenever we are creating a new stack or an existing stack that is being updated sees a new logical resource ID within the resources block.

The update function for resources is invoked during stack updates, whenever we change a property on a resource or we change a dependent resource of a property. For example, the update function will run for any subnet if the underlying VPC has been updated. This does not necessarily mean that the subnet itself has or will be changed. It simply means that the update function operates over the subnet and checks if there needs to be any updates done.

If no updates are found, CloudFormation will just return a success code and do no operations during an update. That is, there are many cases in which a previous resource is exactly equal to the fresh resource.

The delete action is invoked on resources whenever we are deleting a stack, or we are doing a full replacement operation on a resource in a stack during an update. This can happen when CloudFormation needs to clean resources that are no longer needed after a stack update.

During the first phase of an update that requires a full replacement of a resource, the update function will actually create a new fresh resource based off of the resource properties.

During the second phase, it will then delete the unused resource later. This pattern of new resource creation, then delete on full replacement updates, is important because it enables us to make major changes to stacks with minimal downtime.

In summary, CloudFormation acts as a state machine to create, update, and delete stacks. CloudFormation resources themselves are implemented via a resource provider logic function, which understands create, update, and delete.

Depending on which action is being invoked, the necessary inputs will be provided so that the CloudFormation service can appropriately process the request. That about wraps it up for our discussion of how CloudFormation actually processes, creates, updates, and deletes internally. See you next time.

State Machines and AWS CloudFormation

About