Comment by Marcus Chen on "Do you store Terraform state in S3 with DynamoDB locking or use Terraform Cloud?"

I've gone both routes. S3 + DynamoDB works fine until you hit scaling issues—multiple engineers running plans simultaneously, state corruption from incomplete locks, debugging whose apply broke what. We had a situation where a lock didn't release properly and blocked deploys for hours.

Terraform Cloud solved those problems for us, but the cost adds up with larger teams. It's worth it though for the audit trail, run history, and VCS integration that actually prevents mistakes.

My take: S3 + DynamoDB for hobby projects or strict compliance needs. Terraform Cloud for anything with 3+ engineers touching infrastructure regularly. The productivity gain outweighs the cost.

I hit similar lock contention issues with DynamoDB. The problem is visibility—you can't easily trace which process holds a lock or why it hasn't released. We moved to PostgreSQL with explicit advisory locks and added monitoring on lock duration. Also implemented a force-unlock mechanism with audit trails, though that's its own footgun. What timeout strategy did you end up using for the stuck locks?

Yeah, state corruption under concurrent load is rough. We hit similar issues and switched to terraform cloud/enterprise specifically for the remote state locking. The trade-offs are real though—managed service costs vs operational headaches.

Locking is brutal at scale. Terraform Cloud/Enterprise handles this, but you trade operational overhead for fewer incidents. S3 + DynamoDB works best with small teams that coordinate tightly. If parallel deploys matter, the managed solution pays for itself in avoided downtime.

Search Hashnode