Elastic Load Balancing
Elastic Load Balancing
Automatyczne rozkładanie ruchu między instancje, kontenery i funkcje Lambda. ALB, NLB i GLB dla wysokiej dostępności i skalowalności.
Elastic Load Balancing (ELB) automatycznie rozkłada ruch przychodzący między wiele celów - instancje EC2, kontenery ECS, adresy IP czy funkcje Lambda. Load balancer monitoruje zdrowie celów i kieruje ruch tylko do zdrowych instancji, zapewniając wysoką dostępność aplikacji.
AWS oferuje trzy typy load balancerów: Application Load Balancer (ALB) dla ruchu HTTP/HTTPS, Network Load Balancer (NLB) dla ruchu TCP/UDP o ultra-niskim latency i Gateway Load Balancer (GLB) dla urządzeń sieciowych. Każdy typ jest zoptymalizowany pod inne scenariusze.
Network Load Balancer potrafi obsłużyć nagły skok do milionów requestów na sekundę bez rozgrzewania (warm-up). W przeciwieństwie do ALB, który potrzebuje czasu na skalowanie, NLB jest gotowy od razu na ekstremalny ruch.
Dla większości aplikacji webowych zacznij od ALB. Używaj path-based routing, żeby jeden ALB obsługiwał wiele mikroserwisów - zaoszczędzisz na kosztach. NLB wybierz tylko gdy potrzebujesz stałego IP, ultra-niskiego latency lub protokołów innych niż HTTP.
Elastic Load Balancing automatycznie rozdziela ruch przychodzacy pomiedzy wiele celow - instancje EC2, kontenery ECS, adresy IP czy funkcje Lambda. AWS oferuje cztery typy load balancerow: Application (ALB) dla HTTP/HTTPS, Network (NLB) dla TCP/UDP z ultra-niska latencja, Gateway (GLB) dla appliance sieciowych i Classic (CLB) jako starszy typ. ELB skaluje sie automatycznie i zapewnia wysoka dostepnosc w wielu Availability Zones.
Wybor typu load balancera (ALB/NLB/GLB/CLB)
Wybor typu to kluczowa decyzja architektoniczna. ALB dziala na warstwie 7 (HTTP/HTTPS) - idealny dla aplikacji webowych, REST API i mikrouslug z routingiem opartym na sciezkach, naglowkach i query string. NLB dziala na warstwie 4 (TCP/UDP) - oferuje miliony requestow na sekunde z latencja ponizej milisekundy, statyczny IP i jest wymagany dla gRPC czy WebSocketow na skale. GLB to warstwa 3 - do integracji z firewallami i IDS/IPS. CLB jest przestarzaly - nie uzywaj go w nowych projektach.
Tworzenie Target Group
Target Group definiuje grupow celow, do ktorych load balancer kieruje ruch. Cele moga byc typu: instance (EC2 instance ID), ip (prywatny adres IP - przydatne dla kontenerow i on-premises), lambda (funkcja Lambda) lub alb (ALB za NLB). Konfiguracja obejmuje protokol (HTTP, HTTPS, TCP, gRPC), port docelowy i VPC. Jeden load balancer moze kierowac ruch do wielu Target Groups na podstawie regul routingu.
Rejestracja celow (targets)
Rejestracja dodaje konkretne zasoby do Target Group. Mozesz rejestrowac recznie (przez konsole, CLI lub API) lub automatycznie - Auto Scaling Group automatycznie rejestruje nowe instancje i wyrejestrowuje terminowane. Dla ECS serwis automatycznie rejestruje taski. Po rejestracji cel przechodzi przez poczatkowy health check zanim zacznie otrzymywac ruch. Stan kazedgo celu to: initial, healthy, unhealthy, unused lub draining.
Konfiguracja listenerow
Listener to proces nasluchiujacy na okreslonym porcie i protokole. ALB wspiera HTTP (80) i HTTPS (443) - dla HTTPS musisz dolaczyc certyfikat SSL/TLS z ACM. NLB wspiera TCP, TLS, UDP i TCP_UDP. Kazdy listener ma domyslna akcje (forward, redirect, fixed-response) i moze miec dodatkowe reguly. Typowa konfiguracja: listener HTTP na porcie 80 z redirectem na HTTPS, listener HTTPS na 443 z forwardem do Target Group.
Health checks - kontrola zdrowia celow
Health checks regularnie sprawdzaja dostepnosc zarejestrowanych celow. Konfigurujesz: protokol i sciezke sprawdzania (np. /health), port, interwal (domyslnie 30s), timeout, progi healthy/unhealthy threshold. ALB wysyla HTTP GET i sprawdza kod odpowiedzi (np. 200-299). NLB sprawdza polaczenie TCP. Cele oznaczone jako unhealthy przestaja otrzymywac ruch, ale nie sa automatycznie terminowane - to zadanie Auto Scaling. Unikaj kosztownych operacji w endpointach health check.
Reguly routingu (ALB)
Reguly routingu w ALB pozwalaja kierowac ruch na podstawie warunkow: sciezka URL (path-based, np. /api/* do backendu), naglowek Host (host-based, np. api.example.com), naglowki HTTP, metody HTTP, query string i zrodlowy adres IP. Reguly sa ewaluowane w kolejnosci priorytetu (nizszy numer = wyzszy priorytet). Akcje to: forward (do Target Group), redirect (np. HTTP na HTTPS), fixed-response (np. strona maintenance) i authenticate (integracja z Cognito lub OIDC).
Praktyczne wskazowki dotyczace konfiguracji load balancerow AWS - od wyboru typu po optymalizacje wydajnosci i kosztow w srodowisku produkcyjnym.
ALB vs NLB - kiedy ktory wybrac
ALB wybieraj, gdy potrzebujesz routingu opartego na tresci HTTP (sciezki, naglowki, host-based routing) - typowo dla mikrouslug, REST API i aplikacji webowych. NLB wybieraj dla ekstremalnej wydajnosci (miliony RPS), ultra-niskiej latencji, protokolow TCP/UDP (np. gRPC, MQTT, gaming), potrzeby statycznego IP lub PrivateLink. Czesty wzorzec: NLB przed ALB, gdy potrzebujesz jednoczesnie statycznego IP i zaawansowanego routingu HTTP. Unikaj CLB w nowych projektach.
PoczatkujacyPath-based routing dla mikrouslug
Uzywaj path-based routing w ALB do kierowania ruchu do roznych Target Groups na podstawie sciezki URL. Przyklad: /api/users/* do serwisu users, /api/orders/* do serwisu orders, /static/* do S3 (przez Target Group typu Lambda lub redirect). To pozwala uzyc jednego ALB zamiast wielu - oszczednosc kosztow i uproszczenie DNS. Pamietaj o kolejnosci regul: bardziej specyficzne sciezki powinny miec wyzszy priorytet niz ogolne (np. /api/users/admin przed /api/users/*).
PoczatkujacySticky sessions - kiedy uzywac
Sticky sessions (session affinity) kieruja kolejne requesty od tego samego klienta do tego samego celu. ALB wspiera dwa typy: duration-based (cookie AWSALB z konfigurowalnym TTL) i application-based (Twoje wlasne cookie). Uzywaj sticky sessions tylko gdy aplikacja przechowuje stan w pamieci sesji i nie mozesz przeniesc go do zewnetrznego store (Redis, DynamoDB). W wiekszosci przypadkow lepszym rozwiazaniem jest externalizacja stanu sesji - sticky sessions utrudniaja rownomierne rozlozenie ruchu i komplikuja skalowanie.
ZaawansowanyCross-zone load balancing
Cross-zone load balancing rozklada ruch rownomiernie miedzy wszystkie zarejestrowane cele we wszystkich wlaczonych Availability Zones. Dla ALB jest wlaczony domyslnie i bezplatny. Dla NLB jest wylaczony domyslnie i platny - ale w wiekszosci scenariuszy warto go wlaczyc, bo zapobiega nierownowaznemu obciazeniu AZ z mniejsza liczba celow. Wylacz go tylko gdy zalezy Ci na izolacji ruchu w obrebie AZ (np. latency-sensitive workloads).
ZaawansowanySlow start mode
Slow start mode stopniowo zwieksza ilosc ruchu kierowanego do nowo zarejestrowanego celu, zamiast od razu wysylac pelne obciazenie. Konfigurowalny czas trwania: 30-900 sekund. Kluczowe dla aplikacji, ktore potrzebuja czasu na rozgrzanie (warm-up) - np. JVM-based (Java, Kotlin), aplikacje z cache w pamieci lub connection pooling. Bez slow start nowy cel moze zostac zalany ruchem i zwracac bledy 5xx lub miec wysoka latencje w pierwszych sekundach.
ZaawansowanyConnection draining (deregistration delay)
Deregistration delay (dawniej connection draining) to czas, przez ktory load balancer kontynuuje kierowanie istniejacych polaczen do celu, ktory jest w trakcie wyrejestrowywania. Domyslna wartosc to 300 sekund - dla wiekszosci API mozesz ja zmniejszyc do 30-60 sekund. Dlugi delay spowalnia deployments i skalowanie w dol. Krotki delay moze powodowac przerwanie dlugich operacji. Dopasuj wartosc do maksymalnego czasu trwania requestu w Twojej aplikacji.
PoczatkujacyScreenshoty z AWS Console
Wkrotce pojawia sie tu zrzuty ekranu pokazujace jak korzystac z Elastic Load Balancing bezposrednio w konsoli AWS.
Do czego sluzy Elastic Load Balancing?
Aplikacje webowe z wysoką dostępnością
ALB rozkłada ruch HTTP/HTTPS między instancje EC2 w wielu Availability Zones. Jeśli jedna AZ padnie, ruch automatycznie trafia do zdrowych instancji.
Mikroserwisy i kontenery
ALB z path-based routing kieruje /api/* do jednego serwisu ECS, /auth/* do drugiego. Jeden load balancer obsługuje wiele mikroserwisów.
Aplikacje real-time i gaming
NLB obsługuje miliony połączeń TCP/UDP na sekundę z opóźnieniem poniżej milisekundy. Idealny dla gier online, IoT i tradingu.
Inspekcja ruchu sieciowego
GLB kieruje cały ruch przez urządzenia bezpieczeństwa (firewalle, IDS/IPS) przed dostarczeniem do aplikacji.
Co musisz wiedziec?
Application Load Balancer (ALB)
Load balancer warstwy 7 (HTTP/HTTPS). Wspiera routing na podstawie ścieżki URL, nagłówków, query stringów. Idealny dla aplikacji webowych i mikroserwisów.
Network Load Balancer (NLB)
Load balancer warstwy 4 (TCP/UDP/TLS). Ultra-niskie latency, miliony requestów na sekundę, stały adres IP. Dla aplikacji wymagających najwyższej wydajności.
Gateway Load Balancer (GLB)
Load balancer warstwy 3 (IP). Kieruje ruch przez appliance sieciowe (firewalle, IDS) w sposób transparentny dla aplikacji.
Target Group
Grupa celów (instancje EC2, IP, Lambda), do których load balancer kieruje ruch. Każda target group ma własne health checki i reguły routingu.
Health Check
Okresowe sprawdzanie zdrowia celów. Load balancer wysyła requesty testowe (np. GET /health) i usuwa z rotacji cele, które nie odpowiadają poprawnie.
SSL Termination
Load balancer odszyfrowuje ruch HTTPS, odciążając backend. Certyfikat SSL instalujesz na load balancerze, backend komunikuje się po HTTP.
Architektura: Elastic Load Balancing z wieloma Target Groups
Typowa architektura produkcyjna, w ktorej ALB rozdziela ruch HTTP/HTTPS pomiedzy rozne Target Groups na podstawie regul routingu. Route 53 kieruje uzytkownikow do load balancera, a CloudWatch monitoruje metryki zdrowia i wydajnosci.
ALB vs NLB vs GLB
| Cecha | ALB | NLB | GLB |
|---|---|---|---|
Ile kosztuje Elastic Load Balancing?
ALB
Opłata godzinowa + LCU (Load Balancer Capacity Units) na podstawie nowych połączeń, aktywnych połączeń, przetworzonych bajtów i reguł.
$0.0225/godz. + $0.008/LCU (~$16/mies. + ruch)
NLB
Opłata godzinowa + NLCU (Network LCU) na podstawie nowych połączeń, aktywnych połączeń i przetworzonych bajtów.
$0.0225/godz. + $0.006/NLCU (~$16/mies. + ruch)
GLB
Opłata godzinowa + GLCU (Gateway LCU) na podstawie nowych połączeń, aktywnych połączeń i przetworzonych bajtów.
$0.0125/godz. + $0.004/GLCU
Transfer danych
Standardowe opłaty AWS za transfer danych. Transfer wewnątrz AZ między load balancerem a celami jest darmowy.
Transfer w ramach jednej AZ: $0
Przyklady AWS CLI
Utwórz Application Load Balancer
Tworzy ALB w dwóch Availability Zones
aws elbv2 create-load-balancer \
--name moj-alb \
--type application \
--subnets subnet-abc123 subnet-def456 \
--security-groups sg-xyz789
Utwórz Target Group
Tworzy target group z health checkiem na endpoint /health
aws elbv2 create-target-group \
--name moja-target-group \
--protocol HTTP --port 80 \
--vpc-id vpc-abc123 \
--health-check-path /health \
--health-check-interval-seconds 30
Zarejestruj cele
Dodaje instancje EC2 do target group
aws elbv2 register-targets \
--target-group-arn arn:aws:elasticloadbalancing:eu-central-1:123456789012:targetgroup/moja-tg/abc123 \
--targets Id=i-1234567890abcdef0 Id=i-0987654321fedcba0
Dodaj listener HTTPS
Tworzy listener HTTPS na porcie 443 z certyfikatem ACM
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:eu-central-1:123456789012:loadbalancer/app/moj-alb/abc123 \
--protocol HTTPS --port 443 \
--certificates CertificateArn=arn:aws:acm:eu-central-1:123456789012:certificate/abc-123 \
--default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:eu-central-1:123456789012:targetgroup/moja-tg/abc123
Quiz: Elastic Load Balancing
Sprawdz czy dobrze rozumiesz podstawy. Kliknij odpowiedz — feedback pojawi sie od razu.
1. Który load balancer jest najlepszy dla aplikacji webowej z routing na podstawie URL?
2. Co się dzieje, gdy health check load balancera wykryje niezdrowią instancję?
3. Który load balancer oferuje stały adres IP?
4. Czym jest SSL Termination w kontekście load balancera?
Czesto uzywane razem z Elastic Load Balancing
Czytaj więcej o Elastic Load Balancing
Chcesz poznac Elastic Load Balancing w praktyce?
Darmowy kurs "AWS od podstaw" pokazuje jak uzywac Elastic Load Balancing krok po kroku. Teoria + praktyka od zera.