Server Load Balancer:FAQ tentang ALB

Apakah ALB memiliki spesifikasi instans tertentu?

Anda tidak perlu memilih tipe instans untuk ALB. Instans ALB yang ditingkatkan dapat menggunakan fitur penskalaan VIP otomatis untuk mencapai QPS sebesar 1 juta pada satu instans. Untuk detail mengenai kinerja instans ALB, lihat Metrik kinerja instans.

Dapatkah saya mengganti instans ALB dari IPv4 ke dual-stack atau dari dual-stack ke IPv4?

Tidak didukung.

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

Apakah VIP instans ALB mendukung penonaktifan Ping?

• Instans ALB yang ditingkatkan mendukung pengelolaan lalu lintas akses melalui security group. Anda dapat mengonfigurasi aturan inbound deny ICMP pada security group yang terkait dengan instans tersebut.

• Untuk instans ALB non-ditingkatkan, Anda dapat menambahkan EIP yang dilampirkan ke Firewall internet dan mengonfigurasi kebijakan inbound deny ICMP.

Bagaimana cara meningkatkan bandwidth publik instans ALB?

Jika instans ALB diterapkan di dua zona dan tidak dikaitkan dengan instans Internet Shared Bandwidth, bandwidth publik puncak default-nya adalah 400 Mbps.

Dapatkah saya menggunakan Paket Transfer Data untuk mengimbangi biaya lalu lintas publik ALB?

• Saat instans ALB menggunakan Elastic IP Address (EIP) untuk menyediakan akses Internet, lalu lintas Internet yang dihasilkan oleh EIP tersebut dapat diimbangi menggunakan paket transfer data general-purpose.

• Instans ALB yang menggunakan Anycast Elastic IP Addresses (Anycast EIPs) untuk menyediakan layanan melalui Internet tidak dapat menggunakan paket transfer data general untuk mengimbangi lalu lintas Internet yang dihasilkan oleh Anycast EIPs tersebut.

Jenis EIP apa saja yang dapat dikaitkan dengan instans ALB?

Dapatkah saya mengaitkan EIP dengan instans ALB privat?

Ya.

Untuk mengaitkan Elastic IP Address dengan ALB akses internal, ubah jenis jaringan instans tersebut untuk mengonversi ALB akses internal menjadi ALB akses Internet. Untuk informasi lebih lanjut, lihat Ubah jenis jaringan instans ALB.

Saat Anda mengonversi jaringan privat menjadi jaringan publik, Elastic IP Address (EIP) akan dikaitkan dan biaya jaringan publik akan berlaku. Untuk informasi lebih lanjut, lihat Penagihan Elastic IP Address.

Bagaimana cara mengganti EIP instans ALB saya menjadi EIP BGP (Multi-ISP) Pro?

Anda dapat menggantinya dengan mengubah jenis jaringan instans ALB.

1. Ubah jenis jaringan instans ALB dari publik menjadi privat untuk melepaskan EIP saat ini dari instans tersebut.

2. Ubah kembali jenis jaringan instans ALB dari privat menjadi publik. Saat melakukan operasi ini, pilih dua EIP BGP (Multi-ISP) premium yang telah Anda buat.

Mengapa beban lalu lintas tidak seimbang di antara EIP yang dikaitkan dengan ALB?

Penyebabnya mungkin salah satu dari berikut:

• Nama domain bisnis di-resolve ke satu EIP yang dikaitkan dengan instans ALB, bukan ke nama DNS instans ALB sebagaimana mestinya.

• Proxy Lapisan 7, seperti WAF atau Anti-DDoS Proxy, diterapkan di depan instans ALB. Algoritma back-to-origin proxy tersebut, seperti IP Hash, mencegah lalu lintas didistribusikan secara merata di antara beberapa EIP.

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

Apa yang perlu saya ketahui tentang Penghapusan DNS ALB?

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

Setelah Anda menyelesaikan operasi penghapusan DNS, probing ketersediaan untuk VIP di zona tersebut berhenti. VIP atau EIP (termasuk IPv4 dan IPv6) di zona tersebut dihapus dari resolusi DNS nama domain ALB. Anda tidak dapat hanya menghapus alamat VIP IPv4 atau IPv6 saja.

Apakah ALB mendukung pencerminan lalu lintas?

Untuk informasi lebih lanjut, lihat Cerminkan lalu lintas produksi ke lingkungan staging.

Mengapa instans ALB gagal mencapai batas QPS yang ditentukan dalam aturan pengalihan pendengar?

• Cara kerja: Sistem load balancing menyediakan layanan kepada instans SLB melalui penerapan kluster, mendistribusikan semua permintaan akses eksternal secara merata ke server backend untuk pengalihan. Oleh karena itu, QPS maksimum yang dikonfigurasi dalam aturan pengalihan didistribusikan secara merata ke setiap server backend.

  QPS maksimum setiap server backend dihitung menggunakan rumus berikut: QPS maksimum setiap server backend = Total QPS/(N-1). N menentukan jumlah server backend dalam grup server. Misalnya, Anda menetapkan QPS maksimum menjadi 1.000 dalam aturan pengalihan di konsol. Jika jumlah server backend adalah 8, QPS maksimum setiap server backend dihitung menggunakan rumus berikut: 1000/(8-1) = 142.

• Penyebab: Dalam skenario dengan jumlah kecil koneksi persisten, tidak semua server backend dalam grup server dialokasikan koneksi persisten. Akibatnya, instans ALB tidak dapat mencapai QPS maksimum.

• Saran: Untuk mencegah gangguan layanan, kami merekomendasikan agar Anda menetapkan QPS maksimum dalam aturan pengalihan ke nilai yang sesuai sesuai kebutuhan. Untuk informasi lebih lanjut mengenai cara menetapkan QPS maksimum dalam aturan pengalihan untuk pendengar Server Load Balancer, lihat Tambahkan aturan pengalihan.

Berapa batas panjang permintaan yang diteruskan oleh ALB? Apakah dapat disesuaikan?

Apakah waktu pemrosesan ALB mencakup waktu yang diperlukan untuk menerima data klien dan mengirim data respons?

Waktu pemrosesan ALB mencakup waktu yang diperlukan untuk menerima data klien dan mengirim data.

Berapa jumlah maksimum permintaan yang didukung oleh satu koneksi persisten HTTP dari klien ke ALB?

Satu koneksi persisten mendukung maksimum 100 permintaan berturut-turut. Setelah batas ini terlampaui, koneksi akan ditutup secara otomatis.

Hanya saat Anda menggunakan pendengar HTTPS dan mengaktifkan HTTP/2, jumlah maksimum permintaan yang didukung oleh satu koneksi persisten dapat ditingkatkan menjadi 1.000.

Berapa batas panjang paket Client Hello klien untuk pendengar QUIC ALB?

Saat Anda menggunakan pendengar QUIC, ALB menetapkan batas panjang minimum untuk paket Client Hello klien. Panjangnya harus minimal 1.024 byte. Jika tidak, ALB akan mengembalikan "client hello too small" dan menutup koneksi. Anda dapat mengisi paket Client Hello dengan karakter null hingga mencapai 1.024 byte agar lolos pemeriksaan.

Apa yang perlu saya ketahui saat menggunakan Ingress ALB?

Umumnya, Anda sebaiknya tidak memodifikasi secara manual instans ALB di konsol yang dibuat menggunakan ALB Ingress. Konfigurasi untuk ALB terutama disinkronkan dari sumber daya AlbConfig. Untuk informasi lebih lanjut mengenai ALB Ingress, lihat Manajemen ALB Ingress dan Operasi ALB Ingress.

Jika Anda memodifikasi konfigurasi secara manual di konsol, perubahan tersebut akan ditimpa karena konfigurasi AlbConfig tidak dimodifikasi. Hal ini dapat menyebabkan masalah seperti log akses dinonaktifkan dan aturan routing dihapus.

FAQ tentang permintaan lintas asal

Saat saya mengonfigurasi aturan pengalihan pendengar ALB dengan aksi menulis header, bagaimana cara mereferensikan nilai header asli?

Key adalah nama header yang akan ditulis, dan Value adalah metode referensi yang Anda pilih dan nama header asli yang nilainya ingin Anda referensikan. Misalnya, Anda menulis nama header abc-abc dan mereferensikan nilai header asli abc. Aturan pengalihan mengambil nilai bidang dari header asli abc dan menetapkannya ke header baru abc-abc.

Klien

Sisi server

Apakah ALB mendukung otentikasi timbal balik?

Tidak, instans ALB dasar tidak. Anda dapat mengaktifkan Otentikasi timbal balik untuk pendengar HTTPS pada instans ALB standar atau yang berkemampuan Web Application Firewall (WAF). Untuk menggunakan Otentikasi timbal balik pada instans ALB dasar, Anda harus mengubah edisinya.

Apa aturan yang harus dipenuhi saat pendengar ALB menggunakan sertifikat wildcard?

Dapatkah saya mengunggah sertifikat di konsol ALB?

Tidak, Anda tidak dapat.

ALB menggunakan sertifikat langsung dari SSL Certificate Service. Anda harus mengunggah sertifikat Anda ke konsol SSL Certificate Service, bukan ke konsol ALB. Untuk informasi lebih lanjut, lihat Unggah sertifikat SSL.

Setelah saya memperbarui sertifikat ALB, tanggal kedaluwarsa sertifikat nama domain di browser tidak berubah.

Masalah ini biasanya terjadi karena instans ALB terhubung ke WAF 2.0 dalam mode proxy transparan, dan sertifikat di sisi WAF belum diperbarui. WAF menyinkronkan sertifikat dari ALB secara berkala. Untuk menyinkronkan sertifikat segera, Anda dapat menonaktifkan lalu mengaktifkan kembali pengalihan lalu lintas di sisi WAF untuk memaksa refresh status sertifikat. Perhatikan bahwa operasi ini menyebabkan pemutusan sementara selama 1 hingga 2 detik untuk layanan Anda.

Bagaimana cara mengubah konfigurasi pemeriksaan kesehatan pendengar?

1. Anda dapat login ke Konsol ALB.

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

3. Di halaman Server Groups, temukan grup server yang ingin Anda kelola dan klik ID-nya.

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

5. Di kotak dialog Edit Health Check, klik Edit di sebelah kanan Health Check Configuration, modifikasi konfigurasi sesuai kebutuhan, lalu klik Save.

   Untuk informasi lebih lanjut, lihat Pemeriksaan kesehatan.

Mengapa kode status 502 dikembalikan saat pemeriksaan kesehatan normal?

Hal ini biasanya karena server backend instans ALB kelebihan beban. Saat server backend instans ALB kelebihan beban, server tersebut mungkin gagal merespons permintaan akses meskipun pemeriksaan kesehatan berhasil. Untuk informasi lebih lanjut, lihat Pemecahan masalah beban tinggi pada instans Linux.

Bagaimana ALB meneruskan permintaan saat semua server backend dalam grup server yang sama gagal dalam pemeriksaan kesehatan?

ALB mendistribusikan permintaan berdasarkan algoritma penjadwalan untuk menjaga ketersediaan layanan. Untuk mengatasi masalah ini, Anda dapat memeriksa log untuk menentukan apakah server backend mengalami error, atau memeriksa konfigurasi pemeriksaan kesehatan. Untuk informasi lebih lanjut, lihat Pemecahan masalah pemeriksaan kesehatan ALB.

Bagaimana cara memecahkan masalah saat layanan tidak dapat diakses melalui ALB?

Ikuti langkah-langkah berikut:

1. Verifikasi resolusi nama domain (CNAME): Instans ALB yang baru dibuat tidak dapat diakses langsung menggunakan nama DNS-nya. Anda harus mengonfigurasi resolusi CNAME dari domain kustom Anda ke nama DNS instans ALB. Anda dapat menggunakan perintah nslookup atau dig untuk memverifikasi resolusi tersebut. Untuk informasi lebih lanjut, lihat Ikhtisar Nama DNS Instans ALB.

2. Konfirmasi jenis jaringan instans: Instans ALB privat hanya mendukung akses VPC internal dan tidak dapat diakses langsung melalui jaringan publik. Untuk mengaktifkan akses jaringan publik, ubah jenis jaringan instans menjadi publik dan lampirkan EIP. Untuk informasi lebih lanjut, lihat Ubah jenis jaringan instans ALB.

3. Konfirmasi pendengar dan aturan pengalihan: Di konsol ALB, periksa apakah pendengar telah dibuat. Pastikan port dan protokol pendengar dikonfigurasi dengan benar, dan aturan pengalihan dapat mencocokkan nama domain dan path permintaan.

4. Konfirmasi status pemeriksaan kesehatan: Di konsol ALB, lihat status pemeriksaan kesehatan server backend. Jika server backend gagal dalam pemeriksaan kesehatan, ALB mungkin tidak dapat meneruskan permintaan secara normal.

5. Verifikasi bahwa layanan backend berfungsi dengan baik: Login langsung ke server backend dan gunakan curl -I http://<alamat IP jaringan privat server backend>:<port> untuk memverifikasi bahwa layanan backend merespons secara normal.

6. Konfirmasi aturan security group: Periksa aturan security group untuk server backend dan instans ALB untuk memastikan bahwa port pendengar dan blok CIDR alamat sumber permintaan diizinkan.

Bagaimana cara memecahkan masalah latensi tinggi saat mengakses melalui ALB?

Sebagai layanan berbasis aplikasi, ALB meneruskan permintaan ke server backend. Hal ini mengakibatkan sedikit peningkatan latensi dibandingkan akses langsung ke backend, yang merupakan hal normal.

Jika latensi sangat tinggi, ikuti langkah-langkah berikut untuk pemecahan masalah:

1. Aktifkan log akses dan analisis bidang latensi: Aktifkan log akses ALB, dan fokus pada bidang berikut:

   • request_time: Interval waktu antara saat Server Load Balancer menerima pesan permintaan pertama dan saat mengembalikan acknowledgement, dalam satuan detik.

   • upstream_response_time: Waktu dari saat ALB membentuk koneksi ke server backend hingga menerima semua data lalu menutup koneksi, dalam satuan detik.

2. Identifikasi sumber latensi:

   • Jika upstream_response_time tinggi, sumber latensi biasanya disebabkan oleh pemrosesan lambat oleh server backend. Anda dapat memecahkan masalah kinerja aplikasi backend, efisiensi kueri database, penggunaan sumber daya seperti CPU dan memori, atau menambahkan server backend untuk mendistribusikan beban.

   • Jika request_time jauh lebih besar daripada upstream_response_time, latensi kemungkinan disebabkan oleh jalur jaringan antara klien dan ALB. Kami merekomendasikan menjalankan pengujian ping berkelanjutan atau pelacakan rute MTR dari klien ke titik akhir ALB untuk memecahkan masalah jalur jaringan.

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

Apa yang harus saya lakukan saat layanan tidak dapat diakses melalui nama domain via ALB?

Anda tidak dapat langsung mengakses instans ALB baru menggunakan nama DNS-nya. Anda harus mengarahkan nama domain kustom Anda ke nama DNS instans ALB menggunakan rekaman CNAME sebelum dapat mengaksesnya. Jika Anda telah mengonfigurasi rekaman CNAME dengan benar tetapi masih tidak dapat mengakses layanan (mengembalikan 403 atau koneksi di-reset), alasan paling umum adalah nama domain belum menyelesaikan Pendaftaran ICP.

Kami merekomendasikan agar Anda mengikuti langkah-langkah berikut untuk pemecahan masalah:

1. Verifikasi konfigurasi resolusi CNAME: Gunakan perintah nslookup atau dig untuk memverifikasi bahwa nama domain di-resolve dengan benar ke nama DNS instans ALB. Untuk informasi lebih lanjut, lihat Konfigurasi Resolusi CNAME.

2. Konfirmasi status Pendaftaran ICP nama domain Anda: Menurut peraturan terkait, saat Anda menggunakan nama domain untuk mengakses layanan melalui jaringan publik di wilayah Tiongkok daratan, nama domain tersebut harus telah menyelesaikan Pendaftaran ICP. Jika tidak, akses akan diblokir. Login ke Sistem Pendaftaran ICP Alibaba Cloud untuk memeriksa status Pendaftaran ICP nama domain Anda. Jika nama domain belum didaftarkan, selesaikan Pendaftaran ICP terlebih dahulu. Untuk informasi lebih lanjut, lihat Alur Pendaftaran ICP.

3. Konfirmasi apakah Anda perlu menambahkan Alibaba Cloud ke informasi Pendaftaran ICP: Jika nama domain telah menyelesaikan Pendaftaran ICP dengan penyedia layanan cloud lain tetapi digunakan di Alibaba Cloud untuk pertama kalinya, Anda juga perlu menambahkan Alibaba Cloud ke informasi Pendaftaran ICP sebagai penyedia layanan. Kegagalan melakukannya juga dapat menyebabkan akses diblokir.

500 (Internal Server Error)

Server backend mengalami error internal dan tidak dapat mengeksekusi permintaan.

• Backend langsung mengembalikan 500: Periksa log akses. Jika upstream_status adalah 500, ALB kemungkinan meneruskan kode status upstream tersebut. Pecahkan masalah layanan backend.

• Server backend menutup koneksi secara abnormal: Server backend menutup koneksi secara abnormal sebelum mengirim respons lengkap. Tangkap paket di server backend untuk memecahkan penyebab penutupan koneksi abnormal tersebut.

502 (Bad Gateway)

Setelah pendengar HTTP atau HTTPS menerima permintaan klien, ALB tidak dapat meneruskan permintaan tersebut ke server backend dengan benar atau tidak dapat menerima respons dari server backend.

• Backend langsung mengembalikan 502: Periksa log akses. Jika upstream_status adalah 502, ALB kemungkinan meneruskan kode status upstream tersebut. Pecahkan masalah layanan backend.

• Server backend mengembalikan kode status error lain: Misalnya, 504 atau 444, tetapi ALB secara seragam mengembalikan 502. Periksa bidang status dan upstream_status di log akses dan pecahkan masalah berdasarkan kode status upstream.

• Error komunikasi TCP antara ALB dan server backend: Periksa apakah layanan backend berjalan normal, apakah port layanan mendengarkan dengan baik, atau tangkap paket untuk memeriksa apakah handshake TCP berjalan normal.

• Backlog server backend penuh: Hal ini menyebabkan permintaan koneksi baru ditolak atau di-drop. Jalankan netstat -s | grep -i listen di server backend untuk memeriksa apakah ada jumlah drop.

• Panjang paket klien melebihi MTU server backend: Hal ini ditandai dengan paket pendek seperti pemeriksaan kesehatan berjalan normal, tetapi paket panjang mengalami anomali. Tangkap paket di server backend untuk menganalisis apakah panjang paket memenuhi persyaratan.

• Format paket respons server backend abnormal atau berisi header HTTP ilegal: Tangkap paket di server backend untuk menganalisis apakah format paket respons sesuai standar.

• Server backend tidak memproses permintaan tepat waktu: Periksa log server backend dan lihat pemanfaatan CPU dan memori.

503 (Service Temporarily Unavailable)

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

• Backend langsung mengembalikan 503: Periksa log akses. Jika upstream_status adalah 503, ALB kemungkinan meneruskan kode status upstream tersebut. Pecahkan masalah layanan backend.

• Permintaan klien memicu pembatasan kecepatan ALB:

  • Periksa metrik Requests per second melalui CloudMonitor.

  • CloudMonitor menampilkan data per menit dan mungkin tidak mencerminkan situasi yang melebihi batas per detik. Periksa log akses. Jika nilai bidang upstream_status adalah -, permintaan tidak mencapai server backend.

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

• Klien mengakses langsung IP ALB atau resolusi DNS abnormal saat mengakses melalui nama domain: Hal ini dapat menyebabkan lalu lintas terkonsentrasi pada beberapa IP dan melebihi batas. Kami merekomendasikan agar klien mengakses melalui nama domain ALB (lihat Konfigurasikan rekaman CNAME untuk instans ALB dan pastikan resolusi DNS berjalan normal.

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

504 (Gateway Time-out)

Respons server backend mengalami timeout.

• Backend langsung mengembalikan 504: Periksa log akses. Jika upstream_status adalah 504, ALB kemungkinan meneruskan kode status upstream tersebut. Pecahkan masalah layanan backend.

• Pembentukan koneksi antara ALB dan server backend mengalami timeout: Timeout default adalah 5 detik dan tidak dapat dimodifikasi. Tangkap paket untuk memecahkan mengapa respons server backend mengalami timeout.

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

Apa perbedaan antara mode proxy transparan WAF 2.0 dan mode integrasi layanan WAF 3.0?

Untuk informasi lebih lanjut, lihat Bandingkan WAF 3.0 dan WAF 2.0.

Petunjuk penggunaan ALB dengan WAF

• Kami merekomendasikan agar Anda menggunakan tipe koneksi berbasis layanan untuk mengaktifkan proteksi WAF 3.0 untuk instans ALB. Metode ini 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), dan China (Hong Kong)
    Asia Pasifik	Filipina (Manila), Indonesia (Jakarta), Jepang (Tokyo), Malaysia (Kuala Lumpur), Singapura, Thailand (Bangkok), dan Korea Selatan (Seoul)
    Eropa dan Amerika	Jerman (Frankfurt), AS (Virginia), AS (Silicon Valley), dan Meksiko
    Timur Tengah	SAU (Riyadh - Partner Region), UEA (Dubai)

  • Versi WAF: Anda harus menggunakan WAF 3.0. Jika Anda memiliki instans WAF 2.0 di akun Anda, Anda harus terlebih dahulu melepas instans WAF 2.0 atau memigrasikannya ke WAF 3.0.

    Secara default, ALB tidak mengaktifkan header X-Forwarded-Proto dalam permintaan yang diteruskan ke grup server backend. Setelah Anda menghentikan instans WAF 2.0, mengakses ALB secara langsung dapat menyebabkan gangguan layanan, seperti pengalihan loop tak terbatas, karena layanan backend tidak dapat mengenali protokol (HTTP/HTTPS) dengan benar. Untuk mencegah masalah ini, Anda harus mengaktifkan secara manual header permintaan X-Forwarded-Proto dalam konfigurasi pendengar ALB.

  • Ketersediaan fitur: WAF untuk instans ALB tidak mendukung fitur berikut: modul pencegahan kebocoran data dan fitur integrasi Web SDK otomatis untuk aturan anti-crawler untuk situs web dalam modul manajemen bot.

• Untuk menggunakan instans WAF 2.0 yang sudah ada di akun Anda, instans ALB publik Dasar dan Standar mendukung mode proxy transparan untuk proteksi WAF 2.0. Wilayah yang didukung: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Chengdu), China (Beijing), dan China (Zhangjiakou). Instans ALB privat tidak mendukung proteksi WAF 2.0.

Apakah CLB dan ALB mendukung proxy transparan WAF 2.0 dan integrasi layanan WAF 3.0?

Mengapa terjadi masalah konfigurasi seperti timeout dan sertifikat tidak tersinkronisasi pada proxy transparan WAF 2.0?

Saat Anda mengintegrasikan WAF 2.0 dalam mode transparan, permintaan klien difilter oleh WAF sebelum diteruskan ke ALB atau CLB. Karena permintaan melewati dua gerbang, konfigurasi harus disinkronkan antara WAF dan Server Load Balancer. Perubahan pada periode timeout atau sertifikat dapat menyebabkan keterlambatan dalam sinkronisasi ini.