chris - Fotolia
CloudFormation StackSets drive cross-account automation
AWS gave its automation capabilities a boost with the release of CloudFormation StackSets, a feature that lets dev teams deploy stacks across multiple accounts and regions.
Many DevOps teams define infrastructure as code and automate cloud resource deployment through declarative templates. AWS has supported this powerful technique for several years through its CloudFormation service.
Until recently, AWS customers could only automate their infrastructure within a single region and account. Most customers now have multiple AWS accounts for various teams within their organizations. It's also common to use multiple regions to support global applications and enable geographic redundancy for their supporting services. This left a gap in automation capabilities for those customers.
Therefore, AWS introduced a new feature called CloudFormation StackSets, enabling customers to deploy CloudFormation stacks across multiple AWS accounts and regions.
Let's take a look at how AWS implemented CloudFormation StackSets and how to build a stack across two separate AWS accounts.
Configure the administrator account
The traditional CloudFormation console provides a central point of administration for StackSets; this gives a DevOps team a simple option to kick off deployment and monitor the status of a build across multiple accounts in various regions.
Within StackSets, a central administrator account manages CloudFormation stacks. This administrator account controls the stack operations that happen within other AWS accounts, referred to as target accounts. To enable CloudFormation to perform this work, configure AWS Identity and Access Management (IAM) permissions in both the administrator and target accounts.
The AWS administrator account will need to create an IAM service role, which allows CloudFormation to assume an IAM role in your target accounts to manage resources on your behalf. This delegation model ensures that an admin account will be able to manage CloudFormation stacks in target AWS accounts.
Create this service role via CloudFormation templates that AWS provides. The template creates the required IAM service role with the correct policy settings and trust relationship.
Configure the target accounts
For each AWS account in which you want to deploy resources with CloudFormation StackSets, you'll need to create another IAM service role that defines which resources can be created inside the target account. CloudFormation assumes this role from the admin account and uses the permissions defined within it to carry out all required tasks.
AWS also provides a CloudFormation template for this service role. The template creates the required IAM service role with the correct policy settings and trust relationship. You'll need to provide the admin account ID when you deploy this template. This enables the trust relationship in the service role to allow only the admin account to assume these permissions. Documentation for CloudFormation StackSets contains more information on role configuration for admin and target accounts.
Create your first StackSet
With the requisite permissions in place, we can build our first StackSet. Sign into the admin account and navigate to the CloudFormation console. Click on Create new StackSet to start the new StackSet wizard.
Next, define which template will create the stack in your target accounts. In this case, I used a sample template to enable AWS CloudTrail. You can also upload your own CloudFormation templates on this page or provide the URL to the template in a Simple Storage Service bucket.
Next, provide a name for the StackSet. Depending on the template, you might have a number of parameters available to control the behavior of the build process. In this case, I left the default options enabled.
The deployment option screen requires several important inputs. As shown in the image above, I defined the target AWS account number where I want to create the stack. I could also select an AWS organizational unit or upload a CSV file containing multiple AWS target account IDs. Note that I chose the stack's region within the target AWS account instead of on this screen. In theory, I could select multiple accounts and regions on this screen.
Finish the remaining prompts to deploy the stack in the target account. Keep in mind that this simple example targets only one account, but this approach becomes even more valuable when you manage multiple accounts that need to have resources deployed to them in parallel and across multiple AWS regions.
