Destroy #

terraform destroy adalah perintah yang paling perlu kehati-hatian di seluruh Terraform. Ia menghapus semua resource yang dikelola Terraform secara permanen — tidak ada undo, tidak ada recycle bin. Memahami kapan destroy tepat digunakan, bagaimana cara melindungi resource yang tidak boleh dihapus, dan alternatif selain full destroy adalah keterampilan penting untuk siapapun yang mengelola infrastruktur di production.

Apa yang Terjadi Saat terraform destroy #

terraform destroy — Urutan Eksekusi:

1. Baca state saat ini
        │
        ▼
2. Generate "reverse plan"
   (kebalikan dari apply — semua resource ditandai untuk dihapus)
        │
        ▼
3. Tampilkan rencana penghapusan dan minta konfirmasi
        │
        ▼
4. Hapus resource dalam urutan terbalik dari dependency graph
   (resource yang bergantung pada yang lain dihapus lebih dulu)
        │
        ├── Destroy: aws_instance.web      (bergantung pada subnet dan sg)
        ├── Destroy: aws_security_group    (bergantung pada VPC)
        ├── Destroy: aws_subnet.public     (bergantung pada VPC)
        └── Destroy: aws_vpc.main          (tidak ada dependency)
        │
        ▼
5. State dikosongkan setelah semua resource terhapus

Urutan penghapusan adalah kebalikan dari urutan pembuatan — resource yang paling “dalam” dihapus dulu, baru resource yang jadi pondasinya.


Menjalankan Destroy #

# Destroy semua resource (minta konfirmasi)
terraform destroy

# Output konfirmasi:
# Plan: 0 to add, 0 to change, 5 to destroy.
#
# Do you really want to destroy all resources?
#   Terraform will destroy all your managed infrastructure, as shown above.
#   There is no undo. Only 'yes' will be accepted to confirm.
#
#   Enter a value: yes

# Destroy tanpa konfirmasi (untuk CI/CD atau automation)
terraform destroy -auto-approve

# Cara lain yang ekuivalen — lebih eksplisit tentang intent
terraform apply -destroy

# Destroy hanya resource tertentu
terraform destroy -target=aws_instance.web
terraform destroy -target=module.staging

Melindungi Resource dari Destroy #

Ada beberapa mekanisme untuk melindungi resource yang tidak boleh dihapus secara tidak sengaja.

# Mekanisme 1: lifecycle prevent_destroy
# Terraform akan ERROR jika ada yang mencoba menghapus resource ini
resource "aws_rds_instance" "production_db" {
  identifier        = "production-database"
  engine            = "postgres"
  instance_class    = "db.t3.medium"
  allocated_storage = 100

  lifecycle {
    prevent_destroy = true
    # Error saat destroy:
    # Error: Instance cannot be destroyed
    # Resource aws_rds_instance.production_db has lifecycle.prevent_destroy
    # set to true.
  }
}
# Mekanisme 2: ignore_changes untuk atribut yang dikelola di luar Terraform
resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.instance_type

  lifecycle {
    ignore_changes = [
      # Abaikan perubahan pada atribut ini — tidak akan trigger destroy/recreate
      ami,
      user_data,
    ]
  }
}
# Mekanisme 3: Hapus resource dari state tanpa menghapusnya dari cloud
# Resource tetap ada di AWS, tapi Terraform tidak lagi mengelolanya
terraform state rm aws_instance.web
# Sekarang terraform destroy tidak akan menyentuh resource ini

Kapan Destroy Tepat Digunakan #

GUNAKAN terraform destroy JIKA:
  ✓ Menghapus environment sementara (dev, feature branch)
  ✓ Membersihkan resource demo atau eksperimen
  ✓ Teardown environment yang sudah tidak diperlukan
  ✓ Migrasi ke konfigurasi yang benar-benar baru dari awal

JANGAN GUNAKAN terraform destroy JIKA:
  ✗ Ingin menghapus hanya sebagian resource — gunakan -target atau
    hapus blok resource dari konfigurasi lalu apply
  ✗ Ada resource yang mengandung data production (database, storage)
    tanpa backup yang sudah diverifikasi
  ✗ Tidak yakin resource apa saja yang akan terhapus —
    selalu jalankan plan dulu dan baca outputnya dengan cermat

Alternatif Selain Full Destroy #

Destroy penuh seringkali bukan satu-satunya pilihan. Ada pendekatan yang lebih aman.

# Alternatif 1: Hapus resource dari konfigurasi, lalu apply
# (Terraform akan menghapus hanya resource yang dihilangkan dari .tf)

# Sebelum:
resource "aws_instance" "staging" {
  ami           = var.ami_id
  instance_type = "t3.micro"
}

# Sesudah (hapus blok ini):
# (tidak ada lagi)

# Lalu: terraform apply
# Terraform mendeteksi resource tidak lagi ada di konfigurasi
# dan menghapusnya dari cloud
# Alternatif 2: Destroy hanya module atau resource spesifik
terraform destroy -target=module.staging
terraform destroy -target=aws_instance.old_server

# Alternatif 3: Unmanage resource (lepas dari Terraform tanpa destroy)
terraform state rm aws_s3_bucket.old_bucket
# Resource tetap ada di AWS, Terraform tidak lagi mengelolanya

Destroy di CI/CD Pipeline #

Untuk lingkungan yang di-destroy secara otomatis (misalnya: ephemeral environment per PR), ada pola yang aman.

# Pola destroy yang aman di CI/CD:

# 1. Generate destroy plan dulu
terraform plan -destroy -out=destroy-plan

# 2. Review plan (manual atau automated check)
terraform show destroy-plan

# 3. Apply destroy plan jika sudah diverifikasi
terraform apply destroy-plan

# Kenapa tidak langsung -auto-approve?
# Destroy plan yang disimpan memberikan audit trail
# dan mencegah surprise dari kondisi yang berubah
# antara inisiasi destroy dan eksekusinya.

Ringkasan #

  • Destroy tidak bisa di-undo — selalu jalankan terraform plan -destroy dan baca outputnya sebelum mengkonfirmasi.
  • Urutan penghapusan otomatis — Terraform menghapus resource dalam urutan terbalik dari dependency, tidak perlu ditentukan manual.
  • prevent_destroy = true untuk resource kritis seperti production database — Terraform akan error sebelum sempat menghapusnya.
  • Hapus blok resource dari .tf lalu apply untuk menghapus resource tertentu saja — lebih terkontrol dari destroy penuh.
  • terraform state rm untuk unmanage resource tanpa menghapusnya dari cloud — berguna untuk transisi ownership.
  • Di CI/CD, gunakan saved destroy plan agar ada audit trail yang jelas dari apa yang akan dihapus.

← Sebelumnya: Apply   Berikutnya: Execution Plan →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact