Terraform & Infrastructure as Code: From Zero to Production
Learn how to define, version, and deploy cloud infrastructure automatically using Terraform and HashiCorp Configuration Language (HCL).
What Is Infrastructure as Code (IaC)?#
In traditional cloud management, engineers configured servers, VPC networks, and databases by manually clicking around the AWS, Google Cloud, or Azure web consoles. This manual approach inevitably leads to severe operational risks: configuration drift between staging and production, untracked security loopholes, and environments that cannot be quickly recovered after an outage.
Infrastructure as Code (IaC) allows developers to define and provision cloud infrastructure using declarative configuration files.
Terraform (by HashiCorp) is the industry-standard, open-source IaC tool that supports over 3,000 cloud providers through a single unified language: HashiCorp Configuration Language (HCL).
1. The Core Terraform Workflow#
The standard Terraform lifecycle follows a simple 3-step loop:
[ Write HCL Config (.tf) ]
│
▼
1. terraform init ──► (Downloads cloud provider plugins)
│
▼
2. terraform plan ──► (Generates speculative preview diff)
│
▼
3. terraform apply ──► (Provisions cloud resources via API)2. Practical Example: Provisioning AWS S3 & Cloudflare DNS#
Here is a clean, production-ready Terraform configuration for setting up cloud asset storage:
# main.tf — Declarative cloud resource definition
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
# Store state file securely in cloud storage with locking
backend "s3" {
bucket = "vyuhantrix-terraform-state"
key = "prod/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-locks"
}
}
provider "aws" {
region = var.aws_region
}
# Variable Definitions
variable "aws_region" {
type = string
default = "us-east-1"
}
variable "environment" {
type = string
default = "production"
}
# Resource: S3 Bucket for Public Assets
resource "aws_s3_bucket" "static_assets" {
bucket = "vyuhantrix-public-assets-${var.environment}"
tags = {
Environment = var.environment
ManagedBy = "Terraform"
Project = "Vyuhantrix"
}
}
# Resource: Block Public S3 Access Rules
resource "aws_s3_bucket_public_access_block" "assets_access" {
bucket = aws_s3_bucket.static_assets.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
# Output Variables
output "bucket_name" {
description = "The name of the created S3 storage bucket"
value = aws_s3_bucket.static_assets.id
}3. Managing Terraform State Safely#
Terraform records the mapping between your configuration files and the real-world resources in a state file (terraform.tfstate).
Critical State Rules: 1. **Never Commit `terraform.tfstate` to Git:** State files often contain sensitive passwords, database connection strings, and private IP addresses. 2. **Use Remote State with Locking:** Always store state in AWS S3 or Terraform Cloud with DynamoDB state locking to prevent two engineers from running `terraform apply` simultaneously. 3. **Use Modular Architecture:** Break monolithic infrastructure into isolated modules (`modules/networking`, `modules/database`, `modules/compute`).
4. Terraform Best Practices Checklist#
- [ ] Always review the output of
terraform planbefore executingterraform apply. - [ ] Run
terraform fmtandtflintin pre-commit hooks to maintain clean code formatting. - [ ] Use environment variables (
TF_VAR_...) for secrets, never hardcoded strings. - [ ] Tag all cloud resources with
Environment,Project, andManagedBy: Terraformfor automated billing tracking.
5. Structuring Terraform Projects with Environments#
In real-world engineering teams, you never mix production and staging resources in a single file. Organize your repository using environments:
terraform/
├── environments/
│ ├── staging/
│ │ ├── main.tf
│ │ └── terraform.tfvars
│ └── production/
│ ├── main.tf
│ └── terraform.tfvars
└── modules/
├── vpc/
├── s3-assets/
└── postgres-database/6. Frequently Asked Questions (FAQ)#
Q: What is the difference between Terraform and Ansible? Terraform is a declarative **Infrastructure Provisioning** tool (best for creating cloud networks, databases, S3 buckets, and load balancers). Ansible is a procedural **Configuration Management** tool (best for installing software packages, configuring Nginx, and updating configuration files inside running virtual machines).
Q: What happens if an AWS resource is deleted manually in the cloud console? When you run `terraform plan`, Terraform refreshes its state against the real cloud provider, detects the missing resource (**Configuration Drift**), and proposes re-creating it to match your `.tf` configuration files.
Published by
Vyuhantrix Team
Web & Systems Engineering · Vyuhantrix
Vyuhantrix is an open technology learning platform based in Ahmedabad, India, publishing step-by-step programming tutorials, system design breakdowns, and free developer tools.
Keep Learning
Recommended Guides
Cloud Infrastructure Demystified: AWS, Cloudflare, and Serverless Architecture
A clear breakdown of cloud service models (IaaS, PaaS, Serverless), edge deployments, storage buckets, container orchestrations, and DevOps best practices.
AWS Lambda & Serverless Architecture: Complete Production Guide
A comprehensive guide to building production serverless applications with AWS Lambda — cold starts, memory optimization, event sources, VPC integration, layers, concurrency limits, monitoring with CloudWatch, and cost optimization strategies.
Docker in Production: Containers, Images, and Orchestration Best Practices
A practical production guide to Docker — multi-stage builds, layer caching optimization, security hardening, health checks, Docker Compose for local development, and preparing containers for Kubernetes deployment.