This is the second post in a series of two on how Vantage securely connects to user AWS accounts. Start by reading the first post on how Vantage uses cross-account IAM roles https://www.vantage.sh/blog/how-vantage-uses-cross-account-iam-roles-to-securely-connect-to-customer-aws-accounts.
In the previous post we talked about how Vantage quickly and securely connects to users' AWS accounts. Immediately after connecting the root account the user can see all their cost data and begin exploring Cost Reports due to the fact that AWS root accounts have access to all member account cost data. However, in order to access resource level information, for instance seeing the full list of currently running EC2 instances, users have to connect one or more member accounts where those resources reside. This post outlines the reasoning for utilizing member accounts in the first place and how we use CloudFormation StackSets to automate the connection to these member accounts.
It is considered best practice to set up multiple member accounts as part of an AWS organization. It allows for better security practices, simplified cost allocation and for teams to move more independently. It is common for organizations to create AWS accounts per environment, team or project which can lead to dozens or even hundreds of AWS member accounts. AWS automatically aggregates cost data from member accounts up to the root account in order to provide unified billing reports, however access to service APIs, which Vantage uses to collect data about individual resources, requires specifically defined permissions for that account.
While it takes less than a minute to connect a single AWS account to Vantage, doing this process for each member account was cumbersome for our customers and took a long time. We wanted to provide as close to the "1-click" experience we have for connecting a single account and make it as seamless as possible to connect any number of member accounts. After a bit of research we decided to leverage CloudFormation StackSets.
CloudFormation StackSets are an extension of CloudFormation Stacks which allow you to run the same Stack across multiple AWS accounts. If you are unfamiliar with CloudFormation, it is an AWS service which provisions and configures AWS services based on an inputted template. With StackSets you also provide a single template along with a configuration of which accounts it should be deployed in and what permission mode should be used. Vantage currently uses the "service-managed" permission mode which requires AWS Organizations to be set up and configured. The other option is the "self-managed" permission mode which requires more setup and a role to be created in each member account. With the service-managed mode it requires no additional setup if your organization is already configured and it will automatically run the stack when you create a new member account. This is great because with no additional work new member accounts will automatically be connected to Vantage.
An overview of CloudFormation StackSets. Source.
The one downside to StackSets is there is currently no console UI we can integrate with to make it easy for the user to complete this process through the AWS UI. When not using StackSets we use the "quick-create links" functionality of CloudFormation to pass in required information via URL parameters. Using the "quick-create links", the user just has to click through the wizard to create the connection to Vantage. With StackSets, we instead give the user a set of AWS CLI commands to run in order to kick off the process. (P.S. If anyone from the CloudFormation team is reading, it would be great if AWS added the quick-create functionality for StackSets.)
The first command creates the Stack in the root AWS account, but does not yet run anything. Vantage passes a series of parameters (which are the same parameters that are passed to the regular CloudFormation quick-create interface) and a couple configuration options for StackSets. There are two configuration options you need to pass when creating a service-managed StackSet. AutoDeployment dictates whether new member accounts should automatically run this stack when they are created which the user can set to false if they would like to disable this functionality. RetainStacksOnAccountRemoval will automatically remove any created resources if the account is ever removed from the Organization.
aws cloudformation create-stack-set \
--auto-deployment Enabled=true,RetainStacksOnAccountRemoval=true \
--permission-mode SERVICE_MANAGED \
--stack-set-name <VANTAGE_GENERATED_NAME> \
--template-url <PUBLIC_URL_FOR_STACK_TEMPLATE> \
--parameters <SERIES_OF_VANTAGE_SPECIFIC_PARAMETERS>
The second command actually starts the process of running the Stacks for a StackSet. This command requires the name of the stack which was just created, the region and accounts in which you would like to deploy the stacks. For the accounts we use the Root organization ID since we want to deploy this to all member accounts, but this can be changed to use the Accounts parameter instead to limit the deployment to specific accounts.
aws cloudformation create-stack-instances \
--stack-set-name <VANTAGE_GENERATED_NAME> \
--regions us-east-1 \
--deployment-targets OrganizationalUnitIds=<ROOT_ORGANIZATION_ID>
Previous to this process we were not aware of StackSets. Overall they provide a very easy way for us to automate the connection to any number of member accounts and a great user experience for Vantage users. Users looking to find these commands with all of the correct parameters filled in can visit their settings page.
