Amazon SAA-C03: Sieci i łączność — Przewodnik do nauki

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Część AWS SAA-C03 — Kompletny przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Projektowanie VPC i planowanie CIDR

Każdy VPC zaczyna się od bloku CIDR, a wybór dokonany w momencie tworzenia ma późniejsze konsekwencje dla peeringu, podłączeń Transit Gateway i łączności hybrydowej. Główny CIDR musi mieścić się w zakresie od /16 do /28, być wybrany z przestrzeni RFC 1918 i nie może pokrywać się z żadną siecią, z którą zamierzasz nawiązać peering, routować ruch przez Transit Gateway, ani łączyć się przez Direct Connect lub VPN. Pokrywające się bloki CIDR są najczęstszą przyczyną nieprawidłowo działających architektur hybrydowych, ponieważ AWS nie może routować ruchu między dwiema sieciami o tej samej przestrzeni adresowej — Transit Gateway zaakceptuje podłączenie, ale propagacja tras zakończy się niepowodzeniem lub ruch będzie po cichu odrzucany (blackholing).

Gdy w VPC zabraknie przestrzeni adresowej, nie trzeba go budować od nowa. Można dołączyć do czterech dodatkowych bloków CIDR IPv4 (oraz dodatkowe zakresy z szerszej puli, co daje domyślnie łącznie pięć bloków; limit ten można zwiększyć). Dodatkowe bloki mogą pochodzić z tego samego zakresu RFC 1918 lub ze współdzielonej przestrzeni adresowej 100.64.0.0/10, co jest przydatne, gdy przestrzeń 10.0.0.0/8 została wyczerpana lub gdy potrzebna jest przestrzeń adresowa klasy operatorskiej (carrier-grade NAT). Dodatkowe bloki CIDR pozwalają wydzielić nowe podsieci na potrzeby rozbudowy — np. dla sieci podów EKS czy nowej warstwy aplikacji — bez konieczności zmiany numeracji istniejących zasobów.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

Solidny projekt rezerwuje /17 lub /18 na przyszły rozwój, dopasowuje granice podsieci do Stref Dostępności (AZ) (częstym wzorcem jest /20 na każdą AZ dla każdej warstwy aplikacji) i pozostawia zapas na interfejsy sieciowe (ENI) używane przez punkty końcowe interfejsu, bramy NAT i load balancery.

VPC jest konstruktem regionalnym, podzielonym na podsieci, z których każda jest przypisana do jednej Strefy Dostępności (AZ). Rozróżnienie między podsiecią „publiczną” a „prywatną” jest czysto decyzyjne na poziomie routingu: podsieć publiczna ma trasę 0.0.0.0/0 → igw-xxxx wskazującą na Internet Gateway, podczas gdy podsieć prywatna albo nie ma trasy domyślnej, albo jej trasa 0.0.0.0/0 wskazuje na urządzenie NAT. Instancje w podsieci publicznej potrzebują również publicznego adresu IP lub Elastic IP, aby były osiągalne z zewnątrz; IGW wykonuje translację NAT 1:1 między prywatnym a publicznym adresem IP.

Bramy NAT, instancje NAT i ruch wychodzący IPv6

Dla zapewnienia dostępu do internetu tylko dla ruchu wychodzącego w standardzie IPv4 z podsieci prywatnych, bramy NAT (NAT gateways) są właściwym rozwiązaniem. Zarządzana brama NAT skaluje się automatycznie do 45–100 Gb/s, obsługuje 55 000 jednoczesnych połączeń do jednego unikalnego celu, jest aktualizowana przez AWS i zapewnia wysoką dostępność w ramach swojej Strefy Dostępności (AZ). Opłaty za bramy NAT naliczane są za godzinę pracy i za każdy przetworzony GB danych.

Instancje NAT (NAT instances) — samodzielnie zarządzane instancje EC2 z wyłączoną weryfikacją źródła/przeznaczenia (source/destination check) — są rozwiązaniem przestarzałym. Są one ograniczone przepustowością pojedynczej instancji, wymagają skryptów do obsługi przełączania awaryjnego (failover) i stają się wąskim gardłem przy stałym obciążeniu. Są odpowiednie tylko w nietypowych przypadkach, takich jak niestandardowe filtrowanie, a nawet wtedy zazwyczaj preferowane jest urządzenie wirtualne za Gateway Load Balancer.

Kanoniczny wzorzec wysokiej dostępności to jedna brama NAT na każdą Strefę Dostępności (AZ), każda umieszczona w publicznej podsieci danej strefy, oraz osobna tablica routingu dla podsieci prywatnych w każdej AZ, której trasa domyślna wskazuje na lokalną bramę NAT:

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

Wdrożenie jednej bramy NAT, współdzielonej przez wiele Stref Dostępności, jest pułapką z dwóch powodów. Po pierwsze, stanowi pojedynczy punkt awarii (single point of failure): awaria jednej Strefy Dostępności odcina ruch wychodzący dla wszystkich podsieci prywatnych. Po drugie, każdy pakiet z instancji w innych Strefach Dostępności przekracza granicę strefy, co generuje opłaty za transfer danych między strefami (obecnie 0,01 USD/GB w każdą stronę), oprócz opłat za przetwarzanie przez bramę NAT. Przy obciążeniach generujących setki TB ruchu wychodzącego, koszt ten znacznie przewyższa koszt dodatkowych bram NAT. Drugim częstym błędem konfiguracyjnym jest umieszczenie samej bramy NAT w podsieci prywatnej — nie ma ona wtedy ścieżki do IGW i nie działa.

W przypadku IPv6, NAT nie jest ani potrzebny, ani dostępny, ponieważ każdy adres IPv6 jest globalnie routowalny. Aby zezwolić tylko na ruch wychodzący IPv6, blokując jednocześnie niezamówiony ruch przychodzący, należy podłączyć bramę internetową tylko do ruchu wychodzącego (egress-only internet gateway) i skierować do niej trasę ::/0 z podsieci prywatnych. Zwykła brama IGW jest dwukierunkowa i naraziłaby instancje na ruch z zewnątrz.

Punkty końcowe VPC: Gateway vs. Interface

Punkty końcowe VPC utrzymują ruch między Twoim VPC a usługami AWS w sieci szkieletowej AWS, całkowicie omijając internet, bramki NAT i bramki internetowe. Istnieją dwie fundamentalnie różne implementacje, a ich mylenie jest jednym z najczęstszych błędów architektonicznych.

Gateway endpoints (bramkowe punkty końcowe) istnieją tylko dla Amazon S3 i DynamoDB. Są one wpisem w tablicy routingu — listą prefiksów (np. pl-63a5400a dla S3 w us-east-1) wskazującą na sam punkt końcowy. Nie ma tu ENI, zmiany w DNS, kosztów godzinowych ani grup bezpieczeństwa (dostęp jest kontrolowany przez tablicę routingu oraz politykę punktu końcowego). Ponieważ opierają się na routingu, działają tylko dla zasobów wewnątrz VPC — sieci on-premises łączące się z S3 przez Direct Connect nie mogą z nich korzystać.

Interface endpoints (interfejsowe punkty końcowe, AWS PrivateLink) to interfejsy sieciowe (ENI) z prywatnymi adresami IP umieszczone w Twoich podsieciach, rozliczane godzinowo za każdą strefę dostępności (AZ) plus za GB. Działają dla prawie każdej innej usługi — SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS i setek innych — a także dla usług firm trzecich publikowanych jako usługi typu endpoint service. Interface endpoints wspierają prywatny DNS, który nadpisuje publiczną nazwę hosta usługi, aby wskazywała na prywatny adres IP punktu końcowego, dzięki czemu zestawy SDK i interfejsy CLI nie wymagają zmian w kodzie. Ponieważ są oparte na ENI, stosuje się do nich grupy bezpieczeństwa.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

Logika kosztów ma znaczenie: każdy ruch opuszczający prywatną podsieć do publicznej usługi AWS domyślnie przechodzi przez bramkę NAT, co kosztuje około 0,045 USD/GB. Dla obciążenia skonteneryzowanego, które wysyła 1 TB danych dziennie do S3, różnica między ścieżką przez bramkę NAT a gateway endpoint to tysiące dolarów miesięcznie. Interface endpoints są opłacalne, gdy zastępują ruch wychodzący przez NAT na dużą skalę lub gdy zgodność z przepisami zabrania routingu internetowego.

Pułapki: dołączanie grupy bezpieczeństwa do gateway endpoint (nie mają one ENI); zakładanie, że gateway endpoint jest osiągalny z sieci on-premises (nie jest — użyj interface endpoint lub hybrydowego wzorca EC2 → S3 gateway endpoint → oddzielna ścieżka DX); wyłączanie prywatnego DNS na interface endpoint i oczekiwanie, że niezmodyfikowane wywołania SDK zadziałają (trafią one do publicznego punktu końcowego przez internet, całkowicie niwecząc cel punktu końcowego); tworzenie gateway endpoint, ale zapominanie o powiązaniu go z tablicą routingu prywatnej podsieci (ruch po cichu nadal korzysta z publicznej ścieżki); próba użycia gateway endpoint dla usługi, która go nie posiada (np. KMS) — kwalifikują się tylko S3 i DynamoDB.

Łączność między VPC: Peering vs. Transit Gateway

VPC peering to połączenie jeden-do-jednego, nietranzytywne, na warstwie 3 między dwoma VPC, w tym samym lub innym koncie, w tym samym lub innym regionie. Ruch przechodzi przez sieć szkieletową AWS, nie ma wąskiego gardła przepustowości i nie ma opłaty godzinowej — płacisz tylko za transfer danych między strefami dostępności (cross-AZ) lub między regionami. Dwie właściwości ograniczają peering: (1) jest nietranzytywny — jeśli A jest połączone peeringiem z B, a B z C, to A nie może dotrzeć do C przez B; oraz (2) zakresy CIDR nie mogą się pokrywać. Połączenie N VPC w pełnej siatce (full-mesh) wymaga N(N-1)/2 połączeń peeringowych z edycją tablic routingu w obu kierunkach każdego z nich; przy 30 VPC daje to 435 połączeń peeringowych. Oczekiwanie, że peering będzie skalowalny do setek VPC, jest pułapką.

Transit Gateway (TGW) to regionalny router chmurowy. Każde VPC, VPN lub bramka Direct Connect jest załącznikiem (attachment), a tablice routingu TGW kontrolują, który załącznik może dotrzeć do którego prefiksu. Zamienia to siatkę o złożoności O(n²) na O(n) załączników i umożliwia topologie hub-and-spoke, w których VPC bezpieczeństwa hostuje zapory sieciowe (firewalls), które inspekcjonują cały ruch między VPC. TGW wspiera routing tranzytywny, natywnie kończy powiązania z bramkami VPN i Direct Connect oraz może być współdzielony w ramach AWS Organizations za pomocą Resource Access Manager, dzięki czemu centralne zespoły sieciowe kontrolują routing, podczas gdy konta z obciążeniami roboczymi są właścicielami VPC. TGW dodaje opłatę godzinową za załącznik oraz około 0,02 USD za przetworzony GB.

Dla łączności międzyregionalnej, peering TGW łączy TGW w różnych regionach przez globalną sieć szkieletową AWS z szyfrowanym ruchem — jeden TGW na region, połączone peeringiem w architekturze siatki (mesh) lub gwiazdy (hub). Pozwala to uniknąć problemu N-kwadrat w skali międzyregionalnej, który ponownie wprowadza międzyregionalny peering VPC.

Higiena tablic routingu to tutaj cichy zabójca. Utworzenie połączenia peeringowego lub załącznika TGW nic nie daje, dopóki w tablicach routingu podsieci obu VPC nie zostaną dodane jawne trasy CIDR wskazujące na cel pcx- lub tgw-, a grupy bezpieczeństwa nie zezwolą na ten ruch. Ciche błędy łączności prawie zawsze wynikają z brakującej trasy lub niejawnej reguły deny w grupie bezpieczeństwa, która odwołuje się do niewłaściwego źródłowego CIDR.

Łączność hybrydowa: Site-to-Site VPN vs. Direct Connect

Wybór między Site-to-Site VPN a Direct Connect to kompromis pomiędzy szybkością wdrożenia i wbudowanym szyfrowaniem z jednej strony, a stałym, niskim opóźnieniem, dedykowaną przepustowością i przewidywalną przepływnością z drugiej.

Site-to-Site VPN tworzy dwa tunele IPsec pomiędzy bramą klienta (router on-premise) a Virtual Private Gateway lub Transit Gateway. Każdy tunel ma limit przepustowości około 1,25 Gb/s. Ruch jest szyfrowany w warstwie sieciowej, co w połączeniu z TLS spełnia wymagania dotyczące szyfrowania w warstwie sieciowej i sesji. Przechodzi przez publiczny internet, więc opóźnienie i jitter są zmienne, ale usługa jest dostępna w ciągu kilku minut i kosztuje centy za godzinę. Należy jej używać, gdy łączność jest potrzebna natychmiast, gdy wymagania dotyczące przepustowości są umiarkowane lub jako ścieżka zapasowa.

Direct Connect (DX) zapewnia dedykowane połączenie światłowodowe (1, 10 lub 100 Gb/s) z routera on-premise do lokalizacji AWS Direct Connect. Omija publiczny internet, co zapewnia stałe opóźnienia i wyższą przepływność. Ceny za ruch wychodzący (egress) w DX są znacznie niższe niż za ruch internetowy, co ma znaczenie przy przesyłaniu setek gigabajtów danych dziennie. Uruchomienie usługi trwa tygodniami — wymaga krosowania (cross-connects), dokumentów LOA i konfiguracji BGP.

Dominują tu dwie pułapki. Po pierwsze, sam Direct Connect nie szyfruje ruchu. Prywatne łącze nie jest kanałem chronionym kryptograficznie. Aby spełnić wymóg szyfrowania przez DX, należy nałożyć na niego warstwę Site-to-Site VPN lub użyć MACsec do szyfrowania w warstwie 2 na obsługiwanych portach dedykowanych. Po drugie, surowe połączenie DX samo w sobie nie zapewnia routingu do wielu VPC. Prywatny VIF łączy się z pojedynczą Virtual Private Gateway podłączoną do jednego VPC. Aby uzyskać dostęp do wielu VPC — zwłaszcza na różnych kontach i w różnych regionach — należy użyć Direct Connect Gateway powiązanej z Transit Gateway za pomocą transit VIF i podłączyć każde VPC do TGW:

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

Kanoniczny wzorzec produkcyjny wykorzystuje dwa połączenia DX w dwóch lokalizacjach DX, zakończone na oddzielnych routerach klienta, z Site-to-Site VPN jako automatycznym przełączaniem awaryjnym (failover) BGP. Mechanizmy BGP, takie jak AS-path prepending lub MED, kierują ruch do DX, gdy jest on aktywny; w przypadku awarii, BGP wycofuje trasy DX, a połączenie przejmuje VPN.

Load Balancery: ALB, NLB i GWLB

ALB działa w warstwie 7 i rozumie semantykę HTTP — routing oparty na hoście i ścieżce, WebSockets, przekierowania, sesje lepkie oparte na ciasteczkach. Jest to niewłaściwe narzędzie do wszystkiego, co nie jest HTTP: MQTT, surowy TCP, syslog przez UDP, SMTP. ALB używa adresowania opartego na DNS z adresami IP, które zmieniają się w czasie; nie można mu przypisać adresów Elastic IP. Gdy klienci dodają docelowe adresy IP do białej listy, sam ALB jest nieodpowiedni — należy użyć NLB z EIP lub umieścić przed ALB usługę Global Accelerator z jej dwoma statycznymi adresami IP anycast. “Po prostu rozwiąż raz DNS dla ALB i przypnij adresy IP w regułach firewalla” to pułapka: AWS zmienia je bez powiadomienia.

NLB działa w warstwie 4 i skaluje się do milionów przepływów na sekundę. Domyślnie zachowuje prawdziwy źródłowy adres IP klienta (cele widzą rzeczywistego klienta), obsługuje przypisywanie statycznego adresu Elastic IP na każdą strefę dostępności (AZ) i radzi sobie z obciążeniami TCP/UDP o wysokiej przepustowości. Historycznie NLB nie obsługiwał grup bezpieczeństwa na samym load balancerze — zakresy CIDR klientów musiały być dozwolone bezpośrednio w grupie bezpieczeństwa celu (targetu). AWS dodał opcjonalne grupy bezpieczeństwa dla NLB w 2023 roku, ale wiele projektów wciąż zakłada klasyczne zachowanie.

Kanoniczny wzorzec dla usług publicznych to:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Odwoływanie się do grupy bezpieczeństwa ALB jako źródła w regułach dla backendu — zamiast do zakresu CIDR — jest wzorcem najmniejszych uprawnień i automatycznie obejmuje ruch z kontroli stanu (health check), który pochodzi z interfejsów sieciowych (ENI) ALB. Sam ALB znajduje się w podsieciach publicznych w co najmniej dwóch strefach dostępności (z trasami do IGW); cele (targety) znajdują się w podsieciach prywatnych. Umieszczenie ALB z dostępem do internetu w podsieci prywatnej to klasyczny błąd konfiguracji — rejestracja celu powiedzie się, ale klienci nie będą mogli się z nim połączyć.

Gateway Load Balancer (GWLB) jest specjalnie zaprojektowany do transparentnego wstawiania wirtualnych urządzeń firm trzecich (firewalle, IDS/IPS, DPI). Działa w warstwie 3, przekazując wszystkie protokoły IP za pomocą enkapsulacji GENEVE na porcie UDP 6081. Ruch dociera do GWLB przez punkt końcowy GWLB (GWLBe) — jest to interfejsowy punkt końcowy, który znajduje się w podsieci i pojawia się w tablicach routingu jako cel (target):

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

Punkt końcowy przekazuje pakiety przez PrivateLink do GWLB, który równoważy obciążenie między flotą urządzeń, używając lepkości przepływu (flow stickiness), aby oba kierunki danego przepływu trafiały do tego samego urządzenia. W architekturze inspekcji typu hub-and-spoke, VPC typu spoke są podłączone do TGW, którego tablice routingu wymuszają przepływ ruchu wschód-zachód przez VPC inspekcyjne (zawierające GWLB i urządzenia) przed dotarciem do docelowych VPC. Inspekcja ruchu przychodzącego (ingress) wykorzystuje brzegowe tablice routingu, które najpierw przekierowują ruch z IGW do warstwy webowej przez GWLBe:

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

Jest to prawidłowe rozwiązanie dla scentralizowanej inspekcji między kontami — tworzenie własnych rozwiązań z EC2, niestandardowe modyfikacje tablic routingu i skrypty failover to wymyślanie na nowo tego, co GWLB zapewnia natywnie.

PrivateLink dla usług typu konsument-dostawca

Oprócz zasilania interfejsowych punktów końcowych dla usług AWS, PrivateLink umożliwia prywatną łączność z usługami publikowanymi przez strony trzecie lub inne konta AWS. Dostawca umieszcza swoją usługę za NLB i tworzy usługę punktu końcowego VPC (VPC endpoint service). Konsumenci tworzą we własnych VPC interfejsowe punkty końcowe (interface endpoints), które na nią wskazują.

Kluczowa zasada dotycząca kierunkowości: połączenie jest zawsze inicjowane od konsumenta w kierunku dostawcy. Dostawca nie może inicjować połączeń do VPC konsumenta. Ruch nigdy nie przechodzi przez internet, osiągalna jest tylko konkretna usługa docelowa (a nie całe VPC dostawcy, jak w przypadku peeringu), a problemy z nakładaniem się CIDR nie występują, ponieważ po każdej stronie eksponowane są tylko adresy IP punktów końcowych. Jest to kanoniczne rozwiązanie dla wzorca dostępu do SaaS lub bazy danych dostawcy, w którym VPC konsumenta nie ma IGW, VPN ani Direct Connect. Peering VPC udostępnia całe zakresy CIDR i wymaga nienakładających się adresów IP; załącznik TGW kieruje ruch szeroko; publiczne API przez internet nie jest prywatne.

Global Accelerator i Route 53

AWS Global Accelerator przydziela dwa statyczne adresy IPv4 typu anycast, rozgłaszane z lokalizacji brzegowych AWS na całym świecie. Ruch klienta wchodzi do najbliższej lokalizacji brzegowej i podróżuje przez sieć szkieletową AWS do najbliższego sprawnego regionalnego punktu końcowego (ALB, NLB, EIP lub EC2). Rozwiązuje to jednocześnie dwa problemy: statyczne adresy IP przed ALB (naprawiając lukę w białych listach) oraz zmniejszone jitter/opóźnienie dla globalnie rozproszonych użytkowników poprzez omijanie publicznego internetu. Przyspiesza ruch TCP/UDP, którego nie da się buforować (non-cacheable), do źródeł, gdzie CloudFront (który buforuje zawartość) nie ma zastosowania.

Route 53 rozwiązuje inny problem — kierowanie ruchem na poziomie DNS. Global Accelerator wpływa na samą płaszczyznę danych (data plane); Route 53 wpływa tylko na proces rozwiązywania nazw DNS, po którym połączenie TCP trafia tam, gdzie znajduje się rozwiązany adres IP. Oba te serwisy są często łączone: alias Route 53 wskazuje na Global Accelerator, który stoi przed regionalnymi ALB.

Polityki routingu Route 53:

Polityki latency-based i geolocation są często mylone: latency-based minimalizuje odczuwalny przez użytkownika RTT; geolocation wymusza rezydencję danych niezależnie od opóźnienia. Wieloregionowy failover wymaga health checków na zasobie podstawowym (primary). Rekordy aliasowe (Alias records) są specyficzne dla AWS, rozwiązują się bezpośrednio na punkty końcowe ALB, NLB, CloudFront, S3 website i API Gateway bez opłat za zapytania i — w przeciwieństwie do CNAME — działają dla domeny głównej (zone apex).

Route 53 Resolver odpowiada na zapytania DNS wewnątrz VPC za pośrednictwem adresu .2 (baza CIDR VPC + 2). W przypadku hybrydowego DNS, punkty końcowe przychodzące (inbound endpoints) pozwalają resolverom on-premises odpytywać prywatne strefy hostowane w AWS; punkty końcowe wychodzące (outbound endpoints) z regułami przekierowywania (forwarding rules) pozwalają zasobom VPC rozwiązywać nazwy on-premises. Bez nich instancje EC2 nie mogą rozwiązać nazwy corp.internal, a serwery on-prem nie mogą rozwiązać db.prod.internal — subtelny błąd, który ujawnia się dopiero, gdy aplikacje zaczynają odpytywać zasoby w różnych środowiskach. Interfejsowe punkty końcowe wymagają włączenia opcji Enable Private DNS, aby wywołania SDK trafiały do ENI punktu końcowego; bez tego wywołania nadal trafiają do publicznego punktu końcowego przez internet, niwecząc cel ich użycia.

Security Groups, NACLs i zasada najmniejszych uprawnień

Grupy bezpieczeństwa (Security groups) są stanowe (stateful) — ruch powrotny jest automatycznie dozwolony — i działają na poziomie ENI. NACL-e są bezstanowe (stateless) i działają na granicy podsieci. Każda reguła TCP w NACL wymaga jawnej reguły przychodzącej i wychodzącej; ponieważ klienci wybierają port źródłowy z zakresu portów efemerycznych, reguła dla ruchu powrotnego musi zezwalać na porty 1024–65535 (Linux domyślnie używa 32768–60999; szerszy zakres obejmuje Windows i inne systemy). Zapomnienie o regule dla ruchu powrotnego na portach efemerycznych jest klasyczną przyczyną połączeń, które kończą fazę SYN, ale zawieszają się w oczekiwaniu na odpowiedź.

Aby zapewnić zasadę najmniejszych uprawnień między warstwami, reguły grup bezpieczeństwa powinny odwoływać się do ID innych grup bezpieczeństwa, a nie do zakresów CIDR. Skaluje się to wraz z Auto Scaling i pozwala uniknąć kruchych białych list IP:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACL-e służą do ogólnej kontroli zasięgu rażenia (blast-radius), a nie jako substytut grup bezpieczeństwa. Zacieśnianie NACL-i „dla dogłębnej obrony” bez odpowiednich zmian w grupach bezpieczeństwa często psuje przepływy inicjowane z wewnątrz, takie jak aktualizacje yum/apt przez NAT gateway, ponieważ bezstanowy ruch powrotny jest po cichu odrzucany. Tablice routingu ostatecznie określają osiągalność: nawet zezwalająca grupa bezpieczeństwa nie może dostarczyć ruchu, jeśli w tablicy routingu brakuje wpisu dla miejsca docelowego, i odwrotnie, gateway endpoint jest skuteczny tylko wtedy, gdy trasa z listą prefiksów S3 jest faktycznie zainstalowana w tablicach routingu podsieci, w których działa obciążenie.

Tabela decyzyjna

← Transfer i migracja danych · Wszystkie domeny · Dostarczanie treści →

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

Przeglądaj Amazon →