Infrastructure as Code (IaC) Skala Besar Menggunakan Terraform dan AWS

1. Konteks Industri & Analisis Akar Masalah

Pertumbuhan ekosistem aplikasi web modern menuntut arsitektur infrastruktur yang tidak hanya cepat merespons lonjakan traffic, tetapi juga harus dapat direplikasi secara instan dan bebas dari human error. Di era komputasi awan saat ini, konfigurasi manual melalui AWS Management Console (sering disebut sebagai "ClickOps") telah menjadi ancaman laten bagi stabilitas sistem enterprise. Bayangkan sebuah platform e-commerce enterprise yang menggunakan stack modern: Nginx sebagai reverse proxy, PHP-FPM / Go / Node.js untuk backend processing, MySQL/MariaDB berklaster dengan replikasi master-slave, Redis untuk caching serta manajemen session real-time, RabbitMQ/SQS sebagai message queue, Supervisor untuk mengelola worker background, serta Cloudflare di layer edge untuk proteksi WAF, SSL/TLS, DNS, dan CDN caching.

Jika seluruh komponen tersebut dibangun secara manual, inkonsistensi antar environment (Development, Staging, Production) adalah sebuah kepastian. Ketika terjadi kegagalan sistem, pemulihan manual (Disaster Recovery) bisa memakan waktu berjam-jam atau bahkan berhari-hari karena tidak adanya jejak deklaratif mengenai bagaimana infrastruktur tersebut seharusnya tersusun. Di sinilah Infrastructure as Code (IaC) menggunakan Terraform hadir sebagai fondasi utama.

Sebelum penerapan IaC skala besar:

• Inkonsistensi Environment: Konfigurasi server staging berbeda tipis dengan production, menyebabkan bug "works on my machine/staging" lolos ke production.
• Downtime Tinggi Saat Pemulihan: Mengandalkan dokumentasi wiki atau ingatan sysadmin untuk membangun ulang infrastruktur saat terjadi bencana.
• Tidak Ada Audit Trail: Siapa yang mengubah konfigurasi security group atau menambah port terbuka? Tidak ada catatan historis yang jelas.
• Ketergantungan pada Individu: Pengetahuan sistem terkunci pada satu atau dua orang principal engineer.

Setelah penerapan IaC skala besar dengan Terraform dan AWS:

• Immutable Infrastructure: Setiap perubahan infrastruktur dideklarasikan dalam kode, divalidasi via Code Review (Pull Request), dan dieksekusi secara otomatis oleh pipeline CI/CD.
• Reproduksibilitas Sempurna: Membuat kloning environment production untuk kebutuhan pengujian beban (load testing) dapat dilakukan dalam hitungan menit.
• Keamanan Terstandarisasi: Validasi keamanan otomatis menggunakan tool seperti Checkov sebelum kode diterapkan ke AWS.
• Kolaborasi Skala Tim: Seluruh engineer dapat berkolaborasi dalam mengelola infrastruktur dengan state management yang aman dan terdistribusi.

2. Konsep Inti & Deep Dive Arsitektur

Terraform bekerja dengan cara membaca file konfigurasi berformat HashiCorp Configuration Language (HCL), membangun Directed Acyclic Graph (DAG) dari resource yang dideklarasikan, dan berkomunikasi dengan AWS Provider API untuk membuat, mengubah, atau menghapus sumber daya cloud.

Arsitektur deployment IaC skala enterprise melibatkan beberapa komponen inti yang saling berinteraksi secara aman:

+-----------------------------------------------------------------------------------+
|                           Developer / CI/CD Pipeline                              |
|                  (Terraform CLI / Plan / Apply / Checkov Scan)                    |
+-----------------------------------------------------------------------------------+
          |                                                   |
          v (State Lock)                                      v (AWS API Calls)
+-----------------------+                         +-------------------------+
|   Amazon DynamoDB     |                         |       AWS Cloud         |
|   (State Locking)     |                         |  (VPC, EC2, RDS, S3)    |
+-----------------------+                         +-------------------------+
          ^
          | (Remote State)
+-----------------------+
|      Amazon S3        |
|  (Encrypted Backend)  |
+-----------------------+

Alur eksekusi di balik layar:

1. Initialization (terraform init): Terraform mengunduh provider AWS yang kompatibel dan menginisialisasi backend S3 serta DynamoDB.
2. Planning (terraform plan): Terraform melakukan refresh state saat ini dari AWS, membandingkannya dengan file konfigurasi HCL lokal, dan menghasilkan execution plan (tindakan +, -, ~).
3. State Locking: Sebelum eksekusi apply, Terraform membuat lock pada tabel DynamoDB untuk mencegah eksekusi konkuren yang dapat merusak state file (terraform.tfstate).
4. Application (terraform apply): Terraform mengirimkan perintah API terstruktur ke AWS untuk mewujudkan infrastruktur sesuai deklarasi.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun arsitektur IaC di AWS, terdapat beberapa pendekatan populer yang sering dibandingkan:

[!TIP] Gunakan Terraform jika perusahaan Anda membutuhkan strategi multi-cloud atau integrasi pihak ketiga yang luas (seperti manajemen DNS Cloudflare, Datadog monitoring, dan GitHub repositories) dalam satu alur kerja deklaratif.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum menyelami kode implementasi, pastikan environment lokal atau runner CI/CD Anda telah dipersiapkan dengan spesifikasi berikut:

• Sistem Operasi: Linux (Ubuntu 22.04 LTS / Amazon Linux 2023) atau macOS.
• Terraform CLI: Versi minimum v1.5.0.
• AWS CLI v2: Terkonfigurasi dengan kredensial IAM yang memiliki hak akses administratif atau kebijakan minimal yang mencakup IAM, EC2, RDS, S3, DynamoDB, dan VPC.
• Checkov: Tool static code analysis untuk security compliance.
• Git: Untuk manajemen version control.

Verifikasi instalasi dengan menjalankan perintah berikut di terminal:

terraform --version
aws --version
checkov --version

Konfigurasikan profil AWS CLI Anda:

aws configure --profile enterprise-iac
export AWS_PROFILE=enterprise-iac
export AWS_REGION=ap-southeast-1

5. Panduan Implementasi Langkah demi Langkah

Berikut adalah struktur direktori proyek Terraform berskala enterprise yang modular dan dapat diskalakan:

infra-enterprise/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── database/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   └── web_cluster/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
└── environments/
    └── production/
        ├── backend.tf
        ├── main.tf
        ├── variables.tf
        ├── terraform.tfvars
        └── outputs.tf

A. Modul VPC (modules/vpc/main.tf)

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

variable "vpc_cidr" {
  type        = string
  description = "CIDR block untuk VPC production"
}

variable "environment" {
  type        = string
  description = "Nama environment, misal: production"
}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "${var.environment}-vpc"
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name        = "${var.environment}-igw"
    Environment = var.environment
  }
}

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, count.index)
  map_public_ip_on_launch = true

  tags = {
    Name        = "${var.environment}-public-subnet-${count.index + 1}"
    Environment = var.environment
  }
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index + 10)
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name        = "${var.environment}-private-subnet-${count.index + 1}"
    Environment = var.environment
  }
}

data "aws_availability_zones" "available" {
  state = "available"
}

output "vpc_id" {
  value = aws_vpc.main.id
}

output "public_subnet_ids" {
  value = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

B. Modul Database RDS MySQL (modules/database/main.tf)

terraform {
  required_version = ">= 1.5.0"
}

variable "environment" { type = string }
variable "vpc_id" { type = string }
variable "private_subnet_ids" { type = list(string) }
variable "db_password" {
  type      = string
  sensitive = true
}

resource "aws_db_subnet_group" "main" {
  name       = "${var.environment}-db-subnet-group"
  subnet_ids = var.private_subnet_ids

  tags = {
    Name = "${var.environment}-db-subnet-group"
  }
}

resource "aws_security_group" "db" {
  name        = "${var.environment}-rds-sg"
  description = "Security group untuk database MySQL"
  vpc_id      = var.vpc_id

  ingress {
    from_port   = 3306
    to_port     = 3306
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${var.environment}-rds-sg"
  }
}

resource "aws_db_instance" "mysql" {
  identifier             = "${var.environment}-mysql-db"
  engine                 = "mysql"
  engine_version         = "8.0"
  instance_class         = "db.t3.medium"
  allocated_storage      = 50
  max_allocated_storage  = 200
  db_name                = "app_production"
  username               = "admin_db"
  password               = var.db_password
  db_subnet_group_name   = aws_db_subnet_group.main.name
  vpc_security_group_ids = [aws_security_group.db.id]
  skip_final_snapshot    = false
  final_snapshot_identifier = "${var.environment}-mysql-final-snapshot"
  multi_az               = true

  tags = {
    Environment = var.environment
  }
}

output "db_endpoint" {
  value = aws_db_instance.mysql.endpoint
}

C. Konfigurasi Environment Production (environments/production/backend.tf)

terraform {
  backend "s3" {
    bucket         = "enterprise-terraform-state-bucket-prod"
    key            = "production/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "enterprise-terraform-locks"
    encrypt        = true
  }
}

D. Root Module Production (environments/production/main.tf)

provider "aws" {
  region = "ap-southeast-1"

  default_tags {
    tags = {
      Environment = "production"
      ManagedBy   = "Terraform"
      Project     = "EnterpriseWebStack"
    }
  }
}

module "vpc" {
  source      = "../../modules/vpc"
  vpc_cidr    = "10.100.0.0/16"
  environment = "production"
}

module "database" {
  source             = "../../modules/database"
  environment        = "production"
  vpc_id             = module.vpc.vpc_id
  private_subnet_ids = module.vpc.private_subnet_ids
  db_password        = var.db_password
}

variable "db_password" {
  type      = string
  sensitive = true
}

6. Bedah Kode & Penjelasan Detail Baris Kunci

• cidrsubnet(var.vpc_cidr, 8, count.index): Fungsi bawaan Terraform yang sangat powerful untuk memecah CIDR block utama menjadi subnet yang lebih kecil secara dinamis. Parameter 8 menentukan penambahan prefix panjang mask (dari /16 menjadi /24), dan count.index bertindak sebagai iterator yang menghasilkan subnet unik (10.100.0.0/24, 10.100.1.0/24, dst).
• backend "s3" dengan dynamodb_table: Mekanisme krusial dalam kolaborasi tim. S3 menyimpan file state (.tfstate) secara terenkripsi, sementara DynamoDB mengunci state tersebut saat proses apply berjalan untuk menghindari korupsi data akibat dua engineer melakukan deployment secara bersamaan.
• sensitive = true: Melindungi variabel password database agar nilainya tidak tercetak di terminal saat eksekusi terraform plan atau terraform apply dijalankan.
• multi_az = true pada RDS: Memastikan AWS secara otomatis membuat replika standby di Availability Zone berbeda untuk menjamin ketersediaan tinggi (High Availability).

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam menghadapi traffic tinggi (high concurrency) hingga 50.000 request per detik pada platform web berbasis Go/PHP-FPM, arsitektur Terraform yang kita bangun harus diintegrasikan dengan Auto Scaling Group (ASG) dan Application Load Balancer (ALB).

Studi Kasus: Lonjakan traffic mendadak saat flash sale.

1. ALB mendistribusikan traffic HTTP/HTTPS secara merata ke instance EC2 Nginx + PHP-FPM di subnet publik/privat.
2. CloudWatch Metric Alarm memantau utilisasi CPU instance EC2. Jika CPU rata-rata melampaui 70% selama 3 menit berturut-turut, ASG yang dideklarasikan via Terraform akan otomatis menambah jumlah instance EC2 baru.
3. Koneksi database dialihkan melalui RDS Proxy (yang juga dapat dikelola via Terraform) untuk melakukan connection pooling, mencegah database MySQL mengalami crash akibat kelebihan koneksi thread.
4. Redis cluster di-provision menggunakan AWS ElastiCache untuk menangani session store dan caching query berat secara terdistribusi.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Anti-Pattern 1: Hardcoding Secret di dalam File Konfigurasi HCL. Kesalahan: Menyimpan password database atau API key secara plain text di file terraform.tfvars yang ter-commit ke GitHub. Solusi: Selalu gunakan AWS Secrets Manager atau parameter store, atau teruskan variabel sensitif melalui environment variable (TF_VAR_db_password) saat eksekusi CI/CD.

[!WARNING] Anti-Pattern 2: Menggunakan Satu State File untuk Seluruh Infrastruktur Global. Kesalahan: Menggabungkan VPC, database, IAM, dan Kubernetes cluster dalam satu file state raksasa. Solusi: Terapkan pemisahan state berdasarkan layer (Layer 0: Networking, Layer 1: Database/Storage, Layer 2: Compute/Application) menggunakan workspace atau direktori terpisah.

• Lupa Mengaktifkan skip_final_snapshot = false pada RDS Production: Dapat menyebabkan kegagalan penghapusan resource atau hilangnya data snapshot saat destruksi infrastruktur uji coba.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk memastikan infrastruktur AWS yang diprovision oleh Terraform mampu menangani beban produksi, lakukan pengujian performa menggunakan tool benchmarking modern seperti k6 atau wrk.

Contoh skrip pengujian k6 (load-test.js):

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // Ramp-up ke 100 pengguna
    { duration: '5m', target: 500 }, // Tahan di 500 pengguna
    { duration: '2m', target: 0 },   // Ramp-down
  ],
};

export default function () {
  const res = http.get('http://your-alb-dns-name.amazonaws.com/');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

Eksekusi benchmark:

k6 run load-test.js

Tuning parameter lanjutan yang perlu diperhatikan pada infrastruktur terkait:

• OS Kernel (sysctl.conf): Tingkatkan nilai net.core.somaxconn dan fs.file-max pada instance EC2 web server untuk menangani koneksi TCP konkuren yang masif.
• PHP-FPM / Go Worker: Sesuaikan jumlah worker process (pm.max_children pada PHP-FPM) berdasarkan alokasi RAM instance EC2 (t3.medium atau c6i.xlarge).
• Nginx Worker Connections: Atur worker_connections 10240; dan aktifkan epoll untuk performa I/O non-blocking yang optimal.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis infrastruktur Terraform ke lingkungan production, pastikan Anda telah melewati checklist validasi berikut:

• Menjalankan terraform fmt dan terraform validate tanpa error.
• Memeriksa keamanan kode menggunakan checkov -d . dan memastikan tidak ada high-severity vulnerability.
• Memastikan S3 Backend terenkripsi dan mengaktifkan versioning untuk pencegahan kehilangan state.
• Tabel DynamoDB telah aktif dengan Primary Key LockID bertipe String.
• Seluruh variabel sensitif telah diamankan menggunakan secret manager atau environment variables.
• Rencana disaster recovery dan backup otomatis (AWS Backup / RDS Snapshot) telah terkonfigurasi.

Dengan menerapkan prinsip-prinsip desain modular, manajemen state yang aman, dan otomasi berbasis Terraform yang dikupas dalam panduan ini, tim infrastruktur Anda kini memiliki kapabilitas untuk mengelola arsitektur AWS berskala enterprise secara deklaratif, handal, dan siap menghadapi pertumbuhan bisnis yang masif.