ALB a NLB i GLB: kiedy używać którego rozwiązania

Elastic Load Balancing (ELB) automatycznie rozdziela przychodzący ruch aplikacji między wiele celów — instancje EC2, kontenery, funkcje Lambda lub adresy IP. ELB to usługa zarządzana, co oznacza, że AWS obsługuje udostępnianie, skalowanie i dostępność samego modułu równoważenia obciążenia w wielu strefach dostępności.

AWS oferuje trzy typy modułów równoważenia obciążenia w ramach ELB: Application Load Balancer (ALB), Network Load Balancer (NLB) i Gateway Load Balancer (GWLB). Każdy działa na innej warstwie modelu OSI i jest zoptymalizowany pod kątem innych zastosowań.

ALB działa w warstwie 7 (HTTP/HTTPS) modelu OSI. Może analizować nagłówki HTTP, ścieżki, parametry zapytań, nazwy hostów i pliki cookie, aby podejmować inteligentne decyzje dotyczące routingu. ALB jest podstawowym wyborem dla aplikacji internetowych, mikrousług i punktów końcowych API wymagających routingu na podstawie treści.

Najważniejsze funkcje ALB: routing na podstawie ścieżki (/api/* do jednej grupy docelowej, /static/* do innej), routing na podstawie hosta (różne hosty wirtualne do różnych backendów), routing na podstawie nagłówków HTTP i parametrów zapytań, obsługa WebSocket oraz HTTP/2. ALB może kierować ruch do instancji EC2, kontenerów (ECS/EKS), funkcji Lambda i adresów IP.

NLB działa w warstwie 4 (TCP/UDP/TLS). Kieruje pakiety na podstawie danych protokołu IP bez analizowania zawartości aplikacji. NLB został zaprojektowany z myślą o wyjątkowej wydajności: obsługuje miliony żądań na sekundę przy bardzo małych opóźnieniach (zwykle poniżej 100 mikrosekund).

Najważniejsze funkcje NLB: statyczne adresy IP dla każdej strefy dostępności (jeden Elastic IP na podsieć), przekazywanie TLS (przekazywanie zaszyfrowanego ruchu bez odszyfrowywania), zachowanie adresu IP klienta oraz obsługa protokołów UDP (np. DNS, RADIUS i serwerów gier). NLB nie może wykonywać routingu na podstawie treści ani analizować nagłówków HTTP.

GWLB działa w warstwie 3 (warstwie sieci) i służy wyłącznie do wdrażania, skalowania oraz zarządzania wirtualnymi urządzeniami sieciowymi innych firm — zaporami sieciowymi, systemami wykrywania i zapobiegania włamaniom (IDS/IPS) oraz systemami głębokiej inspekcji pakietów.

GWLB używa protokołu GENEVE (port 6081) do hermetyzacji ruchu i przesyłania go do floty urządzeń. Urządzenie analizuje pakiet i zwraca go przez ten sam punkt końcowy GWLB. Ruch przepływa w sposób przezroczysty, bez konieczności zmiany routingu w źródłowym VPC. Jest to standardowy wzorzec wprowadzania scentralizowanej inspekcji bezpieczeństwa do przepływów ruchu AWS VPC.

Wybierz ALB, gdy:

• Potrzebujesz routingu HTTP/HTTPS na podstawie treści (ścieżki, hosta, nagłówka lub parametru zapytania)
• Twój backend obejmuje funkcje Lambda lub kontenery ECS
• Potrzebujesz połączeń WebSocket lub HTTP/2
• Chcesz zintegrować usługę z AWS WAF w celu zapewnienia bezpieczeństwa aplikacji internetowej na poziomie modułu równoważenia obciążenia
• Tworzysz architekturę mikrousług z wieloma usługami dostępnymi pod różnymi ścieżkami URL
• Potrzebujesz terminowania SSL/TLS na module równoważenia obciążenia

ALB jest prawidłową odpowiedzią w większości pytań egzaminu SAA-C03 dotyczących równoważenia obciążenia aplikacji internetowych i interfejsów REST API.

Wybierz NLB, gdy:

• Potrzebujesz wyjątkowej wydajności (miliony żądań na sekundę, opóźnienia poniżej milisekundy)
• Wymagasz statycznych adresów IP, które partnerzy lub zapory sieciowe mogą umieścić na liście dozwolonych
• Musisz obsługiwać ruch UDP (gry, DNS, RADIUS, IoT)
• Chcesz używać przekazywania TLS bez odszyfrowywania ruchu na module równoważenia obciążenia (szyfrowanie między klientem a celem)
• Potrzebujesz natywnego zachowania źródłowego adresu IP klienta na poziomie TCP
• Korzystasz z AWS PrivateLink do udostępniania usług innym VPC lub kontom (PrivateLink wymaga NLB)

Wybierz GWLB, gdy chcesz:

• Włączyć do przepływu ruchu sieciowego urządzenia zaporowe innych firm (Palo Alto, Fortinet, Check Point)
• Wykonywać głęboką inspekcję pakietów na poziomie VPC dla całego ruchu przychodzącego lub wychodzącego
• Skalować poziomo flotę urządzeń IDS/IPS za pomocą automatycznego równoważenia obciążenia

Architektura: ruch przepływa ze źródłowego VPC → punkt końcowy GWLB → VPC urządzeń (gdzie GWLB rozdziela ruch między instancje urządzeń) → urządzenie zwraca ruch do GWLB → GWLB przekazuje go do pierwotnego miejsca docelowego. Źródło i miejsce docelowe nie wiedzą o przeprowadzanej po drodze inspekcji.

Równoważenie obciążenia między strefami rozdziela ruch równomiernie między wszystkie zarejestrowane cele we wszystkich włączonych strefach dostępności, niezależnie od tego, w której strefie węzeł modułu równoważenia obciążenia otrzymał żądanie. Bez równoważenia między strefami węzeł każdej strefy rozdziela ruch wyłącznie między cele znajdujące się w tej samej strefie.

W ALB równoważenie między strefami jest domyślnie włączone i nie wiąże się z dodatkowymi kosztami. W NLB jest domyślnie wyłączone — jego włączenie powoduje naliczanie opłat za transfer danych między strefami. W GWLB równoważenie między strefami jest domyślnie wyłączone. Włącz je, gdy liczba celów w poszczególnych strefach jest różna, aby uniknąć przeciążonych punktów.

Szybka tabela porównawcza do egzaminu:

• Warstwa OSI: ALB = 7 (HTTP), NLB = 4 (TCP/UDP), GWLB = 3 (IP)
• Protokoły: ALB = HTTP, HTTPS, WebSocket; NLB = TCP, UDP, TLS; GWLB = wszystkie protokoły IP za pośrednictwem GENEVE
• Statyczny adres IP: ALB = nie (użyj wzorca NLB + ALB); NLB = tak (1 na strefę dostępności); GWLB = nie dotyczy
• Integracja z WAF: ALB = tak; NLB = nie; GWLB = nie
• Cel Lambda: ALB = tak; NLB = nie; GWLB = nie
• Opróżnianie połączeń: wszystkie trzy obsługują opóźnienie wyrejestrowania

ALB natywnie integruje się z AWS WAF w celu zapewnienia ochrony regionalnej (w przeciwieństwie do WAF na CloudFront, który zapewnia globalną ochronę na brzegu sieci). Dołączając listę ACL Web WAF do ALB, możesz filtrować żądania HTTP, zanim dotrą do aplikacji — blokując SQL injection, XSS, znane złośliwe adresy IP i klientów generujących zbyt wiele żądań.

Użyj ALB + WAF, gdy chcesz przeprowadzać inspekcję bezpieczeństwa na poziomie modułu równoważenia obciążenia (np. aby chronić interfejsy API, które nie są obsługiwane przez CloudFront). Listy ACL Web WAF dołączone do ALB muszą znajdować się w tym samym regionie co ALB i muszą mieć zakres REGIONAL (w przeciwieństwie do WAF CloudFront, który wymaga zakresu CLOUDFRONT w us-east-1).

AWS PrivateLink używa NLB do udostępniania usług z jednego VPC użytkownikom w innych VPC lub kontach AWS bez konieczności korzystania z peeringu VPC, bramy internetowej ani NAT. Dostawca usługi tworzy NLB przed swoją usługą, a następnie tworzy usługę punktu końcowego VPC. Użytkownicy tworzą w swoim VPC interfejsowy punkt końcowy VPC, który wskazuje tę usługę.

Ruch przepływa przez prywatną sieć AWS i nigdy nie przechodzi przez internet. PrivateLink to standardowy wzorzec dla dostawców SaaS w AWS oraz do udostępniania współdzielonych usług (np. scentralizowanej usługi bezpieczeństwa) wielu wewnętrznym kontom AWS.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji dowiedziałeś się, że: ALB wykonuje routing w warstwie 7 (HTTP) za pomocą reguł opartych na treści, integracji z WAF i celów Lambda; NLB wykonuje routing w warstwie 4 (TCP/UDP), zapewniając statyczne adresy IP i wyjątkową przepustowość; a GWLB wdraża wirtualne urządzenia sieciowe w warstwie 3, korzystając z GENEVE. Dopasuj moduł równoważenia obciążenia do wymaganych protokołów i funkcji. W następnej części omówimy grupy docelowe i kontrole kondycji.