Infrastructure as Code with Terraform: the fundamentals

Provisioning your infrastructure by hand doesn't scale and isn't reproducible. Terraform describes your infrastructure as declarative code that is versionable and repeatable.

The basic vocabulary

• Provider: the plugin that talks to a platform (AWS, Azure, GCP…).
• Resource: a managed object (a VM, a bucket, a network…).
• State: the file that records the real state of the infrastructure.

A first configuration

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

provider "aws" {
  region = var.region
}

resource "aws_s3_bucket" "assets" {
  bucket = "inskillops-assets-demo"
  tags = {
    Environment = "demo"
  }
}

And the variables file:

variable "region" {
  type    = string
  default = "eu-west-3"
}

The init / plan / apply workflow

terraform init     # download providers
terraform plan     # show planned changes
terraform apply    # apply the changes

The plan is your best ally: it shows exactly what will be created, changed or destroyed before any action.

Best practices

• Store the state remotely (S3 backend + DynamoDB lock, Terraform Cloud…) for teamwork.
• Never change the infrastructure by hand in parallel with Terraform.
• Split into reusable modules and separate environments.
• Version everything in Git and review plan output in code review.

---

Terraform is the gateway to IaC. We build a complete cloud infrastructure step by step in the dedicated path.