Listener untuk Application Load Balancer Anda

Listener adalah proses yang memeriksa permintaan koneksi, menggunakan protokol dan port yang Anda konfigurasikan. Sebelum Anda mulai menggunakan Application Load Balancer, Anda harus menambahkan setidaknya satu pendengar. Jika penyeimbang beban Anda tidak memiliki pendengar, ia tidak dapat menerima lalu lintas dari klien. Aturan yang Anda tetapkan untuk pendengar menentukan cara penyeimbang beban merutekan permintaan ke target yang Anda daftarkan, seperti instance. EC2

Konfigurasi listener

Listener mendukung protokol dan port berikut ini:

Anda dapat menggunakan HTTPS pendengar untuk menurunkan pekerjaan enkripsi dan dekripsi ke penyeimbang beban Anda sehingga aplikasi Anda dapat fokus pada logika bisnis mereka. Jika protokol listenerHTTPS, Anda harus menerapkan setidaknya satu sertifikat SSL server pada listener. Untuk informasi selengkapnya, lihat Buat HTTPS pendengar untuk Application Load Balancer.

Jika Anda harus memastikan bahwa target mendekripsi HTTPS lalu lintas alih-alih penyeimbang beban, Anda dapat membuat Network Load Balancer dengan TCP pendengar di port 443. Dengan TCP pendengar, penyeimbang beban meneruskan lalu lintas terenkripsi ke target tanpa mendekripsi. Untuk informasi selengkapnya, lihat Panduan Pengguna untuk Network Load Balancer.

Application Load Balancers memberikan dukungan asli untuk. WebSockets Anda dapat memutakhirkan koneksi HTTP /1.1 yang ada ke koneksi WebSocket (wsatauwss) dengan menggunakan peningkatan HTTP koneksi. Saat Anda memutakhirkan, TCP koneksi yang digunakan untuk permintaan (ke penyeimbang beban serta ke target) menjadi WebSocket koneksi persisten antara klien dan target melalui penyeimbang beban. Anda dapat menggunakan WebSockets dengan keduanya HTTP dan HTTPS pendengar. Opsi yang Anda pilih untuk pendengar Anda berlaku untuk WebSocket koneksi serta HTTP lalu lintas. Untuk informasi selengkapnya, lihat Cara Kerja WebSocket Protokol di Panduan CloudFront Pengembang Amazon.

Application Load Balancers memberikan dukungan asli HTTP untuk/2 dengan pendengar. HTTPS Anda dapat mengirim hingga 128 permintaan secara paralel menggunakan satu koneksi HTTP /2. Anda dapat menggunakan versi protokol untuk mengirim permintaan ke target menggunakan HTTP /2. Untuk informasi selengkapnya, lihat Versi protokol. Karena HTTP /2 menggunakan koneksi front-end lebih efisien, Anda mungkin melihat lebih sedikit koneksi antara klien dan penyeimbang beban. Anda tidak dapat menggunakan fitur server-push /2. HTTP

Untuk informasi lebih lanjut, lihat Perutean permintaan di Panduan Pengguna Elastic Load Balancing.

Atribut pendengar

Berikut ini adalah atribut listener untuk Application Load Balancers

Aturan pendengar

Setiap pendengar memiliki tindakan default, juga dikenal sebagai aturan default. Aturan default tidak dapat dihapus dan selalu dilakukan terakhir. Aturan tambahan dapat dibuat dan terdiri dari prioritas, satu atau lebih tindakan, dan satu atau lebih kondisi. Anda dapat menambahkan atau mengedit peraturan kapan saja. Untuk informasi selengkapnya, lihat Mengedit peraturan.

Peraturan default

Bila Anda membuat listener, Anda menentukan tindakan untuk peraturan default. Peraturan default tidak dapat memiliki syarat. Jika tidak ada syarat untuk peraturan listener yang terpenuhi, maka tindakan untuk peraturan default akan dilakukan.

Berikut ini adalah contoh peraturan default seperti yang ditunjukkan dalam konsol:

Prioritas peraturan

Setiap peraturan memiliki prioritas. Peraturan dievaluasi dalam urutan prioritas, dari nilai terendah ke nilai tertinggi. Peraturan default dievaluasi terakhir. Anda dapat mengubah prioritas peraturan nondefault kapan saja. Anda tidak dapat mengubah prioritas peraturan default. Untuk informasi selengkapnya, lihat Perbarui prioritas aturan.

Tindakan aturan

Setiap tindakan aturan memiliki jenis, prioritas, dan informasi yang diperlukan untuk melakukan tindakan. Untuk informasi selengkapnya, lihat Jenis tindakan peraturan.

Syarat peraturan

Setiap syarat peraturan memiliki jenis dan konfigurasi informasi. Bila syarat untuk suatu peraturan terpenuhi, maka tindakannya dilakukan. Untuk informasi selengkapnya, lihat Jenis syarat peraturan.

Jenis tindakan peraturan

Berikut ini adalah jenis tindakan yang didukung untuk peraturan listener:

Tindakan dengan prioritas terendah dilakukan terlebih dahulu. Setiap peraturan harus menyertakan satu dari tindakan berikut: forward, redirect, atau fixed-response, dan itu harus menjadi tindakan terakhir yang harus dilakukan.

Jika versi protokol adalah g RPC atau HTTP /2, satu-satunya tindakan yang didukung adalah forward tindakan.

Tindakan respons tetap

Anda dapat menggunakan fixed-response tindakan untuk menghapus permintaan klien dan mengembalikan HTTP respons khusus. Anda dapat menggunakan tindakan ini untuk mengembalikan kode respons 2XX, 4XX, atau 5XX dan pesan opsional.

Ketika fixed-response tindakan diambil, tindakan dan target URL pengalihan dicatat dalam log akses. Untuk informasi selengkapnya, lihat Entri log akses. Hitungan tindakan fixed-response yang berhasil dilaporkan dalam metrik HTTP_Fixed_Response_Count. Untuk informasi selengkapnya, lihat Metrik Application Load Balancer.

[
  {
      "Type": "fixed-response",
      "FixedResponseConfig": {
          "StatusCode": "200",
          "ContentType": "text/plain",
          "MessageBody": "Hello world"
      }
  }
]

Tindakan ke depan

Anda dapat menggunakan tindakan forward untuk mengarahkan permintaan ke satu grup target atau lebih. Jika Anda menentukan beberapa kelompok target untuk tindakan forward, Anda harus menentukan bobot untuk setiap grup target. Bobot setiap grup target adalah nilai dari 0 hingga 999. Permintaan yang sesuai dengan peraturan listener dengan kelompok target tertimbang didistribusikan ke grup target ini berdasarkan bobot mereka. Misalnya, jika Anda menentukan dua grup target, masing-masing dengan bobot 10, setiap grup target menerima setengah dari permintaan. Jika Anda menentukan dua grup target, satu dengan bobot 10 dan lainnya dengan bobot 20, grup target dengan bobot 20 menerima permintaan dua kali lebih banyak dari grup target lainnya.

Secara default, mengonfigurasi aturan untuk mendistribusikan lalu lintas di antara grup target berbobot tidak menjamin bahwa sesi lekat akan dipenuhi. Untuk memastikan bahwa sesi lekat dipatuhi, aktifkan kelekatan grup target untuk peraturan. Saat penyeimbang beban pertama kali merutekan permintaan ke grup target tertimbang, ia menghasilkan cookie bernama AWSALBTG yang mengkodekan informasi tentang grup target yang dipilih, mengenkripsi cookie, dan menyertakan cookie dalam respons terhadap klien. Klien harus menyertakan cookie yang diterimanya dalam permintaan berikutnya ke penyeimbang beban. Saat penyeimbang beban menerima permintaan yang cocok dengan peraturan dengan kelengketan grup target yang diaktifkan dan berisi cookie, permintaan akan diarahkan ke grup target yang ditentukan dalam cookie.

Application Load Balancers tidak mendukung nilai cookie yang URL dikodekan.

Dengan permintaan CORS (berbagi sumber daya lintas asal), beberapa browser SameSite=None; Secure perlu mengaktifkan kekakuan. Dalam hal ini, Elastic Load Balancing menghasilkan cookie kedua AWSALBTGCORS, yang mencakup informasi yang sama dengan cookie lengket asli ditambah atribut ini. SameSite Klien menerima kedua cookie.

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067"
              }
          ]
      }
  }
]

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ]
      }
  }
]

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ],
          "TargetGroupStickinessConfig": {
              "Enabled": true,
              "DurationSeconds": 1000
          }
      }
  }
]

Tindakan pengalihan

Anda dapat menggunakan redirect tindakan untuk mengalihkan permintaan klien dari satu URL ke yang lain. Anda dapat mengonfigurasi pengalihan sebagai sementara (HTTP302) atau permanen (HTTP301) berdasarkan kebutuhan Anda.

A URI terdiri dari komponen-komponen berikut:

protocol://hostname:port/path?query

Anda harus memodifikasi setidaknya satu dari komponen berikut untuk menghindari loop pengalihan: protokol, nama host, port, atau jalur. Setiap komponen yang tidak Anda ubah mempertahankan nilai aslinya.

Anda dapat menggunakan kembali URI komponen asli URL dalam target URL menggunakan kata kunci cadangan berikut:

Saat tindakan redirect diambil, tindakan tersebut dicatat dalam log akses. Untuk informasi selengkapnya, lihat Entri log akses. Hitungan tindakan redirect yang berhasil dilaporkan dalam metrik HTTP_Redirect_Count. Untuk informasi selengkapnya, lihat Metrik Application Load Balancer.

contoh Contoh tindakan pengalihan menggunakan konsol

Aturan berikut mengatur pengalihan permanen ke yang menggunakan HTTPS protokol dan port URL yang ditentukan (40443), tetapi mempertahankan nama host asli, jalur, dan parameter kueri. Layar ini setara dengan "https://#{host}:40443/#{path}?#{query}".

Aturan berikut mengatur pengalihan permanen ke URL yang mempertahankan protokol asli, port, nama host, dan parameter kueri, dan menggunakan #{path} kata kunci untuk membuat jalur yang dimodifikasi. Layar ini setara dengan "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".

[
  {
      "Type": "redirect",
      "RedirectConfig": {
          "Protocol": "HTTPS",
          "Port": "443",
          "Host": "#{host}",
          "Path": "/#{path}",
          "Query": "#{query}",
          "StatusCode": "HTTP_301"
      }
  }
]

Jenis syarat peraturan

Berikut adalah jenis syarat yang didukung untuk peraturan:

Setiap peraturan secara opsional dapat menyertakan hingga salah satu dari masing-masing syarat berikut: host-header, http-request-method, path-pattern, dan source-ip. Setiap peraturan dapat juga secara opsional mencakup satu atau lebih dari masing-masing syarat berikut: http-header dan query-string.

Anda dapat menentukan hingga tiga evaluasi kecocokan per syarat. Misalnya, untuk setiap http-header kondisi, Anda dapat menentukan hingga tiga string untuk dibandingkan dengan nilai HTTP header dalam permintaan. Kondisi terpenuhi jika salah satu string cocok dengan nilai HTTP header. Untuk mengharuskan semua string cocok, buat satu syarat per evaluasi kecocokan.

Anda dapat menentukan hingga lima evaluasi kecocokan per peraturan. Misalnya, Anda dapat membuat peraturan dengan lima ketentuan di mana setiap syarat memiliki satu evaluasi kecocokan.

Anda dapat memasukkan karakter wildcard dalam evaluasi kecocokan untuk syarat http-header, host-header, path-pattern, dan query-string. Ada batas lima karakter wildcard per peraturan.

Aturan hanya diterapkan pada karakter yang terlihat; ASCII karakter kontrol (0x00 hingga 0x1f dan 0x7f) dikecualikan.

Untuk demo, lihat Perutean permintaan lanjutan.

HTTPkondisi header

Anda dapat menggunakan kondisi HTTP header untuk mengonfigurasi aturan yang merutekan permintaan berdasarkan HTTP header untuk permintaan tersebut. Anda dapat menentukan nama bidang HTTP header standar atau kustom. Nama header dan evaluasi kecocokan tidak peka huruf besar/kecil. Karakter wildcard berikut didukung dalam string perbandingan: * (cocok dengan 0 karakter atau lebih) dan ? (cocok persis dengan 1 karakter). Karakter wildcard tidak didukung dalam nama header.

[
  {
      "Field": "http-header",
      "HttpHeaderConfig": {
          "HttpHeaderName": "User-Agent",
          "Values": ["*Chrome*", "*Safari*"]
      }
  }
]

HTTPkondisi metode permintaan

Anda dapat menggunakan kondisi metode HTTP permintaan untuk mengonfigurasi aturan yang merutekan HTTP permintaan berdasarkan metode permintaan permintaan. Anda dapat menentukan HTTP metode standar atau kustom. Evaluasi kecocokan peka terhadap huruf besar-kecil. Karakter wildcard tidak didukung; oleh karena itu, nama metode harus sama persis.

Kami menyarankan Anda merutekan GET dan HEAD meminta dengan cara yang sama, karena respons terhadap HEAD permintaan dapat di-cache.

[
  {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {
          "Values": ["CUSTOM-METHOD"]
      }
  }
]

Syarat host

Anda dapat menggunakan syarat host untuk menentukan peraturan yang merutekan permintaan berdasarkan nama host di header host (juga dikenal sebagai perutean berbasis host). Ini memungkinkan Anda untuk mendukung beberapa subdomain dan domain tingkat atas yang berbeda menggunakan penyeimbang beban tunggal.

Nama host tidak peka huruf besar/kecil, dapat memiliki panjang hingga 128 karakter, dan dapat berisi salah satu dari karakter berikut:

Anda harus menyertakan setidaknya satu karakter ".". Anda hanya dapat memasukkan karakter alfabet setelah akhir karakter ".".

Peraturan *.example.com cocok dengan test.example.com tetapi tidak cocok dengan example.com.

[
  {
      "Field": "host-header",
      "HostHeaderConfig": {
          "Values": ["*.example.com"]
      }
  }
]

Syarat jalur

Anda dapat menggunakan kondisi jalur untuk menentukan aturan yang merutekan permintaan berdasarkan permintaan (juga dikenal sebagai perutean berbasis jalur). URL

Pola jalur diterapkan hanya ke jalurURL, bukan ke parameter kuerinya. Ini hanya diterapkan pada karakter yang terlihat; ASCII karakter kontrol (0x00 hingga 0x1f dan 0x7f) dikecualikan.

Evaluasi aturan dilakukan hanya setelah URI normalisasi terjadi.

Pola jalur peka huruf besar-kecil, panjangnya bisa hingga 128 karakter, dan bisa berisi salah satu karakter berikut.

Jika versi protokol adalah gRPC, kondisi dapat spesifik untuk paket, layanan, atau metode.

Pola jalur digunakan untuk merutekan permintaan tetapi tidak mengubahnya. Misalnya, jika sebuah peraturan memiliki pola jalur /img/*, aturan meneruskan permintaan untuk /img/picture.jpg ke grup target yang ditentukan sebagai permintaan untuk /img/picture.jpg.

[
  {
      "Field": "path-pattern",
      "PathPatternConfig": {
          "Values": ["/img/*"]
      }
  }
]

Syarat string kueri

Anda dapat menggunakan syarat string kueri untuk mengonfigurasi aturan yang merutekan permintaan berdasarkan pasangan kunci/nilai atau nilai dalam string kueri. Evaluasi kecocokan tidak peka huruf besar-kecil. Karakter wildcard berikut didukung: * (cocok dengan 0 karakter atau lebih) dan ? (cocok persis dengan 1 karakter).

[
  {
      "Field": "query-string",
      "QueryStringConfig": {
          "Values": [
            {
                "Key": "version", 
                "Value": "v1"
            },
            {
                "Value": "*example*"
            }
          ]
      }
  }
]

Syarat alamat IP sumber

Anda dapat menggunakan syarat alamat IP sumber untuk mengonfigurasi aturan yang merutekan permintaan berdasarkan alamat IP sumber permintaan. Alamat IP harus ditentukan dalam CIDR format. Anda dapat menggunakan keduanya IPv4 dan IPv6 alamat. Karakter wildcard tidak didukung. Anda tidak dapat menentukan 255.255.255.255/32 CIDR untuk kondisi aturan IP sumber.

Jika klien berada di belakang proxy, ini adalah alamat IP proxy, bukan alamat IP klien.

Kondisi ini tidak dipenuhi oleh alamat di X-Forwarded-For header. Untuk mencari alamat di X-Forwarded-For header, gunakan http-header kondisi.

[
  {
      "Field": "source-ip",
      "SourceIpConfig": {
          "Values": ["192.0.2.0/24", "198.51.100.10/32"]
      }
  }
]

HTTPheader dan Application Load Balancers

HTTPpermintaan dan HTTP tanggapan menggunakan bidang header untuk mengirim informasi tentang HTTP pesan. HTTPheader ditambahkan secara otomatis. Bidang header adalah pasangan nama-nilai yang dipisahkan titik dua yang dipisahkan oleh carriage return (CR) dan line feed (LF). Satu set standar bidang HTTP header didefinisikan dalam RFC 2616, Header Pesan. Ada juga HTTP header non-standar yang tersedia yang secara otomatis ditambahkan dan banyak digunakan oleh aplikasi. Beberapa HTTP header non-standar memiliki awalan. X-Forwarded Application Load Balancer mendukung header X-Forwarded berikut.

Untuk informasi selengkapnya tentang HTTP koneksi, lihat Meminta perutean di Panduan Pengguna Elastic Load Balancing.

X-Diteruskan-Untuk

Header X-Forwarded-For permintaan membantu Anda mengidentifikasi alamat IP klien saat Anda menggunakan HTTP atau penyeimbang HTTPS beban. Karena penyeimbang beban mencegat lalu lintas antara klien dan server, log akses server Anda hanya berisi alamat IP penyeimbang beban. Untuk melihat alamat IP klien, gunakan routing.http.xff_header_processing.mode atribut. Atribut ini memungkinkan Anda untuk memodifikasi, mempertahankan, atau menghapus X-Forwarded-For header dalam HTTP permintaan sebelum Application Load Balancer mengirimkan permintaan ke target. Nilai yang mungkin untuk atribut ini adalahappend,preserve, danremove. Nilai default untuk atribut ini adalahappend.

Menambahkan

Secara default, Application Load Balancer menyimpan alamat IP klien di header X-Forwarded-For permintaan dan meneruskan header ke server Anda. Jika header X-Forwarded-For permintaan tidak disertakan dalam permintaan asli, penyeimbang beban membuat satu dengan alamat IP klien sebagai nilai permintaan. Jika tidak, penyeimbang beban menambahkan alamat IP klien ke header yang ada dan kemudian meneruskan header ke server Anda. Header permintaan X-Forwarded-For mungkin berisi beberapa alamat IP yang dipisahkan koma.

Header permintaan X-Forwarded-For memiliki bentuk berikut:

X-Forwarded-For: client-ip-address

Berikut adalah contoh header permintaan X-Forwarded-For untuk klien dengan alamat IP 203.0.113.7.

X-Forwarded-For: 203.0.113.7

Berikut ini adalah contoh header X-Forwarded-For permintaan untuk klien dengan IPv6 alamat2001:DB8::21f:5bff:febf:ce22:8a2e.

X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e

Ketika atribut pelestarian port klien (routing.http.xff_client_port.enabled) diaktifkan pada penyeimbang beban, header X-Forwarded-For permintaan menyertakan yang client-port-number ditambahkan keclient-ip-address, dipisahkan oleh titik dua. Header kemudian mengambil bentuk berikut:

IPv4 -- X-Forwarded-For: client-ip-address:client-port-number

IPv6 -- X-Forwarded-For: [client-ip-address]:client-port-number

UntukIPv6, perhatikan bahwa ketika penyeimbang beban menambahkan client-ip-address ke header yang ada, itu melampirkan alamat dalam tanda kurung siku.

Berikut ini adalah contoh header X-Forwarded-For permintaan untuk klien dengan IPv4 alamat 12.34.56.78 dan nomor port8080.

X-Forwarded-For: 12.34.56.78:8080

Berikut ini adalah contoh header X-Forwarded-For permintaan untuk klien dengan IPv6 alamat 2001:db8:85a3:8d3:1319:8a2e:370:7348 dan nomor port8080.

X-Forwarded-For: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:8080

Pertahankan

preserveMode dalam atribut memastikan bahwa X-Forwarded-For header dalam HTTP permintaan tidak dimodifikasi dengan cara apa pun sebelum dikirim ke target.

Menghapus

removeMode dalam atribut menghapus X-Forwarded-For header dalam HTTP permintaan sebelum dikirim ke target.

Tabel berikut menunjukkan contoh X-Forwarded-For header yang diterima target ketika Anda memilih salah satuappend, preserve atau remove mode. Dalam contoh ini, alamat IP dari hop terakhir adalah127.0.0.1.

Untuk memodifikasi, mempertahankan, atau menghapus X-Forwarded-For header menggunakan AWS CLI

Gunakan modify-load-balancer-attributesperintah dengan routing.http.xff_header_processing.mode atribut.

X-Diteruskan-Proto

Header X-Forwarded-Proto permintaan membantu Anda mengidentifikasi protokol (HTTPatauHTTPS) yang digunakan klien untuk terhubung ke penyeimbang beban Anda. Log akses server Anda hanya berisi protokol yang digunakan antara server dan penyeimbang beban; mereka tidak berisi informasi tentang protokol yang digunakan antara klien dan penyeimbang beban. Untuk menentukan protokol yang digunakan antara klien dan penyeimbang beban, gunakan header permintaan X-Forwarded-Proto. Elastic Load Balancing menyimpan protokol yang digunakan antara klien dan penyeimbang beban di header permintaan X-Forwarded-Proto dan meneruskan headerdan meneruskan tajuk ke server Anda ke server Anda.

Aplikasi atau situs web Anda dapat menggunakan protokol yang disimpan di header X-Forwarded-Proto permintaan untuk membuat respons yang dialihkan ke yang sesuai. URL

Header permintaan X-Forwarded-Proto memiliki bentuk berikut:

X-Forwarded-Proto: originatingProtocol

Contoh berikut berisi header X-Forwarded-Proto permintaan untuk permintaan yang berasal dari klien sebagai HTTPS permintaan:

X-Forwarded-Proto: https

Port-X-Diteruskan

Header permintaan X-Forwarded-Port membantu Anda mengidentifikasi port tujuan yang digunakan klien untuk menyambung ke penyeimbang beban.