1. Home
  2. Training Library
  3. Automation & Optimization (SOA-C02)

State Machines

Contents

keyboard_tab
AWS CloudFormation Operations
6
State Machines
PREVIEW8m 54s
7
Data Flow
19m 36s

The course is part of this learning path

State Machines
Overview
Difficulty
Beginner
Duration
1h 23m
Students
44
Ratings
5/5
starstarstarstarstar
Description

This section of the SysOps Administrator - Associate learning path introduces you to automation and optimization services relevant to the SOA-C02 exam. We will understand the service options available and learn how to apply these designs and solutions to meet specific design scenarios relevant to the exam. 

Learning Objectives

  • Understand how to decouple architecture using Amazon Simple Notification Service and the Simple Queue Service
  • Learn how AWS CloudFormation can be used to optimize and speed up your deployments using infrastructure as Code (IaC)
Transcript

Today we'll be talking about the true nature of CloudFormation, and a way to reason about the system so that we can learn further advanced topics. First, let's talk about how CloudFormation actually achieves the create, update, and delete actions when we work with stacks.

It's important to know that a stack is effectively a state machine inside of CloudFormation. How does this work? Well, CloudFormation acts as the transition function that changes templates and parameters into a stack during a create operation, templates, parameters, and the present stack into the next stack iteration, and transforms the present state of the current stack into nothing. That is, deleting it. Why is this important? Well, it helps us to model our stack creation, not as some magical process, but to think of it as taking two inputs, running through the CloudFormation service itself as a function, or rather the CloudFormation create operation that produces a stack.

When we do an operate operation, it's important to understand that we not only get the original parameters and template that are coming in, but we also get this present state of the stack. That is, CloudFormation needs all three of these things to go through and do an update. We need the two new inputs and the present state to produce the new state. We also need the present state to delete, which should be pretty clear.

Now, this is pretty a complicated operation, but the entire benefit of CloudFormation is that it reads our JSON templates, understands the dependencies between each of the resources in the system, then invokes the transition functions for each resource in the stack, and propagates it until the very last resource that depends on the most recent other updated resource is finished.

So when I trigger a create over here in CloudFormation, it first figures out from the template the appropriate resource to create first. That would be a resource that does not depend on any other resources in the stack. It will create that resource by doing a signal of a create to the resource, then create the next resource that depends on that resource, etc.etc.

There are also 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. However, in the update function, we also receive this third parameter, which is the present state of the stack. It is important for the update cycle to have the present stack value because CloudFormation needs to know how to modify some existing resources to create the new stack state. Or in cases where we do a full replacement operation, CloudFormation needs to know how to create the new value of the stack based on the template and parameters, but also delete the present stack based on the old values. Then during the delete cycle, CloudFormation needs the present state of the stack in order to delete everything and reduce the stack to nothingness.

Now, why is this important that we understand how the CloudFormation service itself acts as a state transition function? Well, because this is very similar to how resources behave. This slide should look pretty familiar after looking at the stack state machine slide before. This is because resources follow a very similar life cycle model to stacks, having create, update, and delete actions themselves.

As we can see, similar to the stack create function, 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.

As I was saying on the previous slide, these resource provider logic functions are CloudFormation or user-defined functions that take a properties object defined in the resources block of the template, operate over it with some logic, and then produce actual resources, which can then be referred to elsewhere in the template using the ref function or fn.getAttributes.

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 underlying resource represented by the subnet inside of the template 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 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 second kind of delete happens during the update complete cleanup in progress stack status. This second form of delete that happens during the update cleanup phase is important to clean resources that are no longer needed after a stack update, which produces new resources.

For example, if we have a stack in which we model a VPC and a subnet and we change the underlying VPC to map to a different CIDR block, then the VPC will be fully replaced. Because subnets belong to VPCs, the subnet will also be updated in order to fully replace it and move it over to the other VPC.

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 resources are implemented via a resource provider logic function, which understands create, update, and delete. Depending on which action is being invoked, the different properties will be provided to this resource provider logic.

In most cases, the resource provider logic is defined by the CloudFormation team itself. In some cases, we can author our own resource provider logic in order to extend the functionality of CloudFormation.

Later in the course, we will go over how to create your own custom resource provider logic functions in order to define custom resources that can be used in templates. When we do this, we will also use something called a service token. When using built-in CloudFormation resources, the service token is already known to the CloudFormation template since it's a built-in resource.

When creating or utilizing a custom resource, the service token defines either the SNS topic that the custom resource should post its properties to, or the lambda function that the custom resource should submit its property to for event processing when it's time to run the resource provider logic itself.

That about wraps it up for our advanced discussion of how CloudFormation actually works internally. Next up, we'll be discussing how to tie into the fronts and backs of these different resource life cycles by using SNS topics to create automation.

About the Author
Avatar
Stuart Scott
AWS Content Director
Students
170496
Labs
1
Courses
140
Learning Paths
96

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 90+ courses relating to Cloud reaching over 140,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.