Topik ini memberikan contoh konfigurasi aturan pengalihan ALB, mencakup pencocokan nama domain dan path, penulisan ulang (rewrite), serta pengalihan (redirect).
Contoh konfigurasi
Skenario 1: Mengalihkan HTTP ke HTTPS
Alihkan permintaan HTTP ke HTTPS untuk memastikan data dienkripsi selama transmisi. Anda dapat melakukannya dengan menambahkan aturan pengalihan ke listener HTTP (port 80).
|
Parameter |
Deskripsi |
|
Add Condition |
Setel Path ke Exact Match and Wildcard dan masukkan |
|
Action |
Pilih Redirect.
|
Hasil: Saat pengguna mengakses http://www.example.com/page, browser secara otomatis mengalihkan ke https://www.example.com/page.
Konfigurasikan aturan ini pada listener HTTP (port 80). Pastikan juga listener HTTPS (port 443) telah dibuat dan dikaitkan dengan Sertifikat SSL yang valid. Untuk prasyarat lengkap dan prosedurnya, lihat Gunakan ALB untuk mengalihkan permintaan HTTP ke HTTPS.
Skenario 2: Mengarahkan traffic berdasarkan path
Untuk satu domain, Anda dapat meneruskan permintaan dengan path berbeda ke kelompok server yang berbeda. Misalnya, permintaan API dan aset statis dapat diteruskan ke backend terpisah.
Aturan 1: Teruskan permintaan untuk /api/* ke kelompok server API.
|
Parameter |
Deskripsi |
|
Add Condition |
Setel Path ke Exact Match and Wildcard dan masukkan |
|
Action |
Pilih Forward, lalu pilih kelompok server API. |
Aturan 2: Teruskan permintaan untuk /static/* ke kelompok server aset statis.
|
Parameter |
Deskripsi |
|
Add Condition |
Setel Path ke Exact Match and Wildcard dan masukkan |
|
Action |
Pilih Forward, lalu pilih kelompok server aset statis. |
ALB mengevaluasi aturan pengalihan berdasarkan nomor prioritasnya. Tempatkan aturan path yang lebih spesifik (dengan nomor prioritas lebih rendah) sebelum aturan yang lebih umum agar tidak tertangkap oleh aturan wildcard terlebih dahulu. Misalnya, aturan untuk/api/v2/*harus memiliki nomor prioritas lebih rendah daripada aturan untuk/api/*.
Skenario 3: Meneruskan beberapa domain
Host beberapa domain pada satu instans ALB dan teruskan permintaan untuk setiap domain ke kelompok server backend masing-masing.
Aturan 1: Teruskan permintaan untuk www.example.com ke kelompok server web.
|
Parameter |
Deskripsi |
|
Add Condition |
Setel Domain Name ke Exact Match and Wildcard dan masukkan |
|
Action |
Pilih Forward, lalu pilih kelompok server web. |
Aturan 2: Teruskan permintaan untuk api.example.com ke kelompok server API.
|
Parameter |
Deskripsi |
|
Add Condition |
Setel Domain Name ke Exact Match and Wildcard dan masukkan |
|
Action |
Pilih Forward, lalu pilih kelompok server API. |
Skenario 4: Menghapus awalan path sebelum meneruskan
Hapus awalan tertentu dari path permintaan sebelum meneruskan ke backend, sambil tetap mempertahankan path multi-level setelah awalan tersebut. Misalnya, saat ALB meneruskan permintaan untuk www.example.com/api/aaa/bbb/..., bagian /api perlu dihapus dari path, tetapi path multi-level berikutnya seperti /aaa/bbb/... tetap dipertahankan.
Rewrite mengganti path secara internal dalam ALB; URL di bilah alamat browser klien tidak berubah. Redirect mengembalikan URL baru ke klien, sehingga bilah alamat browser diperbarui ke URL baru tersebut. Gunakan rewrite jika hanya backend yang perlu menerima path tanpa awalan. Gunakan redirect jika klien harus mengetahui perubahan URL tersebut.
Rewrite
|
Parameter |
Deskripsi |
|
|
Add Condition |
Domain Name |
Setel ke Exact Match and Wildcard dan masukkan |
|
Path |
Setel ke Regular Expression Match | Case Insensitive dan masukkan |
|
|
Action |
Rewrite |
|
|
Forward |
Pilih kelompok server target. |
|
Redirect
|
Parameter |
Deskripsi |
|
|
Add Condition |
Domain Name |
Setel ke Exact Match and Wildcard dan masukkan |
|
Path |
Setel ke Regular Expression Match | Case Insensitive dan masukkan |
|
|
Action |
Redirect |
|
Hasil: Untuk permintaan ke www.example.com/api/aaa/bbb/..., server backend menerima path /aaa/bbb/....
Skenario 5: Mengalihkan domain telanjang ke www
Alihkan permintaan dari domain telanjang (seperti example.com) ke www.example.com. Hal ini menyatukan titik masuk untuk SEO yang lebih baik dan manajemen yang lebih mudah.
|
Parameter |
Deskripsi |
|
Add Condition |
Setel Domain Name ke Exact Match and Wildcard dan masukkan |
|
Action |
Pilih Redirect.
|
Hasil: Saat pengguna mengakses example.com, browser secara otomatis mengalihkan ke www.example.com. Protokol dan port tetap tidak berubah.
Jika Anda juga perlu mengalihkan permintaan HTTP ke HTTPS, gabungkan konfigurasi ini dengan Skenario 1.
Skenario 6: Mencocokkan domain wildcard
Gunakan domain wildcard untuk mencocokkan semua subdomain dan meneruskan permintaannya ke kelompok server yang sama.
|
Parameter |
Deskripsi |
|
Add Condition |
Setel Domain Name ke Exact Match and Wildcard dan masukkan |
|
Action |
Pilih Forward, lalu pilih kelompok server target. |
Hasil: Permintaan ke semua subdomain yang cocok, seperti a.example.com, b.example.com, dan tenant1.example.com, diteruskan ke kelompok server yang sama.
Untuk meneruskan subdomain tertentu ke kelompok server berbeda, buat aturan untuk domain eksak tersebut dan berikan nomor prioritas lebih rendah daripada aturan wildcard. ALB mengevaluasi aturan berdasarkan nomor prioritasnya, bukan berdasarkan tingkat kekhususan pencocokan domain.
Skenario 7: Rilis canary berdasarkan Header HTTP
Gunakan Header HTTP untuk menerapkan rilis canary. Permintaan dengan header tertentu diteruskan ke kelompok server versi baru, sedangkan permintaan lainnya diteruskan ke kelompok server versi saat ini.
Aturan 1 (aturan canary, prioritas lebih tinggi): Teruskan permintaan yang berisi header X-Canary: true ke kelompok server versi baru.
|
Parameter |
Deskripsi |
|
Add Condition |
Pilih HTTP Header, setel kunci ke |
|
Action |
Pilih Forward, lalu pilih kelompok server versi baru. |
Aturan 2 (aturan default, prioritas lebih rendah): Permintaan tanpa header canary diteruskan ke kelompok server versi saat ini. Hal ini dapat diimplementasikan menggunakan aturan pengalihan default listener.
Hasil: Saat permintaan klien menyertakan header X-Canary: true, trafik diteruskan ke kelompok server versi baru. Permintaan tanpa header ini diteruskan ke kelompok server versi saat ini.
Untuk memastikan trafik canary dicocokkan terlebih dahulu, aturan canary harus memiliki nomor prioritas lebih rendah (menunjukkan prioritas lebih tinggi) daripada aturan default. Untuk informasi tentang metode rilis canary berdasarkan cookie dan bobot kelompok server, lihat Gunakan ALB untuk menerapkan rilis canary.
Pencocokan domain dalam aturan pengalihan
ALB mengevaluasi aturan pengalihan berdasarkan nomor prioritasnya, dari terendah ke tertinggi, dan berhenti pada aturan pertama yang cocok. Aturan tidak diurutkan secara otomatis berdasarkan kekhususan domain. Perilaku ini berbeda dari CLB, yang secara otomatis memprioritaskan aturan berdasarkan kekhususan (misalnya, exact match > narrower wildcard > broader wildcard).
Misalnya, pertimbangkan listener dengan dua aturan berikut:
|
Nomor prioritas |
Kondisi pencocokan |
|
Aturan 1 (Prioritas: 1) |
Domain = |
|
Aturan 2 (Prioritas: 2) |
Domain = |
Permintaan ke www.example.com cocok dengan Aturan 1 (aturan wildcard), bukan Aturan 2 (aturan exact match), karena Aturan 1 memiliki nomor prioritas lebih rendah.
Praktik terbaik: Untuk memastikan aturan yang lebih spesifik dievaluasi terlebih dahulu, berikan nomor prioritas lebih rendah daripada aturan yang kurang spesifik. Misalnya, atur aturan untukwww.example.comke Prioritas 1 dan aturan untuk*.example.comke Prioritas 2.
|
Jenis pencocokan |
Deskripsi |
|
Exact match and wildcard match |
|
|
Regular expression match |
|
Pencocokan path aturan pengalihan
Aturan pencocokan path ALB berbeda dari Nginx. ALB tidak mendukung prinsip longest prefix match. Misalnya, Nginx menggunakan metode longest prefix match untuk konfigurasi umum seperti location /api. Untuk mencapai efek yang sama di ALB, Anda harus menggunakan wildcard. Anda dapat mengonfigurasi path sebagai /api/* (kombinasi exact match dan wildcard).
Jika listener memiliki aturan untuk/api/*dan/api/v2/*, Anda harus menempatkan aturan/api/v2/*sebelum aturan/api/*dengan memberikan nomor prioritas lebih rendah. Jika tidak, aturan/api/*akan mencocokkan semua permintaan terlebih dahulu.
|
Jenis pencocokan |
Deskripsi |
|
Exact and wildcard match |
|
|
Regular expression match |
|
Konfigurasi path lanjutan untuk rewrite dan redirect
Jika Anda menggunakan ekspresi reguler untuk menentukan path dalam kondisi pengalihan, Anda dapat menggunakan substitusi ekspresi reguler dalam path aksi rewrite atau redirect.
-
Catatan
-
Jumlah grup tangkapan, yang didefinisikan oleh tanda kurung
( ), dalam ekspresi reguler kondisi pengalihan harus sesuai dengan jumlah variabel ${n} dalam path rewrite atau redirect aksi pengalihan. -
Path rewrite atau redirect dalam aksi pengalihan harus menyertakan satu atau lebih dari
${1},${2}, dan${3}. Jangan mengganti variabel ini dengan karakter lain. -
Dalam path rewrite atau redirect, gunakan karakter
$hanya untuk mereferensikan variabel berikut:${host},${path},${port},${protocol}, dan variabel grup tangkapan ekspresi reguler seperti${1},${2}, dan${3}. Tidak ada variabel lain yang didukung.
-
-
Cara kerja
-
Pencocokan path: Klien mengirim permintaan yang cocok dengan ekspresi reguler dalam aturan pengalihan.
-
Ekstraksi dan substitusi: Sistem mengekstraksi konten dari tiga grup tangkapan pertama, yang didefinisikan oleh tanda kurung
( ), dan menyimpannya ke variabel${1},${2}, dan${3}. Variabel ini kemudian digunakan untuk substitusi dalam path rewrite atau redirect aksi pengalihan. -
Konstruksi path: Sistem mengganti variabel
${1},${2}, dan${3}dengan nilai yang ditangkap dan membangun path akhir untuk rewrite atau redirect.
No.
Langkah
Contoh
1
Konfigurasikan kondisi pengalihan dan aksi pengalihan untuk aturan pengalihan.
-
Path dalam kondisi pengalihan:
/app/(.*)/(.*)/settings -
Path untuk aksi rewrite atau redirect:
/${1}/${2}
2
Klien mengirim permintaan yang cocok dengan path tersebut.
-
Path permintaan dari klien:
/app/users/profile/settings -
Path yang cocok dalam kondisi pengalihan:
/app/(.*)/(.*)/settings
3
Ekstraksi dan substitusi nilai.
Sistem mengekstraksi
usersdanprofiledari dua(.*)grup tangkapan dalam path kondisi pengalihan dan menyimpan nilai tersebut ke variabel ${1} dan ${2} untuk aksi pengalihan.-
${1}diganti denganusers. -
${2}diganti denganprofile.
4
Bangun path.
Path yang diterima server backend:
/users/profile -
-
Contoh konfigurasi
Saat menambahkan aturan pengalihan di konsol, rujuk catatan dan deskripsi alur kerja di atas.
Contoh 1: Actionaksi ke Rewrite dan Forward
Contoh ini menunjukkan cara menulis ulang path
/app/users/profile/settingsmenjadi/users/profilelalu meneruskan permintaan ke server backend. Ekspresi reguler/app/(.*)/(.*)/settingsmenggunakan dua grup tangkapan untuk mengekstraksiusersdanprofile. Path yang ditulis ulang kemudian menggunakan/${1}/${2}untuk membangun path akhir.Parameter
Deskripsi
Add Condition
Path
Pilih Regular Expression Match | Case Insensitive dan masukkan ekspresi reguler
/app/(.*)/(.*)/settings.Misalnya, jika klien meminta path
/app/users/profile/settings, aturan tersebut cocok. Grup tangkapan mengekstraksiusersdanprofile, yang disimpan ke variabel${1}dan${2}masing-masing.Action
Rewrite
-
Domain Name:
${host} -
Path:
/${1}/${2} -
Search:
${query}
Search adalah bagian URL yang mengikuti tanda tanya. Misalnya, untuk URL
www.example.com/test/test1?x=1, Search adalahx=1.Forward
Pilih kelompok server target dari daftar kelompok server.
Contoh 2: Mengatur aksi penerusan ke pengalihan
Contoh berikut mengalihkan path
/app/users/profile/settingske/users/profile. Berbeda dengan Contoh 1, redirect ini mengembalikan kode status 301, dan URL di bilah alamat browser berubah.Parameter
Deskripsi
Add Condition
Path
Pilih Regular Expression Match | Case Insensitive dan masukkan ekspresi reguler
/app/(.*)/(.*)/settings.Misalnya, jika klien meminta path
/app/users/profile/settings, aturan tersebut cocok. Grup tangkapan mengekstraksiusersdanprofile, yang disimpan ke variabel${1}dan${2}masing-masing.Action
Redirect
-
Protocol:
${protocol} -
Domain Name:
${host} -
Port:
${port} -
Path:
/${1}/${2} -
Search:
${query} -
Status Code:
301
-
FAQ
Menulis ulang hanya nama domain
Untuk menulis ulang nama domain yang diminta ke domain lain sambil menjaga path dan string kueri tetap tidak berubah, konfigurasikan aturan sebagai berikut:
-
Add Condition: Setel nama domain ke nama domain asli, misalnya
old.example.com. -
Action: Pilih rewrite. Setel nama domain ke nama domain baru (misalnya
new.example.com), path ke${path}, dan kueri ke${query}. Juga, konfigurasikan Forward untuk menentukan kelompok server.
Menambahkan awalan ke path
Untuk menambahkan awalan ke path (misalnya, menulis ulang /users/list menjadi /v2/users/list), konfigurasikan aturan sebagai berikut:
-
Add Condition: Setel path agar cocok dengan ekspresi reguler
^/(.*). -
Action: Pilih rewrite dan setel path ke
/v2/${1}. Juga, konfigurasikan Forward untuk menentukan kelompok server.
Setelah Anda mengonfigurasi aturan tersebut, ALB menulis ulang permintaan untuk /users/list menjadi /v2/users/list dan meneruskannya ke server backend.
Menghapus awalan path
Lihat Studi kasus 4: Meneruskan permintaan setelah menghapus awalan path dalam topik ini. Studi kasus ini memberikan contoh konfigurasi lengkap untuk menghapus awalan, seperti /api/*, dengan menggunakan pencocokan ekspresi reguler bersama aksi rewrite atau redirect.
Troubleshooting pencocokan dan routing aturan pengalihan
Jika aturan pengalihan Anda tidak mengarahkan permintaan seperti yang diharapkan, gunakan langkah troubleshooting berikut:
-
Periksa prioritas aturan: ALB mengevaluasi aturan dalam urutan menaik berdasarkan nomor prioritasnya dan berhenti pada kecocokan pertama. Jika aturan yang lebih luas memiliki nomor prioritas lebih rendah (dan dievaluasi terlebih dahulu), aturan yang lebih spesifik dengan nomor prioritas lebih tinggi tidak akan dicocokkan.
-
Periksa jenis pencocokan: Pastikan Anda menggunakan jenis pencocokan yang benar (exact match, wildcard, atau ekspresi reguler). Misalnya, exact match untuk
/apitidak cocok dengan/api/users. Untuk mencocokkan keduanya, Anda harus menggunakan wildcard, seperti/api/*. -
Periksa beberapa kondisi: Saat mengonfigurasi beberapa kondisi untuk satu aturan pengalihan, kondisi dengan jenis berbeda digabungkan dengan operator AND, sedangkan beberapa nilai untuk jenis kondisi yang sama digabungkan dengan operator OR. Untuk informasi lebih lanjut, lihat Konfigurasikan aturan pengalihan listener.
-
Periksa log akses: Gunakan bidang
hostdanrequest_uridalam log akses ALB untuk memverifikasi bahwa detail permintaan yang diterima ALB sesuai dengan harapan Anda.
Rewrite versus redirect
|
Item |
Rewrite |
Redirect |
|
Bilah alamat browser |
Tidak berubah (transparan bagi pengguna) |
Berubah ke URL baru |
|
Cara kerja |
ALB menulis ulang path permintaan secara internal lalu meneruskan permintaan ke server backend. Seluruh proses selesai dalam satu permintaan. |
ALB mengembalikan kode status 3xx, dan browser memulai permintaan kedua ke URL baru. |
|
Kasus penggunaan |
Penyesuaian path internal, seperti menghapus awalan atau menambahkan nomor versi. |
Pengalihan HTTP ke HTTPS, pengalihan domain telanjang ke www, dan migrasi URL lama. |
|
Memerlukan "Forward to" |
Ya. Aksi rewrite harus dikonfigurasi dengan aksi "Forward to" yang menentukan kelompok server. |
Tidak. Aksi redirect berdiri sendiri. |
Dokumen terkait
Untuk petunjuk mengonfigurasi aturan pengalihan listener untuk ALB, lihat Konfigurasikan aturan pengalihan listener.