ASG Health Check: Kenapa Instance Terus Diterminasi dan Kapan Harus Pakai ELB Health Check

Instance di Auto Scaling Group kamu berstatus 'running' di EC2 console, tapi ASG terus menerus menterminasi dan mengganti instance tersebut — ini salah satu skenario paling membingungkan di production. Masalahnya bukan di instance, tapi di perbedaan antara apa yang EC2 anggap 'sehat' dan apa yang load balancer anggap 'siap melayani traffic'. Memahami cara kerja ASG health check sebelum mengubah konfigurasi adalah langkah yang tidak bisa dilewati.

TL;DR: ASG Health Check EC2 vs ELB

Aspek EC2 Health Check ELB Health Check
Apa yang diperiksa Status sistem dan instance EC2 (hardware/hypervisor) Respons HTTP/TCP dari aplikasi di dalam instance
Default ASG Ya, selalu aktif Harus diaktifkan secara eksplisit
Kapan instance dianggap unhealthy Status instance bukan 'running' atau system check gagal Target group melaporkan instance unhealthy
Cocok untuk Deteksi kegagalan infrastruktur Deteksi kegagalan aplikasi
Risiko jika salah konfigurasi Aplikasi crash tidak terdeteksi Instance diterminasi saat startup jika grace period terlalu pendek

Bagaimana ASG Health Check Bekerja

ASG menentukan apakah sebuah instance harus diganti berdasarkan hasil health check. Ada dua sumber informasi yang bisa digunakan ASG: status dari EC2 itu sendiri, dan status dari load balancer yang terhubung. Keduanya bisa aktif secara bersamaan, dan jika salah satu melaporkan instance sebagai unhealthy, ASG akan menterminasi instance tersebut.

Yang sering tidak disadari: ketika kamu mengaktifkan ELB health check di ASG, kamu tidak mengganti EC2 health check — kamu menambahkan satu lapisan pemeriksaan lagi. ASG akan menterminasi instance jika EC2 health check atau ELB health check melaporkan unhealthy.

graph TD A["Instance Launched"] --> B["Health Check Grace Period ASG mengabaikan hasil check"] B --> C{"Grace Period Selesai"} C --> D["EC2 Health Check Status: running? System check: passed?"] C --> E["ELB Health Check (jika diaktifkan) Target group: healthy?"] D -->|"Healthy"| F["Instance Tetap Berjalan"] E -->|"Healthy"| F D -->|"Unhealthy"| G["ASG Menterminasi Instance"] E -->|"Unhealthy"| G G --> H["Instance Baru Diluncurkan sesuai Launch Template"] H --> A
  1. EC2 Health Check — ASG memeriksa apakah status instance adalah 'running' dan EC2 system status check lulus. Ini berjalan terus-menerus tanpa konfigurasi tambahan.
  2. ELB Health Check — Jika diaktifkan, ASG membaca status health dari target group yang terhubung. Load balancer yang melakukan probe ke endpoint aplikasi, bukan ASG langsung.
  3. Health Check Grace Period — Jendela waktu setelah instance launch di mana ASG mengabaikan hasil health check. Ini mencegah instance diterminasi sebelum aplikasi selesai startup.
  4. Terminasi & Penggantian — Instance yang dinyatakan unhealthy akan diterminasi dan diganti dengan instance baru sesuai launch template/configuration.

Mengapa Instance 'Running' Bisa Diterminasi ASG

Ini titik kebingungan yang paling umum. Ada beberapa skenario berbeda yang menghasilkan gejala yang sama persis — instance terlihat normal di console tapi terus diganti.

Skenario 1: ELB Health Check Aktif, Aplikasi Tidak Merespons

Jika kamu sudah mengaktifkan ELB health check di ASG, tapi aplikasi di dalam instance mengembalikan status code di luar range yang dikonfigurasi di target group (misalnya mengembalikan 503 padahal target group hanya menerima 200), load balancer akan melaporkan instance sebagai unhealthy. ASG membaca laporan ini dan menterminasi instance — meskipun EC2 instance itu sendiri berstatus 'running' sempurna.

Skenario 2: Health Check Grace Period Terlalu Pendek

Ini penyebab yang paling sering diabaikan. Jika grace period diset 60 detik tapi aplikasi butuh 3 menit untuk startup (misalnya karena inisialisasi database connection pool, loading konfigurasi dari Parameter Store, atau warming cache), ELB health check akan gagal selama startup dan ASG akan menterminasi instance sebelum aplikasi siap. Hasilnya: instance baru diluncurkan, gagal lagi, diterminasi lagi — loop tak berujung.

Skenario 3: EC2 System Status Check Gagal

Ini murni masalah infrastruktur AWS — hardware atau hypervisor yang menjalankan instance mengalami masalah. Instance berstatus 'running' tapi EC2 system status check menunjukkan 'impaired'. ASG dengan EC2 health check default akan menterminasi instance ini. Ini perilaku yang benar dan diinginkan.

Analoginya seperti perbedaan antara lampu 'power on' di server dan hasil ping ke port aplikasi. Lampu menyala tidak berarti Nginx sudah melayani request.

Diagnosis: Kenapa ASG Menterminasi Instance Kamu

Sebelum mengubah tipe health check, identifikasi dulu penyebab sebenarnya. Langkah-langkah berikut bergerak dari lapisan yang paling mudah diverifikasi ke yang paling spesifik.

Langkah 1: Periksa Activity History ASG

Activity history mencatat alasan setiap terminasi. Ini titik awal yang wajib — tanpa ini kamu hanya menebak.

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name nama-asg-kamu \
  --region us-east-1 \
  --query 'Activities[?StatusCode==`Failed` || contains(Description, `Terminating`)].[ActivityId,Description,Cause,StatusMessage]' \
  --output table

Perhatikan kolom Cause. Jika tertulis sesuatu seperti 'Instance failed ELB health checks' atau 'Instance failed EC2 health checks', kamu sudah tahu lapisan mana yang bermasalah.

Langkah 2: Periksa Status Health Check di ASG

Cek konfigurasi health check yang aktif saat ini di ASG, termasuk tipe dan grace period yang dikonfigurasi.

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names nama-asg-kamu \
  --region us-east-1 \
  --query 'AutoScalingGroups[0].{HealthCheckType:HealthCheckType,HealthCheckGracePeriod:HealthCheckGracePeriod,LoadBalancerNames:LoadBalancerNames,TargetGroupARNs:TargetGroupARNs}' \
  --output json

Jika HealthCheckType sudah ELB tapi instance masih diterminasi, masalahnya bukan di tipe health check — melainkan di konfigurasi target group atau grace period.

Langkah 3: Periksa Status Instance di Target Group

Jika ELB health check aktif, lihat langsung apa yang dilaporkan target group untuk instance yang bermasalah. Ini menjawab pertanyaan apakah load balancer yang menjadi sumber laporan unhealthy.

aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/nama-target-group/1234567890abcdef \
  --region us-east-1 \
  --query 'TargetHealthDescriptions[*].{Id:Target.Id,Port:Target.Port,State:TargetHealth.State,Reason:TargetHealth.Reason,Description:TargetHealth.Description}' \
  --output table

Kolom Reason dan Description akan menjelaskan mengapa instance dianggap unhealthy oleh load balancer — misalnya Target.ResponseCodeMismatch atau Target.Timeout.

Langkah 4: Periksa Konfigurasi Health Check di Target Group

Verifikasi endpoint, protocol, port, dan success code yang dikonfigurasi di target group. Mismatch di sini adalah penyebab yang sangat umum — terutama ketika aplikasi berjalan di port non-standard atau path health check tidak ada.

aws elbv2 describe-target-groups \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/nama-target-group/1234567890abcdef \
  --region us-east-1 \
  --query 'TargetGroups[0].{Protocol:HealthCheckProtocol,Port:HealthCheckPort,Path:HealthCheckPath,Interval:HealthCheckIntervalSeconds,Timeout:HealthCheckTimeoutSeconds,HealthyThreshold:HealthyThresholdCount,UnhealthyThreshold:UnhealthyThresholdCount,Matcher:Matcher}' \
  --output json

Langkah 5: Periksa EC2 Instance Status Checks

Jika activity history menunjukkan EC2 health check sebagai penyebab, periksa status check EC2 langsung. Ini membedakan antara masalah hardware/hypervisor (system status check) dan masalah OS/software (instance status check).

aws ec2 describe-instance-status \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1 \
  --query 'InstanceStatuses[0].{InstanceState:InstanceState.Name,SystemStatus:SystemStatus.Status,InstanceStatus:InstanceStatus.Status,SystemDetails:SystemStatus.Details,InstanceDetails:InstanceStatus.Details}' \
  --output json
graph TD START(["Instance diterminasi ASG"]) START --> Q1{"Cek Activity History aws autoscaling describe-scaling-activities"} Q1 -->|"EC2 health check failed"| Q2{"Cek EC2 Status Check aws ec2 describe-instance-status"} Q1 -->|"ELB health check failed"| Q3{"Cek Target Group Health aws elbv2 describe-target-health"} Q1 -->|"Tidak jelas"| Q4["Cek HealthCheckType di ASG aws autoscaling describe-auto-scaling-groups"] Q2 -->|"System status impaired"| FIX1["Masalah infrastruktur AWS Stop & Start instance untuk migrasi host"] Q2 -->|"Instance status impaired"| FIX2["Masalah OS/software Periksa log sistem di dalam instance"] Q3 -->|"Target.Timeout"| FIX3["Periksa Security Group Apakah LB bisa reach instance?"] Q3 -->|"Target.ResponseCodeMismatch"| FIX4["Periksa konfigurasi Matcher di target group atau fix response aplikasi"] Q3 -->|"Initial health checks failed"| FIX5["Grace period terlalu pendek Update health-check-grace-period di ASG"]

Kapan Harus Mengubah Health Check Type ke ELB

Pertanyaan aslinya — 'haruskah saya ganti ke ELB health check?' — jawabannya bergantung pada apa yang ingin kamu deteksi.

Gunakan ELB health check jika:

  • ASG kamu terhubung ke Application Load Balancer atau Network Load Balancer
  • Kamu perlu mendeteksi kegagalan aplikasi (crash, deadlock, OOM yang membuat app tidak merespons) dan ingin ASG otomatis mengganti instance tersebut
  • EC2 instance bisa berstatus 'running' tapi aplikasi di dalamnya tidak melayani traffic

Tetap gunakan EC2 health check saja jika:

  • ASG tidak terhubung ke load balancer (misalnya worker/batch processing)
  • Kamu belum siap mengkonfigurasi grace period yang tepat dan endpoint health check yang stabil

Mengaktifkan ELB health check tanpa grace period yang memadai akan menciptakan masalah baru yang lebih sulit di-debug daripada masalah asal.

Mengaktifkan ELB Health Check dengan Konfigurasi yang Benar

Langkah 1: Tentukan Grace Period yang Tepat

Grace period harus lebih panjang dari waktu startup aplikasi yang paling lambat. Ukur waktu dari instance launch sampai aplikasi siap merespons health check — termasuk waktu boot OS, pull image (jika pakai container), dan inisialisasi aplikasi. Tambahkan buffer sekitar 20-30%.

Langkah 2: Pastikan Endpoint Health Check Tersedia

Endpoint yang dikonfigurasi di target group harus mengembalikan response code yang sesuai tanpa autentikasi. Path /health atau /ping yang hanya mengecek apakah proses berjalan (bukan dependency eksternal) adalah pilihan yang lebih stabil daripada endpoint yang bergantung pada koneksi database.

Langkah 3: Update Health Check Type di ASG

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name nama-asg-kamu \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --region us-east-1

Nilai 300 di atas adalah contoh — sesuaikan dengan waktu startup aktual aplikasi kamu yang sudah diukur di langkah sebelumnya.

Langkah 4: Verifikasi Konfigurasi Setelah Update

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names nama-asg-kamu \
  --region us-east-1 \
  --query 'AutoScalingGroups[0].{HealthCheckType:HealthCheckType,HealthCheckGracePeriod:HealthCheckGracePeriod}' \
  --output json

Kasus Nyata: Salah Diagnosis yang Hampir Bikin Pusing Semalam Suntuk

Skenario yang sering terjadi di production: tim mendapati ASG terus mengganti instance setiap 8-10 menit. Activity history menunjukkan 'Instance failed ELB health checks'. Asumsi pertama: ada bug di aplikasi yang menyebabkan crash.

Setelah masuk ke instance dan mengecek log aplikasi — semua normal, tidak ada error. Aplikasi merespons dengan baik jika di-curl langsung dari dalam instance. Tapi target group tetap melaporkan unhealthy.

Penyebab sebenarnya: security group pada instance tidak mengizinkan inbound traffic dari load balancer pada port health check. Load balancer tidak bisa mencapai endpoint health check, sehingga melaporkan timeout sebagai unhealthy. Instance berjalan sempurna, aplikasi berjalan sempurna, tapi koneksi antara load balancer dan instance diblokir di lapisan network.

Perbaikannya: tambahkan inbound rule di security group instance untuk mengizinkan traffic dari security group load balancer pada port aplikasi.

# Cek security group yang terhubung ke instance
aws ec2 describe-instances \
  --instance-ids i-1234567890abcdef0 \
  --region us-east-1 \
  --query 'Reservations[0].Instances[0].SecurityGroups' \
  --output json

# Tambahkan inbound rule dari security group load balancer
aws ec2 authorize-security-group-ingress \
  --group-id sg-instance-security-group-id \
  --protocol tcp \
  --port 8080 \
  --source-group sg-loadbalancer-security-group-id \
  --region us-east-1

Pelajarannya: ELB health check failure tidak selalu berarti aplikasi bermasalah. Bisa jadi network path antara load balancer dan instance yang terputus.

IAM Permission yang Dibutuhkan untuk Diagnosis

Untuk menjalankan semua perintah diagnosis di atas, pastikan IAM principal kamu memiliki permission berikut:

🔽 Klik untuk melihat IAM policy diagnosis ASG health check 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ASGHealthCheckDiagnosis",
      "Effect": "Allow",
      "Action": [
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeScalingActivities",
        "autoscaling:UpdateAutoScalingGroup",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeTargetHealth",
        "ec2:DescribeInstanceStatus",
        "ec2:DescribeInstances",
        "ec2:DescribeSecurityGroups",
        "ec2:AuthorizeSecurityGroupIngress"
      ],
      "Resource": "*"
    }
  ]
}

Perlu dicatat: beberapa action di atas seperti DescribeAutoScalingGroups dan DescribeInstanceStatus memerlukan "Resource": "*" karena tidak mendukung resource-level permission. Verifikasi selalu di AWS Service Authorization Reference sebelum menerapkan di production.

Wrap-Up: ASG Health Check dan Langkah Selanjutnya

Mengubah ASG health check type ke ELB adalah langkah yang tepat jika kamu ingin ASG mendeteksi kegagalan aplikasi — bukan hanya kegagalan infrastruktur. Tapi perubahan ini hanya efektif jika tiga kondisi terpenuhi: grace period cukup panjang untuk startup aplikasi, endpoint health check stabil dan tidak bergantung pada dependency eksternal yang flaky, dan network path antara load balancer dan instance tidak diblokir.

Jika instance masih diterminasi setelah mengaktifkan ELB health check dengan konfigurasi yang benar, mulai dari activity history ASG — bukan dari asumsi tentang aplikasi.

Referensi resmi untuk topik ini:

Glossary

Istilah Penjelasan
Health Check Grace Period Durasi waktu (dalam detik) setelah instance launch di mana ASG tidak akan menterminasi instance berdasarkan hasil health check, memberikan waktu untuk startup aplikasi.
EC2 Status Check Pemeriksaan otomatis oleh AWS terhadap kondisi hardware dan software instance. Terdiri dari system status check (infrastruktur AWS) dan instance status check (OS dan software).
Target Group Health Check Probe yang dilakukan load balancer ke endpoint yang dikonfigurasi untuk menentukan apakah instance siap menerima traffic.
Activity History Log dari semua aktivitas scaling di ASG, termasuk alasan terminasi dan launch instance.
Launch Template Konfigurasi yang mendefinisikan parameter instance baru yang diluncurkan oleh ASG, termasuk AMI, instance type, security group, dan user data.

Related Posts

Komentar

Posting Komentar

Postingan populer dari blog ini

EC2 Tidak Bisa Akses Internet di Custom VPC: Cara Pasang Internet Gateway dan Update Route Table

Kamu baru saja membuat custom VPC, meluncurkan EC2 instance di public subnet, lalu mencoba ping google.com — dan tidak ada respons sama sekali. Ini adalah salah satu jebakan paling umum saat pertama kali bekerja dengan EC2 no internet access di custom VPC , dan penyebabnya hampir selalu kombinasi dari tiga hal: tidak ada Internet Gateway, route table yang belum diupdate, atau Security Group yang memblokir traffic. TL;DR: Checklist EC2 Tidak Bisa Internet di Custom VPC Komponen Yang Harus Dicek Kondisi Benar Internet Gateway Sudah dibuat dan di-attach ke VPC State: attached Route Table Ada route 0.0.0.0/0 ke IGW Target: igw-xxxxxxxx Subnet Association Public subnet terhubung ke route table yang benar Subnet ID muncul di associations Security Group Inbound HTTP/HTTPS/ICMP diizinkan Rule eksplisit untuk port 80, 443, atau ICMP Public IP Instance punya public IP atau Elastic IP PublicIpAddress tidak n...
Baca selengkapnya