Amazon ANS-C01: Dostarczanie treści i sieci brzegowe — Przewodnik do nauki
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.
Podstawowe koncepcje
Dostarczanie treści i sieci brzegowe rozdzielają dwie powiązane ze sobą odpowiedzialności: transport ruchu od klienta z niskim opóźnieniem oraz działanie jako rozproszona warstwa pamięci podręcznej/obliczeniowa blisko użytkowników końcowych. CloudFront to platforma CDN dla HTTP(S) i platforma obliczeń brzegowych, która buforuje odpowiedzi HTTP, terminuje TLS na brzegu sieci i może uruchamiać kod w lokalizacjach brzegowych za pomocą Lambda@Edge (pełne środowisko wykonawcze Lambda replikowane do regionów) lub CloudFront Functions dla lekkich skryptów JavaScript na etapie żądania/odpowiedzi klienta. Zachowanie CloudFront jest sterowane przez obiekty konfiguracji dystrybucji tworzone za pomocą CreateDistribution i dostrajane przy użyciu obiektów CachePolicy i OriginRequestPolicy. Pola polityki buforowania, takie jak DefaultTTL, MinTTL i MaxTTL, oraz zestaw nagłówków, ciasteczek i parametrów zapytania (query strings) włączonych do klucza pamięci podręcznej, determinują współczynnik trafień w pamięci podręcznej i obciążenie źródła (origin). Mechanizmy kontroli dostępu do źródła (origin) obejmują S3 OAC/OAI dla prywatnych źródeł S3 (CreateCloudFrontOriginAccessControl) oraz podpisane adresy URL lub podpisane ciasteczka (CreateKeyGroup, CreatePublicKey i proces podpisywania URL) w celu ochrony prywatnej zawartości.
Global Accelerator i Anycast działają poniżej warstwy HTTP. Global Accelerator ogłasza dwa statyczne adresy IP anycast z sieci brzegowej AWS i kieruje przepływy TCP/UDP do sprawnych regionalnych punktów końcowych (Network Load Balancers, Application Load Balancers, instancje EC2 lub Elastic IPs). Ponieważ Global Accelerator działa w warstwach L3/L4, zachowuje szyfrowanie TLS end-to-end, gdy jest skonfigurowany do przekazywania TCP (TCP pass-through), i poprawia globalny routing, wykorzystując wewnętrzną sieć szkieletową AWS na odcinku „ostatniej mili” do regionalnych punktów końcowych. Dla protokołów innych niż HTTP lub gdy konieczne jest zachowanie prawdziwego szyfrowania end-to-end i wzajemnego uwierzytelniania TLS (mTLS) między klientem a backendem, kanonicznym wzorcem jest ścieżka przekazywania TCP (TCP pass-through) z użyciem Global Accelerator przed Network Load Balancer (NLB): NLB działają w warstwie L4, skalują się do milionów połączeń i mogą rejestrować cele IP dla podów lub węzłów w Amazon EKS.
Funkcje Lambda@Edge są powiązane z zachowaniami (behaviors) CloudFront i muszą być wdrożone (CreateFunction z opcją Publish) oraz powiązane w LambdaFunctionAssociations dystrybucji dla wyzwalaczy viewer-request, origin-request, origin-response i viewer-response. Ponieważ Lambda@Edge replikuje się do wielu regionów brzegowych, wersje i semantyka publikacji są ważne; należy używać wersjonowanych obiektów Lambda i ostrożnie zarządzać wdrożeniami, aby uniknąć niespójnego zachowania podczas aktualizacji.
Kluczowe usługi i konfiguracja
Konfiguracja dystrybucji CloudFront opiera się na trzech ściśle powiązanych obiektach: samej dystrybucji (CreateDistribution / UpdateDistribution), obiektach CachePolicy, które określają klucz pamięci podręcznej i wartości TTL (CreateCachePolicy), oraz obiektach OriginRequestPolicy, które określają, które nagłówki/ciasteczka/parametry zapytania są wysyłane do źródła (CreateOriginRequestPolicy). Dla prywatnej zawartości S3 należy użyć CreateCloudFrontOriginAccessControl lub starszej wersji origin access identity, a dostęp dodatkowo zabezpieczyć za pomocą podpisanych adresów URL / podpisanych ciasteczek, używając CreateKeyGroup i CreatePublicKey; SDK lub narzędzia cloudfront-signing generują podpisany URL lub dokument polityki i podpis RSA. Operacje unieważniania są wykonywane za pomocą CreateInvalidation w celu selektywnego usuwania obiektów z pamięci podręcznej.
Konfiguracja Global Accelerator jest tworzona za pomocą wywołań API create-accelerator, create-listener i create-endpoint-group. Listener może nasłuchiwać na porcie TCP:443 dla gRPC lub na dowolnym innym porcie TCP i będzie przekazywać przepływy do grup punktów końcowych (endpoint groups), które wskazują na regionalny NLB lub ALB. Gdy Global Accelerator jest używany do przekazywania TCP (TCP pass-through) w celu zachowania szyfrowania TLS end-to-end i mTLS, należy go połączyć z Network Load Balancer, który ma listenery TCP na porcie 443 i grupy docelowe (target groups) rejestrujące adresy IP podów (target type ip) lub porty węzłów (node ports). W Kubernetes EKS jest to zazwyczaj osiągane przez utworzenie serwisu (Service) typu LoadBalancer z adnotacjami takimi jak service.beta.kubernetes.io/aws-load-balancer-type: “nlb” i service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”, lub przez użycie AWS Load Balancer Controller do stworzenia NLB z target type ip. Aby zachować źródłowy adres IP klienta do celów logowania, należy ustawić externalTrafficPolicy: Local w serwisie lub użyć przekazywania przez NLB (passthrough), które zachowuje oryginalny adres IP źródła.
Wymuszanie reguł na poziomie sieci między Global Accelerator a regionalnymi punktami końcowymi wykorzystuje listy prefiksów zarządzane przez AWS (AWS-managed prefix lists), aby zmniejszyć narzut administracyjny. Wywołanie AWS CLI aws ec2 describe-managed-prefix-lists wyświetla zarządzane listy prefiksów; ta o nazwie com.amazonaws.globalaccelerator może być używana w regułach grup bezpieczeństwa (AuthorizeSecurityGroupIngress z –source-prefix-list), aby zezwolić na ruch do ALB/NLB pochodzący wyłącznie z akceleratora. Gdy ALB terminuje TLS, do logowania adresu IP klienta należy używać nagłówków X-Forwarded-For; przy użyciu przekazywania przez NLB (passthrough) z Global Accelerator, adresy IP klientów są zachowywane natywnie, a backendy muszą obsługiwać terminację TLS/mTLS.
Wzorce projektowe i kompromisy
Gdy wymagane jest buforowanie treści, przetwarzanie na brzegu sieci (edge compute) i odpowiedzi HTTP o niskim opóźnieniu, CloudFront jest właściwym narzędziem. CloudFront powinien kończyć połączenia TLS na brzegu sieci, gdy poufność serwera źródłowego (origin) nie jest wymagana; użyj CachePolicy i OriginRequestPolicy, aby minimalizować liczbę żądań do serwera źródłowego, wykluczając z klucza pamięci podręcznej (cache key) nagłówki i ciasteczka, gdy jest to bezpieczne. W przypadku dynamicznej personalizacji, która wciąż korzysta z buforowania, użyj normalizacji klucza pamięci podręcznej (różnicowanie w oparciu o minimalny zestaw nagłówków lub podpisanych ciasteczek) i projektuj unieważnianie pamięci podręcznej poprzez wersjonowane klucze obiektów, zamiast częstych wywołań CreateInvalidation.
Dla protokołów wymagających szyfrowania TLS end-to-end, przepływów HTTP/2 i gRPC, które nie mogą być deszyfrowane aż do backendu (dla mTLS), należy umieścić ścieżkę TCP/L4 z przodu, używając Global Accelerator + NLB z przekazywaniem TLS (TLS passthrough). Kompromisem jest utrata możliwości buforowania HTTP i przetwarzania na brzegu sieci, które oferuje CloudFront; jednakże Global Accelerator zapewnia statyczne adresy IP anycast, ulepszony routing i przełączanie awaryjne (failover) między regionami. ALB obsługuje HTTP/2 i gRPC, gdy ALB kończy połączenie TLS, co umożliwia routing na warstwie aplikacji (oparty na hoście/ścieżce) oraz integrację z WAF, ale zakończenie połączenia na ALB uniemożliwia mTLS end-to-end i przenosi zarządzanie certyfikatami na load balancer. Dla masowej liczby jednoczesnych połączeń, NLB skalują się lepiej na warstwie L4 — NLB są zoptymalizowane pod kątem liczby połączeń na sekundę i zachowują źródłowy adres IP, podczas gdy ALB są zaprojektowane do routingu na poziomie HTTP i funkcji takich jak reguły listenera dla routingu na poziomie hosta/ścieżki oraz integracji z Cognito/OIDC.
Mechanizmy kontroli bezpieczeństwa i wzorce izolacji regionalnej wymagają starannego wyboru między współdzielonym VPC peering, Transit Gateway, PrivateLink i punktami końcowymi (endpoints) Load Balancer. PrivateLink zapewnia szczegółową kontrolę dostępu na poziomie usług i dobrze się skaluje dla wielu konsumentów, ponieważ każdy z nich tworzy interfejsowy punkt końcowy (interface endpoint) w swoim VPC. Transit Gateway jest odpowiedni do centralizacji o dużej przepustowości, ale brakuje mu szczegółowych kontroli na poziomie usług oraz widoczności na poziomie SNI/hosta, które zapewnia punkt końcowy PrivateLink. Projekt musi uwzględniać limity routingu, uprawnienia między kontami oraz możliwość stosowania grup bezpieczeństwa (security groups) na granicy usługi.
Typowe pułapki i kryteria decyzyjne
Częstym błędem jest nieprawidłowe mieszanie mechanizmów kontroli pamięci podręcznej: pozwolenie, aby nagłówki Cache-Control ustawione przez serwer źródłowy sterowały buforowaniem na brzegu sieci, podczas gdy jednocześnie stosowane są polityki pamięci podręcznej CloudFront, może prowadzić do nieoczekiwanych wartości TTL; preferuj jawne obiekty CachePolicy i nie polegaj wyłącznie na nagłówkach z serwera źródłowego, chyba że jest to celowe. Inną pułapką jest wybór ALB, gdy wymagane jest szyfrowanie TLS end-to-end lub miliony jednoczesnych połączeń TCP; zakończenie TLS na ALB uniemożliwia mTLS i może stać się wąskim gardłem przy bardzo dużej liczbie jednoczesnych połączeń. Konfiguracje bezpieczeństwa próbujące ograniczyć dostęp do publicznego ALB często pomijają zablokowanie dostępu za pomocą listy prefiksów (prefix list) Global Accelerator lub reguły WAF; bez jawnych reguł zezwalających, ALB pozostanie osiągalny przez swój publiczny DNS. Wreszcie, wdrożenia Lambda@Edge, które nie używają wersjonowanych funkcji Lambda, mogą powodować niespójne zachowanie podczas wdrażania (rollout), ponieważ powiązanie w dystrybucji jest przypisane do konkretnej opublikowanej wersji.
Praktyczny problem: Scenariusz użycia
Firma: AcmeTelemetrics — wyzwanie: globalna flota automatów sprzedających IoT używa gRPC przez TCP:443 do backendu w regionie us-east-1 działającego na Amazon EKS; wymaganiem jest wzajemne uwierzytelnianie TLS end-to-end (mTLS), aby ruch nigdy nie był deszyfrowany w tranzycie, obsługa tysięcy jednoczesnych połączeń oraz konieczność zaprogramowania statycznych adresów IP w maszynach.
Podejście:
- Utwórz Global Accelerator (
undefined
) z dwoma statycznymi adresami IP anycast i listenerem TCP na porcie 443 (
undefined
). Skonfiguruj grupę punktów końcowych (endpoint group), która kieruje ruch do regionalnego Network Load Balancer w us-east-1 (
undefined
). 2) Zainicjuj NLB w us-east-1 z listenerem TCP na porcie 443 i grupą docelową (target group) typu ip. W Kubernetes utwórz serwis typu LoadBalancer z adnotacjami
undefined
i
undefined
, ustaw
undefined
i zarejestruj adresy IP podów jako cele, aby TLS był przekazywany bezpośrednio do podów. 3) Wdróż serwery gRPC w EKS i zakończ połączenia TLS/mTLS w procesach podów. Przechowuj certyfikaty i materiały zaufania w Kubernetes Secrets; skonfiguruj serwer tak, aby wymagał weryfikacji certyfikatu klienta dla wzajemnego uwierzytelniania TLS. 4) Zablokuj bezpośredni dostęp do NLB, aby tylko Global Accelerator mógł się z nim połączyć, aktualizując grupę bezpieczeństwa NLB tak, aby zezwalała na ruch przychodzący (ingress) tylko z zarządzanej przez AWS listy prefiksów Global Accelerator (do znalezienia za pomocą
undefined
i odwołania się do tej listy w regułach grupy bezpieczeństwa), uniemożliwiając maszynom ominięcie akceleratora i bezpośrednie połączenie z NLB.
5) Monitoruj współbieżność połączeń i skalowanie, konfigurując Kubernetes HorizontalPodAutoscaler i Cluster Autoscaler, i upewnij się, że opóźnienia slow start i deregistration delay grupy docelowej NLB są dostrojone do płynnego skalowania w dół (scale-in) (
undefined
). Użyj metryk CloudWatch z Global Accelerator, NLB i EKS do obserwacji liczby połączeń i ich stanu.
Uzasadnienie ze strony AWS: Global Accelerator dostarcza statyczne adresy IP anycast wymagane przez automaty sprzedające i kieruje przepływy TCP przez sieć szkieletową AWS do regionalnego NLB, poprawiając niezawodność i zmniejszając opóźnienia. NLB zachowuje oryginalne połączenie TCP klienta i jego źródłowy adres IP oraz obsługuje masową liczbę jednoczesnych połączeń, umożliwiając podom zakończenie połączenia mTLS bez pośredniego przerywania TLS. Użycie zarządzanej listy prefiksów Global Accelerator w regułach grupy bezpieczeństwa zapobiega bezpośredniemu ominięciu akceleratora i wymusza, aby ruch docierał wyłącznie przez adresy IP anycast. Ta kombinacja spełnia wymagania dotyczące szyfrowania end-to-end, mTLS, dużej liczby jednoczesnych połączeń, statycznych adresów IP i automatycznego skalowania w EKS.
← Bezpieczeństwo sieci i zgodność · Wszystkie domeny · Wydajność sieci i monitorowanie →
Przećwicz te pytania → · Testy na czas na ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Zdaj egzamin →