AWS NAT Gateway - rzeczywiste koszty, pułapki i strategie optymalizacji w VPC

Dlaczego AWS NAT Gateway w VPC generuje wysokie koszty i kiedy jest niezbędny?

NAT Gateway to kluczowy komponent architektury AWS VPC, który umożliwia instancjom w prywatnych podsieciach dostęp do internetu bez nadawania im publicznych adresów IP. Z perspektywy bezpieczeństwa jest to standardowy wzorzec: serwery aplikacyjne, bazy danych czy backendowe mikroserwisy pozostają w prywatnych podsieciach, a jednocześnie mogą pobierać aktualizacje, obrazy kontenerów czy komunikować się z zewnętrznymi API.

Typowe zastosowania NAT Gateway:

• Pobieranie pakietów aktualizacyjnych z publicznych repozytoriów (np. yum, apt, pip)
• Komunikacja z zewnętrznymi API (płatności, CRM, systemy billingowe)
• Wysyłanie logów i metryk do usług monitorowania spoza VPC
• Pobieranie artefaktów z Docker Hub, GitHub, publicznych rejestrów

NAT Gateway umieszczamy w publicznych podsieciach i kierujemy przez niego ruch z prywatnych podsieci za pomocą odpowiednich route tables. To poprawny wzorzec bezpieczeństwa, ale jeśli nie jest zaprojektowany świadomie, staje się jednym z bardziej „ukrytych” generatorów kosztów w chmurze AWS.

Jak działa model kosztowy AWS NAT Gateway i gdzie faktycznie płacisz?

AWS rozlicza NAT Gateway w dwóch głównych wymiarach, które trzeba rozumieć łącznie: opłata za godzinę działania oraz opłata za przetworzony ruch.

Opłata za godzinę działania NAT Gateway w VPC

Opłata za godzinę działania. Każdy NAT Gateway generuje stały koszt za każdą godzinę, w której jest aktywny. W regionie us-east-1 jest to około 0,045 USD/godzinę (ceny różnią się w zależności od regionu i należy je zawsze weryfikować w aktualnym cenniku AWS). NAT Gateway działający przez cały miesiąc (720 godzin) to ~32 USD/miesiąc samej opłaty za dostępność.

W środowiskach produkcyjnych, gdzie standardem jest wysoka dostępność (co najmniej 2 strefy dostępności), ten koszt mnoży się liniowo wraz z liczbą bram NAT.

Opłata data processing w NAT Gateway

Opłata za przetworzony ruch (GB). Drugim składnikiem jest opłata za każdy GB danych przetworzony przez NAT Gateway. W regionie us-east-1 jest to około 0,045 USD/GB (również zależne od regionu).

Przykład: 1 TB (1024 GB) danych przetworzonych przez NAT Gateway w miesiącu to 1024 GB x 0,045 USD/GB ≈ 46 USD/miesiąc.

W praktyce to właśnie ten komponent (data processing) potrafi „wystrzelić”, gdy:

• obrazy Docker są pobierane wielokrotnie z publicznych rejestrów,
• brak jest buforowania zależności (np. pakietów językowych),
• ruch do usług AWS (S3, DynamoDB, CloudWatch) idzie przez NAT zamiast przez VPC Endpoints.

Gdzie nie płacisz za NAT Gateway

Za co nie płacisz w kontekście NAT Gateway:

• Ruch między instancjami w tej samej VPC (routing lokalny local w route table)
• Ruch do usług AWS w ramach tej samej VPC przez VPC Endpoint (np. S3, DynamoDB)
• Ruch przychodzący do instancji (NAT Gateway rozlicza tylko ruch wychodzący)

To oznacza, że poprawne użycie VPC Endpoints oraz projektowanie ruchu wewnątrz VPC ma bezpośredni wpływ na rachunek za NAT Gateway.

Porównanie AWS NAT Gateway vs NAT Instance (EC2) pod kątem kosztów i zarządzania

AWS oferuje dwa główne mechanizmy translacji adresów w VPC: zarządzany NAT Gateway oraz NAT Instance oparty o EC2. Wybór między nimi to klasyczny kompromis: koszt vs niezawodność i prostota operacyjna.

NAT Gateway jest droższy w przeliczeniu na GB, ale oferuje automatyczną skalowalność, brak konieczności patchowania systemu operacyjnego i prostszy model operacyjny. NAT Instance może być sensowny w środowiskach testowych, dev lub przy bardzo niskim ruchu.

Realna kalkulacja kosztów NAT Gateway w typowej architekturze VPC

Załóżmy typową architekturę produkcyjną:

• 2 NAT Gateway (po jednym w każdej strefie dostępności dla wysokiej dostępności)
• 500 GB ruchu wychodzącego miesięcznie
• Region: us-east-1

Obliczenie:

• Opłata za dostępność: 2 NAT Gateway x 720 h/miesiąc x 0,045 USD/h ≈ 64 USD/miesiąc
• Opłata za ruch: 500 GB x 0,045 USD/GB ≈ 23 USD/miesiąc
• Łącznie: ~87 USD/miesiąc za NAT Gateway

W skali roku to już ponad 1000 USD tylko za warstwę NAT. Dla organizacji z wysokim ruchem wychodzącym (wiele TB miesięcznie) koszty mogą rosnąć do kilku lub kilkunastu tysięcy dolarów rocznie.

Główne źródła kosztów NAT Gateway i potencjał oszczędności

Strategie optymalizacji kosztów NAT Gateway w AWS

1. Używaj VPC Endpoints zamiast NAT Gateway do usług AWS. Zamiast routować ruch do usług AWS (S3, DynamoDB, CloudWatch, Systems Manager) przez NAT Gateway, należy użyć VPC Endpoints. Dla S3 i DynamoDB są to Gateway Endpoints, które są bezpłatne (brak opłaty godzinowej i brak opłaty za GB po stronie endpointu).

Wdrożenie:

1. Wejdź do AWS Management Console → VPC → Endpoints.
2. Utwórz Gateway Endpoint dla S3 oraz DynamoDB.
3. Wybierz odpowiednią VPC oraz route tables używane przez prywatne podsieci.
4. Zapisz zmiany i zweryfikuj, że ruch do S3/DynamoDB nie przechodzi już przez NAT Gateway.

Jeśli znaczna część ruchu wychodzącego dotyczy usług AWS, wdrożenie VPC Endpoints potrafi obniżyć koszty NAT Gateway nawet o ~50%.

2. Konsoliduj ruch przez jeden NAT Gateway. Jeśli krótkotrwała niedostępność nie jest krytyczna (np. środowiska dev, test, staging), można rozważyć użycie jednego NAT Gateway zamiast jednego na każdą strefę dostępności. Oszczędności: 50% opłat za dostępność (~32 USD/miesiąc w naszym przykładzie).

3. Zoptymalizuj rozmiar obrazów i pobieranych danych. Wiele organizacji generuje zbędny ruch przez NAT Gateway:

• Layer caching w Dockerze - używaj Amazon ECR jako prywatnego rejestru, aby obrazy były pobierane z wewnątrz AWS, a nie z internetu
• Lokalne repozytoria pakietów - hostuj pakiety w S3 lub wewnętrznych repozytoriach (np. Artifactory, Nexus)
• CloudFront dla statyki - serwuj pliki statyczne przez CloudFront zamiast bezpośrednio z EC2 za NAT
• Kompresja (gzip, brotli) - włącz kompresję dla wszystkich transferów tekstowych

Możliwe oszczędności: 20-40% ruchu wychodzącego.

4. Monitoruj wydatki i konfiguruj alerty kosztowe. Korzystaj z AWS Cost Explorer do śledzenia wydatków na NAT Gateway. Skonfiguruj budżety w AWS Budgets z powiadomieniami uruchamianymi przy wzroście kosztów.

1. W AWS Billing Console otwórz Cost Explorer.
2. Ustaw filtr Service = "NAT Gateway".
3. Analizuj koszty w ujęciu dziennym/miesięcznym, szukając skoków.
4. W AWS Budgets utwórz budżet typu Cost dla NAT Gateway i ustaw próg alertu (np. 80% planowanego budżetu).

5. Rozważ NAT Instance przy niskim ruchu. Dla środowisk non-prod lub przy bardzo niskim ruchu (<50 GB/miesiąc) NAT Instance może być tańsza niż NAT Gateway. Koszt t3.nano: ~0,0052 USD/godzinę = ~3,74 USD/miesiąc. Pamiętaj jednak, że tracisz automatyczną dostępność i skalowalność.

Jak zmniejszyć ruch przez NAT Gateway w praktyce

Przeanalizuj rzeczywisty ruch. Skorzystaj z VPC Flow Logs, aby zobaczyć, co faktycznie przechodzi przez NAT Gateway:

1. W AWS Console przejdź do VPC → Your VPCs → Flow Logs.
2. Utwórz nowy Flow Log dla prywatnego subnetu (lub całej VPC).
3. Skieruj logi do CloudWatch Logs (lub S3) w dedykowanym log group.
4. Analizuj logi, identyfikując docelowe adresy IP/porty generujące największy ruch.

Często dopiero analiza Flow Logs ujawnia nieoczekiwane pobierania (np. buildy CI/CD ściągające gigabajty artefaktów) lub skanowanie generujące nadmiarowy ruch.

Włącz cache zależności. Używaj Amazon ECR zamiast Docker Hub do przechowywania obrazów Docker. Hostuj pakiety w S3 zamiast pobierać je z publicznych repozytoriów. Włącz cache odpowiedzi API w ElastiCache (Redis/Memcached).

Ogranicz ruch wychodzący. Domyślnie wiele Security Groups ma regułę „allow all outbound”, co sprzyja niekontrolowanemu ruchowi przez NAT Gateway. Skonfiguruj reguły Security Group:

- Zezwalaj: Port 443 (HTTPS) do zaufanych publicznych API (np. konkretne CIDR lub FQDN przez proxy)
- Zezwalaj: Port 53 (DNS) do Route 53 Resolver lub dedykowanego serwera DNS
- Blokuj: Wszystkie pozostałe połączenia outbound (domyślnie deny)

Takie podejście ogranicza powierzchnię ataku, redukuje niepotrzebny ruch i ułatwia audyt oraz FinOps.

AWS NAT Gateway a alternatywy w architekturze sieciowej

Dobre praktyki FinOps dla AWS NAT Gateway i kosztów sieci w VPC

Planuj architekturę z myślą o kosztach. Przed wdrożeniem oszacuj spodziewany ruch wychodzący (CI/CD, aktualizacje, API), oblicz koszty różnych scenariuszy (1 vs 2 NAT Gateway, z VPC Endpoints vs bez) i jeśli to możliwe, wybierz regiony z niższymi cenami transferu i NAT Gateway.

Korzystaj z Data Transfer Savings Plans. AWS oferuje Data Transfer Savings Plans, które mogą zmniejszyć koszty transferu danych nawet o ~40%, jeśli Twój ruch wychodzący jest przewidywalny i przekracza np. 1 TB/miesiąc.

Automatyzuj usuwanie nieużywanych NAT Gateway. NAT Gateway, które nie są już routowane (brak wpisów w route tables), nadal generują opłaty godzinowe. Warto wdrożyć cykliczny mechanizm ich czyszczenia:

import boto3


ec2 = boto3.client("ec2")


def find_unused_nat_gateways():
    nat_gateways = ec2.describe_nat_gateways()["NatGateways"]
    route_tables = ec2.describe_route_tables()["RouteTables"]

    used_nat_ids = set()
    for rt in route_tables:
        for route in rt.get("Routes", []):
            nat_id = route.get("NatGatewayId")
            if nat_id:
                used_nat_ids.add(nat_id)

    unused = [ng for ng in nat_gateways if ng["NatGatewayId"] not in used_nat_ids]
    return unused


if __name__ == "__main__":
    unused_nat = find_unused_nat_gateways()
    for ng in unused_nat:
        print(f"Nieużywany NAT Gateway: {ng['NatGatewayId']} w stanie {ng['State']}")

Nawet prosta automatyzacja, uruchamiana raz w miesiącu, potrafi wyeliminować „zapomniane” NAT Gateway i odzyskać kilkaset dolarów rocznie.

Dokumentuj decyzje architektoniczne. Zapisuj uzasadnienia decyzji, np. dlaczego wybrano 2 NAT Gateway zamiast 1 albo dlaczego zrezygnowano z VPC Endpoint. Ułatwia to późniejsze przeglądy kosztów.

Przeglądaj koszty co miesiąc. Na koniec każdego miesiąca przeanalizuj koszty NAT Gateway w AWS Cost Explorer, porównaj je z poprzednimi miesiącami i zidentyfikuj anomalie.

Narzędzia do monitorowania kosztów i ruchu NAT Gateway

AWS Cost Explorer - filtruj po usłudze „NAT Gateway” w kategorii Service, analizuj koszty w ujęciu dziennym i miesięcznym, identyfikuj trendy i anomalie. Bezpłatne, wbudowane w konsolę AWS.

CloudWatch Metrics - NAT Gateway publikuje metryki do Amazon CloudWatch (ilość przetworzonych bajtów, liczbę aktywnych połączeń). Twórz dashboardy do monitorowania ruchu i konfiguruj alarmy reagujące na wzrost ruchu o 50% lub więcej.

Przykładowy szkic Terraform tworzący alarm:

resource "aws_cloudwatch_metric_alarm" "nat_gateway_traffic_spike" {
  alarm_name          = "nat-gateway-traffic-spike"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name         = "BytesOutToDestination"
  namespace           = "AWS/NATGateway"
  period              = 3600
  statistic           = "Sum"
  threshold           = 50000000000
  alarm_description   = "Alarm przy nagłym wzroście ruchu przez NAT Gateway"
  actions_enabled     = true
  alarm_actions       = [aws_sns_topic.alerts.arn]

  dimensions = {
    NatGatewayId = "nat-xxxxxxxxxxxxxxxxx"
  }
}

Narzędzia zewnętrzne - Cloudability, Anodot do automatycznego wykrywania anomalii kosztów. Infracost do szacowania kosztów przed wdrożeniem (Terraform).

FAQ - Najczęstsze pytania o AWS NAT Gateway i koszty

P: Czy NAT Gateway jest bezpłatny? O: Nie. NAT Gateway kosztuje ~0,045 USD/godzinę + ~0,045 USD/GB przetworzonych danych. Nie ma bezpłatnej warstwy.

P: Czy można korzystać z NAT Gateway bez ponoszenia kosztów? O: Częściowo. Używaj VPC Endpoint zamiast NAT Gateway do dostępu do usług AWS (S3, DynamoDB, Secrets Manager). Takie połączenia są bezpłatne.

P: Ile NAT Gateway powinienem mieć? O: To zależy od wymagań dotyczących dostępności. W środowiskach produkcyjnych zaleca się jeden NAT Gateway w każdej strefie dostępności (minimum 2). W środowiskach deweloperskich i testowych wystarczy jeden.

P: Czy ruch między EC2 a S3 jest rozliczany przez NAT Gateway? O: Nie, jeśli korzystasz z VPC Endpoint dla S3. Jeśli ruch jest kierowany przez NAT Gateway, opłata za każdy GB zostanie naliczona.

P: Jaka jest różnica między NAT Gateway a NAT Instance? O: NAT Gateway to usługa zarządzana, droższa, ale niezawodna. NAT Instance to instancja EC2 zarządzana samodzielnie, tańsza przy niskim ruchu, ale wymagająca więcej pracy operacyjnej.

P: Czy VPC Endpoint dla S3 jest naprawdę bezpłatny? O: Tak. Gateway Endpoint dla S3 i DynamoDB nie wiąże się z żadnymi opłatami. Interface Endpoint kosztuje ~0,01 USD/godzinę.

P: Jak zmniejszyć koszty NAT Gateway o 50%? O: Zastosuj trzy strategie: 1) używaj VPC Endpoint dla S3 i DynamoDB, 2) ogranicz liczbę NAT Gateway, jeśli wysoka dostępność nie jest priorytetem, 3) włącz cache pobieranych danych i minimalizuj ruch wychodzący.

Podsumowanie

AWS NAT Gateway to niezbędny element bezpiecznych architektur, który jednak generuje istotne koszty. Kluczowe wnioski:

1. Dwuwymiarowe rozliczanie: opłata za dostępność (godzina) + ruch (GB)
2. Koszty rosną szybko: 500 GB/miesiąc + 2 NAT Gateway = ~87 USD/miesiąc
3. VPC Endpoint to przełom: eliminuje znaczną część ruchu kierowanego do S3 i DynamoDB
4. Aktywne monitorowanie: korzystaj z Cost Explorer i metryk CloudWatch
5. Optymalizuj architekturę: włącz cache danych, ogranicz ruch, konsoliduj NAT Gateway

Wdrożenie tych strategii pozwala zmniejszyć koszty NAT Gateway o 30-50% bez utraty funkcjonalności. W skali roku przekłada się to na wymierne oszczędności w budżecie infrastruktury AWS.

Chcesz omówić optymalizację kosztów AWS dla swojego środowiska? Zespół Devopsity specjalizuje się w FinOps i optymalizacji infrastruktury. Sprawdź naszą usługę FinOps (Optymalizacja kosztów).