Elastic Load Balancing
Networking Cloud Practitioner Solutions Architect Associate

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.

Czy wiesz, ze...

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.

Pro Tip

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.

1

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.

2

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.

3

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.

4

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.

5

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.

6

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.

Poczatkujacy

Path-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/*).

Poczatkujacy

Sticky 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.

Zaawansowany

Cross-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).

Zaawansowany

Slow 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.

Zaawansowany

Connection 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.

Poczatkujacy

Screenshoty 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?

01

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.

02

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.

03

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.

04

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.

Uzytkownik Wysyla request HTTP/HTTPS do aplikacji
DNS resolution
Route 53
Route 53 DNS alias record kieruje ruch do load balancera
HTTPS request
Elastic Load Balancer
Elastic Load Balancer ALB z listenerami HTTPS, regulami routingu i health checks
/app/* routing
Target Group A (EC2)
Target Group A (EC2) Instancje EC2 w Auto Scaling Group - frontend lub API
/api/* routing
Target Group B (ECS)
Target Group B (ECS) Kontenery ECS Fargate - mikroserwisy backendowe
metryki i alarmy
CloudWatch
CloudWatch Metryki: RequestCount, TargetResponseTime, HealthyHostCount, 5xx errors
ALB umozliwia path-based i host-based routing do roznych Target Groups z jednego load balancera.
Health checks automatycznie wylaczaja ruch do niezdowych celow, zapewniajac wysoka dostepnosc.
Cross-zone load balancing rownomiernie rozklada ruch miedzy wszystkie AZ - wlaczony domyslnie dla ALB.

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.

Twoj wynik: 0 / 4

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?

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.

Zacznij darmowy kurs Wszystkie serwisy