Łączenie VPC i usług AWS bez wychodzenia do internetu
Do tej pory Twoje VPC było jak samotna wyspa. Miało subnety, routing, firewalle, ale co jeśli potrzebujesz połączyć dwa VPC ze sobą? Albo chcesz, żeby Twoja instancja EC2 w prywatnym subnecie korzystała z S3 bez przechodzenia przez internet? Do tego służą mechanizmy, które poznasz w tej lekcji.
VPC Peering - łączenie dwóch VPC
VPC Peering to połączenie sieciowe między dwoma VPC, które pozwala im komunikować się tak, jakby były w jednej sieci. Ruch między nimi nie przechodzi przez publiczny internet, tylko przez wewnętrzną sieć AWS.
Kluczowe cechy VPC Peering:
- Działa między VPC w tym samym regionie lub między regionami (cross-region)
- Działa między VPC w tym samym koncie lub między kontami (cross-account)
- Zakresy CIDR obu VPC nie mogą się nakładać
- Nie jest tranzytywne! Jeśli VPC-A jest peerowane z VPC-B, a VPC-B z VPC-C, to VPC-A NIE może komunikować się z VPC-C przez VPC-B
- Musisz zaktualizować Route Tables w obu VPC
Firma „DataCorp" ma osobne konta AWS dla zespołów Dev i Prod. Zespół Dev (VPC: 10.0.0.0/16) potrzebuje dostępu do bazy danych w VPC Prod (172.16.0.0/16) do celów debugowania.
Rozwiązanie: VPC Peering cross-account. Konto Prod wysyła zaproszenie do peeringu, konto Dev akceptuje. Obie strony aktualizują Route Tables:
- VPC Dev Route Table: 172.16.0.0/16 → pcx-peering123
- VPC Prod Route Table: 10.0.0.0/16 → pcx-peering123
Security Groups w VPC Prod mogą ograniczyć dostęp tylko do konkretnych portów bazy danych (np. 5432 dla PostgreSQL), dając zespołowi Dev dostęp tylko do tego, czego potrzebuje.
VPC Endpoints - dostęp do usług AWS bez internetu
Wiele usług AWS (S3, DynamoDB, SQS, SNS) to usługi publiczne, dostępne przez internet. Ale co, jeśli Twoja instancja EC2 jest w prywatnym subnecie bez NAT Gateway? Albo chcesz, żeby ruch do S3 nigdy nie opuszczał sieci AWS z powodów bezpieczeństwa?
VPC Endpoints umożliwiają prywatne połączenie z usługami AWS bez przechodzenia przez internet, NAT Gateway czy VPN. Ruch zostaje w sieci AWS.
Dwa typy VPC Endpoints:
| Cecha | Gateway Endpoint | Interface Endpoint |
|---|---|---|
| Obsługiwane usługi | Tylko S3 i DynamoDB | Większość usług AWS |
| Jak działa | Wpis w Route Table | ENI z prywatnym IP w subnecie |
| Koszt | Bezpłatny | Opłata za godzinę + transfer danych |
| Dostęp spoza VPC | Nie | Tak (przez VPN, Direct Connect, Peering) |
| Security Groups | Nie | Tak, przypisane do ENI |
Interface Endpoint tworzy ENI (Elastic Network Interface) z prywatnym adresem IP w Twoim subnecie. Kiedy Twoja aplikacja łączy się z usługą AWS (np. SQS), ruch idzie do tego prywatnego IP zamiast do publicznego endpointa usługi.
Pod spodem Interface Endpoint używa technologii AWS PrivateLink. PrivateLink zapewnia prywatne połączenie, które nie przechodzi przez internet.
Interface Endpoint obsługuje też Private DNS. Gdy włączysz tę opcję, standardowa nazwa DNS usługi (np. sqs.eu-central-1.amazonaws.com) automatycznie rozwiązuje się na prywatny IP endpointa. Twoja aplikacja nie wymaga żadnych zmian w kodzie!
AWS PrivateLink - udostępnianie usług prywatnie
PrivateLink to nie tylko „silnik" pod Interface Endpoints. To osobna usługa, która pozwala Ci udostępnić swoją usługę innym kontom AWS (lub w ramach swojego konta) przez prywatne połączenie.
Jak to działa:
- Service Provider tworzy Network Load Balancer przed swoją usługą i rejestruje ją jako VPC Endpoint Service
- Service Consumer tworzy Interface Endpoint w swoim VPC, który łączy się z tą usługą
- Ruch przechodzi przez prywatną sieć AWS, bez internetu
- Consumer widzi usługę jako ENI z prywatnym IP w swoim VPC
PrivateLink jest używany przez wiele usług SaaS dostępnych na AWS Marketplace (np. Datadog, Snowflake) do bezpiecznego połączenia z Twoim VPC.
Transit Gateway - hub dla wielu VPC
VPC Peering działa świetnie dla 2-3 VPC, ale co gdy masz 10? 50? Przy peeringu potrzebujesz n*(n-1)/2 połączeń, co szybko staje się koszmarem zarządzania.
Transit Gateway (TGW) to regionalny hub sieciowy, który łączy VPC, VPN i Direct Connect w architekturze hub-and-spoke. Zamiast peerować każdy VPC z każdym, łączysz wszystkie z Transit Gateway.
Kluczowe cechy:
- Tranzytywne routing - w przeciwieństwie do VPC Peering, Transit Gateway pozwala na komunikację tranzytywną
- Łączy VPC, VPN, Direct Connect, inne Transit Gateway (cross-region)
- Centralne zarządzanie Route Tables
- Obsługuje tysiące VPC
- Działa w ramach regionu (ale można peerować TGW cross-region)
| Cecha | VPC Peering | Transit Gateway |
|---|---|---|
| Tranzytywność | Nie | Tak |
| Skalowalność | Ograniczona (mesh) | Hub-and-spoke, tysiące VPC |
| Koszt | Tylko transfer danych | Opłata za godzinę + transfer |
| Przypadek użycia | Kilka VPC | Wiele VPC, złożone architektury |
| Cross-region | Tak | Tak (peering TGW) |
- VPC Peering łączy 2 VPC prywatnie, ale NIE jest tranzytywne
- VPC Endpoints pozwalają na prywatny dostęp do usług AWS bez internetu
- Gateway Endpoint (S3, DynamoDB) jest bezpłatny i działa przez Route Table
- Interface Endpoint (większość usług) tworzy ENI i używa PrivateLink
- PrivateLink umożliwia prywatne udostępnianie usług między kontami
- Transit Gateway to hub sieciowy dla złożonych architektur z wieloma VPC
- Transit Gateway obsługuje tranzytywny routing, VPC Peering nie
VPC-A jest peerowane z VPC-B, a VPC-B z VPC-C. Czy VPC-A może komunikować się z VPC-C?
Instancja w prywatnym subnecie musi korzystać z S3 bez internetu. Jakie rozwiązanie jest najtańsze?
Firma ma 15 VPC, które muszą komunikować się ze sobą i z siecią on-premises. Co jest najlepszym rozwiązaniem?