AWS NAT Gateway: redukcja kosztów 2026

Q: Czy AWS NAT Gateway można zastąpić NAT Instance?

Dla środowisk dev/test tak, projekty jak fck-nat na t4g.nano obsługują ~5 Gbps za ~$3/miesiąc. Dla produkcji NAT Instance ma poważne wady: brak automatycznego failover multi-AZ, ręczne zarządzanie skalowaniem i patchowaniem, limit przepustowości karty sieciowej. Koszt jednej awarii zwykle przekracza roczne oszczędności.

Q: Jak sprawdzić, co generuje ruch przez mój NAT Gateway?

Włącz VPC Flow Logs w formacie Parquet do S3 z polami pkt-dst-aws-service oraz traffic-path , a następnie odpytaj je w Athena filtrując traffic_path = 2 (ruch przez NAT) i grupując po pkt_dst_aws_service . Zapytanie zwróci top konsumentów wraz z realnym kosztem processing per usługa. Alternatywa: włącz AWS Network Access Analyzer i przejrzyj raporty CloudWatch Contributor Insights.

Zaktualizowano: 25 sierpnia 2026

Aby obniżyć koszty AWS NAT Gateway w 2026 roku, przekieruj ruch do usług AWS (S3, DynamoDB, ECR, Secrets Manager, CloudWatch Logs) przez Gateway Endpoints oraz Interface Endpoints (PrivateLink), ponieważ obchodzą one opłatę NAT Processing w wysokości $0.045/GB i redukują rachunek nawet o 60–90%. NAT Gateway w regionie eu-central-1 kosztuje $0.052/godz. za każde AZ plus $0.052/GB przetworzonego ruchu, czyli 10 TB miesięcznie to ponad $530 tylko za processing. Większość tego da się wyeliminować bez zmian w aplikacji.

NAT Gateway w EU/US kosztuje ~$0.045–$0.052/godz. plus tyle samo za GB. W architekturze multi-AZ to minimum ~$97 miesięcznie za samo utrzymanie, zanim popłynie choćby jeden pakiet.
Gateway Endpoints dla S3 i DynamoDB są całkowicie darmowe i eliminują opłatę NAT processing dla największych źródeł ruchu w typowym VPC.
Interface Endpoints (PrivateLink) kosztują $0.011/godz. za AZ oraz $0.011/GB, więc tanieją względem NAT już przy ~2 GB/dobę per ENI.
VPC Flow Logs w formacie Parquet plus Athena pozwalają zidentyfikować top 10 kierunków ruchu w ciągu godziny i wskazać kandydatów do endpointów.
Współdzielony NAT Gateway w koncie egress-vpc (Transit Gateway hub-and-spoke) redukuje liczbę bramek z N × AZ × VPC do 3 w całej organizacji.
Cross-AZ traffic do NAT w innej strefie kosztuje dodatkowe $0.01/GB w każdą stronę, więc trzymanie bramki per AZ zwykle się opłaca mimo wyższego kosztu bazowego.

Ile realnie kosztuje AWS NAT Gateway w 2026?

NAT Gateway ma dwa cenniki, które trzeba liczyć razem: opłatę za godzinę pracy bramki oraz opłatę za GB przetworzonych danych. W regionie eu-central-1 (Frankfurt) obie stawki wynoszą $0.052, w us-east-1 to $0.045, a w ap-southeast-2 $0.059. AWS rekomenduje jeden NAT Gateway per strefa dostępności, żeby ruch nie przechodził przez kosztowne cross-AZ transfery. W trzech AZ mamy więc od 3 × 730 × $0.045 = $98.55 miesięcznie tylko za sam fakt istnienia bramek.

Do tego dochodzi processing. Klient, którego obserwuję od dwóch lat, generuje ~14 TB egressu miesięcznie z klastra EKS w eu-central-1: ECR pull to ~3 TB, S3 read/write ~5 TB, DynamoDB ~1 TB, Secrets Manager plus CloudWatch Logs ~500 GB, ruch do internetu (webhooki, API partnerów) ~4.5 TB. Rachunek za NAT wyszedł: $100 + 14 000 × $0.052 = $828/miesiąc. Po wdrożeniu Gateway Endpoints (S3 + DynamoDB) oraz Interface Endpoints (ECR, Secrets Manager, CloudWatch Logs) zostało tylko ~4.5 TB webowego ruchu, czyli $100 + 4 500 × $0.052 = $334/miesiąc. Redukcja ~60% bez żadnej zmiany aplikacji.

Cross-AZ trap: jeśli EC2 w AZ-a wysyła ruch do NAT Gateway w AZ-b, zapłacisz dwie stawki. Najpierw $0.01/GB "cross-AZ out" i $0.01/GB "cross-AZ in" po stronie NAT, a potem $0.052/GB za sam processing. Dlatego jedna bramka per AZ to zwykle tańsza konfiguracja niż jedna wspólna dla całego VPC. Aktualny cennik znajdziesz w oficjalnym cenniku Amazon VPC, a szczegóły dotyczące opłat za data transfer w dokumentacji EC2 Data Transfer.

Jak zidentyfikować drogi ruch przez NAT Gateway

Zanim zaczniesz cokolwiek zmieniać, potrzebujesz danych. Włącz VPC Flow Logs w formacie Parquet do S3 (natywnie od 2022 roku, Parquet redukuje koszt Athena skanowania o ~80% względem tekstowego formatu), a potem odpytaj je za pomocą Amazon Athena. Poniższy szablon Terraform tworzy Flow Logs dla całego VPC i tabelę w Glue Data Catalog:

resource "aws_flow_log" "vpc" {
  vpc_id               = aws_vpc.main.id
  traffic_type         = "ALL"
  log_destination_type = "s3"
  log_destination      = "${aws_s3_bucket.flow_logs.arn}/AWSLogs/"
  destination_options {
    file_format                = "parquet"
    per_hour_partition         = true
    hive_compatible_partitions = true
  }
  # Pelny format z bytes, srcaddr, dstaddr, dstport, protocol,
  # a KLUCZOWO: pkt-src-aws-service i pkt-dst-aws-service (od 2021).
  log_format = join(" ", [
    "$${version}", "$${account-id}", "$${vpc-id}", "$${subnet-id}",
    "$${instance-id}", "$${interface-id}", "$${srcaddr}", "$${dstaddr}",
    "$${srcport}", "$${dstport}", "$${protocol}", "$${packets}",
    "$${bytes}", "$${action}", "$${log-status}",
    "$${pkt-src-aws-service}", "$${pkt-dst-aws-service}",
    "$${flow-direction}", "$${traffic-path}"
  ])
}

Kluczowe pola to pkt-dst-aws-service (S3, DYNAMODB, EC2, itd.) oraz traffic-path (wartość 2 to ruch przez NAT Gateway, 8 przez internet gateway). Poniższe zapytanie Athena zwraca 10 największych konsumentów NAT w ostatnim tygodniu:

SELECT
  COALESCE(pkt_dst_aws_service, 'external-internet') AS destination,
  ROUND(SUM(CAST(bytes AS DOUBLE)) / 1024 / 1024 / 1024, 2) AS gb_processed,
  ROUND(SUM(CAST(bytes AS DOUBLE)) / 1024 / 1024 / 1024 * 0.052, 2) AS nat_processing_usd
FROM vpc_flow_logs
WHERE traffic_path = 2               -- ruch przez NAT Gateway
  AND flow_direction = 'egress'
  AND year = '2026' AND month = '08'
GROUP BY 1
ORDER BY gb_processed DESC
LIMIT 10;

Wynik pokazuje, ile konkretnie płacisz za ruch do S3, DynamoDB, ECR itd. Każdy wiersz z pkt_dst_aws_service innym niż external-internet to potencjalny kandydat do endpointa. Szczerze mówiąc, w jednym audycie z lipca 2026 zobaczyłem 6.2 TB ruchu do ECR (obrazy kontenerów). Po włączeniu Interface Endpoint dla com.amazonaws.eu-central-1.ecr.dkr oraz ecr.api rachunek NAT spadł o $310/miesiąc, a endpoint kosztuje ~$50/miesiąc. Payback: 5 dni.

Gateway Endpoints: darmowa eliminacja S3 i DynamoDB

Amazon udostępnia dwa typy endpointów: Gateway Endpoints oraz Interface Endpoints. Gateway Endpoints są darmowe i istnieją tylko dla S3 i DynamoDB. Dodają wpis do route table subnetu i przekierowują ruch do tych usług lokalnie w regionie, bez wychodzenia przez NAT. Nie ma opłaty za processing, nie ma opłaty za GB. To pierwszy krok w każdej optymalizacji NAT. Jeśli tego nie masz, tracisz pieniądze bez uzasadnienia.

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = [
    aws_route_table.private_a.id,
    aws_route_table.private_b.id,
    aws_route_table.private_c.id,
  ]

  # Opcjonalna polityka: zawez do konkretnych bucketow, zeby
  # zablokowac data exfiltration przez cudze konto S3.
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = "*"
      Action    = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
      Resource  = [
        "arn:aws:s3:::my-app-data",
        "arn:aws:s3:::my-app-data/*"
      ]
    }]
  })
}

resource "aws_vpc_endpoint" "dynamodb" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.dynamodb"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = local.private_route_table_ids
}

Po zastosowaniu terraform apply ruch S3/DynamoDB natychmiast przełącza się na endpoint. Nie musisz zmieniać kodu ani zmiennych środowiskowych. SDK AWS wybiera trasę na podstawie routing table, więc s3.amazonaws.com jest rozwiązywany do adresu prywatnego w regionie. Weryfikacja przez traceroute z EC2 pokaże pierwszy hop bez NAT ENI. Dla dużych workloadów analitycznych (Athena, EMR, Glue), które piszą 20+ TB do S3, to bywa oszczędność rzędu $1000/miesiąc per VPC.

Interface Endpoints i AWS PrivateLink: kiedy się opłacają

Interface Endpoints (technologia AWS PrivateLink) tworzą ENI z prywatnym IP w twoim VPC dla ~180 usług AWS. Cennik: $0.011/godz. za ENI w każdej AZ plus $0.011/GB przetworzonych danych. Break-even względem NAT (który kosztuje $0.052/GB processing) wygląda tak:

Metryka	NAT Gateway	Interface Endpoint (PrivateLink)	Gateway Endpoint
Koszt godzinowy per AZ	$0.045–$0.052	$0.011	$0 (darmowy)
Koszt data processing	$0.045–$0.052/GB	$0.011/GB (pierwsze 1 PB)	$0 (darmowy)
Wspierane usługi	Dowolny egress do internetu i AWS	~180 usług AWS + własne VPC-do-VPC	Tylko S3 i DynamoDB
Break-even vs NAT	n/d	~7 GB/dobę per ENI	Zawsze wygrywa
Multi-AZ HA	Wymaga bramki per AZ	Automatyczne po wybraniu subnet w każdej AZ	Regionalny, brak konfiguracji AZ
Współdzielenie między VPC	Wymaga Transit Gateway	Natywne przez PrivateLink	Nie (per VPC)

W praktyce wdrażam Interface Endpointy dla trzech grup usług, które w typowym środowisku EKS/ECS generują największy ruch: ECR (ecr.dkr plus ecr.api), observability (logs, monitoring, xray) oraz runtime configuration (ssm, ssmmessages, secretsmanager, sts). Poniższy moduł Terraform zestawia je w bulk:

locals {
  interface_endpoints = [
    "ecr.api", "ecr.dkr", "logs", "monitoring", "xray",
    "ssm", "ssmmessages", "ec2messages", "secretsmanager", "sts",
    "kms", "sqs", "sns"
  ]
}

resource "aws_vpc_endpoint" "interface" {
  for_each          = toset(local.interface_endpoints)
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.${each.key}"
  vpc_endpoint_type = "Interface"
  subnet_ids        = local.private_subnet_ids   # jeden subnet per AZ
  security_group_ids = [aws_security_group.endpoints.id]
  private_dns_enabled = true                     # DNS override -> aplikacja bez zmian
}

# Security group musi zezwalac na 443 z CIDR VPC
resource "aws_security_group" "endpoints" {
  vpc_id = aws_vpc.main.id
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [aws_vpc.main.cidr_block]
  }
}

Włączenie private_dns_enabled = true jest kluczowe. Bez tego twoja aplikacja nadal będzie kierować zapytania na publiczne logs.eu-central-1.amazonaws.com, które rozwiązują się do publicznego IP i wracają przez NAT. Z włączonym DNS override, Route 53 Resolver zwraca prywatne IP endpointa. Weryfikacja: dig logs.eu-central-1.amazonaws.com z EC2 powinno zwrócić adres z zakresu VPC.

Centralny NAT Gateway w architekturze hub-and-spoke

W konfiguracji AWS Organizations z ~50 kontami i ~120 VPC widziałem organizacje, które utrzymywały 360 NAT Gateway (3 AZ × 120 VPC), płacąc tylko za samo istnienie $360 × 730h × $0.045 = $11 826/miesiąc. Wzorzec centralnego egressu przez Transit Gateway redukuje to do trzech bramek w jednym koncie egress-vpc, dzielonych przez wszystkie środowiska.

Kompromis: TGW dodaje $0.02/GB "data processing charge" na każdy przelot przez bramkę, więc pełny koszt egressu z aplikacji przez centralny NAT to $0.02 (TGW) + $0.052 (NAT processing) = $0.072/GB zamiast $0.052/GB w lokalnym setupie. Break-even leży ~1.5 TB/miesiąc: poniżej tego wolumenu centralny NAT wygrywa, a powyżej trzeba policzyć indywidualnie. W praktyce dla dev/test/sandbox VPC (setki, ale każdy z minimalnym ruchem) centralny NAT niemal zawsze wygrywa. Dla produkcyjnych VPC z 10+ TB miesięcznie zostaw lokalne bramki. Więcej wzorców opisuje whitepaper AWS Multi-VPC Networking.

Ten wzorzec dobrze łączy się z centralnym FinOps governance opisanym w naszym przewodniku po strategii tagowania kosztów AWS w multi-account, bo chargeback za NAT wymaga tagowania per-VPC endpoint attachments w Transit Gateway.

Kiedy warto rozważyć NAT Instance lub fck-nat

Dla środowisk dev/test poniżej 500 GB egressu miesięcznie NAT Gateway staje się drogi względem najtańszej alternatywy, czyli samodzielnej instancji EC2 z NAT-em. Open source'owy projekt fck-nat to Amazon Linux 2023 z prekonfigurowaną tabelą iptables i skryptem systemd, który utrzymuje maskaradę SNAT. Na t4g.nano ($3.06/miesiąc w eu-central-1) obsłuży ~5 Gbps ruchu, co wystarcza dla większości środowisk nieprodukcyjnych. Sam tak zrobiłem w trzech sandbox account i przez pół roku nie było ani jednego incydentu.

# fck-nat przez AWS CDK
new ec2.NatInstanceV2(this, "dev-nat", {
  instanceType: ec2.InstanceType.of(
    ec2.InstanceClass.T4G,
    ec2.InstanceSize.NANO
  ),
  machineImage: ec2.MachineImage.lookup({
    name: "fck-nat-al2023-*-arm64-ebs",
    owners: ["568608671756"],
  }),
});

Wady vs NAT Gateway: brak automatycznego failover w AZ (trzeba dopisać ASG albo Auto Recovery), brak wsparcia AWS (troubleshooting na własną rękę), limity przepustowości karty sieciowej. Dla produkcji zdecydowanie zostań przy managed NAT Gateway, bo koszt jednej awarii przekracza roczne oszczędności. Dla sandbox account, gdzie i tak ruch wygasa w piątek wieczór, fck-nat obcina rachunek z ~$32 do ~$3 miesięcznie na VPC.

Monitoring, alerty i FinOps governance dla NAT

NAT Gateway ma cztery kluczowe metryki w CloudWatch, których większość zespołów nie monitoruje: BytesOutToDestination (ruch do internetu), BytesInFromDestination, ErrorPortAllocation (port exhaustion, twardy limit 55 000 połączeń per NAT per unikalny dst) oraz IdleTimeoutCount. Poniższy alert wysyła powiadomienie, gdy dzienny wolumen NAT skoczy o 3× względem 30-dniowej średniej. To typowy objaw wycieku (log shipping bez endpointu, obrazy Dockera bez ECR endpoint, backup job źle skonfigurowany):

resource "aws_cloudwatch_metric_alarm" "nat_spike" {
  alarm_name          = "nat-gateway-egress-spike"
  metric_name         = "BytesOutToDestination"
  namespace           = "AWS/NATGateway"
  statistic           = "Sum"
  period              = 86400            # 1 doba
  evaluation_periods  = 1
  threshold           = 500 * 1024 * 1024 * 1024   # 500 GB/dobe
  comparison_operator = "GreaterThanThreshold"
  dimensions = { NatGatewayId = aws_nat_gateway.a.id }
  alarm_actions = [aws_sns_topic.finops_alerts.arn]
}

W ramach FinOps governance rekomenduję trzy zasady guardrail w Service Control Policies AWS Organizations: (1) blokada tworzenia NAT Gateway w kontach dev bez taga CostCenter; (2) wymóg Gateway Endpoint dla S3 i DynamoDB w każdym nowym VPC (weryfikacja przez AWS Config rule vpc-endpoint-enabled); (3) alert w Cost Anomaly Detection z progiem $50 na usługę Amazon Virtual Private Cloud. Dobrze uzupełnia to nasz materiał o Savings Plans vs Reserved Instances, bo NAT nie ma commit-based zniżek, więc jedyną dźwignią jest architektura.

Dla workloadów kontenerowych warto połączyć optymalizację NAT z right-sizingiem klastrów Kubernetes, bo pull obrazów przez ECR Interface Endpoint plus mniejsza liczba nodes daje efekt złożony. W klastrze EKS z 40 nodes replaceable na 24 po Compute Optimizer recommendations widziałem redukcję ruchu ECR z 6 TB do 3.5 TB, co dodatkowo skróciło payback endpointa.

Najczęściej zadawane pytania

Czy VPC Endpoints redukują koszty NAT Gateway?

Tak. Gateway Endpoints dla S3 i DynamoDB są darmowe i całkowicie eliminują opłatę NAT processing ($0.045–$0.052/GB) dla ruchu do tych usług. Interface Endpoints (PrivateLink) redukują koszt z $0.052/GB do $0.011/GB plus $0.011/godz. za ENI, co się opłaca przy ruchu powyżej ~7 GB/dobę per endpoint.

Ile kosztuje AWS NAT Gateway miesięcznie?

Sam NAT Gateway w eu-central-1 kosztuje $0.052/godz., czyli ~$38/miesiąc, ale AWS rekomenduje jeden per AZ. Realny koszt bazowy to ~$114/miesiąc dla trzech AZ, zanim policzysz $0.052/GB za processing. Typowe środowisko produkcyjne z 5–10 TB ruchu miesięcznie płaci $400–$700/miesiąc bez optymalizacji.

Czy AWS NAT Gateway można zastąpić NAT Instance?

Dla środowisk dev/test tak, projekty jak fck-nat na t4g.nano obsługują ~5 Gbps za ~$3/miesiąc. Dla produkcji NAT Instance ma poważne wady: brak automatycznego failover multi-AZ, ręczne zarządzanie skalowaniem i patchowaniem, limit przepustowości karty sieciowej. Koszt jednej awarii zwykle przekracza roczne oszczędności.

Jak sprawdzić, co generuje ruch przez mój NAT Gateway?

Włącz VPC Flow Logs w formacie Parquet do S3 z polami pkt-dst-aws-service oraz traffic-path, a następnie odpytaj je w Athena filtrując traffic_path = 2 (ruch przez NAT) i grupując po pkt_dst_aws_service. Zapytanie zwróci top konsumentów wraz z realnym kosztem processing per usługa. Alternatywa: włącz AWS Network Access Analyzer i przejrzyj raporty CloudWatch Contributor Insights.

Czy warto centralizować NAT Gateway w Transit Gateway?

Dla organizacji z wieloma VPC (zwłaszcza dev/sandbox z niskim wolumenem) tak. Konfiguracja hub-and-spoke z jednym kontem egress-vpc redukuje liczbę bramek z N × 3 AZ do 3. Kompromis: Transit Gateway dolicza $0.02/GB processing, więc dla VPC z ponad 1.5 TB egressu miesięcznie lokalna bramka wychodzi taniej. Policz break-even per VPC przed decyzją.