Article preview: the full article can be found here.

When developers within a team are working on a feature, they are often faced with the situation that each developer is trying to work on a certain aspect of the feature that requires a different version of the infrastructure than we’ve deployed via a Cloudformation(CF) stack, be it an ECS(Elastic Container Service) cluster with multiple task definitions, or when using any other service provided by AWS.

We at Capmo also ran into a similar situation within our teams. The challenge was not the multiple versions of our infrastructure being deployed: It was how were we going to manage the clean up of the Cloudformation stacks once their work is done. That’s when the idea of auto-deleting the CF stacks came up. After doing some research on our side, we found out that the benefit of owning a piece of infrastructure stack for testing a feature makes the process more agile, flexible and reduces any dependency that might arise when subsequent infrastructure deployments take place, overwriting the previous version of the deployment.

Since our infrastructure deployments are taken care of by CDK, we wanted to have a solution in place which we can integrate with our existing Cloudformation stacks without any hassle. So we decided to package our solution that can be used in all our microservices if needed. And also with the possibility of making it open-source at some point in the future.

Automating deletion of Cloudformation stacks

Now that we knew what we wanted, the question was how to build the solution. We would need a trigger that would initiate the auto-deletion of the Cloudformation stack. This can be achieved with the help of an event, for which we used an EventBridge rule. EventBridge rules have the ability to match an event pattern and trigger its targets. The target of choice was a Lambda function that would initiate the auto-deletion sequence. A serverless solution was a clear answer to this as it makes write and deploy easier, with no effort of managing the deployed resources. All of this was deployed within the same Cloudformation stack that we wanted to delete. Now let’s dig deeper into how we implemented this.

To read on, the full article is published on our engineering blog.