Architektura VPC i bloki CIDR

Amazon Virtual Private Cloud (VPC) to logicznie odizolowana sieć prywatna w Region AWS, którą można samodzielnie definiować i kontrolować. Każde konto AWS ma domyślny VPC (CIDR 172.31.0.0/16) w każdym Region, ale architektury produkcyjne zawsze korzystają z niestandardowych VPC. VPC obejmuje wszystkie Availability Zones w swoim Region i zapewnia pełną kontrolę nad adresacją IP, podsieciami, tabelami routingu, internet gateways i zabezpieczeniami. Zasoby wewnątrz VPC są odizolowane od innych VPC oraz od internetu, chyba że jawnie skonfigurują Państwo połączenie.

Blok CIDR (Classless Inter-Domain Routing) definiuje zakres adresów IP VPC lub podsieci za pomocą formatu x.x.x.x/prefix. Długość prefiksu określa liczbę adresów IP w zakresie: /16 = 65 536 adresów, /24 = 256 adresów, /28 = 16 adresów (minimalny rozmiar podsieci w AWS). W przypadku VPC AWS dopuszcza bloki CIDR od /16 (największy) do /28 (najmniejszy). Należy wybrać blok CIDR VPC, który: (1) nie nakłada się na sieci lokalne (na potrzeby przyszłych połączeń VPN/Direct Connect), (2) jest wystarczająco duży dla planowanych podsieci oraz (3) korzysta z prywatnej przestrzeni adresowej RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Podsieć to segment zakresu adresów IP VPC znajdujący się w jednej Availability Zone. Podsieci dzielą się na publiczne (mają trasę do internet gateway) i prywatne (nie mają bezpośredniej trasy do internetu). Zalecana praktyka dla typowej architektury trójwarstwowej to utworzenie co najmniej trzech warstw podsieci — public (load balancers, bastion hosts), private-app (instancje EC2, zadania ECS) oraz private-data (RDS, ElastiCache) — i replikowanie każdej warstwy w co najmniej dwóch AZ na potrzeby wysokiej dostępności.

Typowy projekt CIDR dla VPC z CIDR 10.0.0.0/16, obejmującego dwie AZ i trzy warstwy, może wyglądać następująco: Public AZ-a: 10.0.1.0/24; Public AZ-b: 10.0.2.0/24; Private-App AZ-a: 10.0.10.0/24; Private-App AZ-b: 10.0.11.0/24; Private-Data AZ-a: 10.0.20.0/24; Private-Data AZ-b: 10.0.21.0/24. Taki układ pozostawia miejsce na dodanie podsieci AZ-c (10.0.3.0/24, 10.0.12.0/24, 10.0.22.0/24) bez konieczności ponownego planowania całego schematu CIDR. Projektując, zawsze należy uwzględniać możliwość rozwoju.

AWS rezerwuje pierwsze cztery i ostatni adres IP w każdej podsieci. W przypadku podsieci 10.0.1.0/24 są to: 10.0.1.0 (sieć), 10.0.1.1 (router VPC), 10.0.1.2 (DNS/DHCP), 10.0.1.3 (przyszłe zastosowanie) oraz 10.0.1.255 (broadcast). Podsieć /24 ma łącznie 256 adresów IP, z czego 5 jest zarezerwowanych, więc pozostaje 251 użytecznych. Podsieć /28 (minimalna) ma 16 adresów IP, z czego 5 jest zarezerwowanych, więc pozostaje 11 użytecznych. Ma to znaczenie podczas określania rozmiaru podsieci na podstawie liczby zasobów (instancji EC2, funkcji Lambda z VPC itd.), które planują Państwo wdrożyć.

Do istniejącej VPC można dodać maksymalnie cztery dodatkowe bloki CIDR bez jej ponownego tworzenia. Jest to przydatne, gdy podstawowy CIDR został wyczerpany (wszystkie podsieci są pełne) lub gdy trzeba dodać przestrzeń adresową z innego zakresu RFC 1918 na potrzeby konkretnego zastosowania, takiego jak sieć podów Kubernetes. Dodatkowe zakresy CIDR podlegają określonym ograniczeniom — na przykład nie można dodać nakładającego się zakresu CIDR, a niektórych publicznych zakresów spoza RFC 1918 nie można używać. Rozmiar CIDR VPC należy dokładnie zaplanować z wyprzedzeniem, aby zminimalizować potrzebę korzystania z dodatkowych zakresów CIDR.

Peering VPC ustanawia prywatne połączenie sieciowe między dwiema VPC, dzięki czemu ich zasoby mogą komunikować się za pomocą prywatnych adresów IP. Połączone za pomocą peeringu VPC mogą znajdować się na tym samym koncie, na różnych kontach, a nawet w różnych regionach (peering międzyregionowy). Wymagania: zakresy CIDR obu VPC nie mogą się nakładać. Ograniczenia: peering jest nietranzytywny — jeśli VPC-A ma peering z VPC-B, a VPC-B z VPC-C, VPC-A nie może komunikować się z VPC-C za pośrednictwem VPC-B. Aby zapewnić pełną łączność typu mesh między wieloma VPC, należy zamiast tego użyć AWS Transit Gateway.

AWS Transit Gateway (TGW) działa jako centralny hub sieciowy — router w chmurze — który łączy wiele VPC, sieci VPN i połączeń Direct Connect. Zamiast tworzyć N*(N-1)/2 połączeń peeringu VPC dla pełnej siatki N VPC, dołączasz każdą VPC i każde połączenie do Transit Gateway, który kieruje między nimi ruch. TGW obsługuje tablice routingu pozwalające kontrolować, które dołączone zasoby mogą się ze sobą komunikować, co umożliwia segmentację sieci (np. odizolowanie produkcyjnych VPC od deweloperskich VPC w ramach tego samego TGW).

Dwa ustawienia DNS kontrolują rozpoznawanie nazw w VPC. enableDnsSupport: gdy ma wartość true (domyślnie), VPC korzysta z dostarczanego przez AWS resolvera DNS pod adresem 169.254.169.253 lub drugim adresem IP zakresu CIDR VPC (np. 10.0.0.2 dla 10.0.0.0/16). enableDnsHostnames: gdy ma wartość true (musi być włączone dla niestandardowych VPC, a w domyślnej VPC jest domyślnie włączone), instancje EC2 w VPC otrzymują nazwy hostów DNS, takie jak ip-10-0-1-15.ec2.internal. Oba ustawienia muszą być włączone, aby prywatne hostowane strefy Route 53 działały w VPC.

Dzienniki przepływu VPC rejestrują metadane dotyczące ruchu sieciowego przepływającego przez VPC — źródłowy i docelowy adres IP, port, protokół, liczbę przesłanych bajtów oraz informację, czy ruch został zaakceptowany, czy odrzucony. Dzienniki przepływu można publikować w CloudWatch Logs (do wykonywania zapytań za pomocą Logs Insights) lub w S3 (do analizy za pomocą Athena). Są niezwykle cenne podczas analizy incydentów bezpieczeństwa (kto połączył się z czym), analizy ruchu (identyfikowanie przepływów o dużej przepustowości) i rozwiązywania problemów (dlaczego połączenie zostało odrzucone?). Dzienniki przepływu działają na poziomie VPC, podsieci lub pojedynczego ENI.

Przed utworzeniem VPC należy zaplanować wszystkie przyszłe potrzeby związane z łącznością: łączność z infrastrukturą lokalną (VPN lub Direct Connect) — upewnij się, że CIDR VPC nie nakłada się na podsieci lokalne; łączność między VPC (peering lub Transit Gateway) — zaplanuj niepokrywające się zakresy CIDR we wszystkich VPC w organizacji; dostęp do usług AWS (punkty końcowe VPC dla S3, DynamoDB i SSM, aby uniknąć kierowania ruchu przez internet); oraz rozmiar podsieci — pozostaw zapas w każdej podsieci na zużycie adresów IP przez pody EKS, funkcje Lambda i interfejsy Elastic Network Interface.

W tej lekcji poznano następujące zagadnienia: VPC to logicznie odizolowana sieć w regionie, zdefiniowana przez blok CIDR dzielony na publiczne i prywatne podsieci w różnych AZ, AWS rezerwuje 5 adresów IP w każdej podsieci, dlatego przy określaniu jej rozmiaru należy zawsze uwzględnić to pomniejszenie oraz peering VPC i Transit Gateway zapewniają prywatne połączenia między VPC, ale zakresy CIDR nie mogą się nakładać. W następnej części omówimy Internet Gateways i tablice routingu.