This whole article is a case <i>not</i> to use Terraform.<p><pre><code> If you are creating an RDS cluster, CloudFormation will call the RDS REST endpoint for you.
</code></pre>
And so AWS takes care of things like retries, and you won't hit AWS's API call limit.<p><pre><code> With Terraform, the error messages you get are usually much more informative
</code></pre>
Often the errors are completely cryptic, or even misleading. Anyway, this isn't really a reason not to use CF or TF, it's a reason not to use AWS.<p><pre><code> With Terraform, you need to use valid credentials that grant access to multiple accounts.
</code></pre>
This is a security and reliability concern. Not only that most people end up making one credential which can access <i>everything</i>, but that people then end up running Terraform from one place, rather than running it per-account/per-region/per-AZ, which is much more resistant to failure and separates security domains.<p><pre><code> CloudFormation’s pseudo parameters and intrinsic functions are cruel jokes. By contrast, Terraform offers a rich set of data sources and transforming data with Terraform is a breeze.
</code></pre>
The more complicated you get with Terraform, the worse it works. This is actually a truism of all DSLs, but when you're using a DSL to talk to a program to talk to an API to talk to a program, it gets even worse. For example, some AWS resources will not work with Terraform properly unless you remember to apply the correct lifecycle policy (they'll go into a create/destroy loop, or never be able to be destroyed, or created, etc). With CF, AWS is taking care of that decision for you.<p><pre><code> AWS CloudFormation is S-L-O-W.
</code></pre>
Someone hasn't tried to apply a Terraform root module that manages hundreds of different resources, I see... Terraform can take dozens of minutes, to hours, depending on how carefully you've crafted your root modules, or your network latency, or even problems with AWS's TF provider. And if you're using STS creds that expire, it can leave you with broken infra / a broken remote state.<p><pre><code> Terraform, on the other hand, will occupy your shell until the directly-involved AWS service coughs up an error. No additional tooling is required.
</code></pre>
There's like 5 different hosted cloud services dedicated just to being able to run Terraform for large teams without it breaking or taking forever. On top of that, often Terraform will fail to apply, <i>half way through applying</i>, because Terraform doesn't ask APIs to validate all the operations before it starts performing them, and it often doesn't even check whether the operation it wants to do makes sense. It is <i>very common</i> for 'terraform apply' to break your Production infrastructure because it was literally impossible for you to know it would work until you tried it.<p><pre><code> If you learn AWS CloudFormation, then guess what: you can’t take your skills with you.
</code></pre>
This is almost a legitimate criticism, but it's not like using CF stops you from using Terraform too. You can use either, or both (just not on the same resources).<p><pre><code> Useful providers you can run on your own laptop include TLS key generators and random string generators.
</code></pre>
I highly recommend not using these. Makes it harder to run TF deterministically, and you want as much determinism as you can get in Immutable IaC.<p><pre><code> Importing Existing Resources
</code></pre>
This is a manual nightmare with TF. Terraformer, a completely different tool, makes this easier.