Setup Auto Scaling Group di AWS: Konfigurasi Launch Template dan Load Balancer

Memahami Konsep Auto Scaling dan Mengapa Kita Membutuhkannya

Ketika sebuah aplikasi mulai menerima traffic yang fluktuatif, menjalankan satu server EC2 secara statis bukanlah solusi yang ideal. Bayangkan sebuah situs e-commerce yang mengalami lonjakan pengunjung saat flash sale — server tunggal pasti kewalahan. Sebaliknya, di jam sepi, server tersebut hanya berjalan idle dengan resource terbuang percuma.

Auto Scaling Group (ASG) hadir untuk menyelesaikan masalah ini. ASG adalah layanan AWS yang secara otomatis menambah atau mengurangi jumlah instance EC2 berdasarkan kebutuhan. Ketika traffic meningkat, ASG meluncurkan instance baru. Ketika traffic menurun, ASG menghentikan instance yang tidak diperlukan. Semua ini terjadi tanpa intervensi manual.

ASG bekerja dengan tiga komponen utama. Launch Template berfungsi sebagai blueprint yang menentukan konfigurasi setiap instance — AMI, instance type, security group, dan user data. Elastic Load Balancer (ELB) mendistribusikan traffic masuk ke seluruh instance yang sehat. Scaling Policy mendefinisikan aturan kapan ASG harus menambah atau mengurangi instance.

Arsitektur dasarnya sederhana: pengguna mengirim request ke load balancer, load balancer meneruskan ke instance EC2 yang terdaftar di target group, dan ASG memastikan jumlah instance selalu berada dalam rentang yang telah ditentukan.

Gambar: Infrastruktur server dan jaringan di data center modern — Sumber: [Unsplash/Taylor Vick](https://unsplash.com/photos/M5tzZtFCOfs)

Membuat Launch Template sebagai Blueprint Instance EC2

Launch Template adalah fondasi dari Auto Scaling Group. Template ini mendefinisikan konfigurasi standar untuk setiap instance EC2 yang akan diluncurkan oleh ASG. AWS sebelumnya mendukung Launch Configuration, tetapi Launch Template menawarkan fleksibilitas lebih baik dengan dukungan versioning, parameter yang lebih lengkap, dan integrasi yang lebih erat dengan layanan AWS lainnya.

Beberapa parameter penting dalam Launch Template meliputi AMI ID (sistem operasi dan software bawaan), instance type (ukuran CPU dan memory), key pair (akses SSH), security group (firewall rules), IAM instance profile (izin akses ke layanan AWS lain), dan user data (script bootstrap yang dijalankan saat instance pertama kali lahir).

Mari kita buat Launch Template menggunakan AWS CLI:

aws ec2 create-launch-template \
  --launch-template-name web-app-template \
  --launch-template-data '{
    "ImageId": "ami-0c55b159cbfafe1f0",
    "InstanceType": "t3.micro",
    "KeyName": "my-key-pair",
    "SecurityGroups": ["web-sg"],
    "IamInstanceProfile": {"Name": "ec2-s3-readonly"},
    "UserData": "'$(echo '#!/bin/bash
yum update -y
yum install -y httpd
systemctl enable httpd
systemctl start httpd
echo "<h1>Web App - Instance $(hostname -f)</h1>" > /var/www/html/index.html' | base64 -w0)'"
  }'

Perhatikan bagian User Data pada kode di atas. Script bash yang dienkode dalam base64 akan menjalankan instalasi Apache HTTP Server, mengaktifkannya sebagai service, dan menulis halaman HTML sederhana yang menampilkan hostname instance. Ini memastikan setiap instance baru langsung siap melayani traffic tanpa konfigurasi manual tambahan.

Launch Template mendukung versioning, artinya kita bisa membuat versi baru saat ada perubahan konfigurasi tanpa mengganggu template yang sudah digunakan oleh ASG yang sedang berjalan. Setiap kali menjalankan perintah di atas, AWS mengembalikan sebuah Launch Template ID (misalnya lt-0123456789abcdef0) yang akan kita gunakan saat membuat ASG.

Mengonfigurasi Auto Scaling Group dengan Load Balancer

Setelah Launch Template siap, langkah berikutnya adalah membuat Auto Scaling Group dan menghubungkannya ke Application Load Balancer (ALB). ALB berperan sebagai entry point tunggal yang mendistribusikan traffic secara merata ke seluruh instance di belakangnya.

Pertama, kita perlu membuat Target Group yang akan menjadi penghubung antara ALB dan instance EC2:

aws elbv2 create-target-group \
  --name web-target-group \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-12345678 \
  --health-check-path / \
  --health-check-interval-seconds 30

aws elbv2 create-load-balancer \
  --name web-alb \
  --subnets subnet-abc subnet-def \
  --security-groups alb-sg

# Catat ARN target group dan ALB dari output perintah di atas

Selanjutnya, kita buat Auto Scaling Group yang menggunakan Launch Template dan terhubung ke Target Group:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template LaunchTemplateName=web-app-template,Version='$Default' \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/web-target-group/abc123 \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --min-size 2 \
  --max-size 6 \
  --desired-capacity 2 \
  --vpc-zone-identifier "subnet-abc,subnet-def" \
  --tags Key=Name,Value=web-asg-instance,PropagateAtLaunch=true

Beberapa parameter penting pada konfigurasi di atas:

• min-size 2: ASG akan selalu menjaga minimal 2 instance berjalan untuk redundancy.
• max-size 6: ASG tidak akan meluncurkan lebih dari 6 instance untuk mengontrol biaya.
• desired-capacity 2: Jumlah instance awal saat ASG pertama kali aktif.
• health-check-type ELB: ASG menggunakan health check dari ELB, bukan EC2 status check. Ini lebih akurat karena ELB memeriksa respons HTTP aplikasi, bukan hanya status sistem operasi.
• health-check-grace-period 300: Memberikan waktu 300 detik bagi instance baru untuk menyelesaikan bootstrap sebelum health check mulai dievaluasi.

Sekarang kita tambahkan Target Tracking Scaling Policy yang akan menyesuaikan jumlah instance berdasarkan rata-rata CPU utilization:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 60.0
  }'

Dengan kebijakan ini, ASG akan berusaha menjaga rata-rata CPU utilization seluruh instance tetap di sekitar 60%. Jika utilization naik di atas ambang, ASG akan meluncurkan instance baru (scaling out). Jika turun, ASG akan menghentikan instance (scaling in).

Uji Coba Scaling dan Monitoring dengan CloudWatch

Setelah konfigurasi selesai, penting untuk memverifikasi bahwa ASG benar-benar bekerja sesuai harapan. Kita bisa melakukan simulasi beban menggunakan alat stress pada salah satu instance:

# SSH ke instance EC2
ssh -i my-key-pair.pem ec2-user@<instance-ip>

# Install stress tool
sudo amazon-linux-extras install epel -y
sudo yum install stress -y

# Simulasi CPU load - 4 workers selama 600 detik
sudo stress --cpu 4 --timeout 600

Saat stress berjalan, kita bisa memantau metrik ASG melalui CloudWatch:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=AutoScalingGroupName,Value=web-asg \
  --start-time $(date -u -d '-10 minutes' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 60 \
  --statistics Average

Setelah beberapa menit, kita akan melihat CPU utilization rata-rata melonjak di atas 60%. Inilah saatnya ASG bereaksi — meluncurkan instance baru untuk membagi beban. Kita bisa memverifikasi dengan melihat jumlah instance berjalan:

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names web-asg \
  --query 'AutoScalingGroups[0].Instances[*].[InstanceId, LifecycleState, HealthStatus]'

Saat beban simulasi berakhir, CPU utilization akan turun. ASG kemudian akan menjalankan scaling in — menghentikan instance yang tidak diperlukan. Proses ini tidak instan karena ASG menerapkan cooldown period, yaitu waktu tunggu setelah sebuah scaling activity selesai sebelum mengeksekusi aktivitas scaling berikutnya. Cooldown period pada ASG mirip seperti jeda setelah menekan tombol lift — sistem perlu waktu untuk merespon sebelum menerima permintaan baru.

Best Practice Konfigurasi ASG untuk Production

Menerapkan ASG untuk production memerlukan beberapa pertimbangan tambahan agar arsitektur benar-benar resilient dan cost-effective.

Lifecycle Hooks memungkinkan kita menjalankan aksi kustom sebelum instance launch atau terminate. Misalnya, saat instance akan di-terminate, kita bisa menjalankan script untuk melakukan drain koneksi atau memindahkan log ke S3 terlebih dahulu.

Multiple Availability Zones adalah keharusan untuk production. Dengan mendistribusikan instance ke minimal dua Availability Zone (AZ), aplikasi tetap berjalan meskipun satu AZ mengalami gangguan. Saat membuat ASG, pastikan parameter --vpc-zone-identifier mencakup subnet dari AZ yang berbeda.

Mixed Instances Policy memungkinkan ASG menggunakan kombinasi instance On-Demand dan Spot. Instance Spot bisa 60-90% lebih murah, ideal untuk workload yang fault-tolerant. Kita bisa mengatur proporsi, misalnya 30% On-Demand untuk baseline capacity dan 70% Spot untuk fleksibilitas scaling.

Warm Pool adalah fitur yang menjaga instance dalam keadaan stopped tetapi siap untuk digunakan. Instance dalam warm pool sudah memiliki semua konfigurasi dan software terinstall, sehingga saat dibutuhkan, instance bisa langsung aktif dalam hitungan detik, bukan menit. Fitur ini sangat berguna untuk aplikasi yang sensitif terhadap latency scaling.

Dengan kombinasi Launch Template yang terstruktur, Auto Scaling Group yang terkonfigurasi dengan benar, dan load balancer sebagai traffic distributor, arsitektur cloud kita menjadi jauh lebih tangguh. Aplikasi tidak hanya mampu menahan lonjakan traffic, tetapi juga mengoptimalkan biaya dengan menyesuaikan kapasitas secara otomatis.

Tertarik membangun arsitektur AWS production-grade yang scalable dan cost-effective? Program Cloud & DevOps di Rumah Coding membahas studi kasus nyata mulai dari infrastruktur dasar hingga auto scaling dan monitoring — semuanya dengan hands-on project.