For those not familiar with it, AWS CloudFormation allows you to create and update any number of AWS resources in an automated and repeatable way. Basically, you can create a JSON template which specifies all the resources for a given “stack,” upload it to CloudFormation, and the service takes care of provisioning and updating all those resources automatically.
CloudFormation templates support almost all the available AWS resource types, including specifying the dependencies which exist between those resources for your stack. For example, a single template could contain all the resources to setup a basic three tier web application infrastructure: IAM for users and access administration, EC2 instances for web and application servers, Aurora/RDS for database storage, S3 for assets, Route 53 & Elastic IP/Load Balancing for networking… just about any AWS resource can be specified and configured in a CloudFormation template. And Amazon provides many sample templates to get you started.
One advantage of using CloudFormation is it allows for a “code as configuration” approach to your AWS infrastructure. Since CloudFormation templates are simply JSON files, they can be treated as source code; checked into version control, reviewed using existing processes or pull requests, and then manually or programmatically deployed using the CloudFormation CLI. In theory, this can make deployments repeatable and updates to existing stacks much easier. In practice though, there were still a few issues that would come up which these latest changes to the service help solve.
One problem was the lack of visibility into how CloudFormation parses a new version of a template for an existing stack, and the associated changes that it determines need to be applied to your resources based on that new template version. And closely related to that, being able to review those changes before CloudFormation automatically attempts to apply them. One scenario that many folks have encountered is the situation where CloudFormation automatically, and unexpectedly, recreates a resource (for example, an EC2 instance) because the updated template contained a change which couldn’t be applied to the existing resource. As templates get larger and the number of dependencies between resources grow, these types of situations get to be both more common and harder to detect at just the template level.
To address both of these issues, CloudFormation now supports the concept of a “change set.” Once you upload the template, CloudFormation will parse it and produce a change set which you can review before having the service apply those changes. This should address the issues described above by providing developers with more visibility into how CloudFormation parses and deploys changes in your templates. These change sets are viewable and executable in both the console and via the CLI. And they also can have access control applied to them via IAM, so for example, one group could be responsible for updating templates and creating new change sets, while another group could be responsible for review and deploying those change sets.
All in all these changes solve some key issues that existed in the service, and provide some additional functionality that could be very useful. See the Amazon blog post for all the details on these updates.