State Machines


DOP-C02 Introduction
Amazon CloudWatch
Anomaly Detection
PREVIEW14m 35s
Advanced CloudFormation Skills
State Machines
Data Flow
19m 36s
AWS OpsWorks
Parameter Store vs. Secrets Manager
AWS Service Catalog
AWS Service Catalog
PREVIEW10m 34s
AWS Control Tower
AWS Control Tower
PREVIEW19m 56s
Managing Product Licenses
Amazon Managed Grafana
Amazon Managed Service for Prometheus
AWS Proton
AWS Resilience Hub

The course is part of this learning path

State Machines
7h 24m

This course provides detail on the AWS Management & Governance services relevant to the AWS Certified DevOps Engineer - Professional exam.

Want more? Try a lab playground or do a Lab Challenge!

Learning Objectives

  • Learn how AWS AppConfig can reduce errors in configuration changes and prevent application downtime
  • Understand how the AWS Cloud Development Kit (CDK) can be used to model and provision application resources using common programming languages
  • Get a high-level understanding of Amazon CloudWatch
  • Learn about the features and use cases of the service
  • Create your own CloudWatch dashboard to monitor the items that are important to you
  • Understand how CloudWatch dashboards can be shared across accounts
  • Understand the cost structure of CloudWatch dashboards and the limitations of the service
  • Review how monitored metrics go into an ALARM state
  • Learn about the challenges of creating CloudWatch Alarms and the benefits of using machine learning in alarm management
  • Know how to create a CloudWatch Alarm using Anomaly Detection
  • Learn what types of metrics are suitable for use with Anomaly Detection
  • Create your own CloudWatch log subscription
  • Learn how AWS CloudTrail enables auditing and governance of your AWS account
  • Understand how Amazon CloudWatch Logs enables you to monitor and store your system, application, and custom log files
  • Explain what AWS CloudFormation is and what it’s used for
  • Determine the benefits of AWS CloudFormation
  • Understand what the core components are and what they are used for
  • Create a CloudFormation Stack using an existing AWS template
  • Learn what VPC flow logs are and what they are used for
  • Determine options for operating programmatically with AWS, including the AWS CLI, APIs, and SDKs
  • Learn about the capabilities of AWS Systems Manager for managing applications and infrastructure
  • Understand how AWS Secrets Manager can be used to securely encrypt application secrets

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
Learning Paths

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 150+ courses relating to Cloud reaching over 180,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.