Using AWS Cloudformation stacks to manage our AWS infrastructure and components has been a pleasant experience that’s highlighted the cloud’s flexibility. Stacks allow us to know at a glance what we have up and available in an environment. They also allow us some flexibility if we ever want to move regions and provide a codified method for recreating our service. As an added bonus for our team, Cloudformation stacks provide us with a way to let each developer run a full environment clone of production so their work does not step on another’s toes.
Creating and using Cloudformation stacks was cumbersome at first, but I would still characterize Cloudformation as a straightforward technology. But sometimes, when you’re working on the leading edge of services, things don’t go as smoothly as everyone would like. The first major headache (and heartache) I’ve encountered with Cloudformation is the intersection of AWS rules and one of our important third-party services, Datomic Cloud.
Cognitect’s really sweet Datomic Cloud service is a shining example of how using AWS’ suite of tools and services enable entirely new tools catered to cloud development. Datomic Cloud is delivered via Cloudformation stacks, so on the surface, it seems to fit our environment like a glove. However, like any valuable data source, it is protected by a VPC. VPCs impose some restrictions on networking, and as our service needs both Datomic and Internet access, I am required to put a NAT into the VPC that Datomic Cloud creates.
On first glance, putting a NAT into a VPC looks pretty straightforward. However, our desire to completely automate and manage the environment with Cloudformation stacks is where all harmony breaks down. I have found that AWS VPCs are simply not modifiable enough via Cloudformation to completely wire up all the needed changes. Instead, I’m forced to put all the pieces in place and finish up with one last manual step with the AWS console UI. This cloud formation yaml file is the end result of my efforts – hopefully, someone, somewhere who runs into this same issue finds this yaml post and saves themselves a headache.
But these types of headaches are to be expected when you’re riding at the forefront of technology services. It’s where you find the rough edges that need some touch-up. I wouldn’t be surprised if there’s a workaround in the next few months to completely automate my deploy, but by then I’m sure we’ll find another rough edge to share.
If you’re a Site Reliability Engineer and want to see how our efforts overcoming Cloudformation challenges result in helping you in moments of crises, please sign up for our Early Access Program today!