VPC od podstaw - sieci w AWS bez bólu głowy

Kiedy stawiasz pierwszą instancję EC2 albo bazę danych RDS, AWS automatycznie umieszcza ją w domyślnym VPC. Działa, więc nie zastanawiasz się nad siecią. Problem pojawia się, gdy aplikacja rośnie, dochodzą nowe środowiska i nagle okazuje się, że baza danych ma publiczny adres IP, a Security Groups są otwarte na cały świat. Z mojego doświadczenia w ClearScale widzę to regularnie - dlatego napisałem ten poradnik.

Jeśli dopiero zaczynasz przygodę z chmurą, przeczytaj najpierw Jak zacząć z AWS w 2026. Ten artykuł zakłada, że masz już konto AWS i podstawową orientację w konsoli.

Czym jest VPC i dlaczego to fundament Twojej chmury

Amazon Virtual Private Cloud (VPC) to logicznie wydzielona sekcja chmury AWS, w której uruchamiasz zasoby. Pomyśl o tym jak o własnym biurowcu. Ty decydujesz, ile pięter (subnetów) ma budynek, gdzie są drzwi wejściowe (Internet Gateway), kto może wejść (Security Groups) i jakie są trasy między pokojami (Route Tables).

Każdy VPC istnieje w jednym regionie AWS, ale rozciąga się na wszystkie Availability Zones w tym regionie. To daje Ci redundancję od pierwszego dnia.

Bloki CIDR - ile adresów naprawdę potrzebujesz?

CIDR (Classless Inter-Domain Routing) to sposób zapisu zakresu adresów IP. Zapis 10.0.0.0/16 oznacza: "wszystkie adresy od 10.0.0.0 do 10.0.255.255", czyli 65 536 adresów.

Zasada jest prosta - im mniejsza liczba po ukośniku, tym więcej adresów:

Subnety publiczne vs prywatne

Subnet to fragment VPC przypisany do jednej Availability Zone. Dzielą się na dwa typy:

• Subnet publiczny - ma trasę do Internet Gateway. Zasoby mogą mieć publiczny adres IP i być dostępne z Internetu. Tu umieszczasz load balancery (Elastic Load Balancing) i bastion hosty.
• Subnet prywatny - nie ma bezpośredniego dostępu do Internetu. Zasoby mogą łączyć się z Internetem tylko przez NAT Gateway. Tu umieszczasz serwery aplikacyjne, bazy danych i funkcje Lambda w VPC.

Typowa architektura wygląda tak:

Internet Gateway vs NAT Gateway

Internet Gateway (IGW) to brama między Twoim VPC a publicznym Internetem. Jest darmowy, wysoko dostępny i zarządzany przez AWS. Podłączasz go do VPC i dodajesz trasę w Route Table subnetu publicznego.

NAT Gateway pozwala zasobom w prywatnych subnetach łączyć się z Internetem (np. pobierać aktualizacje), ale blokuje ruch przychodzący. Działa w subnecie publicznym i przekierowuje ruch z prywatnych subnetów.

Route Tables - GPS Twojego VPC

Route Table to zestaw reguł określających, dokąd trafia ruch sieciowy. Każdy subnet musi być powiązany z jedną Route Table.

Przykładowa Route Table dla subnetu publicznego:

Route Table dla subnetu prywatnego:

Security Groups vs NACLs - dwie warstwy ochrony

AWS daje Ci dwa mechanizmy firewalla. Różnią się zasadniczo:

Stateful oznacza, że jeśli pozwolisz na ruch przychodzący na porcie 443, odpowiedź automatycznie przejdzie z powrotem. W NACLs (stateless) musisz jawnie zdefiniować reguły dla obu kierunków.

Praktyka - budujemy VPC krok po kroku

Zbudujemy VPC z dwiema warstwami: publiczną (dla load balancera) i prywatną (dla aplikacji). Architektura obejmie dwie Availability Zones dla wysokiej dostępności.

Krok 1 - Tworzenie VPC

aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=cloudmaniak-vpc}]'

# Włącz DNS hostnames (potrzebne dla publicznych DNS)
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-XXXXXXXX \
  --enable-dns-hostnames

Krok 2 - Tworzenie subnetów

Tworzymy cztery subnety - po jednym publicznym i prywatnym w dwóch Availability Zones:

# Subnety publiczne
aws ec2 create-subnet --vpc-id vpc-XXXXXXXX \
  --cidr-block 10.0.1.0/24 --availability-zone eu-central-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=public-subnet-1a}]'

aws ec2 create-subnet --vpc-id vpc-XXXXXXXX \
  --cidr-block 10.0.2.0/24 --availability-zone eu-central-1b \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=public-subnet-1b}]'

# Subnety prywatne
aws ec2 create-subnet --vpc-id vpc-XXXXXXXX \
  --cidr-block 10.0.10.0/24 --availability-zone eu-central-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=private-subnet-1a}]'

aws ec2 create-subnet --vpc-id vpc-XXXXXXXX \
  --cidr-block 10.0.11.0/24 --availability-zone eu-central-1b \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=private-subnet-1b}]'

# Włącz auto-assign publicznych IP dla subnetów publicznych
aws ec2 modify-subnet-attribute \
  --subnet-id subnet-XXXXXXXX \
  --map-public-ip-on-launch

Krok 3 - Internet Gateway, NAT Gateway i Route Tables

# Internet Gateway
aws ec2 create-internet-gateway \
  --tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=cloudmaniak-igw}]'
aws ec2 attach-internet-gateway \
  --internet-gateway-id igw-XXXXXXXX --vpc-id vpc-XXXXXXXX

# Elastic IP + NAT Gateway
aws ec2 allocate-address --domain vpc
aws ec2 create-nat-gateway \
  --subnet-id subnet-PUBLIC-1A \
  --allocation-id eipalloc-XXXXXXXX \
  --tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=cloudmaniak-nat}]'

# Route Table publiczna
aws ec2 create-route-table --vpc-id vpc-XXXXXXXX \
  --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=public-rt}]'
aws ec2 create-route --route-table-id rtb-PUBLIC \
  --destination-cidr-block 0.0.0.0/0 --gateway-id igw-XXXXXXXX
aws ec2 associate-route-table --route-table-id rtb-PUBLIC \
  --subnet-id subnet-PUBLIC-1A
aws ec2 associate-route-table --route-table-id rtb-PUBLIC \
  --subnet-id subnet-PUBLIC-1B

# Route Table prywatna
aws ec2 create-route-table --vpc-id vpc-XXXXXXXX \
  --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=private-rt}]'
aws ec2 create-route --route-table-id rtb-PRIVATE \
  --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-XXXXXXXX
aws ec2 associate-route-table --route-table-id rtb-PRIVATE \
  --subnet-id subnet-PRIVATE-1A
aws ec2 associate-route-table --route-table-id rtb-PRIVATE \
  --subnet-id subnet-PRIVATE-1B

VPC Peering i Transit Gateway - łączenie sieci

Gdy Twoja infrastruktura rośnie, pojawia się potrzeba łączenia VPC ze sobą:

• VPC Peering - bezpośrednie, prywatne połączenie między dwoma VPC. Proste, bez dodatkowych kosztów (płacisz tylko za transfer). Idealne gdy łączysz 2-3 VPC. Ograniczenie: nie działa tranzytywnie (jeśli A jest połączone z B i B z C, to A nie widzi C automatycznie).
• Transit Gateway - centralny hub sieciowy. Łączysz do niego wiele VPC, sieci VPN i połączenia Direct Connect. Kosztuje ok. 0,05 USD/h, ale drastycznie upraszcza zarządzanie gdy masz 4+ sieci.

Z mojego doświadczenia, większość firm przechodzi na Transit Gateway gdy liczba VPC przekracza trzy. Wcześniej VPC Peering jest prostszym i tańszym rozwiązaniem. Więcej o projektowaniu architektury znajdziesz w artykule o architekturze aplikacji webowej w AWS.

Najczęstsze błędy - i jak ich unikać

1. Baza danych w publicznym subnecie - to najpopularniejszy błąd. RDS i inne bazy danych zawsze powinny być w prywatnych subnetach. Jedyny sposób dostępu to przez warstwę aplikacyjną lub bastion host.
2. Security Groups otwarte na 0.0.0.0/0 - szczególnie porty SSH (22) i RDP (3389). Zawsze ograniczaj źródło do konkretnych adresów IP lub Security Groups.
3. Brak planowania CIDR - gdy dwa VPC mają ten sam zakres adresów, nie możesz ich połączyć przez peering. Planuj zakresy z wyprzedzeniem, nawet jeśli dziś masz jeden VPC.
4. Jeden NAT Gateway dla wszystkich AZ - jeśli AZ z NAT Gateway ulegnie awarii, zasoby w prywatnych subnetach w innych AZ stracą dostęp do Internetu. W produkcji twórz NAT Gateway w każdej AZ.
5. Ignorowanie VPC Flow Logs - bez logów nie wiesz, co się dzieje w Twojej sieci. Włącz Flow Logs i wysyłaj je do S3 lub CloudWatch Logs.

Koszty VPC - co jest darmowe, a co nie

Konfiguracja Security Groups - przykład dla aplikacji webowej

Na koniec skonfigurujmy Security Groups dla typowej trójwarstwowej architektury, którą omówiliśmy w artykule o EC2:

• SG dla ALB - ruch przychodzący: TCP 443 (HTTPS) z 0.0.0.0/0
• SG dla EC2/ECS - ruch przychodzący: TCP 8080 z SG ALB (referencja po ID Security Group)
• SG dla RDS - ruch przychodzący: TCP 5432 (PostgreSQL) z SG EC2/ECS

Kluczowa technika to referencja między Security Groups zamiast adresów IP. Gdy dodajesz nową instancję EC2 do SG aplikacji, automatycznie uzyskuje ona dostęp do bazy danych. Zero ręcznych zmian.

Następny krok

Masz działający VPC z publicznymi i prywatnymi subnetami. Czas go wykorzystać. Polecam następujące kroki:

1. Uruchom instancję EC2 w prywatnym subnecie i sprawdź, czy łączy się z Internetem przez NAT Gateway.
2. Skonfiguruj Application Load Balancer w subnetach publicznych i przekieruj ruch do instancji prywatnej.
3. Włącz VPC Flow Logs i przeanalizuj ruch sieciowy po kilku godzinach.
4. Zapoznaj się z Route 53 i podepnij domenę do load balancera.

Sieć to fundament, na którym budujesz wszystko inne. Zainwestowany dziś czas w zrozumienie VPC zaprocentuje przy każdym kolejnym projekcie w AWS.