Server Load Balancer:FAQ ALB

Spesifikasi instans ALB

ALB tidak mengharuskan Anda memilih spesifikasi instans. Setelah Anda meningkatkan edisi instans ALB, ALB menggunakan fitur VIP automatic scaling untuk mencapai 1 juta QPS per instans tunggal. Untuk detail kinerja instans, lihat Metrik instans.

Mengonversi instans IPv4 dan dual-stack

Tidak.

Anda hanya dapat membuat instans IPv4 baru atau instans dual-stack baru.

Menonaktifkan ping ke VIP ALB

• Untuk instans ALB yang telah ditingkatkan, Anda dapat mengelola lalu lintas akses dengan menggunakan security group. Anda dapat mengonfigurasi aturan masuk di security group instans untuk menolak permintaan ICMP.

• Untuk instans ALB yang belum ditingkatkan, Anda dapat menambahkan EIP yang terkait dengan instans ke Cloud Firewall dan mengonfigurasi kebijakan masuk untuk menolak permintaan ICMP.

Menambah bandwidth publik ALB

Jika tidak ditambahkan ke instans Shared Bandwidth, satu instans ALB yang ditempatkan di dua zona ketersediaan memiliki bandwidth publik puncak default sebesar 400 Mbps.

Menggunakan Paket Transfer Data dengan ALB

• Jika instans ALB menyediakan layanan publik melalui Elastic IP Address (EIP), Anda dapat menggunakan Paket Transfer Data untuk mengimbangi biaya transfer data publik yang dihasilkan oleh EIP tersebut.

• Jika instans ALB menyediakan layanan publik melalui Anycast Elastic IP Address (Anycast EIP), Anda tidak dapat menggunakan Paket Transfer Data untuk mengimbangi biaya transfer data publik yang dihasilkan oleh Anycast EIP tersebut.

Jenis EIP yang didukung

EIP untuk instans ALB privat

Ya.

Jika Anda perlu mengaitkan Elastic IP Address (EIP) dengan ALB yang menghadap privat, Anda dapat mengonversi ALB yang menghadap privat menjadi ALB yang menghadap publik dengan mengubah jenis jaringan instans tersebut. Untuk informasi selengkapnya, lihat Ubah jenis jaringan instans ALB.

Mengubah jenis jaringan dari privat ke publik akan mengaitkan EIP ke instans dan menimbulkan biaya transfer data Internet. Untuk informasi selengkapnya, lihat Penagihan EIP.

Mengganti EIP dengan EIP BGP (Multi-ISP) Pro

Ganti EIP dengan mengubah jenis jaringan instans ALB:

1. Ubah jenis jaringan instans ALB dari publik ke privat untuk melepas kaitan EIP.

2. Ubah kembali jenis jaringan instans ALB dari privat ke publik. Selama proses ini, pilih dua EIP BGP (Multi-ISP) Pro yang telah Anda buat sebelumnya.

Distribusi lalu lintas tidak merata di antara EIP

Masalah ini mungkin disebabkan oleh hal-hal berikut:

• Nama domain layanan salah di-resolve ke satu EIP yang dikaitkan dengan instans, bukan ke nama DNS instans ALB.

• Proxy Lapisan 7, seperti Web Application Firewall (WAF) atau Anti-DDoS, ditempatkan di depan instans ALB. Algoritma back-to-origin proxy tersebut, seperti IP hash, mencegah lalu lintas terdistribusi merata di antara EIP.

• Beberapa klien menyimpan cache rekaman A dari resolusi DNS, sehingga sejumlah besar permintaan terus-menerus dikirim ke EIP yang sama.

Penghapusan DNS untuk ALB

Instans ALB yang telah ditingkatkan mendukung operasi penghapusan dan pemulihan DNS secara default.

Setelah penghapusan DNS selesai, pemeriksaan kesehatan untuk VIP di zona ketersediaan tersebut dihentikan. VIP atau EIP (termasuk alamat IPv4 dan IPv6) di zona ketersediaan tersebut juga dihapus dari resolusi nama domain ALB. Anda tidak dapat hanya menghapus alamat VIP IPv4 atau IPv6 saja.

Lalu lintas publik tinggi pada instans ECS backend

Lalu lintas yang diteruskan oleh instans ALB ke instans Elastic Compute Service (ECS) backend berjalan melalui jaringan internal Virtual Private Cloud (VPC) dan tidak mengonsumsi bandwidth publik instans ECS. Jika lalu lintas publik instans ECS Anda tetap tinggi, biasanya disebabkan oleh salah satu alasan berikut:

• Lalu lintas masuk melewati instans ALB: Nama domain masih di-resolve ke IP publik ECS, atau klien mengakses instans ECS langsung melalui IP publiknya. Akibatnya, instans ALB tidak meneruskan lalu lintas tersebut.

• Permintaan arah keluar dari instans ECS: Aplikasi yang berjalan di instans ECS memulai permintaan eksternal, seperti pembaruan perangkat lunak, unggah log, atau panggilan API eksternal, yang menghasilkan lalu lintas publik arah keluar.

Langkah pemecahan masalah:

1. Verifikasi bahwa nama domain layanan Anda di-resolve ke alamat ALB, bukan ke alamat IP publik ECS.

2. Periksa aturan grup keamanan masuk untuk instans ECS guna memastikan port layanan tidak terbuka untuk publik.

3. Di instans ECS, gunakan iftop atau nethogs untuk mengidentifikasi proses dan alamat tujuan yang mengonsumsi bandwidth publik.

Apakah ALB mendukung pencerminan lalu lintas?

Ya. Untuk informasi selengkapnya, lihat Gunakan Pencerminan Lalu Lintas ALB untuk Pengujian Stres.

Kegagalan mencapai batas QPS pendengar

• Cara kerja: Sistem load balancing menggunakan kluster server untuk melayani setiap instans ALB. Kluster ini mendistribusikan permintaan masuk secara merata di antara server-servernya untuk diteruskan. Oleh karena itu, batas QPS yang Anda tetapkan dalam aturan pengalihan juga tersebar di seluruh server sistem tersebut.

  Batas QPS untuk satu server sistem dihitung menggunakan rumus berikut: Batas QPS per server sistem = Total QPS yang ditetapkan / (N-1). N adalah jumlah server sistem dalam grup pengalihan. Misalnya, jika Anda menetapkan batas QPS untuk aturan pengalihan sebesar 1.000 QPS di konsol dan terdapat 8 server sistem, QPS maksimum untuk satu server sistem adalah 1000/(8-1) = 142 QPS.

• Penyebab: Dengan jumlah koneksi persisten yang sedikit, beberapa server sistem dalam grup pengalihan mungkin tidak menerima koneksi sama sekali. Hal ini dapat mencegah instans ALB mencapai batas QPS.

• Rekomendasi: Tetapkan batas QPS yang wajar untuk aturan pengalihan Anda berdasarkan kebutuhan bisnis. Hal ini memastikan layanan Anda tetap tersedia dan tidak dibatasi secara tak terduga. Untuk informasi selengkapnya tentang cara menetapkan batas QPS dalam aturan pengalihan pendengar, lihat Tambahkan aturan pengalihan.

Batas panjang permintaan

Ruang lingkup waktu pemrosesan ALB

Ya, waktu pemrosesan ALB mencakup waktu untuk menerima data dari klien dan mengirim data ke klien.

Jumlah permintaan maksimum per koneksi persisten

Satu koneksi persisten mendukung maksimal 100 permintaan berurutan. Jika batas ini terlampaui, koneksi akan ditutup secara otomatis.

Batas ini meningkat menjadi 1.000 jika Anda menggunakan pendengar HTTPS dan mengaktifkan HTTP/2.

Batas panjang Client Hello untuk pendengar QUIC

Saat Anda menggunakan pendengar QUIC, ALB memberlakukan panjang minimum untuk Client Hello klien. Paket tersebut harus memiliki panjang minimal 1.024 byte. Jika tidak, ALB akan mengembalikan kesalahan "client hello too small" dan menutup koneksi. Untuk melewati pemeriksaan ini, isi paket Client Hello dengan karakter null hingga memenuhi persyaratan 1.024 byte.

Pertimbangan untuk Ingress ALB

Dalam kebanyakan kasus, jangan ubah secara manual instans ALB yang dibuat oleh ALB Ingress di konsol. Gunakan AlbConfig sebagai sumber kebenaran untuk konfigurasi ALB. Untuk informasi selengkapnya tentang ALB Ingress, lihat Ikhtisar Ingress ALB dan Gunakan Ingress ALB.

Jika Anda melakukan perubahan manual di konsol, perubahan tersebut tidak akan tercermin dalam resource AlbConfig. Sinkronisasi AlbConfig berikutnya akan menimpa perubahan manual tersebut. Hal ini dapat menyebabkan masalah seperti log akses yang dinonaktifkan atau aturan pengalihan yang dihapus.

FAQ lintas asal ALB

Mereferensikan nilai header asli

Untuk Key, masukkan nama header yang ingin Anda tulis. Untuk Value, pilih metode referensi dan masukkan nama header asli yang nilainya ingin Anda referensikan. Dalam contoh berikut, header baru bernama abc-abc ditulis, dan mereferensikan nilai header asli abc. Aturan pengalihan mengekstraksi nilai dari header asli abc dan menetapkannya ke header baru abc-abc.

Kondisi untuk aturan pengalihan ini adalah pencocokan path eksak untuk /. Selain aksi penulisan header, aturan ini juga dikonfigurasi untuk Forward to grup server tertentu dengan bobot 100.

Klien

Saat klien mengirim permintaan menggunakan curl, ia menyertakan header permintaan kustom abc:123456 dengan parameter -H. Server mengembalikan 200 OK. Kode berikut menunjukkan contoh perintah dan outputnya:

curl http://xxx.xxx.174 -v -k -H abc:123456
*   Trying xxx.xxx.174:80...
* Connected to xxx.xxx.174 (xxx.xxx.174) port 80
> GET / HTTP/1.1
> Host: xxx.xxx 174
> User-Agent: curl/8.4.0
> Accept: */*
> abc:123456
>
< HTTP/1.1 200 OK
< Date: Sat, 13 Sep 2025 16:18:38 GMT
< Content-Type: text/html
< Content-Length: 4833
< Connection: keep-alive
< Vary: Accept-Encoding
< Set-Cookie: acw_tc=0a2a24fb17577803180911860e42646551283f5ec94793498a70af97834171;path=/;HttpOnly;Max-Age=1800
< Last-Modified: Fri, 16 May 2014 15:12:48 GMT
< ETag: "53762af0-12e1"
< Accept-Ranges: bytes

Server

GET / HTTP/1.1
RemoteIp: xxx.xxx.xxx.103
Host: xxx.xxx.xxx.174
X-Forwarded-For: xxx.xxx.xxx.103
User-Agent: curl/8.4.0
Accept: */*
abc: 123456
X-Sinfo: on
abc-abc: 123456
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Sat, 13 Sep 2025 16:18:38 GMT
Content-Type: text/html
Content-Length: 4833

Otentikasi timbal balik CA

Instans ALB Edisi Dasar tidak mendukung Otentikasi timbal balik CA. Instans ALB Edisi Standar dan edisi yang diaktifkan WAF mendukung Otentikasi timbal balik CA saat Anda menambahkan Pendengar HTTPS. Jika Anda ingin menggunakan fitur Otentikasi timbal balik CA pada instans ALB Edisi Dasar, silakan tingkatkan edisi instans.

Aturan untuk sertifikat wildcard

Mengunggah sertifikat

No.

ALB menggunakan sertifikat dari SSL Certificates Service Alibaba Cloud. Oleh karena itu, Anda harus mengunggah sertifikat ke Konsol SSL Certificate alih-alih konsol ALB. Untuk informasi selengkapnya, lihat Unggah Sertifikat SSL.

Tanggal kedaluwarsa sertifikat tidak berubah

Masalah ini biasanya terjadi ketika instans ALB Anda terintegrasi dengan WAF 2.0 dalam mode proxy transparan dan sertifikat di WAF belum diperbarui. WAF menyinkronkan sertifikat dari ALB secara berkala. Untuk memicu pembaruan segera, Anda dapat menonaktifkan lalu mengaktifkan kembali pengalihan lalu lintas untuk domain Anda di konsol WAF. Tindakan ini memaksa penyegaran sertifikat. Perhatikan bahwa operasi ini menyebabkan gangguan layanan singkat selama 1 hingga 2 detik.

Memodifikasi konfigurasi pemeriksaan kesehatan

1. Masuk ke Konsol Application Load Balancer (ALB).

2. Di panel navigasi sebelah kiri, pilih ALB > Server Groups.

3. Di halaman Server Groups, temukan grup server target dan klik ID-nya.

4. Di tab Details, di bagian Health Check, klik Modify Health Check.

5. Di kotak dialog Modify Health Check, klik Edit di samping Health Check Settings, modifikasi pengaturan pemeriksaan kesehatan, lalu klik Save.

   Untuk informasi selengkapnya, lihat Pemeriksaan kesehatan ALB.

Kesalahan 502 meskipun pemeriksaan kesehatan berhasil

Hal ini biasanya karena beban pada server backend instans ALB terlalu tinggi. Saat beban pada server backend instans ALB terlalu tinggi, ketidaksesuaian dapat terjadi antara hasil pemeriksaan kesehatan dan hasil permintaan akses. Untuk informasi cara memeriksa beban server backend, lihat Pemecahan masalah dan penanganan masalah beban tinggi pada instans Linux.

Penerusan permintaan saat pemeriksaan kesehatan gagal

Instans ALB tetap meneruskan permintaan berdasarkan algoritma penjadwalan yang dikonfigurasi untuk meminimalkan gangguan layanan. Jika permintaan tidak ditangani seperti yang diharapkan, periksa log Anda untuk kesalahan server backend atau tinjau konfigurasi pemeriksaan kesehatan Anda untuk menemukan masalah. Untuk informasi selengkapnya, lihat Pemecahan masalah kegagalan pemeriksaan kesehatan ALB.

Layanan tidak dapat diakses melalui ALB

Ikuti langkah-langkah berikut untuk mendiagnosis masalah:

1. Verifikasi resolusi nama domain (CNAME): Anda tidak dapat langsung mengakses instans ALB baru menggunakan nama DNS-nya. Anda harus memetakan nama domain kustom Anda ke nama DNS instans ALB menggunakan rekaman CNAME. Gunakan perintah nslookup atau dig untuk memverifikasi resolusi. Untuk informasi selengkapnya, lihat Nama DNS Instans ALB.

2. Verifikasi jenis jaringan instans: Instans ALB jaringan privat hanya dapat diakses dari dalam Virtual Private Cloud (VPC)-nya. Untuk mengaktifkan akses publik, ubah jenis jaringan instans menjadi publik dan kaitkan Elastic IP (EIP). Untuk informasi selengkapnya, lihat Ubah Jenis Jaringan Instans ALB.

3. Verifikasi pendengar dan aturan pengalihan: Di konsol ALB, periksa apakah pendengar telah dibuat dengan port dan protokol yang benar. Juga, pastikan aturan pengalihan dikonfigurasi untuk mencocokkan nama domain dan path permintaan masuk.

4. Verifikasi status pemeriksaan kesehatan: Di konsol ALB, periksa status pemeriksaan kesehatan server backend Anda. Instans ALB tidak akan meneruskan permintaan ke server backend yang tidak sehat.

5. Konfirmasi layanan backend berjalan dengan benar: Masuk ke server backend dan jalankan perintah curl -I http://<IP_private_server_backend>:<port> untuk memastikan layanan backend merespons dengan benar.

6. Verifikasi pengaturan kontrol akses dan firewall: Pastikan pengaturan kontrol akses atau aturan grup keamanan instans ALB mengizinkan rentang alamat IP sumber klien. Juga, pastikan iptables atau perangkat lunak keamanan pihak ketiga di instans Elastic Compute Service (ECS) backend mengizinkan rentang alamat IP lokal instans ALB.

Pemecahan masalah latensi tinggi

ALB beroperasi di lapisan aplikasi, yang berarti permintaan diteruskan ke server backend. Proses ini menimbulkan latensi tambahan kecil dibandingkan dengan mengakses server backend secara langsung. Ini adalah perilaku yang diharapkan.

Jika Anda mengalami latensi yang sangat tinggi, ikuti langkah-langkah berikut untuk memecahkan masalah:

1. Aktifkan log akses dan analisis field latensi: Aktifkan Log Akses ALB dan fokus pada field berikut:

   • request_time: Waktu dalam detik sejak load balancer menerima paket permintaan pertama hingga load balancer mengirim respons.

   • upstream_response_time: Waktu dalam detik sejak load balancer mulai terhubung ke server backend hingga menerima semua data dan menutup koneksi.

2. Identifikasi sumber latensi:

   • Jika upstream_response_time tinggi, server backend kemungkinan besar merupakan sumber latensi. Periksa kinerja aplikasi backend Anda, efisiensi query database Anda, dan penggunaan resource seperti CPU dan memori. Anda juga dapat menambahkan lebih banyak server backend untuk mendistribusikan beban.

   • Jika request_time jauh lebih tinggi daripada upstream_response_time, latensi kemungkinan berada di jalur jaringan antara klien dan instans ALB. Dari klien, jalankan pengujian ping berkelanjutan atau jejak MTR ke alamat layanan ALB untuk mendiagnosis masalah tautan jaringan.

3. Pertimbangkan skenario akses lintas wilayah: Jika klien dan instans ALB berada di wilayah berbeda, latensi jaringan akibat jarak fisik tidak dapat dihindari. Kami merekomendasikan menggunakan Global Accelerator (GA) untuk mengoptimalkan pengalaman akses lintas wilayah.

Layanan tidak dapat diakses melalui nama domain

Setelah memetakan nama domain kustom Anda ke nama DNS instans ALB dengan rekaman CNAME, Anda mungkin tetap tidak dapat mengakses layanan. Jika Anda menerima kesalahan HTTP 403 atau koneksi di-reset, penyebabnya kemungkinan besar adalah pendaftaran ICP domain Anda yang belum lengkap.

Ikuti langkah-langkah berikut untuk mendiagnosis masalah:

1. Verifikasi konfigurasi rekaman CNAME: Gunakan perintah nslookup atau dig untuk memverifikasi bahwa nama domain Anda di-resolve dengan benar ke nama DNS instans ALB. Untuk informasi selengkapnya, lihat Konfigurasikan Rekaman CNAME.

2. Periksa status pendaftaran ICP nama domain Anda: Menurut peraturan, nama domain yang digunakan untuk akses publik di Tiongkok daratan harus memiliki pendaftaran ICP yang valid. Jika tidak, akses akan diblokir. Masuk ke Sistem Pendaftaran ICP Alibaba Cloud untuk memeriksa status pendaftaran nama domain Anda. Jika belum terdaftar, lengkapi proses pendaftaran ICP terlebih dahulu. Untuk informasi selengkapnya, lihat Proses Pendaftaran ICP.

3. Tentukan apakah diperlukan transfer pendaftaran ICP: Jika nama domain Anda didaftarkan melalui penyedia layanan cloud lain dan Anda menggunakannya dengan Alibaba Cloud untuk pertama kalinya, Anda harus menyelesaikan transfer pendaftaran ICP. Proses ini mendaftarkan informasi pendaftaran Anda ke Alibaba Cloud. Akses mungkin diblokir jika transfer belum selesai.

500 (Internal Server Error)

Server backend mengalami kesalahan internal dan tidak dapat memproses permintaan.

• Backend mengembalikan 500 secara langsung: Periksa log akses. Jika upstream_status adalah 500, ALB kemungkinan meneruskan kode status tersebut dari backend. Selidiki layanan backend.

• Server backend menutup koneksi secara tak terduga: Server backend menutup koneksi sebelum mengirim respons lengkap. Tangkap paket di server backend untuk mengidentifikasi penyebab penutupan koneksi yang tak terduga.

502 (Bad Gateway)

Kesalahan ini terjadi ketika pendengar HTTP atau HTTPS menerima permintaan klien, tetapi ALB gagal meneruskan permintaan ke server backend atau menerima respons darinya.

Pendekatan pemecahan masalah: Pertama, periksa nilai field upstream_status di log akses untuk menentukan langkah selanjutnya.

• Jika upstream_status = 502: ALB meneruskan kode status 502 dari server backend. Masalah terletak pada layanan backend itu sendiri. Selidiki layanan backend Anda. Misalnya, periksa apakah lapisan Nginx atau gateway backend mencoba melakukan reverse proxy ke upstream yang tidak dapat dijangkau.

• Jika upstream_status bernilai lain (seperti 504, 444, atau 500): status yang dikembalikan ALB ke klien berbeda dari upstream_status, yang berarti ALB mengubah kode status tersebut. Selidiki mengapa layanan backend mengembalikan kode status spesifik tersebut dengan memeriksa log Nginx, gateway, atau aplikasi backend.

• Jika upstream_status adalah - atau kosong: ALB tidak menerima respons apa pun dari backend. Artinya, permintaan tidak pernah mencapai backend, atau koneksi backend diputus secara abnormal sebelum respons dikirim. Periksa penyebab berikut secara berurutan:

  • Komunikasi TCP antara ALB dan server backend gagal. Verifikasi bahwa layanan backend berjalan, port layanan mendengarkan dengan benar, dan tidak ada aturan iptables atau perangkat lunak keamanan pihak ketiga di ECS backend yang memblokir blok CIDR VSwitch tempat instans ALB berada. ALB berkomunikasi dengan server backend menggunakan Local IP yang ditetapkan oleh VSwitch. Anda dapat menangkap paket untuk memeriksa apakah handshake TCP berhasil.

  • Backlog server backend penuh. Hal ini menyebabkan server membuang permintaan koneksi baru. Jalankan netstat -s | grep -i listen di server backend dan periksa counter drop.

  • Server backend gagal memproses permintaan tepat waktu. Periksa log server backend dan tinjau penggunaan CPU dan memori untuk mengidentifikasi bottleneck kinerja.

  • Ukuran paket permintaan klien melebihi MTU server backend. Hal ini dapat menyebabkan paket pendek (seperti pemeriksaan kesehatan) berhasil sementara paket panjang gagal. Tangkap paket di server backend untuk menganalisis apakah panjang paket berada dalam batas yang diperlukan.

  • Respons server backend memiliki format tidak valid atau berisi header HTTP tidak valid. Tangkap paket di server backend untuk menganalisis apakah format respons sesuai standar.

503 (Service Temporarily Unavailable)

Server sementara tidak tersedia, biasanya karena lalu lintas melebihi batas atau layanan backend tidak tersedia.

• Backend mengembalikan 503 secara langsung: Periksa log akses. Jika upstream_status adalah 503, ALB kemungkinan meneruskan kode status tersebut dari backend. Selidiki layanan backend.

• Permintaan klien memicu pembatasan kecepatan ALB:

  • Di Cloud Monitor, periksa metrik Requests per second.

  • Cloud Monitor menampilkan data per menit dan mungkin tidak mencerminkan lonjakan per detik. Periksa log akses. Jika field upstream_status adalah -, permintaan tidak mencapai server backend.

  • Periksa header paket respons. Jika berisi field ALB-QPS-Limited:Limited, permintaan tersebut memicu pembatasan kecepatan ALB.

• Akses IP langsung atau resolusi DNS tidak normal: Hal ini dapat memusatkan lalu lintas hanya pada beberapa alamat IP dan memicu pembatasan kecepatan. Akses ALB melalui nama domainnya (lihat Konfigurasikan CNAME untuk instans ALB) dan verifikasi bahwa resolusi DNS berfungsi sebagaimana mestinya.

• Pendengar tidak memiliki server backend yang dikonfigurasi, atau server backend yang dikonfigurasi memiliki bobot 0.

504 (Gateway Time-out)

ALB mengalami timeout saat menunggu respons dari server backend.

• Backend mengembalikan 504 secara langsung: Periksa log akses. Jika upstream_status adalah 504, ALB kemungkinan meneruskan kode status tersebut dari backend. Selidiki layanan backend.

• Upaya koneksi dari ALB ke server backend mengalami timeout: Timeout ini adalah 5 detik secara default dan tidak dapat diubah. Tangkap paket untuk mengidentifikasi mengapa server backend tidak merespons tepat waktu.

• Timeout respons backend: timeout permintaan koneksi adalah 60 detik secara default. Anda dapat memeriksa metrik UpstreamResponseTime di Cloud Monitor dan field upstream_response_time di log akses untuk menentukan apakah respons server backend mengalami timeout.

Integrasi transparan WAF 2.0 vs. integrasi berbasis layanan WAF 3.0

Untuk informasi selengkapnya, lihat Perbandingan antara WAF 3.0 dan WAF 2.0.

Integrasi ALB dan WAF

• Kami menyarankan Anda untuk mengaktifkan perlindungan WAF 3.0 untuk instans ALB dengan menggunakan integrasi berbasis layanan WAF 3.0. Ini berarti menggunakan instans ALB yang ditingkatkan WAF.

  • Wilayah yang didukung:

    Area	Wilayah
    China	China (Chengdu), China (Qingdao), China (Beijing), China (Guangzhou), China (Hangzhou), China (Ulanqab), China (Shanghai), China (Shenzhen), China (Zhangjiakou), China (Hong Kong), China (Heyuan)
    Asia Pasifik	Indonesia (Jakarta), Jepang (Tokyo), Malaysia (Kuala Lumpur), Filipina (Manila), Singapura, Korea Selatan (Seoul), Thailand (Bangkok)
    Eropa & Amerika	Jerman (Frankfurt), AS (Silicon Valley), AS (Virginia), Meksiko
    Timur Tengah	Arab Saudi (Riyadh) (Dioperasikan oleh Mitra), UAE (Dubai)

  • Instans ALB yang diaktifkan WAF menggunakan model integrasi SDK WAF 3.0. Jika Anda memiliki instans WAF 2.0 di akun Anda, Anda harus terlebih dahulu melepaskan instans WAF 2.0 atau memigrasikannya ke WAF 3.0.

    Secara default, ALB tidak menambahkan header X-Forwarded-Proto ke permintaan. Setelah Anda melepaskan instans WAF 2.0, mengakses instans ALB secara langsung dapat menyebabkan masalah layanan seperti redirect tak berujung karena server backend tidak dapat mengidentifikasi protokol asli (HTTP atau HTTPS). Untuk mencegah masalah ini, Anda harus mengaktifkan header permintaan X-Forwarded-Proto secara manual di konfigurasi pendengar ALB.

  • Instans ALB yang diaktifkan WAF tidak mendukung fitur Pencegahan kebocoran data WAF.

• Jika Anda ingin menggunakan instans WAF 2.0 yang sudah ada, instans ALB Basic dan Standard yang menghadap Internet mendukung integrasi transparan WAF 2.0 di wilayah berikut: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Chengdu), China (Beijing), dan China (Zhangjiakou). Instans ALB yang menghadap internal tidak mendukung integrasi transparan WAF 2.0.

Dukungan integrasi WAF untuk CLB dan ALB

Masalah integrasi transparan WAF 2.0

Dalam integrasi transparan WAF 2.0, permintaan klien melewati WAF untuk diperiksa sebelum dikirim ke instans ALB atau CLB. Jalur dua gerbang ini mengharuskan Anda menyinkronkan beberapa konfigurasi antara WAF dan load balancer. Perubahan pada timeout dan sertifikat sangat rentan terhadap keterlambatan sinkronisasi konfigurasi.