Infrastructure IaC State Management

Terraform Cloud Review:
What Actually Changes When You Stop Using S3

I managed Terraform state manually with S3 + DynamoDB for two years across 6 AWS environments before switching to Terraform Cloud. Here's my honest assessment of whether it was worth it.

8.6
SRE Score
Genuinely valuable for teams of 3+ using Terraform
The remote state, policy enforcement, and run history pay for themselves quickly. The CLI-driven workflow feels natural. The VCS-driven workflow has sharp edges you'll need to manage.

The Problem with Self-Managed Terraform State

If you've managed Terraform state with S3 + DynamoDB, you know the pain: someone forgets to run terraform init with the right backend config, two engineers run plan simultaneously and corrupt state, the DynamoDB lock gets stuck after a failed apply, and there's zero audit trail for who changed what and when.

This was our reality managing 6 AWS environments for a 40-person engineering team. I estimated we spent about 4-6 hours per month dealing with state-related incidents before Terraform Cloud.

Context: My team managed AWS infrastructure across dev, staging, and 4 production environments using Terraform. Team size: 3 SREs, 40 engineers with occasional Terraform access. We ran ~200 workspaces before migrating to Terraform Cloud.

What Terraform Cloud Actually Adds

๐Ÿ”’
Remote State
Encrypted state storage with automatic locking. No more stuck DynamoDB locks or concurrent run conflicts.
๐Ÿ“‹
Run History
Every plan and apply is logged with who triggered it, what changed, and the full output. Invaluable for incident retrospectives.
๐Ÿ›ก๏ธ
Sentinel Policies
Policy-as-code that enforces rules before apply โ€” tag enforcement, instance type restrictions, security group rules. This alone is worth the Plus tier.
๐Ÿ‘ฅ
Team Access Control
Workspace-level permissions. Developers can plan but not apply to production. SSO integration with Okta, Azure AD, etc.
๐Ÿ”‘
Variable Management
Encrypted variable storage per workspace. No more .tfvars files with secrets committed to git (yes, this still happens).
๐Ÿ”„
VCS Integration
Auto-plan on PR, auto-apply on merge to main. Powerful in theory, complicated in practice for monorepos.

Terraform Cloud Pricing โ€” Honest Breakdown

Free
$0
up to 500 resources
  • Remote state storage
  • Remote execution
  • VCS integration
  • 5 users max
  • No SSO, no Sentinel
Business
Custom
annual contract
  • Self-hosted option (TFE)
  • Multi-organization
  • Drift detection
  • Advanced security controls
  • SLA + dedicated support

Terraform Cloud vs. Self-Managed โ€” What Actually Changed

Concern S3 + DynamoDB (Self-managed) Terraform Cloud
State lockingManual DynamoDB โ€” gets stuckAutomatic, reliable
Secret managementtfvars files (dangerous)Encrypted workspace vars
Audit trailNone โ€” hope CloudTrail catches itFull run history with who/when/what
Access controlIAM policies (coarse-grained)Workspace-level permissions
Policy enforcementCode review only (humans fail)Sentinel โ€” automated, enforced
Multi-team setupPainful โ€” everyone needs S3 accessClean team/workspace model
Cost~$5/month S3 + DynamoDB$20/user/month
Monorepo supportWorks fine with any structureVCS triggers need careful config

The Sharp Edges No One Talks About

VCS-driven workflows are tricky with monorepos

If you run multiple Terraform workspaces from a single repo (very common in large orgs), configuring VCS triggers correctly is genuinely complex. You'll spend real time tuning working directory patterns and trigger filters. The CLI-driven workflow is much simpler and what I recommend starting with.

The free tier resource limit is real

The 500-resource limit on the free tier sounds like a lot until you start counting โ€” each security group rule, each subnet, each IAM policy attachment is a resource. A typical 3-tier web app with RDS can hit 200+ resources easily. Most real teams need Plus within 6 months.

Migration from S3 backend takes a day, not an hour

Migrating existing workspaces required a careful sequence: create workspace, configure backend, run terraform init -migrate-state, verify state. We had one workspace where a corrupt state required manual editing. Budget 4-8 hours for a team of 10-20 workspaces.

What Justified the Cost

  • Zero state corruption incidents since migration (vs. 3-4 per quarter before)
  • Sentinel policies catch security violations before they reach production
  • Audit log paid for itself the first time an incident required post-mortems
  • Non-SRE engineers can safely plan without risk of applying to prod
  • Encrypted variable storage eliminated tfvars-in-git security risk

Still Frustrating After a Year

  • $20/user/month adds up fast for a large engineering org
  • VCS workflow trigger configuration is genuinely complex
  • UI feels dated compared to modern SaaS tools โ€” functional but not polished
  • Run queue can back up during peak hours on shared runner pool
  • No native drift detection below Business tier โ€” use Atlantis for this

The OpenTofu Question

Since HashiCorp changed Terraform's license to BSL in 2023, OpenTofu (the open-source fork) has become a serious alternative. If vendor lock-in and licensing concerns are on your radar, OpenTofu + Atlantis + S3 backend is now a fully viable enterprise stack that costs a fraction of Terraform Cloud Plus.

My recommendation: if you're starting fresh today with a strong DevOps team, evaluate OpenTofu. If you're already in the HashiCorp ecosystem with HCP Vault and Consul, Terraform Cloud is the path of least resistance.

Start with Terraform Cloud Free

The free tier handles 500 resources with full remote state and VCS integration โ€” enough to evaluate the platform properly before committing to Plus.

Try Terraform Cloud Free โ†’

Affiliate disclosure: I earn a commission if you upgrade to a paid plan. My review reflects real production experience and is not influenced by this relationship.