How Terraform Simplifies Provisioning Infra?

For all types of platforms...

Mar 25, 2025

Managing infrastructure manually is not just inefficient—it’s also prone to human error, inconsistencies, and scalability issues.

Terraform is one tool that makes this task easy.

Whether you're setting up a single virtual machine or orchestrating hundreds of microservices, Terraform helps you scale infrastructure efficiently and reliably.

Here’s a quick introduction to how it works. The diagram below shows the complete flow:

The diagram has been generated using Eraser’s AI diagram feature

Stage 1: Write Infrastructure as Code

At the heart of Terraform is the concept of Infrastructure as Code (IaC). Instead of provisioning resources manually through cloud dashboards or CLI tools, you describe your infrastructure in .tf files using the HashiCorp Configuration Language (HCL).

Key Elements:

Resources: Define infrastructure components like EC2 instances, S3 buckets, load balancers, or Kubernetes clusters.
Providers: Define which platform you are provisioning resources in—AWS, Azure, GCP, etc.
Variables: Allow parameterization of your code to support reusability and flexibility.
Modules: Group common resource configurations into reusable building blocks. Modules can be custom-built or pulled from the Terraform Registry, which hosts hundreds of community-verified modules.

See the below example of a terraform configuration

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = "t2.micro"
}

This simple example defines a web server in AWS, using a variable for the AMI ID.

In larger projects, you can organize your infrastructure into multiple environments (dev, staging, prod) using modules and workspaces.

Stage 2: Terraform Plan – Preview Before Execution

After writing your configuration, you need to understand what changes Terraform will make. That’s where terraform plan comes in.

How It Works:

Terraform reads your current state from a state file (we’ll come back to this later).
It compares the desired state defined in your .tf files with the actual state of resources.
It then generates an execution plan, showing what resources will be created, updated, or destroyed.

This gives you a safe, auditable preview of what Terraform intends to do—no surprises.

Why It Matters:

Prevents unintended changes.
Can be automated in CI/CD pipelines to enforce consistency across environments.
Detects drift between actual and declared infrastructure state.

In a collaborative workflow, running terraform plan in a pull request helps your team review proposed infrastructure changes just like they would with application code.

Stage 3: Terraform Apply – Provision Infrastructure

Once the plan is approved, it's time to apply the changes using terraform apply.

What Happens During Apply:

Terraform uses the execution plan to make API calls to the appropriate cloud provider(s).
It provisions, updates, or destroys infrastructure as needed.
As each action completes, Terraform updates the state file to reflect the new current state of the infrastructure.

Terraform is idempotent, meaning you can apply the same configuration multiple times and it won’t duplicate resources. It only changes what’s necessary.

Providers Supported:

Terraform supports dozens of providers, including:

Cloud platforms: AWS, GCP, Azure, Oracle Cloud
Containers and orchestration: Kubernetes, Docker
Monitoring: Datadog, New Relic
Databases: PostgreSQL, MySQL
Others: GitHub, Vault, Consul

This wide support makes Terraform ideal for managing entire ecosystems in a unified way.

Stage 4: Infrastructure Ready – The Role of State

Once resources are provisioned, Terraform maintains a state file (usually terraform.tfstate) that acts as the single source of truth for the deployed infrastructure.

Why State Matters:

Tracks the current configuration and status of all resources.
Enables Terraform to understand what changes need to happen in future runs.
Allows collaboration across teams using remote backends like Terraform Cloud, S3 with DynamoDB, or Azure Storage.

For teams, storing state remotely with locking mechanisms ensures that only one person (or pipeline) modifies infrastructure at a time—preventing race conditions and accidental overwrites.

Scaling with Terraform

Terraform scales easily from a single developer managing a test environment to enterprise teams managing hundreds of services across regions. Here’s how:

Modular design: You can create reusable modules and compose them into larger systems.
Automated pipelines: Easily integrated into CI/CD for consistent deployment.
Multi-cloud capability: Manage AWS, GCP, and Azure from a single configuration base.
Drift detection and rollback: Stay in sync with real-world infrastructure.

👉 So - have you used Terraform?

System Design Codex

Discussion about this post