When would you choose HCP Terraform's cloud block over a self-managed S3 backend for a team's Terraform state, and what does each choice cost you?

## What each option actually is **Self-managed object storage.** `backend "s3"`, `backend "gcs"` or `backend "azurerm"` writes the state document to a bucket or container in your own account. Locking comes from the backend itself: the S3 backend historically used a DynamoDB table (`dynamodb_table`) and, since Terraform 1.10, supports a native S3 lockfile via `use_lockfile = true`, with the DynamoDB option deprecated in 1.11. GCS and azurerm lock natively. Everything else — where the plan runs, who may approve it, what credentials the runner holds — is your CI system's problem. **HCP Terraform** (the 2024 rename of Terraform Cloud) is configured with a `cloud` block, which replaces the `backend` block and cannot coexist with one: ```hcl terraform { cloud { organization = "acme" workspaces { name = "platform-network-prod" } } } ``` It stores state with versioning and locking, but the product is really the layer above: a run history with plan output and who approved what, stored variables and secrets, team-level permissions, VCS-triggered runs, policy enforcement hooks, and remote execution where the plan and apply run on HashiCorp's workers instead of your runner. ## What you are actually comparing **Cost.** A state bucket costs cents a month. HCP Terraform's paid tiers price on managed resources, which grows with your estate rather than with your usage of the product. At small scale the free tier is generous; at large scale the number becomes a real line item that has to be argued against the engineering time it replaces. **Where credentials live.** With object storage, long-lived cloud credentials or an OIDC-federated role live in your CI system. With remote execution, they live in HCP Terraform. Neither is automatically better — the question is which system you would rather have as the thing that can change your production account, and which one your security review can actually audit. **Network reachability.** Remote execution runs outside your network, so anything only reachable privately — a database whose provider needs a private endpoint, an internal Vault, a Kubernetes API server with no public endpoint — will not resolve. HCP Terraform agents exist precisely for this: a worker you run inside your network that picks up jobs. That is an extra moving part, and if you were going to run workers anyway, some of the appeal fades. **Data residency and sovereignty.** State contains real resource attributes and often secrets. Some organisations cannot let that leave their own cloud account or region, and that constraint decides the question before any of the others are weighed. **What you stop building.** The honest case for the managed product is not the state storage — that is the easy part. It is run history, approvals, RBAC across dozens of teams, and a consistent way to run Terraform that new teams adopt rather than reinvent. If you have already built that on your CI system and it works, the managed product is buying something you own. **Lock-in and licensing.** The `cloud` block ties the run workflow to one vendor; migrating away is another `terraform init -migrate-state`, so the state itself is portable, but the pipeline around it is not. Since Terraform's move to the BUSL licence in 2023 there is also OpenTofu, a Linux Foundation fork, whose ecosystem and hosted options are part of the same decision for some organisations. ## The middle grounds people actually use HCP Terraform supports a local execution mode, where it stores state and provides the run record while the plan and apply still happen on your machine or your CI runner. That gets the state and audit layer without the network constraints of remote execution. Agents get remote execution into a private network at the cost of running the agent fleet. And plenty of mature platform teams run object-storage backends with a well-built CI pipeline and never feel the gap. ## The decision, stated as a rule Choose object storage when you already have a Terraform pipeline you trust, when residency or private-network constraints bind, or when the estate is large enough that per-resource pricing dominates. Choose HCP Terraform when the organisation has many teams and no platform team to build for them, when auditable run history and RBAC are requirements rather than nice-to-haves, and when the cost is genuinely cheaper than the engineers who would otherwise build the same thing worse. What should not drive the decision: the belief that only the managed product gives you locking or versioning — every mainstream backend does — or the assumption that migrating between them is hard. Moving state either way is one `init -migrate-state`; the workflow around it is the part that has weight. ## How to say it in an interview "S3 gives me state and a lock in my own account for nothing, and leaves the pipeline to me. HCP Terraform sells me the pipeline — run history, RBAC, approvals, optional remote execution — for a per-resource price and a network boundary I have to design around. I pick by whether we already have a Terraform platform and whether state may leave our account."