[dhab]

Could you elaborate why one would want to do this besides for unifying everything to terraform.

If you have already written cloudformation, you’d be losing a stack view which centrally describes things deployed in that AWS ac and how they are inter-related?

[shadycuz]

I actually thought your comments on having centrally described infrastructure pretty deserving of its own reply.

Because switching to Terraform doesn't mean you would lose this capability. It just moves it from the AWS console to your code repository. Correctly written Terraform code will show what is deployed in AWS and how it's inter-related.

Unfortunately while Terraform is an IaC tool, it will allow you to write non-IaC code. So if you have a Terraform root module, but you cant tell what's deployed where, because someone made the AWS creds a variable instead of hard coded... That's not real IaC.

[shadycuz]

I can think of a couple use cases.

1. You started on AWS using Cloudformation and now your branching out to other cloud providers and you want to use a cloud agnostic IaC tool.

2. Your company uses Terraform but you come across a rouge team that used Cloudformation.

3. Your company uses Terraform and your about to deploy X but you cant find any Terraform starter code but you do find an AWS quick start.

4. You started with Cloudformation but later discovered Terraform and now you want to migrate everything.

[shadycuz]

Okay so all of these are centered around unifying everything to Terraform. That's pretty much it's only use case.

[shadycuz]

Final follow up ;)

If you like Cloudformation, you might be interested in my Cloudformation testing library.

https://github.com/DontShaveTheYak/cloud-radar

It's the most powerful Cloudformation testing framework that exists.

It allows you to unit test your Templates locally with out deploying resources. That also means you don't need valid AWS creds while unit testing.