Amazon ANS-C01: Równoważenie obciążenia i zarządzanie ruchem — Przewodnik do nauki

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Część AWS Advanced Networking Specialty ANS-C01 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Podstawowa koncepcja

Równoważenie obciążenia w AWS działa na dwóch podstawowych warstwach: L4 (transportowej) i L7 (aplikacji). Network Load Balancer (NLB) zapewnia dystrybucję na warstwie L4 (TCP/UDP/TLS) i jest zoptymalizowany pod kątem ekstremalnej wydajności, zachowując źródłowy adres IP klienta i obsługując miliony jednoczesnych połączeń z bardzo niskimi opóźnieniami i rotacją połączeń. Application Load Balancer (ALB) działa na warstwie L7 (HTTP/HTTPS/WebSocket i HTTP/2/gRPC), zapewnia routing oparty na hoście i ścieżce, inspekcję nagłówków, kontrole kondycji oparte na HTTP i lepkość sesji opartą na ciasteczkach, a także wykonuje terminację TLS, gdy jest skonfigurowany z certyfikatami w ACM. Gateway Load Balancer (GWLB) to specjalnie zaprojektowany system równoważenia obciążenia do skalowania wirtualnych urządzeń firm trzecich (takich jak zapory sieciowe, IDS/IPS) przy użyciu enkapsulacji GENEVE i punktów końcowych Gateway Load Balancer (GWLBe), co umożliwia inspekcję ruchu w trybie inline bez konieczności ręcznego skalowania urządzeń.

Nasłuchiwacze (listeners) i reguły nasłuchiwaczy to punkty wejściowe L4/L7, które mapują protokoły/porty na grupy docelowe (target groups). Nasłuchiwacz na ALB może mieć złożone reguły, które sprawdzają hosta, ścieżkę, nagłówki, źródłowy CIDR IP i przekierowują ruch do różnych grup docelowych; ALB może również odciążać TLS (terminować) i prezentować nagłówki X-Forwarded-For, X-Forwarded-Proto i X-Forwarded-Port celom. Nasłuchiwacz NLB to zazwyczaj nasłuchiwacz TCP/UDP/TLS, który przekazuje ruch do grup docelowych bez parsowania zawartości (chyba że włączysz terminację TLS na NLB): przy użyciu TCP passthrough zachowujesz szyfrowanie TLS end-to-end, więc backend musi prezentować i walidować certyfikaty dla wzajemnego TLS (mTLS). Grupy docelowe to powiązanie między nasłuchiwaczem systemu równoważenia obciążenia a zbiorem punktów końcowych (instancja, IP lub Lambda) i udostępniają atrybuty takie jak protokół/port/ścieżka kontroli kondycji, opóźnienie wyrejestrowania (opróżnianie połączeń) i właściwości lepkości sesji.

Kluczowe usługi i konfiguracja

Wybierz odpowiedni system równoważenia obciążenia dla charakterystyki ruchu i wymagań bezpieczeństwa. Użyj ALB, gdy potrzebujesz routingu opartego na hoście/ścieżce, funkcji HTTP/HTTPS, takich jak WebSockets lub HTTP/2/gRPC z routingiem świadomym aplikacji, oraz lepkości sesji opartej na ciasteczkach. Konfiguruj nasłuchiwacze ALB za pomocą

undefined

lub

undefined

, dołączaj certyfikaty z ACM i ustawiaj reguły nasłuchiwacza za pomocą

undefined

z warunkami (Field=path-pattern, host-header, http-header). Włącz lepkość sesji w grupach docelowych ALB za pomocą

undefined

, ustawiając

undefined

oraz

undefined

, aby używać ciasteczek generowanych przez system równoważenia obciążenia.

Użyj NLB dla połączeń TCP o wysokiej przepustowości i długim czasie życia oraz gdy wymagane jest zachowanie źródłowego adresu IP klienta na backendzie. Utwórz NLB za pomocą

undefined

i dodaj nasłuchiwacz TCP za pomocą

undefined

. Dla trybu passthrough TLS i mTLS skonfiguruj nasłuchiwacz NLB jako TCP, aby TLS był terminowany przez backend; ustaw grupę docelową na

undefined

podczas rejestrowania adresów IP podów dla Kubernetes. Użyj

undefined

, aby ustawić

undefined

w celu umożliwienia opróżniania połączeń; dla NLB można również włączyć powinowactwo źródłowego adresu IP (lepkość grupy docelowej), jeśli jest to właściwe.

Gateway Load Balancer jest konfigurowany za pomocą

undefined

i wspierany przez grupy docelowe instancji twoich urządzeń wirtualnych (lub zestawu skalowania w grupie autoskalowania) i używa punktu końcowego Gateway Load Balancer w konsumenckich VPC do kierowania ruchu do urządzeń w VPC usługi. Użyj tego wzorca, gdy potrzebujesz transparentnej inspekcji i chcesz, aby urządzenia skalowały się automatycznie wraz z ruchem; utwórz nasłuchiwacze na porcie 6081 (enkapsulacja GENEVE) i zarejestruj ENI urządzeń w grupie docelowej GWLB.

Ustawienia operacyjne, które musisz kontrolować programistycznie, obejmują równoważenie obciążenia między strefami (cross-zone load balancing), opóźnienie wyrejestrowania (opróżnianie połączeń) oraz dostrajanie kontroli kondycji. Dla równoważenia między strefami ustaw atrybuty na systemie równoważenia obciążenia (

undefined

), aby zapewnić dystrybucję ruchu między strefami dostępności (AZ), zamiast nierównomiernego obciążania pojemności poszczególnych AZ. Ustaw interwał, limit czasu oraz progi healthy/unhealthy dla kontroli kondycji w grupach docelowych, aby uniknąć niestabilnego przełączania stanu podczas zdarzeń autoskalowania.

Wzorce projektowe i kompromisy

W przypadku szyfrowania end-to-end TLS i wzajemnego TLS (mTLS), gdzie ruch musi pozostać zaszyfrowany, a certyfikaty klienta muszą być przedstawione backendowi, preferuj przekazywanie na warstwie L4 (passthrough) za pomocą NLB z nasłuchiwaniem TCP. Utrzymuje to sesję TLS w nienaruszonym stanie, dzięki czemu backendy mogą weryfikować certyfikaty klienta X.509; skonfiguruj grupy docelowe (target groups) do używania celów IP (IP targets), aby adresy IP podów Kubernetes mogły być rejestrowane bezpośrednio, a AWS Load Balancer Controller mógł zarządzać cyklem życia celów. Kompromisem jest utrata funkcji ALB na warstwie L7, takich jak routing oparty na hoście/ścieżce, integracje z Web Application Firewall oraz natywna lepkość sesji (stickiness) oparta na ciasteczkach HTTP na poziomie load balancera.

Gdy potrzebujesz routingu opartego na treści, terminacji TLS i zaawansowanych funkcji HTTP, użyj ALB i zakończ sesję TLS na poziomie ALB (certyfikaty zarządzane przez ACM). Aby zachować adres IP klienta na potrzeby logowania i reguł WAF, odczytaj nagłówek X-Forwarded-For, który jest dodawany przez ALB, lub użyj warstwy, która wstrzykuje oryginalny adres IP klienta do nagłówków. Jeśli wymagasz, aby stos sieciowy/system operacyjny backendu widział adres IP klienta na poziomie gniazda (socket level), użyj NLB (lub włącz Proxy Protocol, aby przekazać oryginalny adres IP), ale pamiętaj, że Proxy Protocol musi być włączony w grupie docelowej, a Twoja aplikacja lub proxy (na przykład Envoy) musi go przetworzyć.

Obsługa sesji klejonych (sticky sessions) w środowisku autoskalowalnym wymaga starannego rozważenia. Lepkość sesji oparta na ciasteczkach w ALB może powiązać klienta z celem na określony czas, co może utrudniać zrównoważone skalowanie między podami w przypadku dużego ruchu sesyjnego; alternatywne wzorce obejmują użycie krótkotrwałej lepkości w połączeniu z eksternalizacją stanu sesji do ElastiCache (Redis) lub DynamoDB, lub użycie proxy w modelu sidecar (Envoy) do obsługi koligacji sesji (session affinity) za pomocą consistent hashing. Opróżnianie połączeń (connection draining, czyli opóźnienie wyrejestrowania) jest kluczowe dla płynnego zamykania (graceful shutdown): ustaw deregistration_delay.timeout_seconds na czas dłuższy niż najdłuższe żądanie RPC/HTTP, aby uniknąć nagłego przerwania połączeń i błędów po stronie klienta podczas zamykania poda; skonfiguruj hooki preStop w Kubernetes, aby skoordynować cykl życia poda z procesem wyrejestrowywania.

GWLB jest odpowiednim wzorcem, gdy potrzebujesz skalowalnej inspekcji w trybie inline w wielu VPC i chcesz scentralizowanych kontroli bezpieczeństwa. W razie potrzeby połącz GWLB z architekturami opartymi na Transit Gateway lub VPC peering; koszty i złożoność operacyjna zarządzania urządzeniami (appliance) są kompromisem w porównaniu z użyciem usług zarządzanych, takich jak AWS Network Firewall.

Typowe pułapki i kryteria decyzyjne

Częstym błędem jest terminowanie sesji TLS na poziomie ALB bez uwzględnienia potrzeb systemów docelowych w zakresie uwierzytelniania klienta lub oryginalnego źródłowego adresu IP. Jeśli backendy wymagają certyfikatu klienta lub prawdziwego źródłowego adresu IP na warstwie TCP (do logowania lub autoryzacji), należy terminować TLS na backendzie poprzez tryb passthrough w NLB lub użyć protokołu Proxy Protocol i upewnić się, że aplikacja go parsuje. Inną częstą pułapką jest włączanie sesji lepkich (sticky sessions) bez zewnętrznego magazynu sesji podczas korzystania z Horizontal Pod Autoscaler: w miarę skalowania podów w górę lub w dół, powiązanie sesji lepkich może tworzyć hotspoty i prowadzić do marnotrawstwa zasobów; preferuj bezstanowe backendy lub eksternalizuj stan sesji.

Błędy operacyjne wynikają również z nieprawidłowo skonfigurowanych kontroli stanu i opóźnień wyrejestrowania, które prowadzą do utraty żądań podczas skalowania. Zawsze ustawiaj ścieżki i progi kontroli stanu tak, aby odzwierciedlały czas rozgrzewania aplikacji, i używaj deregistration_delay.timeout_seconds, aby pozwolić na drenaż długotrwałych połączeń. Równoważenie obciążenia między strefami (cross-zone load balancing) powinno być konfigurowane świadomie: jego włączenie redukuje latencję ogonową i wyrównuje obciążenie, ale może zwiększyć koszty transferu danych między strefami AZ; należy to ocenić w kontekście pojemności stref AZ i wzorców ruchu. Wreszcie, GWLB wprowadza narzut związany z enkapsulacją (GENEVE) i zarządzaniem urządzeniami (appliance) — zautomatyzuj rejestrację urządzeń za pomocą AWS API (CreateTargetGroup/RegisterTargets) i monitoruj je za pomocą metryk CloudWatch, aby sterować politykami autoskalowania.

Praktyczny problem: Scenariusz użycia

Firma: Acme Telemetry. Wyzwanie: Zapewnienie szyfrowania end-to-end dla usługi gRPC (gRPC over TLS na porcie TCP 443) wdrożonej w klastrze Amazon EKS, obsługa tysięcy współbieżnych, długotrwałych połączeń, użycie Kubernetes Cluster Autoscaler i HPA oraz wymaganie wzajemnego uwierzytelniania TLS (mTLS), aby certyfikat klienta był walidowany przez backend (tzn. ruch nie może być deszyfrowany przez żaden pośredniczący load balancer).

1. Sposób implementacji przypadku użycia: Utwórz Network Load Balancer z listenerem TCP na porcie 443 i grupą docelową typu „ip” wskazującą na adresy IP podów. Utwórz NLB za pomocą

undefined

, utwórz grupę docelową za pomocą

undefined

, rejestruj cele za pomocą adnotacji kontrolera AWS Load Balancer dla Kubernetes (service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip”), dzięki czemu kontroler automatycznie rejestruje adresy IP podów, i utwórz listener za pomocą

undefined

. Ustaw atrybut grupy docelowej deregistration_delay.timeout_seconds na odpowiednią wartość (na przykład 300) za pomocą aws elbv2 modify-target-group-attributes, aby umożliwić płynny drenaż połączeń.

2. Konfiguracja TLS i mTLS na backendzie: Terminuj sesję TLS i realizuj wzajemne uwierzytelnianie TLS na poziomie podów. Wdróż kontenery sidecar z Envoy lub skonfiguruj serwery gRPC tak, aby bezpośrednio akceptowały połączenia TLS, przechowując certyfikaty serwera i pakiety CA w zasobach Kubernetes Secrets i montując je w podzie. Skonfiguruj backendy do walidacji certyfikatów klienta względem Twojego CA i skonfiguruj kontrole stanu, aby używały protokołu TCP, co pozwoli uniknąć terminowania TLS na load balancerze. Upewnij się, że haki cyklu życia HPA i Cluster Autoscaler koordynują wyrejestrowywanie z grupy docelowej poprzez implementację haków preStop, które pozwalają podom na dokończenie drenażu przed zakończeniem działania.

3. Skalowalność i kontrole operacyjne: Włącz równoważenie obciążenia między strefami na NLB, jeśli jest to wymagane, za pomocą

undefined

, aby równomiernie rozkładać połączenia między strefami AZ. Monitoruj liczbę współbieżnych połączeń i przepływność za pomocą metryk CloudWatch (NetworkPackets, ActiveFlowCount dla NLB) i ustaw polityki autoskalowania dla urządzenia (jeśli używasz sidecar) i dla węzłów roboczych. Użyj ModifyTargetGroupAttributes do drenażu połączeń i dostosuj interwały kontroli stanu w celu szybszego wykrywania awarii bez niestabilnego przełączania stanu (flapping). Na koniec zautomatyzuj rotację certyfikatów, używając integracji AWS Secrets Manager z cert-managerem w Kubernetes.

Uzasadnienie AWS: NLB w trybie TCP zachowuje sesję TLS na całej ścieżce (end-to-end), dzięki czemu backend może przeprowadzić walidację mTLS; jego architektura warstwy 4 (L4) jest zbudowana do obsługi milionów współbieżnych przepływów i długotrwałych połączeń, a użycie target-type ip pozwala kontrolerowi AWS Load Balancer na bezpośrednią rejestrację adresów IP podów, co umożliwia HPA/Cluster Autoscaler transparentne skalowanie. Drenaż połączeń (deregistration_delay) i kontrole stanu zapobiegają utracie żądań podczas terminacji podów, a równoważenie obciążenia między strefami zapewnia równomierny rozkład ruchu w strefach AZ, wymieniając koszt transferu między strefami na wydajność.

← DNS i Route 53 · Wszystkie domeny · Bezpieczeństwo sieci i zgodność →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →