Infrastructure as Code Best Practices: Terraform vs. CloudFormation Deep Dive

Infrastructure as Code (IaC) is the foundation of modern cloud engineering. But the choice of tool often sparks heated debates. Should you go with the cloud-agnostic powerhouse Terraform, or the native AWS depth of CloudFormation?

The answer isn't "which is better," but "which is right for your team's workflow." Here are the technical nuances that actually decide it.

1. State Management: The Great Divide

Terraform: Managed State

Terraform keeps track of your infrastructure in a terraform.tfstate file. This is both its greatest strength and its primary management burden.

• Strength: You can inspect exactly what Terraform thinks is reality.
• Burden: You must manage state locking (e.g., using S3 and DynamoDB) to prevent concurrent runs from corrupting your infrastructure.

CloudFormation: Managed Reality

CloudFormation is "state-less" from the user's perspective. AWS manages the state internally.

• Strength: No state files to lose or corrupt. Rollbacks are handled automatically by the AWS engine.
• Constraint: It can sometimes be "stuck" in a DELETE_FAILED or UPDATE_ROLLBACK_FAILED state that requires manual intervention in the console.

2. Language: HCL vs. YAML/JSON

• Terraform (HCL): HashiCorp Configuration Language is purpose-built for infrastructure. It is more concise than YAML and supports powerful logic like for_each, dynamic blocks, and modules.
• CloudFormation (YAML/JSON): While YAML is readable, complex CloudFormation templates can become "Wall of YAML" nightmares. However, the introduction of AWS CDK allows you to write CloudFormation using real programming languages (TypeScript, Python, etc.).

3. The "Drift" Problem

Infrastructure drift occurs when someone makes a manual change in the AWS Console.

• Terraform: Excellent at detecting drift. A simple terraform plan will show you exactly what changed outside of code.
• CloudFormation: Has built-in Drift Detection, but it is a manual trigger and doesn't always cover every resource property perfectly.

Best Practices for Both

Regardless of the tool you choose, follow these three golden rules:

A. Modularize Everything

Don't write 2,000-line files. Break your infrastructure into reusable modules.

• Terraform: Use modules/ directories.
• CloudFormation: Use Nested Stacks or CloudFormation StackSets.

B. CI/CD Integration

Never run IaC from a developer's laptop. Use a pipeline to ensure every change is planned, reviewed, and then applied.

C. Version Control Your Provider/Engine

• In Terraform, lock your provider versions (aws ~> 5.0).
• In CloudFormation, be wary of using latest versions of macros if you have high stability requirements.

Comparison Summary

The Verdict

• Choose Terraform if: You use multiple clouds, want a cleaner language (HCL), or need the most advanced orchestration features.
• Choose CloudFormation if: You are 100% committed to AWS, prefer "zero-maintenance" state, or want the deepest integration with AWS-native security and support.

Evaluating your IaC strategy? Coding Protocols can help you refactor, migrate, or secure your Infrastructure as Code.

See also

• Import Existing AWS Infrastructure into Terraform with import Blocks

Frequently Asked Questions

Is Terraform better than CloudFormation?

Neither is universally better. Terraform wins on multi-cloud support, module ecosystem, and plan readability; CloudFormation wins on zero-infrastructure state handling, native service-team support on launch day, and automatic rollback. If your organization is AWS-only and heavily invested in StackSets and Service Catalog, CloudFormation is a defensible default. Everyone else usually lands on Terraform.

Can I use Terraform and CloudFormation together?

Yes, and many teams do. A common split is Terraform for the long-lived platform layer (VPCs, EKS, IAM) and CloudFormation where AWS forces it — SAM for serverless apps, Control Tower customizations, or third-party marketplace stacks. Terraform can even manage CloudFormation stacks via the aws_cloudformation_stack resource when you need to bridge the two.

Does CloudFormation have a state file like Terraform?

No — and that's one of its biggest operational advantages. CloudFormation tracks stack state server-side inside AWS, so there's no S3 bucket to secure, no state locking to configure, and no risk of a corrupted or leaked state file. The trade-off is less visibility: you can't inspect or surgically edit state the way terraform state commands allow.

What about OpenTofu — does this comparison still apply?

Almost all of it. OpenTofu is the Linux Foundation fork of Terraform 1.5 and remains drop-in compatible for the workflows described here, with the same state model and provider ecosystem. The licensing and governance differences are covered in our dedicated Terraform vs OpenTofu comparison.

Official References

• Terraform documentation — configuration language, state and provider behaviour
• Terraform state — remote backends, locking and drift