qasim@wiki:~$
Automation & Cloud

Terraform

Infrastructure as code for VPC networking, site-to-site VPN, S3 lifecycle management, and reusable provisioning modules.

● Ready

Overview

Terraform is how I make infrastructure repeatable and reviewable. The rule I hold to: if it runs in production, it exists as code, in version control, reviewed before it's applied — not built once by hand and never quite documented. Two production builds anchor this page: a complete site-to-site IPSec VPN as code, and a cross-account, cross-region S3 replication pipeline with custom KMS encryption.

Core Concepts

  • State is the source of truth. Terraform's state file tracks what it believes exists — remote state (S3 + DynamoDB lock table) is non-negotiable for anything team-operated.
  • Modules over copy-paste. A VPN module, once written well, gets reused across environments with different variables — not duplicated and drifted.
  • Plan before apply, always. terraform plan is the seatbelt — reading the diff before it touches production is the single habit that prevents the worst incidents.
Public vs private vs hybrid subnets in a VPC
The hybrid subnet pattern below is this graphic's third column, built as code.

Configuration Reference

Site-to-site IPSec VPN — Customer Gateway, VGW, routing

resource "aws_customer_gateway" "office" {
  bgp_asn    = 65000
  ip_address = var.office_public_ip
  type       = "ipsec.1"
  tags       = { Name = "office-cgw" }
}

resource "aws_vpn_gateway" "this" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "prod-vgw" }
}

resource "aws_vpn_connection" "office" {
  customer_gateway_id = aws_customer_gateway.office.id
  vpn_gateway_id       = aws_vpn_gateway.this.id
  type                 = "ipsec.1"
  static_routes_only   = true
}

resource "aws_vpn_connection_route" "office_cidr" {
  vpn_connection_id     = aws_vpn_connection.office.id
  destination_cidr_block = "10.50.0.0/16"
}

resource "aws_route" "private_to_office" {
  route_table_id         = aws_route_table.private.id
  destination_cidr_block = "10.50.0.0/16"
  gateway_id              = aws_vpn_gateway.this.id
}

Cross-region S3 replication with KMS encryption

resource "aws_s3_bucket" "primary" {
  bucket = "app-data-singapore"
}

resource "aws_kms_key" "replica" {
  provider                = aws.ireland
  description              = "Replica bucket encryption key"
  deletion_window_in_days  = 30
}

resource "aws_s3_bucket_replication_configuration" "this" {
  bucket = aws_s3_bucket.primary.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"
    destination {
      bucket        = aws_s3_bucket.replica.arn
      storage_class = "STANDARD_IA"
      encryption_configuration {
        replica_kms_key_id = aws_kms_key.replica.arn
      }
    }
  }
}

The habits that prevent incidents

# always read the plan before applying
terraform plan -out=tfplan
terraform show tfplan          # human-readable diff review
terraform apply tfplan         # apply exactly what was reviewed — no surprises

# format and validate before every commit
terraform fmt -recursive
terraform validate

# state inspection when something looks wrong
terraform state list
terraform state show aws_vpn_connection.office
Module design principle Variables in, resources out, no hardcoded values. A VPN module written once for one client's office CIDR should take that CIDR as a variable — so the same module stands up VPN #2 for a different client without touching the module's internals.

Real Project: Hybrid Connectivity + Cross-Region DR

Designed and deployed a route-based IPSec site-to-site VPN between AWS VPC networks and physical corporate firewalls — the pattern above, exactly. Paired with a cross-account, cross-region S3 replication pipeline (Singapore ↔ Ireland) using custom KMS encryption architectures, giving durable, geographically separated backups with encryption keys scoped per region.

Related Topics

🎥
Video walkthrough — coming soon
terraform plan/apply walkthrough building the VPN module live