Terraform on AWS
Provision AWS with Terraform's aws provider, with remote state in S3.
Terraform manages AWS through the aws provider. You configure a region and
authenticate via the AWS CLI credentials, environment variables, or — best for CI —
OIDC role assumption (no static keys). The workflow is the same everywhere:
init → plan → apply.
For teams, store remote state in S3 with a DynamoDB table for locking, so state is shared and concurrent applies can’t corrupt it. Compared to CloudFormation, Terraform is multi-cloud and uses HCL; CloudFormation is AWS-native.
terraform {
backend "s3" {
bucket = "my-tfstate"
key = "prod/terraform.tfstate"
region = "eu-west-1"
dynamodb_table = "tf-locks"
encrypt = true
}
}
provider "aws" {
region = "eu-west-1"
}
resource "aws_s3_bucket" "uploads" {
bucket = "my-app-uploads-12345"
}terraform init && terraform plan && terraform apply- Write a
provider "aws"block with a region. - Configure an S3 backend with DynamoDB locking.
- Add a resource for an S3 bucket and run
terraform plan. - Compare Terraform and CloudFormation in two sentences.
Cheat Sheet▾
| Item | Detail |
|---|---|
| Provider | provider "aws" { region = … } |
| Auth (CI) | OIDC role assumption |
| Remote state | backend "s3" |
| Locking | DynamoDB table |
| Workflow | init → plan → apply |
| vs CloudFormation | Multi-cloud, HCL vs AWS-native YAML |
Common Interview Questions▾
How do you store Terraform state for an AWS team?
In an S3 bucket (versioned, encrypted) with a DynamoDB table for state locking, so everyone shares one authoritative state and concurrent applies are serialized.
Terraform vs CloudFormation — when would you pick each?
Terraform for multi-cloud or a single toolchain across providers, with HCL and a large module ecosystem. CloudFormation when staying fully AWS-native with deep service integration and no extra tooling.