We Ditched Terraform 1.10 for CloudFormation: Reducing IaC Complexity for Our Small AWS Team

We’re a 4-person engineering team managing 32 AWS resources across dev, staging, and production environments for a B2B SaaS product. For 18 months, we relied on Terraform 1.10 to manage our infrastructure as code (IaC). But by Q3 2024, the overhead of maintaining Terraform outweighed its benefits for our use case. Here’s why we switched to AWS CloudFormation, how we migrated, and the results.

Our Terraform 1.10 Pain Points

Terraform is an industry-standard IaC tool, but for our small, AWS-only team, it introduced unnecessary complexity:

• State file management headaches: We corrupted our S3-backed state file twice in 6 months, leading to hours of manual reconciliation. Terraform 1.10’s state locking occasionally failed, causing concurrent apply errors.
• Versioning and compatibility issues: Upgrading from Terraform 1.9 to 1.10 broke 3 of our custom modules due to HCL syntax changes. We spent 12+ hours fixing compatibility issues, time we could have spent on product work.
• Steep learning curve for new hires: Our last junior engineer took 6 days to get up to speed on our Terraform module structure, state file workflows, and provider version constraints.
• Unused multi-cloud capability: We have no plans to leave AWS. Paying for (and maintaining) multi-cloud tooling made no sense for our use case.

Why CloudFormation?

We evaluated Pulumi and AWS CDK before settling on CloudFormation. As an AWS-native tool, it solved our biggest pain points out of the box:

• No external state files: CloudFormation tracks resource state via stack metadata, eliminating the risk of state file corruption. We use S3 to store template artifacts, but stack state is managed entirely by AWS.
• Built-in drift detection: CloudFormation’s native drift detection lets us see resource changes in one click via the AWS Console, no third-party tools required.
• Zero additional cost: CloudFormation has no subscription fees, unlike Terraform Cloud which we were paying $300/month for team seats.
• Tight IAM integration: We use existing IAM roles to manage CloudFormation permissions, no need to manage separate service accounts for Terraform.

Our Migration Process

We migrated 32 resources over 3 weeks with zero downtime, following these steps:

1. Audit and map resources: We listed all Terraform-managed resources and mapped them to CloudFormation resource types (e.g., aws_s3_bucket → AWS::S3::Bucket).
2. Start with low-risk resources: We first migrated static S3 buckets, IAM roles, and CloudWatch log groups, validating each stack before moving to critical resources.
3. Use CloudFormation import: For existing resources, we used CloudFormation’s resource import feature to bring live resources under stack management without recreating them.
4. Test and validate: We ran drift checks on each migrated stack to ensure no unintended changes, and ran load tests on our production RDS instance after migrating it to CloudFormation.

Results After 3 Months

The switch to CloudFormation delivered measurable improvements for our team:

• 60% reduction in time spent on IaC maintenance (from 10 hours/week to 4 hours/week)
• New hire onboarding time for IaC dropped from 6 days to 2 days
• Zero state file incidents since migration
• $3,600 annual savings from canceling our Terraform Cloud subscription
• Drift detection time dropped from 15 minutes (using terraform plan) to 2 minutes (via AWS Console)

Challenges We Faced

CloudFormation isn’t perfect. We had to adjust to:

• No native module registry: We use nested stacks to reuse common configurations, which requires more upfront setup than Terraform modules.
• Slower stack updates: CloudFormation stack updates take 2-3x longer than Terraform applies for large changes, though we’ve found this is offset by fewer errors.
• YAML quirks: CloudFormation YAML requires strict indentation and has limited built-in functions compared to HCL, but our team found YAML easier to read than HCL overall.

Final Verdict

For small, AWS-only teams, CloudFormation reduces IaC complexity without sacrificing core functionality. Terraform is still the best choice for multi-cloud environments or teams with complex custom module needs. But if you’re all-in on AWS and struggling with Terraform overhead, CloudFormation is a simpler, cheaper alternative that lets you focus on building products instead of managing IaC tooling.