Projektowanie architektury VPC w AWS dla maksymalnej wydajności. Private networking cloud, best practices i optymalizacja sieci dla enterprise.

Wprowadzenie: Dlaczego architektura sieciowa decyduje o sukcesie projektu w AWS

Podczas jednej z migracji enterprise, z którą pracowałem, zespół deweloperski zmagał się z opóźnieniami rzędu 200-300 ms w komunikacji między usługami. Po trzech tygodniach profile'owania kodu i optymalizacji zapytań do baz danych, okazało się, że problem leżał w prostym błędzie projektowym: dwie instancje EC2 w różnych Availability Zones komunikowały się przez publiczny internet zamiast przez wewnętrzną sieć AWS. Koszt: dodatkowe 40% na rachunkach za ruch sieciowy i frustracja zespołu operacyjnego.

To nie jest odosobniony przypadek. Według raportu AWS Well-Architected Framework, nieprawidłowo zaprojektowana sieć VPC to przyczyna co trzeciego problemu z wydajnością w środowiskach enterprise. W Ciro Cloud widzimy to codziennie: firmy, które zaczęły od prostego "testowego" VPC z adresem 10.0.0.0/16, teraz próbują rozbudować tę architekturę o środowiska produkcyjne, środowiska izolowane dla compliance, i integracje z centrami danych on-premises — natrafiając na limity i konflikty adresacji.

W tym artykule przedstawiam sprawdzoną metodologię projektowania architektury sieciowej AWS, która skaluje się od startupów po korporacje z setkami usług i wieloma kontami AWS.

Podstawy architektury VPC: Struktura i komponenty

Amazon Virtual Private Cloud (VPC) to fundament cloud networking w AWS. To logicznie odizolowana sekcja chmury AWS, gdzie definiujesz własną przestrzeń adresową IP, subnety, tabele tras, i mechanizmy bezpieczeństwa.

Komponenty rdzeniowe VPC

Każda architektura VPC składa się z kilku kluczowych elementów:

  • CIDR Block — zakres adresów IP przypisany do VPC (np. 10.0.0.0/8, 172.16.0.0/12, lub 192.168.0.0/16)
  • Subnety — logiczne segmenty VPC, zazwyczaj mapowane na Availability Zones
  • Internet Gateway (IGW) — punkt dostępu do publicznego internetu
  • NAT Gateway/Instance — mechanizm umożliwiający instancjom w subnetach prywatnych dostęp do internetu
  • VPC Router — wewnętrzny komponent zarządzający routingiem między subnetami i do/z IGW
  • Route Tables — definiują trasy dla ruchu sieciowego
  • Security Groups — stanowe firewalle na poziomie instancji
  • Network ACLs (NACLs) — stateless firewalle na poziomie subnety

Typy subnetyów: Publiczne vs. Prywatne

Subnety publiczne to te, w których instancje mają bezpośrednią trasę do Internet Gateway. Tak wygląda typowy routing:

Destination: 0.0.0.0/0 → Target: igw-xxxxx (Internet Gateway)

Subnety prywatne nie mają trasy do IGW. Instancje w tych subnietach mogą komunikować się ze światem zewnętrznym tylko przez NAT Gateway lub NAT Instance.

Planowanie przestrzeni adresowej: Unikanie pułapek

Projektowanie CIDR to pierwsza strategiczna decyzja, która determinuje możliwości skalowania. Widziałem wiele organizacji, które wybrały zbyt małą przestrzeń adresową i teraz muszą przebudowywać całą architekturę.

Rekomendowane zakresy prywatne (RFC 1918)

Zakres Notacja CIDR Liczba adresów Zastosowanie
Duży 10.0.0.0/8 16,777,216 Enterprise z wieloma kontami
Średni 172.16.0.0/12 1,048,576 Średnie organizacje
Mały 192.168.0.0/16 65,536 Małe wdrożenia, izolowane środowiska

Reguła "leave room to grow"

Zasada, której trzymam się w każdym projekcie: nigdy nie wybieraj mniejszej przestrzeni niż /16 dla głównego VPC. Jeśli planujesz architekturę wielokontową z AWS Organizations, rozważ /8 z predefiniowanymi blokami per konto:

  • 10.0.0.0/8 (cała organizacja)
    • 10.0.0.0/16 (konto produkcyjne)
    • 10.1.0.0/16 (konto staging)
    • 10.2.0.0/16 (konto deweloperskie)
    • 10.3.0.0/16 (konto security/shared services)
    • 10.100.0.0/16 (zakres na integracje on-premises VPN)

Unikanie konfliktów z sieciami on-premises

Przy projektowaniu private networking cloud z połączeniami hybrydowymi (Direct Connect lub VPN), absolutnie krytyczne jest mapowanie przestrzeni adresowej VPC przeciwko istniejącym sieciom firmowym. Typowy scenariusz:

  1. Corporate LAN: 192.168.0.0/16
  2. Data Center on-premises: 10.0.0.0/8
  3. AWS VPC: 172.16.0.0/12

Taka segmentacja eliminuje ryzyko nakładania się tras (overlapping routes), które uniemożliwiają prawidłowe działanie VPN lub Direct Connect.

Architektura subnetyów: Projektowanie dla wysokiej dostępności

Każdy subnet w VPC jest przypisany do jednej Availability Zone. To fundamentalne ograniczenie AWS — subnet nie może "rozciągać" się na wiele AZ. Projektując architekturę high-availability, musisz tworzyć zestawy subnetyów dla każdej strefy.

Trójwarstwowy model klasyczny

Sprawdzony wzorzec dla większości aplikacji:

Warstwa Web (Public Subnets):

  • AZ us-east-1a: 10.0.1.0/24
  • AZ us-east-1b: 10.0.2.0/24
  • Zawiera: Load Balancery (ALB/NLB), Bastion Hosts, NAT Gateways

Warstwa Application (Private Subnets):

  • AZ us-east-1a: 10.0.11.0/24
  • AZ us-east-1b: 10.0.12.0/24
  • Zawiera: Serwery aplikacji, kontenery ECS/EKS, funkcje Lambda w VPC

Warstwa Data (Private Subnets):

  • AZ us-east-1a: 10.0.21.0/24
  • AZ us-east-1b: 10.0.22.0/24
  • Zawiera: RDS, ElastiCache, DocumentDB, wewnętrzne bazy danych

Alternatywne modele: Nadmiarowość vs. izolacja

Model "all private" — eliminuje subnety publiczne całkowicie, używając:- VPC Interface Endpoints (privatelink) dla dostępu do usług AWS

  • AWS Client VPN lub AWS Site-to-Site VPN dla dostępu administracyjnego- Application Load Balancer w trybie wewnętrznym

Ten model jest preferowany w środowiskach z rygorystycznymi wymaganiami bezpieczeństwa (PCI-DSS, HIPAA) i rekomenduję go jako domyślny wybór dla nowych projektów.

NAT Gateway vs NAT Instance: Kiedy co wybrać?

To jedna z najczęstszych decyzji projektowych i źródło wielu nieporozumień.

NAT Gateway — Managed Service

Zalety:

  • Automatyczna redundancja w ramach AZ (SLA 99.9%)
  • Brak zarządzania infrastrukturą, patchowanie, monitoring
  • Skalowalność do 45 Gbps przepustowości
  • Integracja z AWS Shield Standard (DDoS protection)

Ograniczenia:

  • Koszt: $0.045 per GB przetworzonych danych + $0.045 per godzinę (~$32/mo za sam gateway)
  • Działa tylko w jednej AZ (dla high-availability wymaga NAT Gateway w każdej AZ)
  • Brak obsługi protokołów innych niż TCP, UDP, ICMP
  • Statyczny adres IP (ale można użyć Elastic IP)

Wydajność sieci AWS z NAT Gateway:- Przepustowość: do 100 Gbps dla dużych instancji (wymaga cluster placement group)- Opóźnienie: ~1-2 ms dodatkowe w porównaniu do bezpośredniego połączenia

NAT Instance — DIY Approach

Zalety:

  • Pełna kontrola (mozna zainstalować dodatkowe oprogramowanie, np. firewall, proxy)
  • Obsługa protokołów niestandardowych
  • Potencjalnie niższy koszt przy dużym ruchu wychodzącym (opłata za GB zamiast per-gateway)
  • Możliwość użycia w wielu AZ jednocześnie (hub NAT)

Wady:

  • Wymaga zarządzania wysoką dostępnością (Auto Scaling, health checks)
  • Limit przepustowości zależy od typu instancji (maksymalnie ~100 Gbps z c5n.18xlarge)
  • Odpowiedzialność za patchowanie i bezpieczeństwo instancji

Moja rekomendacja

Dla 95% przypadków: NAT Gateway. Oszczędność czasu operacyjnego i przewidywalny koszt przy normalnym ruchu. NAT Instance wybieraj tylko wtedy, gdy:

  • Potrzebujesz zaawansowanego filtrowania ruchu na warstwie 7
  • Masz specyficzne wymagania compliance, które wymagają pełnej kontroli nad urządzeniem NAT
  • Twoje obciążenie generuje ogromne ilości ruchu wychodzącego (>10 TB/miesiąc), gdzie koszt za GB staje się znaczący

VPC Endpoints: Prywatny dostęp do usług AWS

VPC Endpoints to kluczowy element architektury sieci VPC w kontekście private networking cloud. Umożliwiają komunikację między usługami AWS (S3, DynamoDB, SQS, SNS, Secrets Manager, Systems Manager) a instancjami w VPC bez opuszczania sieci AWS.

Gateway Endpoints (S3, DynamoDB)

Bezpłatne punkty końcowe, które dodajesz do route table. Cały ruch do S3/DynamoDB z twoich subnetyów automatycznie przechodzi przez wewnętrzną sieć AWS.

Route table entry:
Destination: pl-63a5400a (S3 prefix list) → Target: vpce-xxxxx

Impact na wydajność: Eliminacja ruchu przez NAT Gateway (oszczędność kosztów) + redukcja opóźnień o 5-15 ms w typowych scenariuszach.

Interface Endpoints (Privatelink)

Płatne punkty końcowe (~$0.01 per hour + opłaty za transfer danych) z prywatnym adresem IP z twojej sieci VPC. Obsługują dziesiątki usług AWS i usługi partnerskie.

Rekomendacja: Dla każdej usługi AWS używanej z instancji w prywatnych subnietach, deploy Interface Endpoint. Typical savings: $50-200/miesiąc na eliminacji ruchu przez NAT Gateway dla Secrets Manager, Systems Manager Session Manager, i ECR.

Transit Gateway: Architektura wielokontowa i hybrydowa

Gdy organizacja rośnie i pojawia się potrzeba połączenia wielu VPC (własnych lub w ramach AWS Organizations) oraz sieci on-premises, Transit Gateway (TGW) staje się centralnym punktem routingu.

Kiedy Transit Gateway jest niezbędny?

Scenariusz Rekomendacja
<5 VPC, proste połączenia VPC Peering (niższy koszt)
5-20 VPC, scentralizowany routing Transit Gateway
>20 VPC, hub-and-spoke z izolacją Transit Gateway + AWS RAM sharing
Hybrydowa architektura (DC + cloud) Transit Gateway + Direct Connect/VPN

Transit Gateway Attachment Types

  1. VPC — bezpośrednie połączenie z VPC
  2. VPN — Site-to-Site VPN do on-premises
  3. Direct Connect Gateway — integracja z AWS Direct Connect
  4. Peering — połączenia TGW-to-TGW (między regionami)

Koszty Transit Gateway

  • $0.02 per AZ per hour (~$14.40/miesiąc per AZ)
  • $0.02 per GB danych przetworzonych (między VPC)
  • $0.05 per GB danych (przez VPN lub Direct Connect)

Praktyczny tip: Przy połączeniach między VPC w tym samym regionie, Transit Gateway jest często droższy niż VPC Peering (bezpłatny za ruch międzyregionowy, ale peerings nie skalują się dobrze powyżej ~10 połączeń).

Security Groups i NACLs: Bezpieczeństwo warstwowe

Security Groups (Stateful)

Działają na poziomie instancji ENI. Pamiętają stan połączeń — odpowiedź na dozwolony ruch przychodzący jest automatycznie dozwolona.

Best practices:

  • Stosuj zasadę least privilege: dozwól tylko wymagany ruch
  • Używajnamed security groups zamiast adresów IP (np. "sg-web-servers", "sg-database-servers")
  • Unikaj reguł z source 0.0.0.0/0 dla SSH/RDP w produkcji
  • Security Groups są stateful — odpowiedzi nie musisz jawnie definiować

Network ACLs (Stateless)

Działają na poziomie subnetyu. Każda reguła musi być jawnie zdefiniowana, włącznie z odpowiedziami.

Kiedy używać NACLs:

  • Blokowanie całego ruchu z określonych zakresów IP (edge-level filtering)
  • Wymuszanie ephemeral ports (1024-65535) dla ruchu wychodzącego
  • Dodatkowa warstwa izolacji między subnetyami

Tip: Nie nadużywaj NACLs. Dla większości aplikacji, Security Groups + WAF (Web Application Firewall) wystarczą. Zbyt restrykcyjne NACLs to częsta przyczyna "mystery" problemów z łącznością.

Optymalizacja wydajności sieci AWS: Advanced techniques

Elastic Network Interfaces (ENI) i przepustowość

Przepustowość sieciowa instancji EC2 zależy od typu instancji:

Typ instancji Przepustowość ENIs IPs per ENI
t3.medium Do 2.125 Gbps 3 6
c5.large Do 10 Gbps 3 10
c5n.18xlarge 100 Gbps 15 50
c6in.48xlarge 400 Gbps 15 50

Network I/O Credit: Dla instancji burst'owych (t3, t3a, t4g), przepustowość jest ograniczona do baseline'u po wyczerpaniu creditów. W środowisku produkcyjnym z wymaganiami wydajnościowymi, zawsze wybieraj instancje z gwarantowaną przepustowością (m5, c5, c6i i nowsze).

Placement Groups: Klastry, Partycje, Rozproszenie

Cluster Placement Group:

  • Maksymalizuje przepustowość między instancjami (do 400 Gbps dla c6in.48xlarge)
  • Użyj dla HPC, ML training, Redis clusters
  • Wszystkie instancje w jednej AZ

Partition Placement Group:

  • Izoluje instancje na poziomie racków
  • Użyj dla HDFS, Kafka, Spark (odporność na awarię całego racku)
  • Spread max 7 partitions per AZ

Spread Placement Group:

  • Maksymalna izolacja (1 instancja per rack)
  • Użyj dla critical control plane services
  • Limit 7 instancji per AZ

Wydajność storage a networking

Często pomijany aspekt: przy projektowaniu architektury obsługującej intensywny I/O (bazy danych, data lakes), musisz balansować:

  1. Instance store — najwyższa przepustowość, ale efemeralna (dane tracone przy zatrzymaniu)
  2. EBS io2 Block Express — 64 TB max, 1,000 MB/s per TB, <1 ms latency
  3. EFS — file storage przez sieć, max ~3 GB/s aggregate throughput
  4. FSx for NetApp ONTAP — enterprise file storage z cachingiem

Monitoring i diagnostyka sieci VPC

Essential CloudWatch Metrics

Skonfiguruj monitoring następujących metryk:

  • VPC Flow Logs — loguj cały ruch sieciowy do S3 lub CloudWatch Logs
  • NAT Gateway metrics: ActiveConnections, PacketsInToDestination, PacketsOutFromSource
  • Transit Gateway metrics: BytesIn, BytesOut, PacketDropCount
  • VPN metrics: TunnelDataIn, TunnelDataOut, TunnelState

Tools diagnostyczne

  1. VPC Reachability Analyzer — automatycznie analizuje ścieżkę sieciową między dwoma endpointami
  2. AWS Network Manager — centralny widok całej globalnej sieci (Transit Gateway, Direct Connect, VPN)
  3. traceroute/mtr z instancji — klasyczne narzędzia diagnostyczne
  4. tcpdump/Wireshark — deep packet analysis (tylko w non-production)

Podsumowanie: Checklist projektowy

Przy projektowaniu architektury sieciowej AWS, przejdź przez te punkty:

  1. Planowanie CIDR:

    • Wybrałeś /16 lub większą przestrzeń?
    • Zweryfikowałeś brak konfliktów z on-premises?
    • Masz rezerwę na przyszły wzrost?

  2. Struktura subnetyów:

    • Co najmniej 2 AZ dla HA?
    • Jasny podział public/private?
    • Odpowiedni routing per warstwa?

  3. Security:

    • Security Groups z least privilege?
    • VPC Endpoints dla usług AWS?
    • Flow Logs włączone?

  4. Wydajność:

    • Właściwe typy instancji dla wymagań sieciowych?
    • Placement Groups dla klastrów?
    • Monitoring skonfigurowany?

  5. Koszty:

    • Kalkulacja NAT Gateway vs NAT Instance?
    • VPC Endpoints zamiast NAT dla usług AWS?
    • Transit Gateway vs VPC Peering analysis?

Dobrze zaprojektowana architektura sieciowa to fundament wydajnej, bezpiecznej i skalowalnej infrastruktury w AWS. Inwestycja czasu w fazę planowania zwraca się wielokrotnie w unikniętych problemach operacyjnych i optymalizacji kosztów. W Ciro Cloud pomagamy firmom projektować i implementować takie architektury — od analizy istniejących środowisk po pełne wdrożenie i transfer wiedzy do zespołów wewnętrznych.

Weekly cloud insights — free

Practical guides on cloud costs, security and strategy. No spam, ever.

Comments

Leave a comment