| Stack Sets are a killer feature, and so much easier than trying to do the same thing in Terraform. CloudFormation Drift Detection is very limited currently: it only supports a small subset of resources that you can create with CloudFormation. If your needs are covered by it, great, but it doesn't take much to go beyond its bounds. Also, it detects drift, but won't correct it. Terraform both detects and corrects drift on almost every resource, on every application. Sometimes there are limitations. This does result in extra work, as you can't just ignore drift without capturing that in code (via ignore_changes), but to me this is absolutely a desirable thing. We use CloudFormation to actually create the state resources to store Terraform state. Terraform can share outputs between different states using the terraform_remote_state data source, though there isn't any restriction on what can be done there (no requirement to update other stacks/states). Despite being an AWS-only shop, we've found the multi-provider support in Terraform to be really useful. For example, as part of our environment configuration, we store resources in Consul, create Pingdom checks, etc all from the same set of Terraform code. |
With Terraform (unless there is functionality I am unaware of) you need the repo where the terraform is stored to be able to perform that check. Then you need to setup the system that does the periodic checks (yes I know a cron in CI is barely any work if thats your desire).
Ultimately like a lot of things, CloudFormation VS Terraform is a long list of tradeoffs. I just would not personally write off CloudFormation depending on I actually need.