Analogi dulu agar konsep HA dan scaling terasa nyata.

Bayangkan aplikasi web seperti restoran populer yang tiba-tiba ramai saat jam makan siang.

Jika semua pelanggan hanya masuk lewat satu pintu dan dilayani satu dapur, antrean panjang akan muncul. Jika dapur itu bermasalah, seluruh restoran berhenti. Solusinya bukan hanya membuat pintu lebih besar, tetapi menambah beberapa pintu, beberapa dapur, dan petugas penerima tamu yang membagi pelanggan ke dapur yang masih sehat.

Di AWS, petugas penerima tamu itu mirip Elastic Load Balancing (ELB). Ia menerima request pengguna lalu mengarahkannya ke target yang sehat, misalnya beberapa EC2 instance. Tim manajer dapur yang menambah atau mengurangi jumlah koki sesuai ramai sepinya restoran mirip Auto Scaling Group (ASG). ASG menjaga jumlah EC2 instance sesuai kebutuhan, mengganti yang rusak, dan membantu biaya tetap masuk akal.

Mengapa dua hal ini selalu muncul bersama? Karena keduanya memecahkan dua masalah yang berbeda namun saling melengkapi. ELB menjawab pertanyaan “request ini harus dikirim ke mesin yang mana?”, sedangkan ASG menjawab “berapa banyak mesin yang harus hidup saat ini?”. Resepsionis tanpa staf yang cukup akan kewalahan, dan staf yang banyak tanpa resepsionis akan duduk menganggur tanpa tahu siapa yang harus dilayani. Itu sebabnya pola ELB + ASG menjadi resep standar aplikasi web yang tahan banting.

Modul ini penting untuk CLF-C02 karena menyentuh nilai utama cloud, yaitu aplikasi yang lebih tersedia, dapat bertumbuh mengikuti permintaan, dan tidak perlu membayar kapasitas berlebih sepanjang waktu. Sebagian besar materi di sini termasuk Domain 3, Cloud Technology and Services (34% soal), dengan sentuhan Domain 1 (konsep HA dan elasticity) dan Domain 2 (security group dan shared responsibility). Rujukan resmi utama: AWS Exam Guide CLF-C02, Elastic Load Balancing Documentation, dan Amazon EC2 Auto Scaling Documentation.

Tiga kata yang sering terdengar mirip, tetapi maknanya berbeda.

Sebelum membahas ELB dan ASG, pisahkan dulu tiga konsep inti yang sering muncul di soal.

High Availability (HA) fokus pada bertahan saat ada gangguan. Jika satu EC2 instance atau satu Availability Zone bermasalah, aplikasi tidak langsung mati karena ada instance lain di tempat lain. Untuk pemula, pikirkan HA sebagai rencana cadangan yang sudah aktif, bukan rencana darurat yang baru dicari saat masalah terjadi. Kuncinya ada pada redundansi: kalau hanya ada satu salinan, tidak ada cadangan saat salinan itu jatuh.

Scalability fokus pada kemampuan tumbuh. Ada dua pola besar. Vertical scaling (scale up) berarti menaikkan ukuran mesin, misalnya dari instance kecil ke instance lebih besar, mirip mengganti motor dengan truk agar muat lebih banyak. Horizontal scaling (scale out) berarti menambah jumlah mesin, misalnya dari dua EC2 instance menjadi empat, mirip menambah armada motor. ELB dan ASG dirancang untuk pola horizontal scaling, karena menambah banyak mesin kecil yang identik lebih tahan gangguan daripada bergantung pada satu mesin besar yang menjadi titik kegagalan tunggal.

Elasticity fokus pada pas dengan kebutuhan. Saat traffic naik, kapasitas bertambah otomatis. Saat traffic turun, kapasitas berkurang otomatis. Perhatikan kata “otomatis” dan “naik turun” itu, di situlah elasticity berbeda dari scalability. Scalability cukup berarti “bisa diperbesar”, sedangkan elasticity berarti “menyesuaikan diri, naik dan turun, tanpa campur tangan manual”. Inilah alasan cloud sering lebih efisien daripada membeli server untuk skenario teramai sepanjang tahun, kamu tidak membayar kapasitas puncak saat sedang sepi.

Satu titik masuk untuk banyak target di belakangnya.

Elastic Load Balancing adalah layanan terkelola yang membagi traffic masuk ke beberapa target yang sehat di satu atau lebih Availability Zone.

Secara sederhana, pengguna tidak perlu tahu ada berapa server di belakang aplikasi. Mereka mengakses satu nama DNS load balancer. ELB menerima traffic, memeriksa target yang tersedia, lalu meneruskan request ke target yang sehat. Target dapat berupa EC2 instance, container, alamat IP, atau Lambda, tergantung tipe load balancer. Karena ELB adalah layanan terkelola, AWS yang menjaga ketersediaan dan skala load balancer itu sendiri, sehingga kamu tidak perlu mengelola server load balancer secara manual.

Menurut dokumentasi AWS, ELB mendistribusikan incoming traffic ke berbagai target dalam satu atau lebih Availability Zone, memantau kesehatan target, dan mengirim traffic hanya ke target yang sehat. Ini membuat ELB menjadi komponen penting untuk aplikasi yang membutuhkan ketersediaan dan skalabilitas. Karena ELB hidup di banyak AZ sekaligus, ia juga ikut menyediakan high availability di lapisan pintu masuk, bukan hanya di lapisan server.

Komponen inti ELB

Cara mudah merangkainya: listener adalah pintu yang dijaga (port mana yang dibuka), rule adalah aturan di pintu itu (request seperti apa diarahkan ke mana), dan target group adalah ruangan tujuan berisi server. Satu load balancer bisa punya beberapa listener, satu listener bisa punya beberapa rule, dan satu rule mengarah ke satu target group. Health check dikonfigurasi di level target group, bukan di level load balancer, jadi tiap kelompok server bisa punya kriteria sehat yang berbeda.

Kenapa ELB penting?

Tanpa ELB, pengguna mungkin diarahkan langsung ke satu EC2 instance. Jika instance itu mati, pengguna gagal mengakses aplikasi, dan kamu harus mengganti alamat IP atau DNS secara manual saat menambah server. Dengan ELB, traffic otomatis dialihkan ke instance sehat saat satu instance jatuh, dan kamu bisa menambah atau melepas target di belakangnya tanpa mengubah alamat akses pengguna. ELB juga menjadi tempat yang nyaman untuk menaruh sertifikat TLS dan menyatukan logging traffic.

Pilih berdasarkan jenis traffic dan kebutuhan aplikasi.

AWS memiliki beberapa jenis load balancer, dan CLF-C02 biasanya menguji kapan masing-masing digunakan secara garis besar.

Cara tercepat memahami perbedaannya adalah lewat lapisan jaringan tempat ia bekerja, sering disebut OSI layer. Layer 7 (application layer) memahami isi request seperti URL dan header HTTP, sementara Layer 4 (transport layer) hanya melihat koneksi, port, dan paket tanpa membaca isinya. Semakin tinggi layer, semakin pintar routing-nya, tetapi semakin rendah layer, semakin cepat dan ringan pemrosesannya.

ALB bekerja di layer aplikasi, sehingga bisa melihat informasi request HTTP, misalnya path /api, host admin.example.com, atau header tertentu. Karena itu ALB cocok saat satu load balancer perlu mengarahkan traffic ke layanan berbeda berdasarkan isi request. ALB juga bisa meneruskan request ke fungsi Lambda, bukan hanya ke EC2.

NLB bekerja lebih dekat ke level jaringan. Ia cocok untuk koneksi TCP, UDP, atau TLS yang membutuhkan throughput tinggi dan latensi rendah, dan mampu menangani jutaan request per detik. Karena tidak membaca isi request, NLB jauh lebih ringan dan bisa memberi IP statis per Availability Zone serta penetapan Elastic IP, sesuatu yang tidak ditawarkan ALB. Pada level Cloud Practitioner, cukup pahami bahwa NLB bukan untuk routing path HTTP yang kaya seperti ALB.

GWLB sering muncul dalam skenario keamanan jaringan. Jika soal menyebut virtual appliance, firewall pihak ketiga, sistem inspeksi traffic (IDS/IPS), atau appliance fleet yang perlu diskalakan, pikirkan Gateway Load Balancer. GWLB bekerja sebagai gateway di Layer 3 yang meneruskan paket ke armada appliance, lalu menyeimbangkannya di Layer 4.

ALB vs NLB, perbandingan yang paling sering ditanya

Dua tipe ini paling sering muncul di soal, dan paling sering tertukar. ALB pintar tetapi sedikit lebih “berat” karena membaca isi request, sedangkan NLB cepat dan ringan tetapi tidak memahami konten HTTP. Pegang perbedaan layer-nya, dari situ semua perbedaan lain mengalir.

ALB adalah tipe ELB yang paling sering dipakai untuk aplikasi web.

ALB menerima request HTTP atau HTTPS, mengevaluasi listener rules berdasarkan prioritas, lalu meneruskan request ke target group yang sesuai.

Bayangkan sebuah situs e-commerce. Request ke /catalog diarahkan ke service katalog, request ke /checkout diarahkan ke service pembayaran, dan request ke /admin diarahkan ke service admin. Dengan ALB, pola ini dapat dibuat menggunakan rule yang membaca isi request. Inilah yang membuat ALB cocok untuk microservices: satu pintu masuk, banyak layanan di belakang, dipisahkan oleh aturan routing, bukan oleh banyak load balancer terpisah.

Algoritma routing

Setelah rule menentukan target group, ALB harus memilih target spesifik di dalamnya. ALB mendukung dua algoritma yang diatur di level target group. Round robin (default) membagi request bergiliran secara merata ke tiap target. Least outstanding requests mengirim request baru ke target yang sedang menangani paling sedikit request yang belum selesai, berguna saat durasi request sangat bervariasi sehingga beban tidak menumpuk di satu target. Untuk CLF-C02, cukup ingat bahwa ALB tidak hanya round robin, ada alternatif least outstanding requests.

Health check

Health check adalah pemeriksaan berkala untuk memastikan target masih bisa melayani request, dan dikonfigurasi per target group. Misalnya ALB memanggil endpoint /health secara berkala. Jika endpoint gagal berulang kali melewati ambang yang ditentukan, target ditandai unhealthy dan tidak lagi menerima traffic sampai pulih. Inilah mekanisme yang membuat satu instance rusak tidak menyeret seluruh aplikasi.

TLS termination

Pada HTTPS listener, ALB dapat menangani sertifikat SSL/TLS di sisi load balancer. Ini sering disebut TLS termination atau SSL offload. Aplikasi di belakangnya dapat lebih fokus pada logika bisnis, sementara ALB menangani bagian koneksi aman dari client dan beban kriptografi. Sertifikat biasanya dikelola lewat AWS Certificate Manager (ACM), sehingga perpanjangan sertifikat tidak perlu dilakukan manual.

ASG menjaga jumlah EC2 instance sesuai kapasitas yang diinginkan.

Auto Scaling Group adalah kelompok EC2 instance yang dikelola sebagai satu unit untuk menjaga kapasitas, kesehatan, dan scaling.

ASG menggunakan launch template sebagai resep membuat instance baru. Resep ini dapat berisi AMI, instance type, security group, key pair, user data, dan konfigurasi lain yang dibutuhkan instance. Saat ASG perlu menambah instance, ia menggunakan resep tersebut agar setiap instance baru konsisten dan identik. Tanpa resep standar, setiap server baru bisa berbeda konfigurasi dan menyebabkan bug yang sulit dilacak.

Launch template vs launch configuration

Dahulu ada dua cara mendefinisikan resep instance: launch template (baru, direkomendasikan) dan launch configuration (lama). Untuk CLF-C02, ingat bahwa launch template adalah pilihan modern dan satu-satunya pilihan untuk fitur baru. Launch configuration sudah sangat dibatasi, dan akun yang dibuat sejak 1 Oktober 2024 tidak dapat membuat launch configuration dengan cara apa pun. AWS merekomendasikan migrasi dari launch configuration ke launch template. Lihat Launch templates dan Launch configurations.

Jika desired capacity adalah tiga, ASG berusaha menjaga tiga instance berjalan. Jika satu instance gagal health check, ASG menghentikannya dan meluncurkan pengganti agar tetap tiga. Jika scaling policy menaikkan desired capacity menjadi lima, ASG menambah instance baru sampai jumlah yang diinginkan tercapai, tetapi tidak akan pernah melampaui maximum. Sebaliknya, scale-in tidak akan menurunkan instance di bawah minimum. Minimum dan maximum adalah pagar pengaman, desired adalah angka yang dijaga di antara keduanya.

Health check dan penggantian instance

ASG mendukung dua sumber health check. EC2 health check memeriksa status instance dari sisi infrastruktur EC2. ELB health check memakai hasil health check dari load balancer, sehingga instance yang aplikasinya rusak (walau instance-nya menyala) tetap dianggap unhealthy. Jika ASG mendeteksi instance unhealthy, ia menghentikannya dan meluncurkan pengganti untuk mempertahankan desired capacity, tanpa perlu intervensi manual. Inilah yang membuat aplikasi bisa “menyembuhkan diri”.

ASG bukan load balancer

ASG mengatur jumlah instance, bukan membagi request pengguna. Untuk aplikasi web yang melayani traffic publik, ASG biasanya dipasangkan dengan ELB. ELB membagi traffic ke target sehat, ASG menjaga jumlah instance yang tersedia di belakangnya. Ini perbedaan yang paling sering jadi jebakan ujian, jadi tanamkan baik-baik.

ELB melihat target sehat, ASG menjaga target tetap cukup.

Kombinasi ELB dan ASG adalah pola klasik untuk aplikasi web yang tersedia dan elastis.

Alur tingkat tinggi biasanya seperti ini. Pengguna mengakses DNS ALB. ALB menerima request dan memilih target group. Target group berisi EC2 instance yang didaftarkan oleh ASG. Health check memastikan hanya instance sehat yang menerima request. CloudWatch metric, seperti CPU utilization atau request per target, dapat memicu ASG menambah atau mengurangi instance.

Pendaftaran otomatis ke target group

Inilah bagian yang membuat keduanya begitu rapi bekerja bersama. Saat ASG yang terhubung ke ALB atau NLB meluncurkan instance baru, instance itu otomatis didaftarkan ke target group, dan saat instance diterminasi, ia otomatis dideregister. Kamu tidak perlu mendaftarkan atau melepas target secara manual setiap kali kapasitas berubah. ASG mengurus jumlah, target group mengurus keanggotaan, dan ELB mengurus distribusi traffic, semuanya tanpa langkah manual berulang.

Walkthrough ringan tanpa masuk terlalu dalam ke konfigurasi Solutions Architect.

Tujuan walkthrough ini adalah memahami alur, bukan menghafal semua tombol console.

Checklist mental saat hands-on

• ALB berada di subnet yang tepat dan dapat diakses sesuai kebutuhan, internet-facing atau internal.
• Security group ALB mengizinkan traffic dari client, security group EC2 mengizinkan traffic dari ALB.
• Health check path benar, cepat dijawab, dan tidak bergantung pada komponen yang tidak perlu.
• ASG memakai subnet di beberapa Availability Zone untuk mendukung high availability.
• ASG di-attach ke target group sehingga instance baru otomatis terdaftar dan instance lama otomatis dilepas.
• Minimum, desired, dan maximum capacity masuk akal untuk skenario latihan.

Dari manual sampai prediktif, pahami kapan masing-masing masuk akal.

EC2 Auto Scaling menyediakan empat kategori scaling, dari paling sederhana sampai paling cerdas.

Penting membedakan kategori dengan sub-tipenya. Ada empat kategori: manual scaling, scheduled scaling, dynamic scaling, dan predictive scaling. Dynamic scaling sendiri terdiri dari tiga sub-tipe: target tracking, step scaling, dan simple scaling. Jangan mencampur kategori dengan sub-tipe saat membaca soal.

Dynamic scaling: target tracking

Target tracking adalah strategi yang paling mudah dipahami dan direkomendasikan AWS sebagai titik awal. Kamu memberi satu target, misalnya rata-rata CPU sekitar nilai tertentu, lalu ASG menambah atau mengurangi instance agar metric mendekati target itu. Dokumentasi AWS memakai analogi thermostat, seperti AC yang menjaga suhu ruangan tetap dekat dengan angka yang kamu pilih, kamu set target, sisanya diurus otomatis.

Dynamic scaling: step scaling dan simple scaling

Step scaling dan simple scaling menggunakan CloudWatch alarm. Simple scaling melakukan satu penyesuaian tunggal saat alarm menyala, lalu menunggu cooldown period sebelum bereaksi lagi. Step scaling memberi kontrol lebih rinci dengan step adjustment sesuai seberapa besar pelanggaran ambang: lonjakan kecil menambah sedikit instance, lonjakan besar menambah lebih banyak. Step scaling tidak menunggu cooldown kaku seperti simple scaling, sehingga lebih responsif terhadap lonjakan tajam.

Predictive scaling

Predictive scaling menganalisis data histori load untuk mendeteksi pola harian atau mingguan, lalu proaktif menambah kapasitas sebelum lonjakan yang diperkirakan terjadi. Ini berbeda dari dynamic scaling yang bersifat reaktif (menunggu metric naik dulu baru bertindak). Predictive scaling sangat cocok untuk workload cyclical, misalnya traffic yang selalu melonjak setiap pagi hari kerja. Keduanya sering dipakai bersama: predictive untuk menyiapkan kapasitas dasar sesuai pola, dynamic untuk menangani lonjakan tak terduga di atasnya.

Kapan memilih yang mana?

Logika memilihnya begini. Jika kamu tahu persis kapan beban naik, scheduled scaling paling sederhana dan pasti. Jika kamu tidak tahu kapan tepatnya tetapi tahu ada pola berulang, predictive scaling membiarkan AWS menebak dari histori. Jika kamu hanya ingin menjaga sebuah metric tetap di target tanpa memikirkan jadwal, target tracking yang paling pas. Untuk lonjakan tak terduga di luar pola, dynamic scaling (target tracking atau step scaling) yang menangani secara reaktif.

Cooldown dan warmup

Instance baru butuh waktu untuk siap menerima beban. Jika ASG terlalu cepat mengambil keputusan sebelum instance siap, sistem bisa menambah atau mengurangi kapasitas secara berlebihan dan berosilasi. Karena itu konsep cooldown, instance warmup, dan health check grace period penting di praktik, walau pada CLF-C02 cukup dipahami sebagai mekanisme agar scaling tidak panik dan tidak bereaksi berlebihan.

Bagian ini mengubah pengalaman praktik menjadi pola jawab ujian.

Banyak jawaban salah terjadi karena mencampur fungsi ELB, ASG, Route 53, dan CloudFront.

Jebakan pilihan layanan

• Jika soal menyebut membagi traffic HTTP ke beberapa EC2 instance di beberapa Availability Zone, pikirkan ALB.
• Jika soal menyebut menjaga jumlah EC2 instance otomatis sesuai demand, pikirkan ASG.
• Jika soal menyebut DNS, domain, dan routing pengguna ke endpoint, pikirkan Route 53, bukan ASG.
• Jika soal menyebut caching konten global di edge location, pikirkan CloudFront, bukan ELB.
• Jika soal menyebut firewall appliance atau inspection appliance yang perlu diskalakan, pikirkan Gateway Load Balancer.
• Jika soal menyebut butuh IP statis atau Elastic IP untuk load balancer performa tinggi, pikirkan NLB.

Jebakan keamanan

ELB dan ASG tetap berada dalam shared responsibility model. AWS mengelola infrastruktur layanan, tetapi pelanggan tetap mengatur security group, subnet, sertifikat, kebijakan akses, patching aplikasi di EC2, dan desain yang benar. Untuk ujian, jangan memilih jawaban yang membuat EC2 backend terbuka langsung ke internet bila cukup menerima traffic dari load balancer.

Peta cepat untuk mengingat Chapter 04 sebelum latihan soal.

ELB dan ASG adalah pasangan penting untuk aplikasi EC2 yang tersedia, dapat diskalakan, dan lebih elastis.

Pemetaan ke domain CLF-C02

Tips menjawab soal

• Jika ada kata “distribute traffic” dan “healthy targets”, jawabannya sering mengarah ke Elastic Load Balancing.
• Jika ada kata “automatically add or remove EC2 instances”, jawabannya sering mengarah ke Auto Scaling Group.
• Jika aplikasi web butuh routing /api dan /images ke service berbeda, pilih Application Load Balancer.
• Jika traffic bukan HTTP dan butuh performa jaringan tinggi atau IP statis, pertimbangkan Network Load Balancer.
• Jika ingin tetap tersedia saat satu instance rusak, kombinasikan health check, multi-AZ, ELB, dan ASG.
• Jika soal menekankan biaya saat traffic turun, cari konsep elasticity atau scale-in.