Terraform on AWS: providers, state, and the remote backend

Providers: HCL over any cloud’s API

You met CloudFormation and CDK in the previous lesson — AWS-native tools where AWS parses your template and tracks the stack for you. Terraform, by HashiCorp, takes a different bet: one tool, one language (HCL, HashiCorp Configuration Language), across every cloud. The bridge to each platform is a provider — a plugin that maps HCL resource blocks to a vendor’s API calls. The aws provider turns an aws_instance block into EC2 RunInstances calls; the cloudflare or google provider does the same for their APIs. One configuration can declare resources across several providers at once, which is the whole pitch: a multi-cloud or multi-vendor estate described in a single language and workflow.

You declare the provider and a resource, and that is the unit of work. The block below pins the AWS provider version, sets a region, and asks for a bucket:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

resource "aws_s3_bucket" "assets" {
  bucket = "acme-prod-assets"
  tags   = { Team = "platform" }
}

That ~> 5.0 version constraint matters more than it looks: providers ship breaking changes, and an unpinned provider can rewrite half your plan after an unrelated upgrade. Pin it, the same way you pin a CloudFormation transform.

State: the thing CloudFormation hides and Terraform hands you

Here is the senior-defining difference. When you apply, Terraform writes a state file that records the bindings between objects in the real cloud and the resource instances in your config — the actual resource IDs, attributes, and dependency metadata. On the next run Terraform reads that state, refreshes it against the live API to detect drift (real world diverging from what state believes), computes the difference against your config, and plans only the delta. State is Terraform’s memory; without it the tool cannot tell a “create” from an “update.”

CloudFormation has the same memory, but AWS keeps it server-side and you never touch it. Terraform makes it a file you are responsible for — and that responsibility has sharp edges:

• Local state is dangerous for teams. A terraform.tfstate on one laptop cannot be shared, is lost if that laptop dies, and serializes nothing — two people cannot collaborate safely.
• State can contain secrets. An RDS password or a generated key lands in state in plaintext. Committing state to git leaks it; the backend must encrypt it at rest.
• Never hand-edit state. It is a derived index, not source. Editing it by hand desynchronizes it from reality; use terraform state subcommands or terraform import to adopt an existing resource into management instead.

Together these three rules add up to one principle: treat state as a shared, encrypted, locking database — because that’s what it is. Skip any one of them and you’re one concurrent apply or one git push away from leaking credentials or losing resources.

The remote backend and state locking

The fix for every state hazard is a remote backend. The S3 backend stores the state object in an S3 bucket (bucket + key + region) so the whole team reads and writes one shared, durable copy, and it encrypts that state at rest. The second half is state locking: before mutating state, Terraform acquires a lock so a concurrent apply must wait instead of racing. Historically you supplied a DynamoDB table (a partition key named LockID) via dynamodb_table; that path still works but is now deprecated in favor of S3-native locking — set use_lockfile = true and Terraform writes a tflock object alongside the state to coordinate, with no separate table required.

terraform {
  backend "s3" {
    bucket       = "acme-tf-state"
    key          = "prod/network/terraform.tfstate"
    region       = "eu-central-1"
    encrypt      = true
    use_lockfile = true
  }
}

With this in place, the Hook’s race cannot happen: the second engineer’s apply blocks on the lock until the first finishes and releases it. This is the configuration the “to keep things simple” team skipped.

Reading the plan, and modules

terraform plan is the safety gate, and reading it is a senior skill. It prints the diff with four actions: + create, - destroy, ~ update in place, and -/+ replace — destroy then recreate. That last symbol is the dangerous one. A field that cannot be changed in place (renaming a DB identifier, changing an immutable attribute) forces a replace, and a replace of a database means it is destroyed and a fresh empty one is created. The plan tells you in plain text — -/+ destroy and then create replacement — and an engineer who applies without reading it loses the data. Always read the plan before you apply; that is the entire reason plan is a separate command.

terraform init        # download providers, configure the backend
terraform plan        # refresh state, show the create/update/replace/destroy diff
terraform apply       # acquire lock, execute, write state back

The last building block is modules — reusable, parameterized bundles of resources, pulled from the public registry or a local path, so you write a VPC once and call it across environments instead of copy-pasting HCL. Modules are how a Terraform codebase stays DRY at scale.