Why I prefer Terraform over CloudFormation
I often get asked why I prefer Terraform over CloudFormation. I just ran into a nitpick of CloudFormation and decided to write this post before I forget about it.
So, I’m currently working on a relatively simple CloudFormation document that includes a CloudFront CDN that is in front of a S3 bucket. It also includes dependencies: the S3 bucket policy and the CloudFront Origin Access Identity. On my first try, I got something wrong in the CloudFront settings. OK, fine, I’ll fix it. It was a silly one-line mistake. Wait for cleanup to finish, removing the S3 bucket. Next, a mistake in the bucket policy. Another simple fix. This time the CloudFront distribution was already created, so I was already waiting for 3-5 minutes (I am so glad that it wasn’t 30 minutes like just a few years ago!). Wait for another 5-10 minutes for the distribution to be deleted and created again.
The simple solution is: don’t make mistakes. But that’s not how I develop software. I make tons of mistakes until it’s working the way I want it to work. CloudFormation is not conducive to that kind of development, and it really slows the development process down.
In contrast to Terraform, I would have been able to use the partially built resources (there were no problems with those resources itself) and I would have been able to get it to the level I wanted in less than a tenth of the time.
I understand why CloudFormation is the way it is, and it is a deliberate decision by the CloudFormation team – it’s better to roll back to a known good state than to have half-complete infrastructure. But it just doesn’t work with my infrastructure development process.
I haven’t tried CDK out yet. However, it just seems like it compiles code down to CloudFormation, which means it wouldn’t really help with this particular problem I just had.