Amazon ANS-C01: Projektowanie VPC i zaawansowane sieci — 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.

Podstawy architektury VPC i podsieci

VPC to fundamentalna granica sieciowa w AWS, a kształt alokacji CIDR definiuje wszystko, co następuje później. Planuj bloki CIDR z myślą o przyszłym wzroście i łączności między kontami: przydzielaj duże, nienakładające się przestrzenie adresowe na konto/region (na przykład /16 na środowisko) i dziel je na podsieci /20–/24, aby izolować obciążenia według funkcji i strefy dostępności. Pamiętaj, że EKS i inne platformy kontenerowe zużywają adresy IP na potrzeby interfejsów ENI podów lub dodatkowych adresów IP; AWS VPC CNI przydziela adresy IP podów z podsieci VPC, a limity ENI/IP na instancję (DescribeInstanceTypes) ograniczają maksymalną gęstość podów. W przypadku wdrażania IPv6 preferuj architekturę dual-stack, aby przenieść usługi publiczne na IPv6, zachowując IPv4 do integracji ze starszymi systemami; skojarz blok CIDR IPv6 dostarczony przez Amazon za pomocą wywołania API

undefined

i włącz przypisywanie IPv6 na poziomie podsieci za pomocą

undefined

i opcji

undefined

. Zaplanuj zasoby NAT dla ruchu wychodzącego (egress) IPv4, a dla IPv6 użyj Egress-Only Internet Gateway, utworzonego za pomocą

undefined

i dołączonego do VPC.

Tablice routingu i rozmieszczenie podsieci to sposoby na wymuszenie topologii i odporności na awarie. Twórz oddzielne tablice routingu dla każdego przeznaczenia podsieci (publiczna, prywatna z NAT, prywatna z Direct Connect i izolowana) za pomocą

undefined

. Używaj wielu bram NAT Gateway (lub instancji NAT z autoscalingiem) w różnych strefach AZ, aby uniknąć pojedynczego punktu awarii dla ruchu wychodzącego; jawnie określaj propagowane trasy podczas korzystania z Transit Gateway (

undefined

), aby prefiksy z lokalizacji on-premises były wstrzykiwane tylko tam, gdzie jest to zamierzone. Do odnajdywania usług wewnątrz konta użyj prywatnych stref hostowanych (private hosted zones) w Route 53 i powiąż je z VPC, które potrzebują tych rekordów, aby uniknąć wycieku zapytań DNS poza granice.

Kluczowe usługi i szczegóły konfiguracji

W przypadku łączności prywatnej istnieją trzy dominujące konstrukcje do zrozumienia: VPC Peering, AWS Transit Gateway i AWS PrivateLink (interfejsowe punkty końcowe VPC). VPC Peering (

undefined

) to prosta, tania łączność typu punkt-punkt, która wymaga wpisów w tablicy routingu i nie obsługuje routingu tranzytowego. Transit Gateway (

undefined

) to skalowalny hub, który obsługuje tysiące VPC, centralne sterowanie routingiem oraz integrację z Direct Connect Gateway dla łączności hybrydowej; użyj propagacji tras i powiązań tablic routingu w Transit Gateway, aby kontrolować przepływ ruchu wschód-zachód (east-west). PrivateLink (

undefined

do rejestracji usługi opartej na NLB i

undefined

do tworzenia interfejsowych punktów końcowych) udostępnia usługi między kontami bez wystawiania VPC na routing, zapewniając szczegółowe zabezpieczenia na poziomie usługi i uproszczone sterowanie grupami bezpieczeństwa; skaluje się dobrze, ponieważ konsumenci tworzą interfejsowe punkty końcowe, a ruch pozostaje na poziomie karty sieciowej (NIC).

Load balancing i zachowanie adresu IP klienta to częste wybory projektowe, które należy dobrze zaimplementować. Application Load Balancer (ALB) terminuje TLS, routuje na warstwie L7 (

undefined

) i wstrzykuje nagłówki X-Forwarded-For/X-Forwarded-Proto, którym backendy muszą ufać w celu logowania adresu IP klienta. Network Load Balancer (NLB) zachowuje źródłowe adresy IP dla grup docelowych i obsługuje miliony połączeń; aby uzyskać prawdziwe przekazywanie TLS (pass-through) do backendów, użyj NLB z listenerem TCP (

undefined

) i rejestruj cele według adresu IP, aby zaszyfrowane sesje docierały do podów lub instancji w nienaruszonym stanie. Dla gRPC i bardzo dużej liczby połączeń preferuj NLB przed EKS z typem celu ip i adnotacją AWS Load Balancer Controller

undefined

, aby rejestrować adresy IP podów bezpośrednio; ta kombinacja zachowuje źródłowy adres IP, obsługuje terminację mTLS na poziomie poda i skaluje się wraz z autoskalerami.

Punkty końcowe VPC eliminują potrzebę wychodzenia do internetu w celu uzyskania dostępu do API AWS i popularnych usług. Bramowe punkty końcowe (Gateway endpoints) dla S3 i DynamoDB (

undefined

) dodają trasy do listy prefiksów punktu końcowego i są bezpłatne. Interfejsowe punkty końcowe (Interface endpoints) (

undefined

) tworzą elastyczne interfejsy sieciowe (ENI) z prywatnymi adresami IP i grupami bezpieczeństwa; są rozliczane za godzinę i za GB, ale umożliwiają konsumpcję w stylu PrivateLink i dostęp między kontami, gdy są sparowane z usługą opartą na NLB.

Wzorce projektowe i kompromisy

Dla centralnej, współdzielonej usługi używanej przez wiele jednostek biznesowych na różnych kontach, PrivateLink i usługi punktów końcowych (endpoint services) są najbezpieczniejszym i najbardziej skalowalnym wzorcem, gdy wymagana jest kontrola i izolacja na poziomie pojedynczego połączenia. Umieść usługę za Network Load Balancer w VPC usług współdzielonych, utwórz usługę punktu końcowego VPC (CreateVpcEndpointServiceConfiguration) i pozwól kontom konsumenckim tworzyć interfejsowe punkty końcowe, które następnie zatwierdzisz. Unika się w ten sposób pełnej siatki połączeń (full mesh) i zapobiega routingowi tranzytowemu, a grupy bezpieczeństwa (security groups) na interfejsowych punktach końcowych pozwalają ograniczyć, którzy konsumenci mogą się łączyć. Kompromisem jest koszt za każdy punkt końcowy oraz pewien narzut administracyjny związany z akceptowaniem i audytowaniem połączeń z punktami końcowymi.

Transit Gateway sprawdza się doskonale, gdy masz wiele VPC, które potrzebują szerokiej łączności, centralnej inspekcji oraz jednego miejsca do rozgłaszania prefiksów on-premise przez Direct Connect (CreateTransitGatewayRoute, CreateTransitGatewayRouteTable). Użyj segmentacji tablic routingu i kontroli propagacji tras, aby uniknąć przypadkowego ruchu bocznego (lateral movement); Transit Gateway wspiera priorytetyzację tras i asocjacje tablic routingu, dzięki czemu możesz izolować ruch produkcyjny od sieci o niższym zaufaniu. Kompromisem jest to, że Transit Gateway centralizuje ruch i może generować koszty za ruch między VPC, który w innym przypadku byłby lokalny; zmienia również domeny awarii (failure domains) i wymaga starannego planowania CIDR, aby zapobiec nakładaniu się adresów.

Dla architektur hybrydowych z ograniczonym ponownym wykorzystaniem CIDR, rozważ połączenie Direct Connect z Transit Gateway i Direct Connect Gateway (CreateDirectConnectGateway), aby zmniejszyć liczbę wirtualnych interfejsów. Jeśli potrzebujesz izolacji przepustowości dla poszczególnych jednostek biznesowych na współdzielonym łączu fizycznym, utwórz wiele prywatnych wirtualnych interfejsów i monitoruj metryki CloudWatch dla każdego VIF (nazwy metryk takie jak AWS/DX: BytesIn, BytesOut) oraz używaj alarmów CloudWatch na poziomie VIF. Aby zidentyfikować użytkowników generujących największe obciążenie, włącz VPC Flow Logs (CreateFlowLogs) do S3 lub CloudWatch Logs i analizuj dane za pomocą Athena lub CloudWatch Logs Insights; do przechwytywania pakietów per-VM na krótkie okresy, użyj Traffic Mirroring (CreateTrafficMirrorSession).

Adopcja IPv6 i projekty dual-stack zmniejszają zależność od NAT, obniżają koszty przepustowości NAT Gateway i upraszczają adresację od strony klienta. Użyj wywołania API aws ec2 associate-vpc-cidr-block, aby przypisać dostarczony przez Amazon prefiks IPv6 i utwórz podsieci z blokami CIDR IPv6. Pamiętaj, że niektóre usługi i urządzenia firm trzecich mogą nie być gotowe na IPv6; użyj trybu dual-stack na load balancerach (CreateLoadBalancer z IpAddressType dualstack), aby wspierać zarówno klientów IPv4, jak i IPv6, podczas gdy systemy backendowe pozostają na IPv4.

Częste pułapki i kryteria decyzyjne

Zaniedbywanie zużycia adresów IP przez pody Kubernetes jest częstym źródłem zakłóceń w działaniu usług. Uwzględnij limity ENI i dodatkowych adresów IP dla danego typu instancji i użyj ustawień VPC CNI, takich jak WARM_IP_TARGETS lub delegacja prefiksów, aby poprawić dostępność adresów IP. Brak zachowania adresów IP klienta na warstwie L7 to kolejna częsta luka: jeśli TLS musi być terminowany na load balancerze, musisz upewnić się, że aplikacja odczytuje nagłówek X-Forwarded-For, a kontrole bezpieczeństwa ALB ograniczają bezpośredni dostęp, aby nagłówki były zaufane. Zakładanie, że VPC peering będzie skalował się w nieskończoność, często prowadzi do niemożliwych do zarządzania siatek połączeń; preferuj Transit Gateway dla połączeń wiele-do-wielu (many-to-many) i PrivateLink dla udostępniania usług jeden-do-wielu (one-to-many), gdzie wymagane jest granularne bezpieczeństwo i izolacja ruchu.

Polityki bezpieczeństwa powinny wykorzystywać grupy bezpieczeństwa (security groups) i sieciowe listy ACL w połączeniu z kontrolami na poziomie przestrzeni nazw (namespace). Aby ściśle wymusić dostęp przez Global Accelerator zamiast bezpośrednio przez URL-e ALB, polegaj na kombinacji zestawów IP w AWS WAF, które są wypełniane zakresami IP Global Accelerator (automatyzacja poprzez publikowany plik ip-ranges.json), lub zaprojektuj ALB jako wewnętrzny i umieść przed nim NLB, który będzie celem dla Global Accelerator, a następnie udostępnij tylko „drzwi wejściowe” Global Accelerator. Zawsze automatyzuj aktualizacje wszelkich kontroli opartych na adresach IP i weryfikuj je za pomocą DescribePrefixLists oraz regularnego pobierania pliku ip-ranges.json.

Praktyczny problem: Scenariusz użycia

Firma: Equinox Payments. Wyzwanie: Equinox uruchamia usługę gRPC opartą na EKS, która wymaga mTLS end-to-end dla tysięcy jednoczesnych połączeń, autoskalowania za pomocą Cluster Autoscaler i HPA oraz zachowania adresów IP klientów na potrzeby logowania. Podejście: 1) Wdróż usługę za Network Load Balancer skonfigurowanym z nasłuchem TCP na porcie 443 za pośrednictwem AWS Load Balancer Controller, używając adnotacji service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip", aby adresy IP podów były rejestrowane jako cele (targets); 2) Terminuj TLS na podach (a nie na NLB) i zaimplementuj mutual TLS w aplikacji (walidacja certyfikatów serwera i klienta), używając Kubernetes Secrets do przechowywania certyfikatów i sond gotowości (readiness probes) do sterowania rejestracją celów; 3) Użyj typu celu ip, aby zachować źródłowe adresy IP klientów, włącz proxy protocol tylko w razie potrzeby dla urządzeń pośredniczących i polegaj na logowaniu po stronie poda, aby przechwycić IP klienta z połączenia TCP; 4) Skonfiguruj kontrole stanu (health checks) jako sondy gotowości TCP lub świadome gRPC i upewnij się, że polityki Cluster Autoscaler oraz typy instancji węzłów mają wystarczającą pojemność ENI i IP; 5) Zaimplementuj CloudWatch Container Insights i VPC Flow Logs (CreateFlowLogs) do monitorowania liczby połączeń i telemetrii na poziomie VPC. Uzasadnienie AWS: NLB z nasłuchem TCP zachowuje zaszyfrowane sesje i źródłowe adresy IP, jednocześnie skalując się do milionów połączeń; typ celu ip pozwala podom otrzymywać źródłowy adres IP bezpośrednio, bez NAT; terminowanie mTLS na podach spełnia wymóg szyfrowania end-to-end i dwukierunkowego uwierzytelniania; autoskalowanie działa, ponieważ gotowość poda bezpośrednio wpływa na rejestrację celu, a NLB skaluje się transparentnie wraz z obciążeniem połączeniami.

Wszystkie domeny · Łączność hybrydowa: VPN i Direct Connect →

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