A Review of AWS CloudFormation StackSets

At the recent AWS Summit in Chicago, Amazon introduced CloudFormation StackSets, a new feature to CloudFormation. As heavy users of AWS CloudFormation for implementing infrastructure as code in an automated, consistent way, we are dedicating today’s blog to reviewing the new CloudFormation StackSets. As proponents of DevOps automation, we are excited to see AWS automation extended through this new feature and will highlight how it can be applied through two specific uses cases.

First, however, let’s review. AWS CloudFormation enables users to create an infrastructure based on templates specified in YAML or JSON. Rather than setting up an environment manually, a CloudFormation template can be used to create all of the necessary resources. In addition to providing consistency, using automation reduces manual errors and increases efficiency.

Until now, this functionality was limited to a single account and a single region. Yet, the AWS infrastructure of an organization oftentimes spans across multiple regions as well as multiple accounts. In these cases, a way to make sure that infrastructure provisioning is consistent across the accounts and regions becomes important. Prior to CloudFormation StackSets, these cases had to be handled with different automation and scripts. Specifically, using CloudFormation templates, users would have to create all the stacks from scratch in a new region either through CLI, SDKs or through the AWS console. In addition to being inefficient, this approach also presented the risk of errors caused by manual interventions.

Two Use Cases

As promised, we have two use cases we will walk through as a way to examine the usefulness of the new CloudFormation feature:

Prepping/Hardening a New Account

Flux7 consultants have long recommended multiple accounts to clients as a best practice for maintaining the separation of roles and applications to address AWS security and AWS compliance policies. (It can be helpful for billing purposes, too.) In this vein, we usually recommend our clients use an account architecture spanning multiple accounts, which is especially helpful for different application environments such as Dev, QA, Production, etc.

Yet, when multiple accounts (or regions for that matter) are involved, the organization should keep all its accounts in a consistent state, keeping security policies, compliance policies and more constant across accounts. Prior to CloudFormation StackSets, Flux7 had wrapper scripts it would use to deploy CloudFormation stacks across AWS accounts. This process was cumbersome and harder to manage than with the new CloudFormation StackSets. Luckily, StackSets can now be used to deploy CloudFormation templates that enable CloudTrail, Config, and certain Config rules to flag non-compliance across accounts. Thus enabling organizations to remedy any non-compliance and consistently maintain the desired state.

Creating a Consistent Networking Infrastructure

Organizations often want to have a consistent networking infrastructure like VPC, Subnets, route tables, etc. For example, they may want to have VPN connections from their on-premise networks providing access to VPCs from a specific set of CIDR blocks. Or, they may wish to have security groups configured with ingress rules from specific IP addresses. These examples can be easily managed through StackSets.

Let us explain why CloudFormation StackSets is of great use here. First, creating CloudFormation StackSets is a one-time operation. Once StackSets are created and deployed, it is very easy to add additional accounts or regions. For, once the infrastructure is set up, it is very easily replicated. One merely creates IAM permission for the master account and then adds the new region and/or account to the StackSets. From here, all the stacks will be created automatically. This makes it very easy to manage and ensure consistency when new regions and/or accounts are added to the organization.

Working with global enterprises, a number of our customers are multinational companies that maintain multiple AWS accounts. In fact, we have had customers with over 100 AWS accounts and multi-region deployments. As these organizations grow their AWS-based infrastructure — and migrate more and more infrastructure and applications to AWS — maintaining consistency across these accounts becomes challenging. StackSets effectively address this issue by giving the ability to centrally manage and deploy infrastructure as code.

Limitations

It should be noted that the new StackSets feature does have some limitations that we’d like to see addressed in future updates:

Currently, a StackSet has a single template and parameter set. The same stack is created in all accounts that are associated with a StackSet. This means that any needed per account, per region configuration should be coded within the template.

Individual stacks within a StackSet cannot be updated. As a result, users need to balance granularity and standardization and decide on the number of StackSets accordingly.

If there are a large number of stack instances in a StackSet, then any operation like Create, Update, or Delete can take a significant amount of time.

In all, the new StackSets feature is a large improvement for any organization working with multiple accounts and/or regions and will bring additional consistency and efficiency to their AWS environment. As fans of AWS automation to increase productivity and decrease risk, we applaud StackSets ability to grow automation in the attainment of these goals. If you are interested in applying or growing DevOps automation in your environment, we recommend the following reading:

The Flux7 Enterprise DevOps Framework, a model for marrying DevOps process improvement with digital transformation.

Seven Steps to Successful and Sustainable DevOps Transformation

What is DevOps? And how do Code, Config, CI/CD & Containers Relate

DevOps Case Studies