harsh040506/infrastructure-as-code

Infrastructure as Code

Provision, manage, and automate cloud infrastructure reproducibly and safely with Terraform (primary), Pulumi, and AWS CDK.

---

Terraform: Core Concepts

The Fundamental Workflow

Write HCL → terraform init → terraform plan → Review → terraform apply

Never skip terraform plan. Always review what will be created, modified, or destroyed before applying.

Color coding in plan output:

• + green = create
• ~ yellow = update in-place (safe)
• -/+ red/green = destroy and recreate (risk of downtime)
• - red = destroy (permanent)

Project Structure

infrastructure/
├── environments/
│   ├── staging/
│   │   ├── main.tf          # Resources specific to staging
│   │   ├── variables.tf     # Input variables
│   │   ├── outputs.tf       # Exposed outputs
│   │   ├── terraform.tfvars # Non-secret variable values
│   │   └── backend.tf       # Remote state config
│   └── production/
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│       ├── terraform.tfvars
│       └── backend.tf
└── modules/
    ├── networking/          # VPC, subnets, security groups
    ├── compute/             # ECS, EC2, Lambda
    ├── database/            # RDS, DynamoDB
    └── observability/       # CloudWatch, Datadog

One state file per environment. Never share state between staging and production.

Remote State (Required for Teams)

# backend.tf — store state in S3 with DynamoDB locking
terraform {
  backend "s3" {
    bucket         = "mycompany-terraform-state"
    key            = "production/api-service/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true                          # Encrypt state at rest
    dynamodb_table = "terraform-state-lock"        # Prevent concurrent applies
  }
}

Create the S3 bucket and DynamoDB table before using this backend. Use versioning on the S3 bucket to recover from accidental state corruption.

Module Design

Write modules for reusable infrastructure patterns:

# modules/ecs-service/main.tf
variable "service_name" {
  type        = string
  description = "Name of the ECS service"
}

variable "image" {
  type        = string
  description = "Docker image with tag: registry/image:tag"
}

variable "cpu" {
  type        = number
  default     = 256
  description = "CPU units (1024 = 1 vCPU)"
}

variable "memory" {
  type        = number
  default     = 512
  description = "Memory in MiB"
}

variable "desired_count" {
  type        = number
  default     = 2
  description = "Number of tasks to run"
}

resource "aws_ecs_service" "this" {
  name            = var.service_name
  cluster         = var.cluster_arn
  task_definition = aws_ecs_task_definition.this.arn
  desired_count   = var.desired_count
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [aws_security_group.service.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = var.target_group_arn
    container_name   = var.service_name
    container_port   = var.container_port
  }

  lifecycle {
    ignore_changes = [desired_count]  # Managed by auto-scaling
  }
}

output "service_name" {
  value = aws_ecs_service.this.name
}

output "service_arn" {
  value = aws_ecs_service.this.id
}

Module best practices:

• One module per logical concern (networking, compute, database)
• Always expose outputs — other modules consume them
• Use lifecycle { ignore_changes = [...] } for fields managed by external systems
• Version modules: source = "git::https://github.com/myorg/tf-modules.git//ecs-service?ref=v1.2.0"

---

Secrets Management in Terraform

NEVER put secrets in .tfvars files or commit them to git.

Option 1: AWS Secrets Manager (Recommended for AWS)

# Read a secret — Terraform doesn't store the value in state
data "aws_secretsmanager_secret_version" "db_password" {
  secret_id = "production/api-service/db-password"
}

resource "aws_ecs_task_definition" "api" {
  # ...
  container_definitions = jsonencode([{
    name = "api-service"
    secrets = [{
      name      = "DATABASE_PASSWORD"
      valueFrom = data.aws_secretsmanager_secret_version.db_password.arn
    }]
  }])
}

Option 2: Environment Variables

Pass secrets as environment variables during CI/CD runs — never write them to any file:

export TF_VAR_db_password="$(aws secretsmanager get-secret-value --secret-id prod/db --query SecretString --output text)"
terraform apply

Option 3: Vault Provider

provider "vault" {
  address = "https://vault.example.com"
  # Auth via environment or OIDC — no hardcoded token
}

data "vault_generic_secret" "db" {
  path = "secret/production/database"
}

---

State Management

Importing Existing Resources

When infrastructure already exists and you want Terraform to manage it:

# Traditional import (Terraform < 1.5)
terraform import aws_s3_bucket.my_bucket my-existing-bucket-name

# Generate import block (Terraform >= 1.5 — preferred)
terraform plan -generate-config-out=generated.tf

State Manipulation (Use with Extreme Caution)

# Remove a resource from state without destroying it
terraform state rm aws_s3_bucket.old_bucket

# Move a resource (rename in refactor)
terraform state mv aws_instance.old_name aws_instance.new_name

# List all resources in state
terraform state list

# Show current state of a specific resource
terraform state show aws_s3_bucket.my_bucket

Always take a state backup before manipulation:

terraform state pull > backup-$(date +%Y%m%d-%H%M%S).tfstate

Drift Detection

Detect when real infrastructure has diverged from Terraform state:

# Shows what would change if you applied (also shows drift)
terraform plan

# Refresh state to match real infrastructure
terraform apply -refresh-only

---

Common Patterns

VPC with Public/Private Subnets

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.0"

  name = "production-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = false  # One per AZ for HA
  
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = local.common_tags
}

RDS with Encryption and Multi-AZ

resource "aws_db_instance" "postgres" {
  identifier = "production-postgres"
  engine     = "postgres"
  engine_version = "16.1"
  
  instance_class        = "db.t3.medium"
  allocated_storage     = 100
  max_allocated_storage = 500   # Enable auto-scaling storage
  
  db_name  = "appdb"
  username = "appuser"
  password = var.db_password    # From secrets manager, not hardcoded
  
  multi_az               = true    # Automatic failover
  storage_encrypted      = true    # Encrypt at rest
  kms_key_id            = aws_kms_key.rds.arn
  
  backup_retention_period = 7      # 7 days of backups
  backup_window          = "03:00-04:00"
  maintenance_window     = "Mon:04:00-Mon:05:00"
  
  deletion_protection = true       # Prevent accidental destroy
  skip_final_snapshot = false      # Take snapshot before destroy
  final_snapshot_identifier = "production-postgres-final-$(timestamp())"
  
  vpc_security_group_ids = [aws_security_group.rds.id]
  db_subnet_group_name   = aws_db_subnet_group.main.name

  tags = local.common_tags
}

---

Terraform Safety Rules

1. Always run plan before apply. Never terraform apply -auto-approve in production.
2. Lock state with DynamoDB (AWS) or GCS object locking (GCP). Two simultaneous applies corrupt state.
3. Enable deletion protection on databases, S3 buckets, and load balancers.
4. Use prevent_destroy lifecycle for critical resources:

   lifecycle {
     prevent_destroy = true
   }
   

5. Pin provider versions to avoid unexpected breaking changes:

   terraform {
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.30"   # Allow patch updates, not major
       }
     }
     required_version = ">= 1.6.0"
   }
   

6. Code review Terraform changes the same way you review application code. A bad terraform apply can take down production.
7. Use Terragrunt or Terraform workspaces to avoid copy-pasting identical configs across environments.

Deeper Reference

For complete IaC module templates and idempotent automation recipes, see:

• references/terraform-patterns.md — reusable Terraform modules for VPC, ECS, RDS, and IAM with remote state configuration
• references/ansible-patterns.md — production Ansible playbooks for server provisioning, application deployment, and secret management