Your friends: AWS Organizations and CloudFormation StackSets

2017-11-07, 14:36 Posted by: Aki Karjalainen

AWS recently extended CloudFormation functionality to include a feature called StackSets which allows you to create and manage stacks across multiple accounts and specified regions. I wanted to use this opportunity to write a little bit about CloudFormation StackSets but I think AWS account structures and organizations is an interesting matter as well especially when combined with StackSets.


cloudformation stacksets

What I hear a lot is how to address security when migrating workloads from traditional data center to AWS. As traditionally IT security has built heavily on network segmentation approach, like having different networks and firewalls in between them etc., it's not necessarily crystal clear how to leverage this segmentation strategy in AWS as there is no physical devices to manage and in many cases building castles and walls is not a viable strategy anymore. Whatsoever, you need some kind of security constructs that enable you to create the necessary security segregations. So, you've figured out you want some segregations to be in place in your AWS setup. How about segregating by VPC. Having separate VPCs in the same account does not separate the administrative control for each VPC as the same account controls both VPCs and its resources. That is, this has very limited security benefit. However, at network level you may have some benefit as by default VPCs can’t talk to each other.

Next, segregation by the next logical construct, subnet. In my opinion, it may make sense to segregate your projects by subnets if using a single VPC. While it may not provide much security isolation, at least it makes things a bit more organized. And in many cases it helps to identify the resources by looking at the subnet allocation of the resources if nothing else.

Usually one size does not fit all, but the highest level of isolation can be provided by segregating by AWS accounts. So, you end up creating many accounts, e.g. one for project X dev, another for project X production etc. This gives administrative isolation to you. And limits the blast radius. Well when you go ahead and create many accounts, eventually you would like to organize them in some sort of security or organizational hierarchy. AWS Organizations lets you do exactly this. Moreover, you may want to consider having a dedicated "identity account". Identity account approach means that you manage your users in a single account and enable specific groups to access to access resources in other accounts (IAM cross-account roles). IAM roles grant temporary access to another account based on the policy and trust relationships.



 Another beneficial account structure pattern is called "logging account". Basically, it means that you store centrally AWS logs, e.g. CloudTrail. You configure accounts to send logs to the parent logging account, S3 bucket that the parent account owns. If you leverage this with AWS Organizations you may want to look into using SCP (service control policy) policies to restrict target accounts from modifying CloudTrail setup. It's also possible to define alarms if your logging setup is changed in any of your target accounts. Or you may want to have a hybrid account, both logging and identity functionality aggregated to single account, or even billing. Whatever you decided just make sure that account relationships are clear and documented.

Now when you have your accounts set up and organized in AWS Organizations let's have a quick look at StackSets. CloudFormation StackSet core concepts include admin account, target account, stack instance, stack set and trust relationship between the admin and target account. Admin account is the account you use to administer the stack sets (it may be your identity account, logging account, security account, billing master account or a dedicated admin account). A stack instance is a reference to a stack in a target account within a region.

stacksets diagram


When you create a stack set you define which are the target accounts to which the sets are to be deployed. A very nice feature is an ability to choose an OU, versus listing all the target accounts. Next you take your usual CloudFormation template which you deploy. When you manage stacks you can also specify operation preferences, the order of regions in which you want the operation to be performed, the failure tolerance beyond which stack operations terminate if there's any exceptions, and the number of accounts in which operations are performed concurrently. You can also define a set of tags which are applied to every resource which is created by the StackSet.


comments powered by Disqus