Amazon ANS-C01: Łączność hybrydowa: VPN i Direct Connect — 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.

Główne koncepcje

Łączność hybrydowa w AWS to połączenie prywatnie udostępnianych obwodów sieciowych i szyfrowanych tuneli IP w celu rozszerzenia sieci on‑premises na chmurę AWS. Site-to-Site VPN dostarcza tunele IPsec (IKEv1/IKEv2) zakończone na Virtual Private Gateway (VGW) lub Transit Gateway; AWS udostępnia dwa niezależne tunele na każde połączenie VPN w celu zapewnienia odporności i obsługuje BGP do dynamicznego routingu lub, w razie potrzeby, trasy statyczne. Client VPN to zarządzany punkt końcowy oparty na OpenVPN, który obsługuje wzajemne uwierzytelnianie certyfikatami (ACM Private CA lub wgrane certyfikaty klienta) lub federację SAML do obsługi tożsamości użytkownika, propagację tras do VPC lub Transit Gateway oraz dzielenie tunelu po stronie klienta (split-tunnelling) w celu ograniczenia ruchu przechodzącego do AWS.

AWS Direct Connect oferuje dedykowane fizyczne połączenie między Twoją lokalizacją a AWS. Połączenia mogą być dedykowane (udostępniane przez AWS) lub hostowane (udostępniane przez partnera); można agregować wiele połączeń za pomocą Link Aggregation Group (LAG), aby przedstawić je jako pojedynczy interfejs logiczny i zwiększyć przepustowość; Direct Connect obsługuje prywatne interfejsy wirtualne (private VIF) do VPC, publiczne VIF do publicznych punktów końcowych AWS oraz tranzytowe VIF do Direct Connect Gateway w celu zapewnienia łączności wieloregionowej lub z Transit Gateway. W celu ochrony danych na łączu fizycznym, w obsługiwanych lokalizacjach dostępny jest MACsec, który zapewnia szyfrowanie ramek w warstwie 2 między urządzeniem brzegowym klienta a brzegiem sieci AWS, a szyfrowanie w locie w warstwie 3 pozostaje w gestii punktów końcowych IPsec lub TLS.

Niezawodność i routing wymagają jawnej kontroli nad przełączaniem awaryjnym (failover) i wyborem ścieżki. Atrybuty BGP (local-preference, AS path prepending) są używane do preferowania Direct Connect nad VPN w celu uzyskania niskich opóźnień i wysokiej przepustowości, przy czym Site-to-Site VPN lub drugie połączenie DX działa jako automatyczna kopia zapasowa. Gdy wymagane jest szyfrowanie TLS end-to-end lub gdy aplikacje wymagają zachowania źródłowego adresu IP klienta i bardzo dużej liczby długotrwałych połączeń TCP (np. gRPC przez TLS na porcie 443), należy używać wzorców TCP/TLS passthrough, takich jak Network Load Balancer (NLB) lub bezpośrednie publiczne punkty końcowe na węzłach EKS z odpowiednimi kontrolami bezpieczeństwa; gdy akceptowalne jest zakończenie połączenia na brzegu sieci, Application Load Balancer (ALB) obsługuje HTTP/2 i gRPC oraz kończy sesje TLS, wstawiając nagłówki X-Forwarded-For, aby pody backendowe mogły logować adresy IP klientów.

Kluczowe usługi i konfiguracja

Podczas tworzenia Site-to-Site VPN używa się API EC2 CreateVpnConnection (aws ec2 create-vpn-connection) i zazwyczaj dołącza wynikowe vpn-connection do virtual private gateway (create-vpn-gateway i attach-vpn-gateway) lub do transit gateway, podając transit-gateway-id. Skonfiguruj urządzenie customer gateway przy użyciu wygenerowanych parametrów tunelu: wersja IKE, algorytmy szyfrowania (AES-GCM), haszowanie (SHA-2), grupa Diffie-Hellmana, czas życia (lifetime) i klucz współdzielony (pre-shared key). Dla routingu dynamicznego włącz BGP i skonfiguruj ASN oraz IP sąsiada BGP; w celu szybszego wykrywania awarii na warstwie routera użyj BFD, jeśli jest obsługiwane, między urządzeniami on-prem a brzegiem sieci AWS.

Punkty końcowe Client VPN tworzy się za pomocą API EC2 CreateClientVpnEndpoint (aws ec2 create-client-vpn-endpoint). Należy podać certyfikat serwera z ACM, opcję uwierzytelniania (certyfikat lub SAML) i powiązać punkt końcowy z jedną lub wieloma podsieciami VPC w celu utworzenia elastycznych interfejsów sieciowych. Użyj authorize-client-vpn-ingress, aby otworzyć dozwolone sieci zgodnie z regułą autoryzacji, oraz create-client-vpn-route, aby wypchnąć trasy do VPC. Dla dużych populacji użytkowników i dostępu warunkowego zintegruj Client VPN z AWS Directory Service lub dostawcami tożsamości SAML i skaluj współbieżność, przypisując wystarczające zakresy adresów CIDR do punktu końcowego Client VPN.

Provisioning Direct Connect wykorzystuje API Direct Connect, takie jak create-connection, lub, w przypadku połączeń partnerskich, partner udostępnia połączenie hostowane, a ty używasz API allocate-hosted-connection lub accept-virtual-interface. Aby agregować łącza fizyczne, wywołaj create-lag, a następnie create-private-virtual-interface lub create-transit-virtual-interface, aby dołączyć wirtualny interfejs do VPC lub Direct Connect Gateway. W przypadku MACsec, skontaktuj się z partnerem lub portalem zamówień AWS, aby zamówić MACsec na połączeniu; konfiguracja obejmuje wymianę kluczy i dopasowanie pakietu szyfrów (cipher suite) na przełączniku brzegowym klienta, a polecenia operacyjne są zazwyczaj koordynowane w czasie provisioningu. W architekturach z wieloma VPC preferuj Direct Connect Gateway z tranzytowym VIF do połączenia z Transit Gateway — takie rozwiązanie skaluje się lepiej niż tworzenie wielu prywatnych VIF i pozwala na scentralizowany routing poprzez tablice routingu TGW.

Wzorce projektowe i kompromisy

Wybierz architekturę active-active, aby uzyskać wysoką przepustowość i krótki czas przełączania awaryjnego, umieszczając dwa połączenia Direct Connect w różnych lokalizacjach, rozgłaszając identyczne prefiksy za pomocą BGP i używając LAG do agregacji łączy w ramach jednej lokalizacji. Architektura active-active z BGP multipath zapewnia wyższą wydajność i rzeczywiste rozłożenie obciążenia; wymaga to jednak symetrycznego routingu, kompatybilnego lokalnego BGP oraz starannego dostrojenia atrybutów AS‑path i local‑preference. Użyj Site‑to‑Site VPN jako automatycznego zapasu w trybie active‑passive, ponieważ tunele IPsec są odporne na awarie i globalnie dostępne, ale należy spodziewać się większego jittera, niższej przepustowości i dłuższego czasu przełączania awaryjnego w porównaniu z Direct Connect. Gdy wymagana jest deterministyczna łączność o niskim opóźnieniu, preferowane jest drugie połączenie DX, pomimo wyższych kosztów.

W przypadku wymagań TLS na poziomie aplikacji, wybory projektowe zależą od tego, czy load balancer może mieć wgląd w odszyfrowany ruch. Jeśli wymagany jest wzajemny TLS (mTLS) typu end‑to‑end, zakończ sesję TLS na backendzie, używając NLB w trybie TCP/TLS passthrough i pozwól, aby pody Kubernetes Ingress obsługiwały mTLS; użyj target type ip dla EKS, aby pody mogły się skalować, a Cluster Autoscaler mógł dodawać węzły bez zmiany konfiguracji NLB, oraz włącz proxy protocol v2, jeśli potrzebujesz oryginalnego źródłowego adresu IP klienta na poziomie poda. Jeśli akceptowalne jest zakończenie sesji TLS na ALB, użyj ALB z listenerem HTTPS, skonfiguruj certyfikaty w ACM, włącz HTTP/2 dla wsparcia gRPC i polegaj na nagłówku X‑Forwarded‑For w celu uzyskania adresów IP klienta; ALB umożliwia routing oparty na ścieżce (path‑based routing) do wielu grup docelowych w celu dystrybucji ruchu na podstawie adresu URL.

Dla łączności obejmującej wiele kont i wiele VPC, gdzie wymagane jest szczegółowe bezpieczeństwo i skalowalność, wzorzec hub‑and‑spoke z Transit Gateway i scentralizowanym Direct Connect Gateway zapewnia najlepszą skalę. Podłącz VPC każdej jednostki biznesowej do Transit Gateway (TGW) i powiąż TGW z Direct Connect Gateway za pomocą interfejsu transit VIF. Użyj tablic routingu TGW do wymuszenia segregacji oraz stosuj polityki na poziomie zasobów, Security Groups i Network ACLs w celu uzyskania szczegółowej kontroli. Kompromisem jest złożoność operacyjna w zarządzaniu tablicami routingu TGW oraz potrzeba starannego projektowania granic kont i uprawnień IAM.

Częste pułapki i kryteria decyzyjne

Częstym błędem jest poleganie na pojedynczym VIF na VPC bez uwzględnienia limitów VIF i złożoności operacyjnej w miarę wzrostu liczby VPC; użyj Direct Connect Gateway i tranzytowych VIF, gdy przewidujesz wiele VPC lub wiele regionów. Inną częstą pułapką jest założenie, że VPN i Direct Connect działają identycznie: renegocjacja kluczy IPsec, implikacje MTU i różnice w przepustowości na tunel oznaczają, że VPN jest niezawodnym rozwiązaniem zapasowym, ale nie jest odpowiednikiem pod względem wydajności. Błędna konfiguracja terminacji TLS i oczekiwań co do adresu IP klienta w systemach podrzędnych to kolejne źródło błędów — wybierz NLB w trybie passthrough dla prawdziwego end-to-end TLS z mTLS, lub terminację na ALB i przetwarzanie nagłówka X‑Forwarded‑For, jeśli brzeg sieci może terminować TLS.

Na koniec, monitorowanie i wgląd w działanie systemu są kluczowe. Włącz metryki CloudWatch dla Direct Connect (ConnectionBpsEgress/Ingress), flow logs dla wglądu w ruch VPC i użyj alarmów CloudWatch do uruchamiania automatyzacji w celu przełączania ruchu lub powiadamiania inżynierów sieciowych. W celu szczegółowej atrybucji ruchu, gdy wiele jednostek biznesowych współdzieli przepustowość na LAG, skoreluj statystyki VIF i flow logs VPC oraz rozważ wprowadzenie kontroli przepustowości na poziomie VPC na brzegu sieci, aby uniknąć problemów z „głośnym sąsiadem” (noisy neighbor).

Problem praktyczny: Scenariusz użycia

Firma: Meridian Medical Analytics. Wyzwanie: Meridian obsługuje globalną flotę urządzeń do obrazowania medycznego, które używają gRPC przez port TCP 443 do przesyłania dużych wolumenów zaszyfrowanych strumieni do backendu hostowanego w klastrze Amazon EKS w regionie us-east-1. Urządzenia wymagają wzajemnego TLS (mutual TLS) do dwukierunkowego uwierzytelniania klienta oraz obsługi tysięcy jednoczesnych, długotrwałych połączeń. Klaster EKS skaluje się automatycznie za pomocą Cluster Autoscaler i HPA. Meridian potrzebuje deterministycznie niskiego opóźnienia z ich głównego centrum danych oraz automatycznego przełączania awaryjnego (failover) na chmurowy VPN.

Podejście:

1. Utwórz Network Load Balancer (NLB) przed usługą EKS z nasłuchiwaniem TCP na porcie 443 i typem celu (target type) ustawionym na IP, aby punkty końcowe podów mogły być bezpośrednimi celami; skonfiguruj NLB do pracy w trybie TLS passthrough (nie terminuj TLS na NLB), aby wzajemny TLS był negocjowany z podami backendu. Użyj aws elbv2 create-load-balancer i create-listener do skonfigurowania NLB i grup docelowych (target groups).
2. Skonfiguruj kontenery podów EKS (Ingress lub sidecar) do terminowania wzajemnego TLS przy użyciu certyfikatów serwera i klienta z prywatnego urzędu certyfikacji (ACM Private CA do wydawania certyfikatów serwera; certyfikaty klienta dostarczane na urządzenia). Upewnij się, że pody obsługują HTTP/2 gRPC i skalują się za pomocą HPA i Cluster Autoscaler; użyj opóźnienia wyrejestrowania grupy docelowej (target group deregistration delay) dostosowanego do długotrwałych połączeń.
3. Dla łączności on-premise, utwórz dedykowane połączenie Direct Connect (create-connection) zagregowane za pomocą LAG, jeśli dostępne są liczne obwody fizyczne, i utwórz prywatny wirtualny interfejs (create-private-virtual-interface) do Direct Connect Gateway połączonego z Twoim Transit Gateway w celu routingu do VPC klastra EKS. Włącz MACsec podczas tworzenia połączenia, jeśli dostawca i lokalizacja go obsługują, aby zabezpieczyć transport w warstwie 2.
4. Zaimplementuj Site‑to‑Site VPN (aws ec2 create-vpn-connection do Transit Gateway) jako automatyczną ścieżkę awaryjną; kontroluj przełączanie awaryjne (failover) za pomocą atrybutów BGP, preferując Direct Connect (wyższy local‑preference) i pozwalając VPN na dziedziczenie niższej preferencji. Użyj BFD tam, gdzie jest to wspierane, dla szybszego wykrywania awarii ścieżki. Monitoruj metryki Direct Connect i VPN w CloudWatch i ustaw alarmy, aby uruchamiały zmiany w inżynierii ruchu lub wysyłały powiadomienia.

Uzasadnienie AWS: NLB w trybie TCP passthrough zachowuje end‑to‑end mutual TLS, dzięki czemu certyfikaty klienta urządzenia są walidowane przez pody backendu, co spełnia wymóg, aby ruch nie był deszyfrowany na brzegu sieci. Typ celu IP i NLB wspierają skalowanie do tysięcy jednoczesnych, długotrwałych połączeń, zachowując jednocześnie adres IP klienta za pomocą protokołu proxy lub odczytując go z sesji TLS, jeśli jest to konieczne. Direct Connect zapewnia deterministyczną łączność o wysokiej przepustowości z regionem us‑east‑1 z LAG dla zwiększenia pojemności i MACsec dla szyfrowania łącza fizycznego; Site‑to‑Site VPN zapewnia globalnie dostępną, szyfrowaną ścieżkę zapasową z przełączaniem awaryjnym (failover) zarządzanym przez BGP. Ten projekt równoważy bezpieczeństwo, wydajność i skalowalność, jednocześnie będąc zgodnym z najlepszymi praktykami konfiguracji AWS Direct Connect i VPN.

← Projektowanie VPC i zaawansowane sieci · Wszystkie domeny · Transit Gateway i topologia sieci →

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

Przeglądaj Amazon →