Infrastruktur Manual #

Bayangkan kamu bergabung dengan tim yang punya 40 server di production. Tidak ada dokumentasi tentang bagaimana server-server itu dibuat. Yang ada hanya seorang senior yang “hapal” konfigurasinya. Suatu hari orang itu resign, dan tim menyadari bahwa tidak ada yang tahu persis setting apa yang dipakai di setiap server. Beberapa server menjalankan versi software yang berbeda, konfigurasi jaringan tidak konsisten, dan tidak ada yang bisa menjamin bahwa staging benar-benar mereplikasi production. Inilah realita dari infrastruktur yang dikelola secara manual — sebuah pendekatan yang tampak cepat di awal, tapi meninggalkan hutang teknis yang mahal dan berbahaya.

Artikel ini membahas secara mendalam mengapa pengelolaan infrastruktur manual menjadi masalah — dari snowflake servers, configuration drift, hingga disaster recovery yang lambat. Kamu juga akan melihat bagaimana setiap masalah ini terhubung dan saling memperparah, serta mengapa beralih ke Infrastructure as Code bukan sekadar pilihan teknis, tapi kebutuhan operasional.

Apa yang Dimaksud dengan Infrastruktur Manual #

Infrastruktur manual adalah setiap pendekatan di mana resource cloud dibuat, dikonfigurasi, dan dikelola melalui tindakan manusia yang tidak terotomasi dan tidak terdokumentasi dalam bentuk kode. Ini termasuk klik-klik di console AWS, menjalankan perintah CLI secara ad-hoc, atau bahkan menulis script yang hanya satu orang yang tahu cara menjalankannya.

flowchart LR
    subgraph Manual["Cara Manual Mengelola Infrastruktur"]
        A["🖱️ Klik di\nConsole Cloud"] --> B["💻 Jalankan\nCLI Command"]
        B --> C["📝 Tulis Script\nAd-hoc"]
        C --> D["🧠 Hanya 1 Orang\nyang Tahu"]
    end

    D --> E["⚠️ Masalah:\nTidak Terdokumentasi"]
    D --> F["⚠️ Masalah:\nTidak Reusable"]
    D --> G["⚠️ Masalah:\nTidak Teruji"]

    style E fill:#ffebee,stroke:#c62828
    style F fill:#ffebee,stroke:#c62828
    style G fill:#ffebee,stroke:#c62828

Setiap metode manual punya masalah fundamental yang sama: prosesnya tidak terdefinisi dalam bentuk yang bisa diverifikasi oleh mesin. Ketika kamu membuat VPC lewat console, tidak ada yang tahu apakah subnet CIDR yang kamu pilih sudah benar kecuali kamu sendiri. Ketika kamu menjalankan aws ec2 run-instances di terminal, tidak ada yang mengecek apakah security group yang kamu pakai sudah sesuai standar keamanan tim.

Contoh Nyata: Membuat EC2 Instance Secara Manual #

Berikut adalah contoh bagaimana seseorang membuat EC2 instance melalui AWS CLI secara manual. Perhatikan bagaimana proses ini memerlukan banyak langkah yang harus diingat dan dijalankan dalam urutan yang benar.

# Langkah 1: Buat VPC
VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 \
  --query 'Vpc.VpcId' --output text)

# Langkah 2: Buat Subnet
SUBNET_ID=$(aws ec2 create-subnet --vpc-id $VPC_ID \
  --cidr-block 10.0.1.0/24 \
  --query 'Subnet.SubnetId' --output text)

# Langkah 3: Buat Internet Gateway
IGW_ID=$(aws ec2 create-internet-gateway \
  --query 'InternetGateway.InternetGatewayId' --output text)
aws ec2 attach-internet-gateway --internet-gateway-id $IGW_ID \
  --vpc-id $VPC_ID

# Langkah 4: Buat Route Table
RT_ID=$(aws ec2 create-route-table --vpc-id $VPC_ID \
  --query 'RouteTable.RouteTableId' --output text)
aws ec2 create-route --route-table-id $RT_ID \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id $IGW_ID
aws ec2 associate-route-table --route-table-id $RT_ID \
  --subnet-id $SUBNET_ID

# Langkah 5: Buat Security Group
SG_ID=$(aws ec2 create-security-group \
  --group-name "web-sg" --description "Web SG" --vpc-id $VPC_ID \
  --query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress --group-id $SG_ID \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

# Langkah 6: Launch Instance
INSTANCE_ID=$(aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --subnet-id $SUBNET_ID \
  --security-group-ids $SG_ID \
  --query 'Instances[0].InstanceId' --output text)

# ...dan masih banyak lagi langkah berikutnya

Bayangkan kamu harus menghafal dan menjalankan seluruh langkah ini setiap kali butuh instance baru. Sekarang bayangkan ada 5 orang di tim yang masing-masing melakukan hal yang sama — dengan cara yang sedikit berbeda setiap kali. Di sinilah masalah dimulai.

Anti-Pattern: Menyamakan “Sudah Jalan” dengan “Sudah Benar” #

ANTI-PATTERN:
  ✗ "Servernya udah jalan kok, ngapain diotomasi?"
  ✗ "Dulu waktu bikin, saya klik-klik aja, 30 menit selesai"
  ✗ "Script bash saya udah ada, tinggal jalanin"

KENAPA BERBAHAYA:
  ✓ "Jalan" ≠ "terdokumentasi" ≠ "bisa diulang" ≠ "aman"
  ✓ Proses 30 menit bisa jadi 3 hari kalau yang bikin resign
  ✓ Script bash tanpa idempotency bisa bikin duplikat resource

Pernyataan “sudah jalan” adalah jebakan paling berbahaya dalam operasi infrastruktur. Server yang berjalan hari ini bisa jadi tidak bisa dibuat ulang besok karena tidak ada yang tahu konfigurasi lengkapnya. Ini bukan masalah teknis — ini masalah operasional yang bisa berdampak pada bisnis.

Snowflake Servers #

Snowflake server adalah server yang unik — tidak ada server lain yang persis sama konfigurasinya. Dinamakan “snowflake” karena seperti salju, setiap server tampak mirip tapi secara detail tidak ada yang identik. Masalahnya, keunikan ini bukan sesuatu yang disengaja, melainkan akumulasi dari perubahan manual yang terjadi selama berbulan-bulan atau bertahun-tahun.

flowchart TD
    A["Server Dibuat\n(semua identik)"] --> B["Admin A\ninstall package X"]
    A --> C["Admin B\nubah config Y"]
    A --> D["Admin C\npatch security Z"]

    B --> E["Server 1\n(package X + config default + no patch)"]
    C --> F["Server 2\n(no package X + config Y + no patch)"]
    D --> G["Server 3\n(no package X + config default + patch Z)"]

    E --> H["❓ Mana yang benar?\nTidak ada yang tahu"]
    F --> H
    G --> H

    style H fill:#ffebee,stroke:#c62828

Dalam skenario di atas, setiap admin melakukan perubahan yang “benar” menurut pengetahuannya masing-masing. Tapi tanpa sumber kebenaran tunggal (single source of truth), tidak ada yang bisa memastikan konfigurasi mana yang seharusnya dipakai di semua server.

Mengapa Snowflake Server Berbahaya #

Snowflake server menciptakan beberapa masalah yang saling berkaitan:

Debugging menjadi sangat sulit. Ketika terjadi error di production, langkah pertama troubleshooting adalah mencari perbedaan antara environment yang berfungsi dan yang tidak. Kalau setiap server unik, kamu tidak punya baseline untuk dibandingkan. Bug yang muncul di server 1 mungkin tidak muncul di server 2 karena perbedaan konfigurasi yang tidak kamu ketahui.

Scaling menjadi unpredictable. Menambah server baru berarti mencoba mereproduksi konfigurasi server yang sudah ada — tapi konfigurasi itu tidak terdokumentasi. Server baru mungkin berjalan dengan versi library yang berbeda, setting timezone yang berbeda, atau parameter JVM yang tidak sama, dan perbedaan kecil ini bisa menyebabkan perbedaan perilaku yang signifikan.

Compliance menjadi mustahil. Standar keamanan mensyaratkan bahwa semua server harus memenuhi baseline keamanan yang sama. Dengan snowflake server, tidak ada cara untuk memverifikasi bahwa semua server sudah di-patch, mengikuti standar hardening yang sama, atau menggunakan versi software yang disetujui.

CHECKLIST: Apakah Tim Kamu Punya Snowflake Server?
  □ Apakah ada server yang "jangan diutak-atik karena sudah lama jalan"?
  □ Apakah ada perbedaan versi OS/package antar server yang seharusnya identik?
  □ Apakah kamu tidak yakin bisa membuat ulang server production dari nol?
  □ Apakah ada konfigurasi yang hanya diketahui oleh 1-2 orang?
  □ Apakah setiap kali ada incident, root cause-nya berbeda-beda?

  Jika jawaban "ya" untuk 2 atau lebih, kemungkinan besar
  tim kamu punya snowflake server.

Configuration Drift #

Configuration drift terjadi ketika kondisi aktual infrastruktur menyimpang dari kondisi yang diharapkan seiring waktu. Drift ini terjadi secara gradual — satu perubahan kecil di sini, satu hotfix di sana — sampai suatu hari kamu menyadari bahwa production sudah sangat berbeda dari yang kamu kira.

flowchart TD
    A["Infrastruktur Awal\n(sesuai desain)"] --> B["Waktu Berjalan..."]

    B --> C["Perubahan 1:\nAdmin tambah security group rule\nuntuk troubleshoot"]
    B --> D["Perubahan 2:\nTim DevOps resize instance\ntanpa update dokumentasi"]
    B --> E["Perubahan 3:\nHotfix: buka port 8080\ndi production sementara"]
    B --> F["Perubahan 4:\nUbah subnet CIDR\nuntuk accommodate resource baru"]

    C --> G["Kondisi Aktual:\nSangat berbeda dari desain awal"]
    D --> G
    E --> G
    F --> G

    G --> H["Tidak ada yang tahu\nperubahan mana yang intentional\ndan mana yang accident"]

    style H fill:#ffebee,stroke:#c62828

Dampak Configuration Drift #

Configuration drift bukan masalah teoritis. Berikut skenario nyata yang sering terjadi di production:

Skenario 1: Security group terbuka. Seorang developer membuka port 22 dari 0.0.0.0/0 untuk troubleshooting di hari Jumat malam. Dia berencana menutupnya Senin pagi, tapi lupa. Tiga bulan kemudian, security audit menemukan bahwa port SSH production terbuka ke publik — dan tidak ada yang tahu kapan atau mengapa itu terjadi.

Skenario 2: Instance type berbeda. Tim melakukan load testing dan mengubah instance type dari t3.medium ke t3.2xlarge. Setelah testing selesai, mereka lupa mengembalikannya. Tagihan AWS bulan berikutnya membengkak 8x lipat, dan butuh 2 hari untuk menemukan penyebabnya karena tidak ada perubahan yang tercatat di Git.

Skenario 3: Manual fix yang tidak terduplikasi. Seorang admin memperbaiki masalah DNS di satu server production dengan mengedit /etc/resolv.conf secara langsung. Ketika server baru ditambahkan dengan auto scaling group, server baru tidak punya fix yang sama dan mengalami intermittent DNS failure yang sangat sulit di-debug.

DRIFT YANG SERING TERJADI TANPA DISADARI:

Infrastruktur Network:
  ✗ Security group rule ditambah/dihapus tanpa dokumentasi
  ✗ Route table dimodifikasi untuk troubleshooting
  ✗ NACL rules diubah sementara tapi tidak dikembalikan

Compute:
  ✗ Instance type diubah untuk testing, tidak dikembalikan
  ✗ AMI di-update manual di satu instance tapi tidak di yang lain
  ✗ User data script dimodifikasi langsung di instance

Storage:
  ✗ EBS volume diresize tanpa update di IaC
  ✗ S3 bucket policy diubah langsung di console
  ✗ Lifecycle policy dihapus untuk "sementara"

Tidak Bisa Direproduksi #

Salah satu sifat paling berbahaya dari infrastruktur manual adalah ketidakmampuan untuk mereproduksi environment secara identik. Ketika kamu tidak bisa membuat ulang infrastruktur yang sama persis, kamu kehilangan kemampuan untuk melakukan disaster recovery, testing yang akurat, dan scaling yang konsisten.

// ANTI-PATTERN: mengandalkan dokumentasi manual untuk reproduksi

// "Dokumentasi" yang sering terjadi di tim tanpa IaC:
// - File .txt di Google Drive yang terakhir di-update 6 bulan lalu
// - Wiki internal yang isinya tidak lengkap
// - Memory senior engineer yang "hapal" konfigurasinya
// - Chat history di Slack yang perlu di-scroll ratusan pesan

// BENAR: konfigurasi dalam kode yang selalu akurat
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  subnet_id     = aws_subnet.private.id

  vpc_security_group_ids = [aws_sg.web.id]

  tags = {
    Name        = "web-server"
    Environment = var.environment
    ManagedBy   = "terraform"
  }
}

Skenario Bencana: Region Outage #

Bayangkan skenario berikut: region ap-southeast-1 mengalami outage besar-besaran. Tim kamu punya 30 server di region tersebut. Dengan infrastruktur manual, proses recovery adalah:

1. Coba ingat-ingat atau cari-cari konfigurasi setiap server (berjam-jam)
2. Buat VPC, subnet, security group secara manual di region baru (berjam-jam)
3. Launch instance satu per satu dengan konfigurasi yang diperkirakan benar (berjam-jam)
4. Konfigurasikan load balancer, DNS, monitoring (berjam-jam)
5. Test dan debug perbedaan konfigurasi (berhari-hari)

Dengan Terraform, proses yang sama:

# Ubah region di satu baris
provider "aws" {
  region = "ap-northeast-1"  # Ganti dari ap-southeast-1
}

# Jalankan satu perintah
# $ terraform apply
# Seluruh infrastruktur dibuat ulang di region baru
# dalam hitungan menit, dengan konfigurasi yang identik

Perbedaannya bukan hanya soal waktu — tapi soal kepastian. Dengan manual, kamu tidak bisa yakin bahwa konfigurasi di region baru identik dengan yang lama. Dengan Terraform, kamu punya jaminan bahwa kode yang sama menghasilkan infrastruktur yang sama.

Tidak Ada Audit Trail #

Audit trail — catatan tentang siapa yang melakukan perubahan apa, kapan, dan mengapa — adalah kebutuhan fundamental untuk operasi yang aman dan compliant. Infrastruktur manual hampir selalu gagal menyediakan ini dengan baik.

flowchart LR
    subgraph Manual["Audit Trail Manual"]
        M1["CloudTrail?"] --> M2["Ada, tapi tersebar\nribuan event"]
        M2 --> M3["Siapa yang buka\nport 22? Siapa yang\nresize instance?"]
        M3 --> M4["Mustahil ditelusuri\ntanpa konteks"]
    end

    subgraph IaC["Audit Trail dengan IaC"]
        I1["Git History"] --> I2["Setiap perubahan\ntercatat dengan\ncommit message"]
        I2 --> I3["Pull Request =\napproval process"]
        I3 --> I4["Siapa, kapan, mengapa\ndan perubahan apa —\nsemua jelas"]
    end

    Manual --> X["❌ Tidak Compliant"]
    IaC --> Y["✅ Compliant"]

    style X fill:#ffebee,stroke:#c62828
    style Y fill:#e8f5e9,stroke:#2e7d32

Masalah Audit di Lingkungan Manual #

Ketika auditor bertanya “siapa yang membuka port 22 ke publik di production?”, tim yang mengelola infrastruktur manual harus:

1. Mengaktifkan CloudTrail (jika belum)
2. Menyaring ribuan event di CloudTrail
3. Mencocokkan event dengan IAM user/role
4. Mencoba menghubungkan event dengan konteks bisnis

Proses ini bisa memakan waktu berhari-hari dan seringkali tidak menghasilkan jawaban yang memuaskan karena CloudTrail hanya mencatat apa yang terjadi di API level, bukan mengapa.

Dengan Git sebagai audit trail, setiap perubahan tercatat dalam commit yang bisa ditelusuri:

# Audit trail dengan Git — jelas dan terstruktur
$ git log --oneline --all security-groups.tf

a1b2c3d Buka port 443 untuk load balancer baru (#234)
e4f5g6h Tutup port 22 dari publik — remediasi audit (#198)
i7j8k9l Tambah SSH bastion access (#156)

# Setiap commit punya:
# - Siapa (git author)
# - Kapan (timestamp)
# - Apa yang berubah (diff)
# - Mengapa (commit message / PR description)

Human Error yang Tidak Terdeteksi #

Manusia membuat error. Itu fakta yang tidak bisa dihindari. Masalahnya bukan pada error itu sendiri, tapi pada ketiadaan mekanisme untuk mendeteksi dan mencegah error sebelum berdampak pada production.

# Contoh human error yang sangat umum:

# Salah ketik CIDR block — seharusnya /24, jadi /16
aws ec2 create-subnet --vpc-id vpc-123 --cidr-block 10.0.0.0/16
# Error ini bisa mengakibatkan overlap CIDR yang baru
# ketahuan berminggu-minggu kemudian

# Lupa tag — instance tanpa tag tidak termonitor
aws ec2 run-instances --image-id ami-xxx --instance-type t3.micro
# Tanpa tag Environment, instance ini tidak masuk dalam
# monitoring dan cost allocation

# Salah environment — deploy ke production bukan staging
aws rds create-db-instance --db-instance-identifier app-prod ...
# Seharusnya app-staging. Tanpa guardrail, ini bisa
# overwrite database production

Mengapa Human Error Sering Tidak Terdeteksi #

Dalam lingkungan manual, tidak ada mekanisme otomatis yang mengecek apakah perubahan yang dilakukan sudah benar. Semua tergantung pada review manual — yang juga dilakukan oleh manusia yang bisa jadi lelah, terburu-buru, atau tidak punya konteks lengkap.

// ANTI-PATTERN: Bergantung pada review manual untuk mencegah error

// Dalam lingkungan manual, "review" biasanya seperti ini:
// 1. Seseorang mengubah konfigurasi di console
// 2. Dia bilang ke tim di Slack: "saya udah buka port 8080 di prod"
// 3. Tim merespons: "ok" (tanpa mengecek apakah ini aman)
// 4. Tidak ada yang memverifikasi apakah perubahan sesuai standar

// BENAR: Dengan Terraform, review dilakukan pada kode di Pull Request
// 1. Perubahan di-commit ke branch feature
// 2. Pull Request otomatis menunjukkan diff
// 3. CI/CD menjalankan terraform plan
// 4. Tim review plan + diff sebelum approve
// 5. Perubahan hanya bisa di-apply setelah approved

Disaster Recovery yang Lambat #

Disaster recovery adalah momen kebenaran bagi setiap tim infrastructure. Ketika terjadi kegagalan besar — region outage, ransomware attack, human error massal — seberapa cepat kamu bisa memulihkan infrastruktur? Jawabannya sangat bergantung pada apakah infrastruktur kamu dikelola secara manual atau terotomasi.

flowchart TD
    A["🚨 Disaster Terjadi\n(Region Outage)"] --> B{"Bagaimana\nInfrastruktur\nDikelola?"}

    B -->|"Manual"| C["Proses Recovery Manual"]
    B -->|"IaC (Terraform)"| D["Proses Recovery Otomatis"]

    C --> C1["Cari dokumentasi\n(bisa tidak ada)"]
    C1 --> C2["Rekonstruksi konfigurasi\ndari memory/dokumen"]
    C2 --> C3["Buat infrastruktur\nsatu per satu"]
    C3 --> C4["Test dan debug\nperbedaan konfigurasi"]
    C4 --> C5["⏱️ Waktu: Berhari-hari\nhingga berminggu-minggu"]

    D --> D1["Ubah region di\nkonfigurasi"]
    D1 --> D2["Jalankan\nterraform apply"]
    D2 --> D3["Infrastruktur baru\nidentik dengan yang lama"]
    D3 --> D4["⏱️ Waktu: Menit\nhingga jam"]

    style C5 fill:#ffebee,stroke:#c62828
    style D4 fill:#e8f5e9,stroke:#2e7d32

RTO dan RPO #

Dua metrik utama disaster recovery:

• RTO (Recovery Time Objective): Seberapa cepat infrastruktur harus pulih. Dengan manual, RTO bisa berhari-hari. Dengan Terraform, RTO bisa diukur dalam menit.
• RPO (Recovery Point Objective): Seberapa banyak data yang boleh hilang. Infrastruktur manual sering tidak punya backup strategy yang konsisten, sehingga RPO bisa sangat besar.

// Contoh: backup strategy yang terdefinisi di Terraform
resource "aws_db_instance" "main" {
  identifier     = "app-database"
  engine         = "postgres"
  engine_version = "15.4"
  instance_class = "db.t3.medium"

  backup_retention_period = 7        # Simpan backup 7 hari
  backup_window          = "03:00-04:00"
  multi_az               = true      # High availability

  # Semua parameter backup terdefinisi di kode
  # Tidak ada yang "lupa" mengaktifkan backup
}

Dengan konfigurasi di atas, setiap kali database dibuat — baik di environment baru, di region baru, atau setelah disaster — parameter backup selalu sama. Tidak ada risiko “lupa mengaktifkan backup” atau “lupa set multi-AZ”.

Biaya Tersembunyi dari Infrastruktur Manual #

Banyak tim menganggap infrastruktur manual “lebih murah” karena tidak perlu investasi waktu untuk menulis kode IaC. Perhitungan ini keliru karena mengabaikan biaya tersembunyi yang jauh lebih besar.

BIAYA TERSEMBUNYI INFRASTRUKTUR MANUAL:

1. Biaya Waktu Engineer
   ✗ Membuat infrastruktur baru: berjam-jam (vs menit dengan IaC)
   ✗ Troubleshooting perbedaan environment: berhari-hari
   ✗ Onboarding engineer baru: berminggu-minggu
   ✗ Dokumentasi yang selalu ketinggalan: ongoing cost

2. Biaya Downtime
   ✗ Recovery lambat = downtime lebih lama
   ✗ Human error tidak terdeteksi = insiden tak terduga
   ✗ Snowflake server = troubleshooting lebih lama

3. Biaya Compliance
   ✗ Audit manual = waktu engineer berhari-hari
   ✗ Remediasi temuan audit = perubahan manual yang bisa salah
   ✗ Ketidakmampuan membuktikan kepatuhan = risiko denda

4. Biaya Opportunity
   ✗ Engineer sibuk mengelola infrastruktur = tidak bisa
     mengerjakan fitur baru
   ✗ Deploy lambat = feedback loop lambat = iterasi lambat
   ✗ Fear of change = resistensi terhadap improvement

Perhitungan Sederhana #

Bayangkan seorang DevOps engineer dengan gaji Rp 25 juta/bulan menghabiskan 40% waktunya untuk tugas-tugas manual yang bisa diotomasi:

48 jam/bulan × Rp 156.000/jam = Rp 7.5 juta/bulan yang terbuang untuk pekerjaan yang bisa diotomasi. Dan ini hanya satu engineer — kalikan dengan ukuran tim.

Dari Manual ke Infrastructure as Code #

Transisi dari infrastruktur manual ke IaC bukan harus terjadi sekaligus. Pendekatan bertahap yang pragmatis lebih realistis dan lebih kecil risikonya.

flowchart LR
    A["Fase 1\nImport\nResource yang\nAda"] --> B["Fase 2\nTulis IaC\nuntuk Resource\nBaru"]
    B --> C["Fase 3\nRefactor\nResource\nLama ke IaC"]
    C --> D["Fase 4\nFull IaC +\nCI/CD Pipeline"]

    A -.->|"terraform import"| B
    B -.->|"kebijakan tim"| C
    C -.->|"terraform plan\nreview"| D

    style A fill:#fff3e0,stroke:#e65100
    style B fill:#e3f2fd,stroke:#1565c0
    style C fill:#e8f5e9,stroke:#2e7d32
    style D fill:#f3e5f5,stroke:#6a1b9a

Langkah 1: Mulai dari Resource Baru #

Tidak perlu langsung mengonversi seluruh infrastruktur. Mulailah dengan kebijakan: “semua resource baru harus dibuat melalui Terraform.” Resource yang sudah ada dibiarkan apa adanya — nanti akan di-migrate secara bertahap.

Langkah 2: Import Resource Lama #

Terraform menyediakan perintah terraform import untuk mengambil resource yang sudah ada ke dalam state management. Ini memungkinkan kamu mengelola resource lama melalui kode tanpa harus menghapus dan membuat ulang.

# Import EC2 instance yang sudah ada ke Terraform state
terraform import aws_instance.web i-0abc123def456789

# Import S3 bucket yang sudah ada
terraform import aws_s3_bucket.data my-existing-bucket

# Setelah import, tulis konfigurasi yang sesuai
# dengan kondisi aktual resource

Langkah 3: Set Guardrail #

Begitu sebagian besar resource dikelola oleh Terraform, tambahkan guardrail untuk mencegah perubahan manual:

GUARDRAIL YANG BISA DITERAPKAN:

Organizational:
  ✓ Kebijakan: semua perubahan infrastruktur harus melalui PR
  ✓ Review wajib oleh minimal 1 orang sebelum merge
  ✓ Dokumentasi proses di README

Technical:
  ✓ IAM policy yang membatasi siapa yang bisa mengubah resource
  ✓ AWS Config Rules untuk mendeteksi perubahan manual
  ✓ CI/CD pipeline yang otomatis menjalankan terraform plan
  ✓ Drift detection yang alert ketika ada perubahan di luar Terraform

Ringkasan #

• Infrastruktur manual — baik klik di console, jalankan CLI, atau tulis script ad-hoc — menghasilkan snowflake server yang unik dan tidak bisa direproduksi.
• Configuration drift terjadi ketika kondisi aktual infrastruktur menyimpang dari yang diharapkan, dan sangat sulit dideteksi tanpa tool otomatis.
• Tidak ada audit trail yang memadai — CloudTrail mencatat event API tapi tidak punya konteks bisnis, sehingga compliance menjadi mahal dan memakan waktu.
• Human error tidak terdeteksi karena tidak ada mekanisme validasi otomatis sebelum perubahan berdampak ke production.
• Disaster recovery lambat — tanpa kode yang mendefinisikan infrastruktur, rebuild memerlukan rekonstruksi manual yang memakan waktu berhari-hari.
• Biaya tersembunyi dari infrastruktur manual jauh lebih besar dari investasi waktu untuk menulis IaC — termasuk waktu engineer, downtime, compliance, dan opportunity cost.
• Transisi bertahap dari manual ke IaC adalah pendekatan yang realistis — mulai dari resource baru, import resource lama, lalu tambahkan guardrail.

← Sebelumnya: Apa itu Terraform?   Berikutnya: Tool Imperatif →