Brama NAT i prywatne podsieci

Zasoby w prywatnych podsieciach mają wyłącznie prywatne adresy IP i nie mają trasy do Internet Gateway, dlatego nie mogą inicjować połączeń wychodzących z internetem. Często jednak muszą mieć dostęp do internetu: aby pobierać poprawki systemu operacyjnego, obrazy Dockera, wywoływać interfejsy API firm zewnętrznych lub aktualizować oprogramowanie. Rozwiązaniem jest kierowanie ruchu z prywatnej podsieci przez urządzenie, które ma dostęp do internetu i wykonuje translację adresów sieciowych (NAT), ukrywając prywatne adresy IP za publicznym adresem IP. AWS udostępnia dwie opcje: NAT Gateway (zarządzaną) oraz samodzielnie zarządzaną NAT Instance (starszą).

NAT Gateway to w pełni zarządzana, wysoce dostępna usługa, która umożliwia instancjom w prywatnych podsieciach inicjowanie połączeń wychodzących z internetem, jednocześnie blokując niezamówiony ruch przychodzący. Znajduje się w publicznej podsieci, ma Elastic IP i automatycznie skaluje przepustowość do 100 Gb/s. Nie trzeba samodzielnie aktualizować poprawek, skalować ani zarządzać bazową infrastrukturą. NAT Gateway tłumaczy prywatny źródłowy adres IP pakietów wychodzących na własny EIP, a następnie przekazuje odpowiedzi z powrotem do pierwotnego prywatnego adresu IP.

Po utworzeniu NAT Gateway należy dodać trasę do tablicy tras prywatnej podsieci: miejsce docelowe 0.0.0.0/0 → identyfikator NAT Gateway. Informuje to, że cały ruch z instancji prywatnej podsieci kierowany do Internetu ma trafiać do NAT Gateway, który następnie przekazuje go przez Internet Gateway do Internetu. Tablica tras nadal zawiera lokalną trasę VPC (np. 10.0.0.0/16 → local) dla ruchu wewnętrznego. Bez tego wpisu trasy instancje w prywatnej podsieci nadal nie będą miały dostępu do Internetu, nawet jeśli wdrożono NAT Gateway.

NAT Gateway jest powiązany z konkretną strefą AZ — obsługuje ruch wyłącznie z podsieci znajdujących się w tej samej strefie AZ. Aby zapewnić wysoką dostępność, należy wdrożyć po jednym NAT Gateway w każdej strefie AZ i utworzyć prywatne tablice tras właściwe dla poszczególnych stref AZ: prywatna tablica tras w AZ-a kieruje 0.0.0.0/0 do NAT-GW w AZ-a, a prywatna tablica tras w AZ-b kieruje ruch do NAT-GW w AZ-b. Pozwala to uniknąć opłat za transfer danych między strefami AZ i zapewnia, że w przypadku awarii AZ-a instancje w AZ-b (z własnym NAT) nadal będą miały dostęp do Internetu.

NAT Instance to zarządzana przez użytkownika instancja EC2 uruchamiająca obraz AMI z funkcją NAT — starsze rozwiązanie stosowane przed wprowadzeniem NAT Gateway. W przypadku NAT Instance należy: wyłączyć kontrolę źródła i miejsca docelowego na instancji EC2, zarządzać przepustowością i skalowaniem, instalować poprawki systemu operacyjnego oraz obsługiwać awarie. NAT Instance są tańsze w zastosowaniach o bardzo małej przepustowości i mogą służyć jako bastion hosts. NAT Gateway to zalecany wybór w środowisku produkcyjnym: jest w pełni zarządzany, automatycznie skalowany, zapewnia dostępność na poziomie 99,99% w obrębie strefy AZ i nie wymaga instalowania poprawek. Egzamin od lat sprawdza to porównanie.

Cena NAT Gateway składa się z dwóch elementów: opłaty godzinowej za każdy NAT Gateway (około 0,045 USD za godzinę w us-east-1, czyli około 32 USD miesięcznie) oraz opłaty za przetwarzanie danych za każdy GB (około 0,045 USD/GB w us-east-1). W przypadku obciążeń, które przesyłają duże ilości danych przez NAT (np. pobierania dużych obrazów kontenerów lub masowych pobrań), koszt przetwarzania danych może stanowić największą część wydatków. Aby zoptymalizować koszty NAT, należy kierować ruch S3 i DynamoDB przez VPC Gateway Endpoints (całkowicie omijają NAT i są bezpłatne), a wywołania API AWS przez VPC Interface Endpoints zamiast przez NAT.

Instancje baz danych w prywatnych podsieciach nie powinny kierować ruchu przez NAT Gateway — nie mają powodu inicjować połączeń z Internetem. Bazy danych muszą jedynie odbierać połączenia z warstwy aplikacji (wewnątrz VPC) i potencjalnie uzyskiwać dostęp do usług AWS, takich jak S3 (na potrzeby eksportu i importu), za pośrednictwem punktu końcowego VPC. W przypadku poprawek i aktualizacji bazy RDS jest usługą zarządzaną, dlatego nie stosuje się bezpośrednio poprawek systemu operacyjnego. W przypadku samodzielnie zarządzanych baz danych na EC2 należy użyć Systems Manager Patch Manager, który może instalować poprawki za pośrednictwem SSM bez dostępu do Internetu, jeśli skonfigurowano punkt końcowy SSM VPC.

NAT Gateway zapewnia stanowy NAT wyłącznie dla ruchu wychodzącego: zezwala na zainicjowane połączenia wychodzące i ich odpowiedzi, ale blokuje wszystkie niezamówione połączenia przychodzące. Nie jest zaporą sieciową — nie analizuje ani nie filtruje zawartości ruchu. Do filtrowania ruchu wychodzącego (np. zezwalania na dostęp z prywatnych podsieci wyłącznie do określonych domen lub adresów IP) potrzebne są dodatkowe mechanizmy: AWS Network Firewall wdrożony w VPC albo zapora sieciowa innego producenta umieszczona za Gateway Load Balancer. Grupy zabezpieczeń i NACL nadal dotyczą instancji w prywatnych podsieciach, niezależnie od NAT.

Oprócz publicznych NAT Gateway (z EIP zapewniającymi dostęp do Internetu) AWS obsługuje prywatne NAT Gateway bez EIP. Prywatne NAT Gateway służą do tłumaczenia prywatnych adresów IP dla ruchu między VPC lub między VPC a sieciami lokalnymi, gdy zakresy CIDR nakładają się na siebie. Jeśli na przykład VPC-A (10.0.0.0/16) musi komunikować się z siecią lokalną, która również korzysta z 10.0.0.0/16, prywatny NAT Gateway w VPC-A tłumaczy źródłowe adresy IP na niekolidujący zakres, a następnie kieruje ruch przez Transit Gateway do sieci lokalnej.

Stan i wydajność NAT Gateway należy monitorować za pomocą metryk CloudWatch. Najważniejsze metryki to: ActiveConnectionCount (bieżąca liczba aktywnych połączeń TCP przechodzących przez NAT), BytesInFromDestination / BytesInFromSource (transfer danych w obu kierunkach), PacketDropCount (liczba odrzuconych pakietów — wskazuje na ograniczenia przepustowości lub błędy) oraz ErrorPortAllocation (NAT wyczerpał pulę przydzielonych portów — może to wskazywać na wyczerpanie portów z powodu zbyt dużej liczby połączeń). Każdy NAT Gateway obsługuje maksymalnie 55 000 jednoczesnych połączeń do każdego unikalnego miejsca docelowego; po przekroczeniu tego limitu połączenia mogą być odrzucane.

Nie wszystkie obciążenia w prywatnych podsieciach potrzebują NAT Gateway. Należy przeanalizować sposób dostępu: jeśli instancje muszą komunikować się wyłącznie z innymi zasobami VPC i usługami AWS dostępnymi za pośrednictwem punktów końcowych VPC (S3, DynamoDB, SSM, ECR, Secrets Manager), można całkowicie zrezygnować z NAT Gateway — oszczędzając około 32 USD miesięcznie za każdą strefę AZ oraz opłaty za przetwarzanie danych. Jest to idealny model dla całkowicie prywatnych mikrousług, które korzystają z VPC Interface Endpoints przy każdym dostępie do usług AWS. Należy przeanalizować każdą usługę wywoływaną przez instancje i sprawdzić, czy NAT można zastąpić bezpłatnym Gateway Endpoint lub płatnym Interface Endpoint.

Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji dowiedział się Pan / dowiedziała się Pani, że: NAT Gateway zapewniają instancjom w prywatnych podsieciach dostęp do Internetu w ruchu wychodzącym, tłumacząc ich prywatne adresy IP na Elastic IP, należy dodać trasę 0.0.0.0/0 w tablicy tras prywatnej podsieci, wskazującą NAT Gateway, a także że aby zapewnić wysoką dostępność i uniknąć opłat za transfer danych między strefami AZ, należy wdrożyć po jednym NAT Gateway w każdej strefie AZ. Następnie porównamy Network ACL i Security Groups jako warstwy ochrony VPC.