CloudFormation stack imports and exports are a great way to easily pass around configuration values amongst CloudFormation stacks. They’re so useful that the CloudFormation best practice page lists using them as a best practice.
At my company, we use these a lot. They’ve been really helpful in passing configuration back and fourth. An additional benefit is that we can’t delete a stack that’s exporting a value when another stack is importing that value. Enforcing that dependency is valuable. We’ve also been able to simplify our automation - we don’t need to pass around VPC IDs in parameters, or update our CloudFormation when we deploy to additional regions if we do a little pre-planning.
We’ve recently gone through an exercise of completely re-building a piece of infrastructure that’s imported in a lot of places, which includes a rename of the underlying resources and exports. In order to better help scope this effort, I’ve been wondering what the web of imports and exports between CloudFormation stacks looks like in a network force diagram.
Between the twins naps, I spent a few hours building a simple go program that would gather data from the AWS APIs, format it for visualization, and an HTML/JS page to visualize the data. You can find a first pass here.
I usually build these types of utilities in Python, so this was my first pass at writing a program in GO. GO is continuing to get more popular, and seems like a nice middle ground to learn between Python (which I’m a fan of because it’s simplicity and ease of use) and Java (which is the predominant language of my current employer). It was an enjoyable experience, and I already have plans to leverage the parallelism that is part of the standard library in future iterations of this utility.
As always, I welcome feedback and pull requests!