This is a short article to share my experience with CloudFormation StackSets across the Organization. This is not a duplication of any documentation. Instead it shares my notes on ease of use, intuitiveness, gotchas and any other benefit that I perceive. These are just my opinions and has no bearing on the underlying product or AWS in general.
The StackSet Journey
1. The Setup:
I am going to use a CloudFormation script that creates a 3 tier network from scratch. Feel free to reuse my script (that can found in the resources section below) or use anything that works for you. My sample is not very complicated but takes a few minutes to deploy, when it’s directly applied in an account using a stack.
2. Enable trusted access
Only administrators can enable this setting. With this setting you can deploy across the organization. There’s a concept of delegated administrator accounts but I didn’t try that out. Instead I logged into the management account (the first account that enabled aws organizations) with a user having admin access.
If you want to try out registering delegated admin accounts try the guide here.
3. Creating the StackSet
Here, I plan to cover just the salient points of creating the stackset. I did the minimal to move forward. So this article doesn’t go through explanations of each field and what it accepts. Feel free to check the guide for more details if that interests you.
The create stackset screens start similar to creating a stack where you say the template is ready and you can provide a template from an s3 bucket or from your computer. I chose to upload my own file.
I left all options as default except for the Execution configuration I set as active, under deployment options I chose all accounts in organization and finally the region was scoped to us-east-1. I left the concurrency options as is and let the stackset rip.
Observations:
- Under the operations tab it said running against the stackset.
Under stack instances tab, each account that executed got a stack id assigned to it.
All accounts started with an OUTDATED status
here you see all accounts are outdated
first account initiated and got an id
first account completed and changed status to CURRENT and second account started processing
finally all accounts updated
- It was hard to say what was what was happening within each account as there was no feedback or details about the processing. On one of my previous attempts the whole stackset FAILED status and I had to switch to each account to delete the stacks to revert back and restart.
- When a stack was successful, the status changed to CURRENT. The next account now received an id as the execution is sequential by default.
- When all stacks completed, the stackset went into SUCCEEDED status.
4. Deleting the StackSet
While deleting the stackset I had to fill the same choices as in creation. I noticed I couldn’t delete the stackset until I delete all stacks within it and I had to know the organization ids to delete the stacks. This time I chose parallel execution and all of them got an id. Once done I could successfully delete the set.
attempt to delete stackset when stacks were not removed
initiating delete stacks within the organization
notice the account was deleted
finally account is ready to delete stackset
My Suggestions
- If this is your first time using a stackset make sure your stack executes in one account successfully
- Don’t make assumptions while executing stacksets. For example security group ids change across the accounts. So don’t hard code them.
- Add default values for things that are static. For example private cidr blocks to be assigned to a vpc or subnet
Final Thoughts
The stackset is not the most intuitive feature. With a little care you can be successful at it. There are alternatives within AWS to execute it against the organization using systems manager or programmatically. You may also use Terraform to make your deployments. Either way by trying it you practice some best practice of cross account deployments.
Resources
- 3 tier vpc network cloud formation script
[about Lionel Pulickal]
Lionel is a Cloud Engineer who has worked in the IT industry since 1997. He has all the 3 AWS associate level exams, the solution architect professional and networking specialty exams under his belt. He loves hands-on and always loves to share the knowledge he has gained over the years.
Top comments (0)