Routing w VPC, czyli kto komu przesyła pakiety
W poprzedniej lekcji poznałeś VPC, subnety i Internet Gateway. Ale skąd Twoje zasoby wiedzą, dokąd wysłać ruch sieciowy? Odpowiedź to Route Tables (tablice routingu).
Route Table to zestaw reguł (tras), które decydują, gdzie kierowany jest ruch wychodzący z subnetu. Każdy subnet w VPC musi być powiązany z dokładnie jedną Route Table. Jeśli nie przypiszesz mu żadnej, użyje domyślnej Route Table VPC (Main Route Table).
Jak działają Route Tables?
Route Table zawiera listę tras. Każda trasa składa się z dwóch elementów:
- Destination - zakres adresów IP (CIDR), do którego chcesz kierować ruch
- Target - gdzie ten ruch ma trafić (np. Internet Gateway, NAT Gateway, VPC Peering)
Przykładowa Route Table publicznego subnetu:
| Destination | Target | Opis |
|---|---|---|
| 10.0.0.0/16 | local | Ruch wewnątrz VPC, zawsze obecna |
| 0.0.0.0/0 | igw-abc123 | Cały pozostały ruch → Internet Gateway |
Trasa local jest automatycznie dodawana do każdej Route Table i nie można jej usunąć. Umożliwia komunikację między wszystkimi subnetami wewnątrz VPC.
NAT Gateway - internet dla prywatnych subnetów
Instancje w prywatnych subnetach nie mają publicznych IP i nie mają trasy do Internet Gateway. Ale co, jeśli potrzebują pobrać aktualizacje systemu, ściągnąć pakiety z npm albo wysłać logi do zewnętrznego serwisu?
Tutaj wchodzi NAT Gateway (Network Address Translation). NAT Gateway pozwala instancjom w prywatnym subnecie inicjować połączenia wychodzące do internetu, ale blokuje połączenia przychodzące z internetu. To jak drzwi, które otwierają się tylko w jedną stronę.
Jak to działa?
- NAT Gateway jest deployowany w public subnecie (bo sam potrzebuje dostępu do internetu)
- Otrzymuje Elastic IP (stały publiczny adres IP)
- Route Table prywatnego subnetu kieruje ruch
0.0.0.0/0do NAT Gateway - NAT Gateway tłumaczy prywatny IP instancji na swój publiczny IP i przekazuje ruch do IGW
- Odpowiedź wraca tą samą drogą
Masz serwer aplikacji EC2 w prywatnym subnecie (10.0.10.0/24). Musisz zainstalować pakiety z internetu. Oto ścieżka pakietu:
- EC2 (10.0.10.15) wysyła request do
registry.npmjs.org - Route Table prywatnego subnetu: 0.0.0.0/0 → nat-gw-xyz
- NAT Gateway (w public subnecie) zamienia adres źródłowy na swój Elastic IP (np. 54.93.x.x)
- NAT Gateway wysyła pakiet przez Internet Gateway do internetu
- Odpowiedź wraca do NAT Gateway → NAT tłumaczy z powrotem na 10.0.10.15 → pakiet trafia do EC2
Efekt: instancja w prywatnym subnecie może pobrać pakiety, ale nikt z internetu nie może się do niej bezpośrednio połączyć. Idealne do bezpieczeństwa!
NAT Gateway vs NAT Instance
Historycznie, zanim AWS wprowadził zarządzaną usługę NAT Gateway, ludzie stawiali zwykłe instancje EC2 skonfigurowane jako NAT (NAT Instance). Dziś NAT Instance to raczej ciekawostka egzaminacyjna niż realna praktyka.
| Cecha | NAT Gateway | NAT Instance |
|---|---|---|
| Zarządzanie | Fully managed przez AWS | Ty zarządzasz (EC2) |
| Dostępność | HA w ramach AZ | Musisz sam konfigurować HA |
| Wydajność | Do 100 Gbps | Zależy od typu instancji |
| Security Groups | Nie można przypisać | Można przypisać SG |
| Bastion Host | Nie można użyć jako bastion | Można użyć jako bastion |
| Koszt | Opłata za godzinę + transfer | Koszt EC2 + transfer |
| Source/Dest Check | Automatycznie wyłączony | Musisz ręcznie wyłączyć |
Elastic IP (EIP)
Elastic IP to statyczny, publiczny adres IPv4, który możesz przydzielić do swojego konta AWS i przypisać do instancji EC2 lub NAT Gateway. W przeciwieństwie do standardowego publicznego IP (który zmienia się po restarcie instancji), Elastic IP jest stały i nie zmienia się, dopóki go nie zwolnisz.
Kluczowe fakty o Elastic IP:
- Jest bezpłatny, dopóki jest przypisany do działającej instancji
- AWS nalicza opłatę za Elastic IP, który NIE jest do niczego przypisany (walka z marnowaniem publicznych IPv4)
- Domyślny limit to 5 Elastic IP na region (można poprosić o zwiększenie)
- Możesz szybko „przenieść" Elastic IP na inną instancję (np. przy failover)
Architektura HA dla NAT Gateway
NAT Gateway jest highly available w ramach jednej AZ, ale jeśli ta AZ ulegnie awarii, Twoje prywatne subnety w innych AZ stracą dostęp do internetu (bo ich trasy wskazywały na NAT GW w uszkodzonej AZ).
Rozwiązanie? Stwórz osobny NAT Gateway w każdej AZ i ustaw Route Tables prywatnych subnetów tak, by każdy korzystał z NAT Gateway w swojej AZ. To kosztuje więcej, ale gwarantuje HA.
Typowa konfiguracja Multi-AZ z dwoma AZ:
Private Subnet AZ-a Route Table:
| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | nat-gw-AZa |
Private Subnet AZ-b Route Table:
| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | nat-gw-AZb |
Dzięki temu awaria jednej AZ nie wpływa na routing w drugiej. Każdy NAT Gateway jest niezależny.
- Route Tables decydują, gdzie kierowany jest ruch sieciowy z subnetu
- Trasa „local" jest automatyczna i umożliwia komunikację wewnątrz VPC
- AWS wybiera trasę z najdłuższym prefixem (most specific match)
- NAT Gateway pozwala prywatnym subnetom na ruch wychodzący do internetu
- NAT Gateway musi być w public subnecie i potrzebuje Elastic IP
- NAT Gateway jest managed i HA w ramach AZ (zalecany przez AWS)
- NAT Instance to starsza alternatywa (EC2), dziś rzadko stosowana
- Elastic IP to statyczny publiczny IPv4, płatny gdy nieprzypisany
- Dla HA: osobny NAT Gateway w każdej AZ z osobną Route Table
Instancja EC2 w prywatnym subnecie musi pobrać aktualizacje z internetu. Co jest wymagane?
Kiedy AWS nalicza opłatę za Elastic IP?
Czym różni się NAT Gateway od NAT Instance?