L
Infrastructure as Code (IaC) • Literally Web ID

Infrastructure as Code: Provisioning Cloud Otomatis dengan Terraform

⏱️ 15 menit baca • 📅 20 Oct 2026 • 👁️ 2 views
Infrastructure as Code: Provisioning Cloud Otomatis dengan Terraform

1. Konteks Industri & Analisis Akar Masalah

Di era modern, arsitektur web berskala enterprise tidak lagi cukup hanya berjalan dengan baik; infrastruktur tersebut harus dapat direproduksi secara instan, aman, dan dapat diskalakan tanpa intervensi manual yang rentan human error. Di masa lalu, manajemen infrastruktur server web, load balancer, database, DNS, serta penyimpanan S3 dilakukan melalui klik pada konsol cloud atau melalui skrip Bash kustom yang rapuh (Imperative Infrastructure). Pendekatan ini menciptakan fenomena "Configuration Drift", di mana dokumentasi server berbeda jauh dengan kondisi aktual di produksi.

Bayangkan sebuah skenario di mana platform e-commerce berskala besar mengalami lonjakan trafik secara tiba-tiba akibat kampanye pemasaran flash sale. Tim DevOps harus secara manual membuat instance EC2 tambahan, mengonfigurasi ulang Nginx/PHP-FPM, menghubungkannya ke target group Application Load Balancer (ALB), dan memperbarui catatan DNS di Cloudflare. Proses manual ini memakan waktu berjam-jam, memicu downtime yang merugikan, dan meninggalkan celah keamanan karena konfigurasi firewall atau SSL/TLS yang terlewat.

Pendekatan modern mengatasi masalah ini menggunakan Infrastructure as Code (IaC) dengan Terraform. Melalui pendekatan Declarative Infrastructure, kita mendefinisikan keadaan akhir (desired state) dari seluruh tumpukan teknologi—mulai dari VPC, subnet, route table, internet gateway, EC2 instances, database RDS MySQL/MariaDB, cluster Redis untuk caching, hingga aturan WAF dan record DNS—ke dalam file konfigurasi teks. Terraform secara otomatis menghitung perbedaan (diff) antara status saat ini dan status yang diinginkan, lalu mengeksekusi rencana eksekusi (execution plan) secara aman dan terkontrol.

Perbandingan antara kondisi Sebelum dan Sesudah penerapan Terraform:

  • Sebelum (Manual / Imperative): Proses provisioning memakan waktu hari/minggu; risiko human error sangat tinggi; tidak ada riwayat perubahan yang jelas (audit trail); konfigurasi server tidak konsisten antara Environment Staging dan Production; pemulihan bencana (Disaster Recovery) sangat lambat dan melelahkan.
  • Sesudah (Otomatisasi Terraform / Declarative): Provisioning seluruh infrastruktur selesai dalam hitungan menit; konsistensi 100% di semua environment; state file tercatat dengan aman; kolaborasi tim melalui Git Workflow (Pull Request sebelum terraform apply); pemulihan bencana dapat dilakukan hanya dengan menjalankan satu perintah apply ulang.

2. Konsep Inti & Deep Dive Arsitektur

Terraform adalah tool open-source yang dikembangkan oleh HashiCorp untuk membangun, mengubah, dan membuat versi infrastruktur dengan aman dan efisien. Di balik kesederhanaannya, terdapat arsitektur berbasis Provider dan State Engine yang bekerja secara sinkron.

Alur Eksekusi Terraform (Under the Hood)

  1. Parsing & Graph Generation: Saat perintah terraform plan dijalankan, Terraform membaca semua file .tf di direktori kerja, mem-parsing sintaks HCL (HashiCorp Configuration Language), dan membangun Directed Acyclic Graph (DAG) untuk menentukan urutan dependensi antar resource (misalnya, memastikan VPC dibuat sebelum Subnet, dan Subnet dibuat sebelum EC2 Instance).
  2. Refresh State: Terraform mencocokkan State File (terraform.tfstate) dengan kondisi nyata di penyedia cloud (AWS, Cloudflare, dll.) untuk mendeteksi apakah ada perubahan manual di luar Terraform.
  3. Plan Execution: Terraform membandingkan Desired State dengan Current State, menghasilkan execution plan (+ untuk pembuatan, - untuk penghapusan, ~ untuk modifikasi).
  4. Apply Execution: Saat terraform apply disetujui, Terraform memanggil API provider cloud secara paralel atau berurutan sesuai DAG untuk mengeksekusi perubahan.
+-----------------------------------------------------------------------+
|                        Developer / GitOps CI/CD                       |
+-----------------------------------------------------------------------+
                                    |
                                    v
+-----------------------------------------------------------------------+
|                       Terraform CLI (HCL Files)                       |
+-----------------------------------------------------------------------+
     |                              |                              |
     v                              v                              v
+------------------+     +--------------------+     +-------------------+
|  AWS Provider    |     | Cloudflare Provider|     | Remote State S3   |----+
+------------------+     +--------------------+     +-------------------+    |
     |                              |                                        |
     v                              v                                        |
+-------------------------------------------------------+                    |
|                 AWS Cloud Infrastructure              |                    |
|  [VPC] -> [Subnets] -> [ALB] -> [EC2 / Nginx] -> [RDS] | <------------------+
+-------------------------------------------------------+    (DynamoDB Lock)

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk mengelola infrastruktur cloud secara otomatis, terdapat beberapa pilihan tool utama di industri. Berikut adalah analisis komparatif mendalam antara Terraform, AWS CloudFormation, dan Ansible:

Parameter Komparasi Terraform (HashiCorp) AWS CloudFormation Ansible (Red Hat)
Paradigma Declarative (HCL) Declarative (JSON/YAML) Procedural / Imperative (YAML)
Cakupan Cloud Multi-Cloud (AWS, GCP, Azure, Cloudflare) Khusus AWS Multi-Cloud & On-Premise
State Management Remote State (S3, Consul, Terraform Cloud) Managed by AWS Stack Stateless (mengandalkan fakta target)
Kurva Belajar Sedang (HCL sangat intuitif) Curam (YAML/JSON yang sangat verbose) Mudah (berbasis task prosedural)
Eksekusi & Kecepatan Cepat (Parallel execution via DAG) Lambat (Bergantung pada AWS Stack update) Cepat untuk konfigurasi OS, lambat untuk cloud infra
Ideal Use Case Provisioning resource infrastruktur cloud global Provisioning native khusus ekosistem AWS murni Manajemen konfigurasi OS, deployment aplikasi, dan provisioning ringan

[!TIP] Pendekatan arsitektur enterprise modern sering kali menggabungkan keduanya: Terraform digunakan untuk provisioning infrastruktur inti (VPC, RDS, EC2, ALB), sedangkan Ansible atau Cloud-Init digunakan untuk provisioning konfigurasi internal OS (menginstal Nginx, PHP-FPM, Redis, dan mengatur file virtual host).

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mulai menulis kode Terraform, pastikan lingkungan kerja (workstation atau CI/CD runner) memiliki dependensi berikut:

  1. Terraform CLI (Versi >= 1.5.0): Unduh dan instal dari situs resmi HashiCorp atau gunakan manajer paket (contoh di Ubuntu/Debian): 
    sudo apt-get update && sudo apt-get install -y gnupg software-properties-common
wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/etc/apt/keyrings/hashicorp-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/etc/apt/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform
  2. AWS CLI v2 terinstal dan terkonfigurasi dengan kredensial IAM yang memiliki hak akses administrator atau kebijakan terkelola penuh untuk VPC, EC2, RDS, S3, dan DynamoDB: 
    aws configure
# Masukkan AWS Access Key ID, Secret Access Key, Region (contoh: ap-southeast-1), dan format output (json)
  3. Git untuk manajemen versi kode.

5. Panduan Implementasi Langkah demi Langkah

Kita akan membangun struktur direktori standar enterprise untuk melakukan provisioning infrastruktur web stack yang mencakup:

  • Custom VPC dengan Public & Private Subnets di 2 Availability Zones.
  • Internet Gateway & NAT Gateway.
  • Security Groups untuk Web Server (Nginx) dan Database (RDS MySQL).
  • AWS RDS MySQL Instance.
  • AWS EC2 Instance (Web Server) dengan skrip Cloud-Init untuk otomatisasi instalasi Nginx, PHP-FPM, dan koneksi database.
  • Remote Backend menggunakan Amazon S3 untuk penyimpanan state dan DynamoDB untuk State Locking.

Struktur Direktori Proyek

terraform-aws-web-stack/
├── backend.tf
├── provider.tf
├── variables.tf
├── vpc.tf
├── security_groups.tf
├── rds.tf
├── ec2.tf
├── outputs.tf
└── user-data.sh

1. File Konfigurasi: provider.tf

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

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Environment = var.environment
      ManagedBy   = "Terraform"
      Project     = "Enterprise-Web-Stack"
    }
  }
}

2. File Konfigurasi: backend.tf

terraform {
  backend "s3" {
    bucket         = "prod-terraform-state-storage-unique-xyz"
    key            = "web-stack/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

3. File Konfigurasi: variables.tf

variable "aws_region" {
  type        = string
  default     = "ap-southeast-1"
  description = "AWS Region utama untuk deployment"
}

variable "environment" {
  type        = string
  default     = "production"
  description = "Nama environment"
}

variable "vpc_cidr" {
  type        = string
  default     = "10.0.0.0/16"
  description = "CIDR block untuk VPC"
}

variable "db_password" {
  type        = string
  sensitive   = true
  description = "Master password untuk RDS MySQL"
}

4. File Konfigurasi: vpc.tf

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

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

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

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

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

resource "aws_subnet" "public_1" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = data.aws_availability_zones.available.names[0]
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.environment}-public-subnet-1"
  }
}

resource "aws_subnet" "public_2" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = data.aws_availability_zones.available.names[1]
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.environment}-public-subnet-2"
  }
}

resource "aws_subnet" "private_1" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.10.0/24"
  availability_zone = data.aws_availability_zones.available.names[0]

  tags = {
    Name = "${var.environment}-private-subnet-1"
  }
}

resource "aws_subnet" "private_2" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.11.0/24"
  availability_zone = data.aws_availability_zones.available.names[1]

  tags = {
    Name = "${var.environment}-private-subnet-2"
  }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.gw.id
  }

  tags = {
    Name = "${var.environment}-public-rt"
  }
}

resource "aws_route_table_association" "pub_1" {
  subnet_id      = aws_subnet.public_1.id
  route_table_id = aws_route_table.public.id
}

resource "aws_route_table_association" "pub_2" {
  subnet_id      = aws_subnet.public_2.id
  route_table_id = aws_route_table.public.id
}

5. File Konfigurasi: security_groups.tf

resource "aws_security_group" "web_sg" {
  name        = "${var.environment}-web-sg"
  description = "Security group untuk web server Nginx"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "HTTP dari internet"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTPS dari internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH Management"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # Sesuaikan dengan IP bastion/admin Anda di produksi
  }

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

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

resource "aws_security_group" "db_sg" {
  name        = "${var.environment}-db-sg"
  description = "Security group untuk RDS MySQL"
  vpc_id      = aws_vpc.main.id

  ingress {
    description     = "MySQL dari Web Server"
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.web_sg.id]
  }

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

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

6. File Konfigurasi: rds.tf

resource "aws_db_subnet_group" "main" {
  name       = "${var.environment}-db-subnet-group"
  subnet_ids = [aws_subnet.private_1.id, aws_subnet.private_2.id]

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

resource "aws_db_instance" "mysql" {
  identifier             = "${var.environment}-mysql-db"
  engine                 = "mysql"
  engine_version         = "8.0"
  instance_class         = "db.t3.medium"
  allocated_storage      = 20
  max_allocated_storage  = 100
  storage_type           = "gp3"
  db_name                = "webappdb"
  username               = "adminuser"
  password               = var.db_password
  db_subnet_group_name   = aws_db_subnet_group.main.name
  vpc_security_group_ids = [aws_security_group.db_sg.id]
  skip_final_snapshot    = true
  multi_az               = true

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

7. File Konfigurasi: user-data.sh

#!/bin/bash
exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>&1)

echo "Memulai instalasi web stack..."
apt-get update -y
apt-get install -y nginx php-fpm php-mysql mysql-client curl

systemctl start nginx
systemctl enable nginx

# Konfigurasi halaman sambutan PHP
echo "<?php echo '<h1>Enterprise Web Stack Active via Terraform & AWS Cloud!</h1>'; ?>" > /var/www/html/index.php
rm -f /var/www/html/index.html

systemctl restart php8.1-fpm
systemctl restart nginx
echo "Instalasi selesai!"

8. File Konfigurasi: ec2.tf

data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  owners = ["099720109477"] # Canonical
}

resource "aws_instance" "web" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = "t3.medium"
  subnet_id              = aws_subnet.public_1.id
  vpc_security_group_ids = [aws_security_group.web_sg.id]
  user_data              = file("${path.module}/user-data.sh")

  tags = {
    Name = "${var.environment}-web-server"
  }
}

9. File Konfigurasi: outputs.tf

output "web_server_public_ip" {
  value       = aws_instance.web.public_ip
  description = "Public IP dari Web Server Nginx"
}

output "rds_endpoint" {
  value       = aws_db_instance.mysql.endpoint
  description = "Koneksi Endpoint database RDS MySQL"
  sensitive   = true
}

6. Bedah Kode & Penjelasan Detail Baris Kunci

  1. Backend S3 & DynamoDB Lock (backend.tf): Menggunakan S3 untuk menyimpan state memastikan seluruh tim atau pipeline CI/CD mengakses state file yang sama. Penambahan DynamoDB mencegah race condition atau bentrokan eksekusi jika dua insinyur menjalankan terraform apply secara bersamaan melalui fitur State Locking.
  2. Data Source AMI (ec2.tf): Alih-alih melakukan hardcode ID AMI (yang berbeda di tiap region AWS), kita menggunakan data "aws_ami" "ubuntu" untuk mengambil AMI Ubuntu Jammy terbaru secara dinamis.
  3. Security Group Interdependency (security_groups.tf): Penggunaan parameter security_groups = [aws_security_group.web_sg.id] pada aturan ingress RDS memastikan bahwa database MySQL hanya dapat diakses secara eksklusif oleh instance web, tanpa membuka port 3306 ke publik internet.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam lingkungan produksi berskala besar, arsitektur di atas perlu diperluas dengan menerapkan konsep High Availability (HA) penuh:

  • Auto Scaling Group (ASG): Mengganti single EC2 Instance (aws_instance.web) dengan aws_launch_template dan aws_autoscaling_group di balik Application Load Balancer (ALB) untuk menangani lonjakan beban HTTP secara otomatis.
  • Multi-Region Failover: Memanfaatkan Terraform workspaces atau direktori terpisah untuk menduplikasi infrastruktur ke region sekunder (misalnya ap-northeast-1 Tokyo) yang dihubungkan dengan Route53 Latency-based Routing.
  • Secret Management: Mengintegrasikan variabel db_password dengan AWS Secrets Manager atau HashiCorp Vault alih-alih menyimpannya langsung di file tfvars biasa.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Kesalahan Fatal #1: Menyimpan State File Tanpa Enkripsi atau Mengunggahnya ke Git. Dampak: State file Terraform menyimpan seluruh parameter rahasia dalam bentuk plaintext (termasuk password database dan private key). Solusi: Selalu gunakan Remote Backend terenkripsi (S3 dengan SSE-S3/KMS) dan tambahkan terraform.tfstate* ke dalam file .gitignore.

[!WARNING] Kesalahan Fatal #2: Modifikasi Manual di Konsol Cloud (Console Drift). Dampak: Mengubah konfigurasi security group atau ukuran instance secara langsung melalui AWS Console akan menyebabkan ketidakcocokan saat Terraform dijalankan kembali, yang berpotensi memicu destroy atau recreate resource tak terduga. Solusi: Terapkan prinsip Immutable Infrastructure. Segala perubahan wajib melalui kode Terraform di Git.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji performa infrastruktur web stack yang baru diprovisioning, gunakan tool benchmark HTTP seperti k6 atau wrk. Jalankan pengujian konkurensi pada IP publik EC2:

# Contoh pengujian beban menggunakan wrk dengan 100 koneksi paralel selama 30 detik
wrk -t12 -c100 -d30s http://<PUBLIC_IP_EC2>/index.php

Parameter Tuning Lanjutan:

  • Nginx Worker Processes: Sesuaikan parameter worker_processes auto; di /etc/nginx/nginx.conf agar memanfaatkan seluruh inti vCPU pada instance t3.medium.
  • PHP-FPM Process Manager: Ubah mode PM menjadi dynamic dengan mengatur pm.max_children, pm.start_servers, dan pm.min_spare_servers berdasarkan kapasitas RAM instans untuk mencegah kehabisan memori (Out Of Memory Killer).

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan infrastruktur ini ke lingkungan Live Production, pastikan checklist berikut terpenuhi:

  • Seluruh file .tf telah diformat menggunakan perintah terraform fmt.
  • Validasi sintaks kode melalui terraform validate tanpa ada peringatan.
  • Konfigurasi Remote State S3 dan DynamoDB Lock sudah aktif dan diuji coba oleh minimal dua engineer.
  • Aturan Security Groups menganut prinsip Least Privilege (port SSH dibatasi hanya untuk IP kantor/Bastion host).
  • Backup otomatis dan automated snapshot pada RDS MySQL telah diaktifkan.
  • Integrasi CI/CD Pipeline (GitHub Actions / GitLab CI) dikonfigurasi untuk menjalankan terraform plan secara otomatis pada setiap Pull Request.

Dengan menguasai otomatisasi infrastruktur menggunakan Terraform, tim teknik Anda tidak lagi direpotkan oleh pekerjaan manual yang repetitif. Anda kini memiliki fondasi arsitektur cloud yang tangguh, dapat diuji (testable), dan siap mendukung pertumbuhan bisnis digital enterprise secara berkelanjutan.

🏷️ Tags: #Nginx #High Concurrency #Performance #Sysadmin #Web Server

Tutorial & Topik Terkait

6 Artikel
Infrastructure as Code (IaC) ⏱️ 15 mnt baca

Zero-Downtime Infrastructure as Code: Terraform & Ansible on AWS

Baca selengkapnya →
Infrastructure as Code (IaC) ⏱️ 18 mnt baca

Automasi Infrastruktur Skala Besar: Terraform dan GitOps di Lingkungan Multi-Cloud

Baca selengkapnya →
Infrastructure as Code (IaC) ⏱️ 15 mnt baca

Automasi Infrastruktur Multi-Cloud Skala Enterprise Menggunakan Terraform dan Ansible

Baca selengkapnya →
Git ⏱️ 25 mnt baca

Membangun Pipeline CI/CD Git Branching Strategy Skala Enterprise

Baca selengkapnya →
Infrastructure as Code (IaC) ⏱️ 15 mnt baca

Infrastructure as Code (IaC) Skala Besar dengan Terraform dan Atlantis

Baca selengkapnya →
Infrastructure as Code (IaC) ⏱️ 15 mnt baca

Automasi Infrastruktur Skala Enterprise Menggunakan Terraform dan Ansible di AWS Multi-Region

Baca selengkapnya →