Terraform Tutorial — Providers, Resources, and Your First Infrastructure

Overview and What You Will Learn

Before Terraform, creating an EC2 instance at a company like Razorpay meant logging into the AWS console, clicking through seven different screens, filling in a form, and hoping the engineer who did it last time left a wiki page with the exact settings. The next time you needed the same instance — for a new environment, a disaster recovery test, a colleague who just joined — you started from scratch. You got slightly different results every time. You could not audit what changed. You could not reproduce it reliably.

Terraform replaces all of that with a text file. You describe the infrastructure you want in plain, readable code. Terraform figures out how to create it, in the right order, using the cloud provider's APIs. Every setting is visible in the file. Every change is a pull request. Every environment is reproducible in minutes.

In this lab you will build real AWS infrastructure from a blank directory using the exact workflow engineering teams use at production scale. By the end you will have:

• Installed Terraform and configured AWS authentication
• Written a complete multi-file Terraform configuration with providers, resources, variables, and outputs
• Used terraform init, plan, and apply to create real AWS resources
• Read and understood plan output — the most critical skill for working safely with Terraform
• Made a live change and watched Terraform apply only what changed
• Cleaned up all resources with terraform destroy

Why This Matters in Production

At Razorpay, every engineer who wants to create infrastructure opens a pull request with a Terraform configuration. Another engineer reviews the terraform plan output posted as a PR comment. If it looks right, they approve. The CI/CD pipeline applies. The infrastructure exists — and the code that created it is in Git history forever.

This workflow gives the team:

• Reproducibility — any environment can be recreated from code in minutes, not days
• Auditability — every infrastructure change has a commit, an author, a reviewer, and a timestamp
• Safety — nobody can create infrastructure without another engineer seeing exactly what it does
• Consistency — dev, staging, and prod are created from the same code with different variable values

Teams that adopt this workflow reduce environment setup time from days to under an hour and eliminate entire classes of production incidents caused by configuration drift between environments.

Core Principles

The Terraform Workflow

How Terraform Talks to AWS

Detailed Step-by-Step Practical Lab

Prerequisites

Before starting this lab you need:

• An AWS account with IAM user or IAM role access
• IAM permissions: EC2 full access, S3 full access (for this lab)
• A terminal — macOS Terminal, Linux shell, or WSL on Windows
• Git installed

Step 1 — Install Terraform

Use tfenv to manage Terraform versions. It reads a .terraform-version file from your project and automatically switches to the correct version — the same way nvm works for Node.js.

Tip

If you cannot use tfenv, download Terraform directly from https://developer.hashicorp.com/terraform/downloads and place the binary in your PATH. Always use the same version as your team — version mismatches cause state file compatibility issues.

Step 2 — Configure AWS Authentication

Terraform uses your AWS credentials to call the AWS APIs. Never put credentials in .tf files — they end up in Git history and get leaked.

Step 3 — Create Your Project Directory

A well-organised Terraform directory separates concerns into different files. Terraform loads all .tf files in a directory together, so the separation is purely for readability.

Step 4 — Declare Terraform and Provider Requirements

Step 5 — Declare Input Variables

Variables make your configuration reusable across environments. Instead of hardcoding "ap-south-1" in ten places, declare it once as a variable and reference it everywhere with var.aws_region.

Create a terraform.tfvars file to set values for this environment:

Step 6 — Write Your Infrastructure Resources

Step 7 — Declare Outputs

Outputs print useful values after apply and make attributes available to other Terraform configurations.

Step 8 — terraform init: Download Providers

Run terraform init from the project directory. This downloads the AWS provider plugin, sets up the backend, and creates the lock file.

Remember

Commit .terraform.lock.hcl to Git. This file records the exact provider version and cryptographic hash — it ensures every engineer and CI/CD pipeline downloads the identical provider binary. Without it, a silent provider upgrade could change behaviour between teammates.

Step 9 — terraform validate: Check for Errors Before Plan

Validate checks syntax and internal consistency without making any API calls. Run it before every plan.

Step 10 — terraform fmt: Format Your Code

terraform fmt normalises all .tf files to the canonical Terraform style — consistent indentation, aligned equals signs, sorted block arguments.

Step 11 — terraform plan: Preview Every Change Before It Happens

This is the most important step. Read every line of the plan before applying. Nothing changes when you run plan — it is entirely read-only.

Plan symbols — memorise these before you ever run terraform apply:

Save the plan to a file for production CI/CD — this guarantees exactly what was reviewed is what gets applied:

Step 12 — terraform apply: Create the Infrastructure

Notice Terraform creates resources in parallel wherever dependencies allow — the S3 bucket and security group start at the same time. Once the security group exists, the EC2 instance starts. Terraform manages all ordering automatically from the dependency graph — you never write "create X before Y" anywhere.

Step 13 — Verify and Inspect State

Step 14 — Make a Change and Apply the Minimum Diff

Terraform calculated that only the instance type needed to change — everything else stayed untouched. This is Terraform's declarative model: you describe the desired end state, Terraform figures out the minimum set of changes to get there.

Step 15 — terraform destroy: Clean Up All Resources

Security

Always run terraform destroy after finishing labs to avoid unexpected AWS charges. A t3.micro instance left running costs roughly $8 per month. Set a billing alert in the AWS console as a safety net.

Production Best Practices and Common Pitfalls

• Pin provider versions with ~> MAJOR.MINOR. An unpinned provider (version = ">= 5.0") can auto-upgrade to a breaking major version. The ~> operator allows patch updates while blocking major jumps — ~> 5.0 means any version from 5.0.0 up to but not including 6.0.0.

• Use default_tags in the provider block. Declare shared tags once in the provider's default_tags block. They apply automatically to every AWS resource the provider creates — you cannot forget them on a resource.

• Never hardcode resource names. Use a locals name prefix: "${var.project}-${var.environment}". This ensures dev, staging, and prod resources all have distinct, recognisable names without duplicating logic across files.

• Use data sources for AMI IDs — never hardcode them. A hardcoded AMI ID eventually becomes outdated or unavailable in another region. The data "aws_ami" data source always returns the current patched image.

• Add a remote backend before your team grows. Set up S3 + DynamoDB locking as soon as a second engineer joins. Adding it later requires a state migration. Start remote from day one.

• Commit .terraform.lock.hcl, never .terraform/. The lock file records exact provider versions and cryptographic hashes — commit it so every engineer and pipeline is on identical providers. The .terraform/ directory is the downloaded binary — large, regenerated by terraform init, never commit it.

• Read every -/+ in the plan. Replace actions destroy the existing resource and create a new one — which causes downtime or data loss for stateful resources like RDS. Always understand why a replacement is happening before you apply.

Quick Reference and Troubleshooting Commands