Demo Remote State Configuration

This lesson shows how to configure Terraform to store its state remotely in Amazon S3. Using a remote backend provides centralized state storage, versioning, and — when paired with DynamoDB — safe state locking for team workflows or automation. If you prefer a different backend, consult the Terraform backend docs for that provider: https://developer.hashicorp.com/terraform/language/settings/backends Prerequisites:

An AWS account with permissions to manage S3, DynamoDB, and KMS (if you enable KMS).
Terraform installed locally.
Credentials available to Terraform (environment variables, AWS CLI profile, or an assumed role).

Below is a small existing Terraform configuration we will manage with a remote backend. Keep this file (for example main.tf) in your working directory.

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = "dev-main-vpc"
    Environment = "development"
  }
}

resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.main.id
  cidr_block = var.subnet_cidr
  tags = {
    Name = "dev-private-subnet"
  }
}

Overview of the steps

Create an S3 bucket to hold the state (enable versioning and encryption).
Optionally create a DynamoDB table for state locking.
Add an S3 backend block to your Terraform configuration.
Run terraform init to initialize the remote backend.
Apply your configuration; Terraform will store state in S3.

Step 1 — Create the S3 bucket Create an S3 bucket to store Terraform state. Recommended settings:

Bucket versioning enabled (for state history and rollbacks).
Server-side encryption enabled (SSE-S3 or SSE-KMS). SSE-KMS is recommended when you need fine-grained key control and auditing.
Block public access enabled.

In my example I created a bucket named krausen-terraform-state-bucket in us-east-2, enabled versioning, and enabled server-side encryption with KMS and the bucket key.

Screenshot of the Amazon S3 "Create bucket" console showing default encryption settings. Dual-layer server-side encryption (DSSE-KMS) is selected with a chosen AWS KMS key ARN and the bucket key enabled.

After creation I copied the bucket name for the backend configuration.

A screenshot of the Amazon S3 Buckets console with a green banner confirming the successful creation of the bucket "krausen-terraform-state-bucket." The General purpose buckets list shows three buckets and S3 actions like Create bucket, Copy ARN, Empty, and Delete.

Optional: create a DynamoDB table for locking To avoid concurrent state writes, create a DynamoDB table with a primary key named LockID (string). Terraform uses this table to acquire locks while modifying state. Example AWS CLI command to create the table:

aws dynamodb create-table \
  --table-name krausen-terraform-locks \
  --attribute-definitions AttributeName=LockID,AttributeType=S \
  --key-schema AttributeName=LockID,KeyType=HASH \
  --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
  --region us-east-2

Step 2 — Add the S3 backend configuration Create a file named terraform.tf (or add to an existing .tf file) and add a terraform block that configures the s3 backend. Provide the bucket name, an object key (path inside the bucket), the region, and optionally the dynamodb_table for locking and encrypt/kms_key_id options.

terraform {
  backend "s3" {
    bucket         = "krausen-terraform-state-bucket"
    key            = "prd/terraform.tfstate"
    region         = "us-east-2"
    dynamodb_table = "krausen-terraform-locks"
    encrypt        = true
  }
}

Backend configuration reference

Setting	Purpose	Example / Notes
`bucket`	The S3 bucket name that stores the state file.	`krausen-terraform-state-bucket`
`key`	The object path inside the bucket for the state file (e.g., environment or workspace path).	`prd/terraform.tfstate`
`region`	The AWS region of the S3 bucket.	`us-east-2`
`dynamodb_table`	(Optional) DynamoDB table name used for state locking. Table must have primary key `LockID` (string).	`krausen-terraform-locks`
`encrypt`	Whether to enable server-side encryption for the state object in S3.	`true` (default: `false`)
`kms_key_id`	(Optional) Use a specific KMS key for encryption. Provide the key ARN or alias.	`arn:aws:kms:...`

Step 3 — Initialize the backend After saving the backend block, run terraform init in your working directory. Terraform will configure the backend, download provider plugins, and create the lock file .terraform.lock.hcl. Example terraform init output:

$ terraform init

Successfully configured the backend "s3"! Terraform will automatically use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 6.31.0"...
- Installing hashicorp/aws v6.31.0...
- Installed hashicorp/aws v6.31.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository.

You must authenticate Terraform so it can access the S3 bucket (and the DynamoDB table, if used). Options include environment variables, a credential/profile configured in the AWS CLI, or an assumed role. Choose the authentication method that fits your environment and ensure credentials are available before running terraform init or terraform apply.

Tip: run terraform fmt to format your .tf files before applying. Step 4 — Apply your configuration When you run terraform apply (for example with -auto-approve), Terraform creates resources in your AWS account and writes the state file to the configured S3 key. Example apply output:

$ terraform apply -auto-approve

aws_vpc.main: Creation complete after 11s [id=vpc-0a1b2c3d4e5f67890]
aws_subnet.private: Creation complete after 13s [id=subnet-04bab1fb64bfc7e85]
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

You will not find a local terraform.tfstate file — the state is stored remotely at prd/terraform.tfstate inside krausen-terraform-state-bucket. With S3 versioning enabled, each state update becomes a new version; you can use S3 versioning to roll back to previous state versions if necessary. Best practices summary

Use a dedicated, versioned, and encrypted S3 bucket for Terraform state.
Use DynamoDB for state locking when multiple users or CI pipelines interact with the same state.
Restrict access to the state bucket and KMS key using IAM policies.
Keep .terraform.lock.hcl in version control, but do not check in sensitive state data (remote backends keep this out of your repo).
Consider separating environments via different state keys or buckets (e.g., dev/terraform.tfstate, prd/terraform.tfstate).

Links and references

Terraform backend docs: https://developer.hashicorp.com/terraform/language/settings/backends
S3 backend details: https://developer.hashicorp.com/terraform/language/settings/backends/s3
State locking docs: https://developer.hashicorp.com/terraform/language/state/locking
AWS S3 documentation: https://docs.aws.amazon.com/s3/index.html
AWS DynamoDB documentation: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Welcome.html

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Demo Remote State Configuration

Watch Video