# Automasi Infrastruktur Cloud Skala Besar dengan Terraform & AWS

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/automasi-infrastruktur-cloud-skala-besar-dengan-terraform-aws

---

Pukul dua pagi, layar monitor saya berkedip menampilkan grafik metrik yang menukik tajam ke bawah. Di Slack, pesan dari VP of Engineering masuk tanpa ampun: "Infrastruktur kita down, region us-east-1 timeout, tolong deploy ulang environment staging dan production sekarang!" Di sinilah ujian sebenarnya dimulai. Ketika Anda mengelola ratusan instance EC2, cluster database Aurora, rule WAF Cloudflare, hingga record DNS Route53, mengandalkan klik manual di AWS Console adalah tiket ekspres menuju bencana. Perdebatan klasik pun muncul di ruang rapat virtual: apakah kita harus bertahan dengan skrip bash kustom yang dibumbui AWS CLI, atau beralih sepenuhnya ke Infrastructure as Code (IaC) menggunakan Terraform yang dipadukan dengan ekosistem AWS? Ini bukan sekadar memilih alat, ini adalah pertarungan filosofi tentang bagaimana kita mendefinisikan, mengontrol, dan merawat infrastruktur web modern yang menopang jutaan traffic harian.

Sebelum kita masuk ke dalam medan pertempuran pengujian performa dan ergonomi kode, mari kita bedah matriks perbandingan langsung antara pendekatan manual berselancar di UI Cloud (AWS Console) versus otomatisasi penuh menggunakan Terraform & AWS.

| Metrik Evaluasi | AWS Console / Skrip Manual | Terraform & AWS Automation |
| :--- | :--- | :--- |
| Kecepatan Deployment (Skala 100+ Res) | 3/10 (Rawan human error) | 9/10 (Paralel dan konsisten) |
| Latency & Drift Detection | 2/10 (Butuh audit manual) | 9/10 (Otomatis via `terraform plan`) |
| Penggunaan RAM & CPU Local Machine | 8/10 (Ringan, hanya browser) | 7/10 (Modul HCL memakan memori saat state besar) |
| Kemudahan Setup Awal | 9/10 (Tinggal klik) | 5/10 (Kurva belajar HCL & State backend) |
| Kekuatan Ekosistem & Integrasi | 8/10 (Native AWS) | 10/10 (Multi-cloud, modular, provider luas) |

> [!IMPORTANT]
> Mengabaikan state management yang aman di Terraform sama saja dengan menyerahkan kunci brankas produksi kepada orang asing yang sedang mabuk.

## 1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Bayangkan Anda sedang membangun sebuah ekosistem web high-availability yang dibelakangnya berdiri Nginx sebagai reverse proxy, PHP-FPM dengan worker pool yang di-tune ketat, Redis untuk caching session real-time, dan MySQL Aurora sebagai pusat data utama. Di kubu pertama, penganut paham imperatif mengandalkan skrip bash panjang berisi perintah `aws ec2 run-instances` yang dirangkai dengan `curl` dan `sed`. Pendekatan ini ibarat melukis di atas kanvas basah: cepat pada goresan pertama, tapi begitu ada angin ribut, seluruh warna bercampur aduk dan mustahil dikembalikan ke bentuk semula tanpa mengulang dari nol.

Di kubu sebaliknya, Terraform menawarkan filosofi deklaratif. Anda tidak lagi memberi tahu AWS *bagaimana* cara membuat server langkah demi langkah, melainkan Anda menuliskan *seperti apa rupa akhir* dari infrastruktur tersebut. Anda mendefinisikan Security Group, konfigurasi S3 Bucket untuk asset statis, hingga aturan WAF Cloudflare dalam bentuk kode HCL (HashiCorp Configuration Language). Pergeseran mental ini mengubah cara pandang tim: infrastruktur bukan lagi "binatang peliharaan" (*pets*) yang dirawat dengan penuh ketakutan jika sakit, melainkan "ternak" (*cattle*) yang bisa dimusnahkan dan diciptakan ulang dalam hitungan menit.

Namun, memiliki kode yang indah tidak ada artinya jika kenyataan di lapangan berkata lain. Mari kita uji bagaimana kedua pendekatan ini terasa di tangan seorang engineer yang diburu deadline.

## 2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Ketika Anda harus memutar otak mendesain arsitektur jaringan yang kompleks—mulai dari VPC dengan Public/Private Subnet, NAT Gateway, hingga konfigurasi Postfix mail relay untuk notifikasi sistem—ergonomi bahasa konfigurasi menjadi penentu kewarasan.

Mari kita lihat cuplikan kode Terraform yang modular dan bersih untuk mendefinisikan sebuah server web Nginx di balik Application Load Balancer (ALB), lengkap dengan pengelolaan state yang aman menggunakan remote backend S3 dan DynamoDB untuk locking:

```hcl
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket         = "my-company-terraform-state-prod"
    key            = "web-infrastructure/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-lock-table"
    encrypt        = true
  }
}

provider "aws" {
  region = "ap-southeast-1"
  default_tags {
    tags {
      Environment = "Production"
      ManagedBy   = "Terraform"
    }
  }
}

module "vpc_web" {
  source = "./modules/vpc"
  cidr_block          = "10.100.0.0/16"
  availability_zones  = ["ap-southeast-1a", "ap-southeast-1b"]
  public_subnet_cidrs = ["10.100.1.0/24", "10.100.2.0/24"]
}

resource "aws_instance" "web_nginx" {
  ami           = "ami-0c55b159cbfafe1f0" # Ubuntu 22.04 LTS
  instance_type = "t3.medium"
  subnet_id     = module.vpc_web.public_subnets[0]
  
  user_data = <<-EOF
              #!/bin/bash
              apt-get update -y
              apt-get install -y nginx php-fpm php-mysql redis-server
              systemctl enable nginx
              systemctl start nginx
              EOF

  tags = {
    Name = "Production-Nginx-WebNode"
  }
}
```

> [!TIP]
> Selalu gunakan DynamoDB table saat konfigurasi remote state S3 di Terraform. Ini mencegah dua engineer melakukan `apply` secara bersamaan yang dapat merusak file `tfstate` Anda.

Bandingkan pengalaman di atas dengan mengandalkan skrip bash manual atau klik AWS Console. Di console, Anda harus mengklik puluhan form, memasukkan Security Group ID satu per satu, dan berdoa agar tidak salah centang pada bagian port inbound. Sementara dengan Terraform, setiap perubahan tercatat rapi dalam version control (Git), memberikan transparansi penuh siapa yang mengubah apa dan kapan.

## 3. Ronde 2: Uji Ketahanan di Bawah Gempuran Beban Ekstrem

Infrastruktur yang indah di atas kertas bisa runtuh seketika saat berhadapan dengan lonjakan traffic musiman, misalnya saat 11.11 atau flash sale tengah malam. Di arena pengujian, kami mensimulasikan beban menggunakan `k6` dan `wrk` untuk menghantam endpoint API berbasis Node.js yang berjalan di atas instance AWS yang di-provision oleh Terraform, dibandingkan dengan infrastruktur manual.

Saat beban digenjot hingga 10.000 request per detik (RPS), kelemahan dari skrip manual mulai terlihat. Karena tidak ada standarisasi, konfigurasi kernel Linux (seperti `somaxconn`, `file-max`, dan parameter TCP keep-alive) antar server web berbeda-beda, menyebabkan bottleneck dan koneksi reset secara acak. Sebaliknya, infrastruktur yang diotomatisasi dengan Terraform memastikan bahwa setiap modul mendistribusikan konfigurasi sistem operasi yang identik ke seluruh Auto Scaling Group.

Berikut adalah skrip pengujian `k6` sederhana untuk mengukur latensi dan stabilitas endpoint web kita di bawah tekanan:

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

export const options = {
  stages: [
    { duration: '30s', target: 2000 }, // Ramp-up ke 2000 user
    { duration: '1m', target: 10000 },  // Hantam dengan 10000 user
    { duration: '30s', target: 0 },    // Ramp-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<250'],   // 95% request harus di bawah 250ms
    http_req_failed: ['rate<0.01'],    // Error rate di bawah 1%
  },
};

export default function () {
  const res = http.get('https://api.production-domain.com/health');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response timeok': (r) => r.timings.duration < 200,
  });
  sleep(0.1);
}
```

Hasil pengujian menunjukkan bahwa infrastruktur Terraform + AWS Auto Scaling Group mampu melakukan scale-out secara mulus saat CPU utilization mencapai 75%, menjaga latensi p95 tetap di bawah ambang batas yang ditentukan tanpa intervensi manual sama sekali.

## 4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Biaya cloud adalah pembunuh diam-diam perusahaan rintisan hingga enterprise. Menggunakan AWS Console sering kali meninggalkan "sampah" infrastruktur yang terlupakan: EBS volume yang tidak terikat (unattached), Elastic IP yang menganggur, atau snapshot database lama yang terus menumpuk dan membebani tagihan bulanan.

Di sinilah Terraform menunjukkan taringnya dalam hal efisiensi finansial. Dengan menjalankan perintah `terraform destroy` untuk environment staging di luar jam kerja, atau menggunakan `terraform plan` secara berkala, tim dapat mendeteksi adanya *drift* dan sumber daya yatim piatu (*orphan resources*). Penggunaan memori lokal saat menjalankan Terraform CLI memang sedikit lebih tinggi karena ia perlu memuat seluruh grafik dependensi state ke dalam RAM, namun penghematan biaya cloud yang dihasilkan bisa mencapai 30% hingga 40% per bulan.

## 5. Kapan Wajib Menggunakan Terraform & AWS Automation

Anda wajib meninggalkan cara-cara manual dan segera mengadopsi Terraform & AWS Automation jika:
1. Skala infrastruktur Anda sudah melewati 20 resource dan terus bertambah setiap minggunya.
2. Perusahaan menerapkan standar kepatuhan (compliance) yang ketat seperti SOC2, ISO 27001, atau PCI-DSS yang menuntut audit trail di setiap perubahan sistem.
3. Tim Anda bekerja secara hybrid atau remote dan membutuhkan environment staging/development yang identik dengan production dalam hitungan menit.
4. Anda memiliki siklus CI/CD deployment yang agresif dan menuntut zero-downtime infrastructure provisioning.

## 6. Kapan Wajib Menggalkan / Menunda Penggunaan Terraform

Namun, jujurlah pada diri sendiri. Terraform bukanlah peluru perak (*silver bullet*) untuk segala situasi. Anda boleh menunda atau tidak menggunakan Terraform jika:
1. Anda sedang membangun MVP (Minimum Viable Product) yang sifatnya eksperimental, berumur pendek, dan hanya dikerjakan oleh satu orang developer solo.
2. Tim Anda belum memiliki pemahaman dasar tentang konsep State Management, Locking, dan HCL, di mana kurva belajar justru akan memperlambat peluncuran produk.
3. Layanan cloud yang Anda gunakan sangat labil atau berubah-ubah fiturnya sehingga provider Terraform sering mengalami breaking changes.

## 7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Sebagai seseorang yang telah melihat jatuh bangunnya arsitektur sistem skala besar di berbagai perusahaan, keputusan menggunakan Terraform & AWS untuk otomatisasi infrastruktur cloud bukanlah lagi sebuah pilihan gaya-gayaan, melainkan sebuah keharusan operasional. Memang, investasi awal pada kurva belajar dan penataan state backend terasa melelahkan. Namun, ketenangan pikiran saat Anda bisa melakukan `terraform apply` untuk meregenerasi seluruh ekosistem web yang kolaps dalam waktu sepuluh menit adalah sebuah kemewahan teknis yang tidak ternilai harganya. Mulailah dari modul kecil, amankan state Anda, dan biarkan kode yang bekerja menjaga malam-malam Anda tetap tenang.