AWS NAT Gateway разходи: VPC Endpoints…

Актуализирано: 15 юли 2026 г.

AWS NAT Gateway разходите се състоят от два компонента: фиксирана почасова такса от $0.045 на час на availability zone плюс такса за обработка на данни от $0.045 за всеки GB, преминаващ през gateway-а. За средно голямо production натоварване, което трансферира 10 TB изходящ трафик месечно през три availability zones, това означава около $560 месечно, преди дори да добавите egress таксите към интернет. През последните две години съм видял седем компании да намалят този разход с 60-90%, като преместят S3, DynamoDB и API трафика през VPC Endpoints и премахнат ненужните cross-AZ преходи.

NAT Gateway струва $0.045/час на AZ плюс $0.045/GB обработени данни, така че 100 GB/ден при 3 AZs излиза около $500/месец само за processing.
Gateway VPC Endpoints за S3 и DynamoDB са напълно безплатни и премахват целия трафик към тези услуги от NAT Gateway.
Interface VPC Endpoints (PrivateLink) струват $0.01/час на AZ плюс $0.01/GB, което е 4.5 пъти по-евтино от NAT Gateway за трафик към AWS API-та.
Cross-AZ NAT трафикът генерира допълнителни $0.01/GB такси в двете посоки, така че консолидирането на workloads в един AZ спестява до 30%.
VPC Flow Logs с Athena заявки идентифицират точно кои destination IP-та консумират най-много NAT трафик за под $5.
Практически case study: миграция на Kubernetes cluster от три NAT Gateways към Gateway плюс Interface endpoints намали месечната сметка от $2,340 на $180.

Колко струва AWS NAT Gateway през 2026?

AWS NAT Gateway има двукомпонентен ценови модел, който в момента остава непроменен от 2017 г. Първият компонент е почасова такса от $0.045 за всеки активен NAT Gateway (цена за us-east-1; в eu-central-1 е $0.052, а в sa-east-1 стига до $0.093). Тъй като NAT Gateway работи в конкретна availability zone, повечето production архитектури изискват три отделни gateway-а за high availability, а това вече прави $99 месечно, преди какъвто и да е трафик да е преминал.

Вторият компонент, и този, който ме изненадва при почти всяка одиторска работа, е такса за обработка на данни от $0.045 за всеки GB, преминаващ през NAT Gateway. И тук идва капанът: тази такса се прилага в двете посоки. Ако вашият Kubernetes pod изтегли 1 GB Docker image от Docker Hub и после изпрати 100 MB метрики към Datadog, това са 1.1 GB обработка. Плюс отделна такса за интернет egress от $0.09/GB за изходящия трафик. Според официалната AWS VPC ценова страница, тази структура важи за всички commercial региони.

Честно казано, това често хваща екипите неподготвени. Реален пример от работата ми през 2026: media streaming startup с 45 EC2 инстанции в три AZ-а генерираше 8.2 TB месечно, преминавайки през NAT Gateway (най-вече ECR image pulls, CloudWatch logs и трафик към SaaS API-та). Месечната им NAT сметка беше $567, от които $468 бяха само processing такси. Постигнахме намаление до $73 месечно чрез мигриране към VPC Endpoints, тоест 87% редукция.

Скритите такси, които не виждате в Cost Explorer

Проблемът с NAT Gateway разходите не е че са скрити. Те се появяват в billing report като USE1-NatGateway-Bytes и USE1-NatGateway-Hours. Проблемът е че AWS Cost Explorer ги показва като агрегирана сума без source или destination breakdown. Виждате че NAT Gateway ви струва $2,340, но не знаете дали е защото един ETL job тегли данни от S3 през NAT (класическа грешка), или защото имате misconfigured EKS node group без правилни VPC endpoints.

Три категории скрити такси, които редовно намирам:

ECR image pulls през NAT: Всеки път когато EKS node изтегли контейнерен image от Amazon ECR без Interface Endpoint, това преминава през NAT Gateway. При node group от 20 инстанции с 500 MB images и autoscaling събития 5 пъти дневно, това са 50 GB/ден = $67/месец само за image pulls.
CloudWatch Logs агенти: Ако вашият CloudWatch agent няма VPC endpoint за logs сервиза, всички log данни преминават през NAT. За приложения, генериращи 200 GB логове месечно, това добавя $9 processing плюс около $18 cross-AZ такси.
DNS resolution към public endpoints: Когато Route 53 Resolver прави outbound DNS query към external DNS, то преминава през NAT. Малко на брой, но при hundreds of thousands на ден се натрупва.

Как да идентифицирам източниците на NAT трафик

Първата стъпка преди каквато и да е оптимизация е точно измерване. AWS не предоставя out-of-the-box breakdown на NAT Gateway трафика по destination, така че трябва да го извлечете от VPC Flow Logs. Ето подходът, който използвам с всеки клиент.

Стъпка 1: Активирайте VPC Flow Logs за подмрежата на NAT Gateway. Не за целия VPC. Само за подмрежите, в които са разположени вашите workloads (private subnets, които маршрутизират през NAT). Изпратете ги в S3 в Parquet формат за оптимална Athena производителност.

aws ec2 create-flow-logs \
  --resource-type Subnet \
  --resource-ids subnet-0a1b2c3d4e5f6g7h8 subnet-0i9j8k7l6m5n4o3p2 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::my-flow-logs-bucket/nat-analysis/ \
  --log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}' \
  --destination-options FileFormat=parquet,HiveCompatiblePartitions=true,PerHourPartition=true

Стъпка 2: Създайте Athena таблица и заявете top destinations. След 24 часа събиране на данни, следната Athena заявка ви показва точно кои external IP адреси консумират най-много NAT bandwidth:

SELECT
  dstaddr,
  SUM(bytes) / 1024.0 / 1024.0 / 1024.0 AS total_gb,
  ROUND(SUM(bytes) * 0.045 / 1024.0 / 1024.0 / 1024.0, 2) AS estimated_nat_cost_usd,
  COUNT(*) AS flow_count
FROM vpc_flow_logs
WHERE year = '2026' AND month = '07'
  AND action = 'ACCEPT'
  AND dstaddr NOT LIKE '10.%'
  AND dstaddr NOT LIKE '172.%'
  AND dstaddr NOT LIKE '192.168.%'
GROUP BY dstaddr
ORDER BY total_gb DESC
LIMIT 25;

Стъпка 3: Reverse DNS lookup на топ дестинациите. Обикновено топ 10 IP-та покриват 80-90% от NAT трафика. Използвайте dig -x или whois, за да ги идентифицирате. Обичайно ще откриете S3 endpoints, ECR, Docker Hub CDN, CloudWatch API и third-party SaaS API-та (Datadog, Snowflake, Stripe). Подробно описание на формата на записите е достъпно в официалната документация за VPC Flow Logs.

VPC Endpoints като алтернатива на NAT Gateway

VPC Endpoints позволяват на ресурсите в private subnet да достъпват AWS услуги без да излизат в интернет, което означава без да преминават през NAT Gateway. Има две категории: Gateway Endpoints (безплатни, само за S3 и DynamoDB) и Interface Endpoints, известни също като PrivateLink ($0.01/час на AZ плюс $0.01/GB). За повечето production workloads с над 200 GB месечен трафик към AWS услуги, VPC Endpoints се изплащат за под седмица.

Според официалната AWS PrivateLink документация, следните услуги поддържат Gateway Endpoints:

Amazon S3, чрез Gateway Endpoint (безплатен) или Interface Endpoint (за cross-region достъп)
Amazon DynamoDB, само Gateway Endpoint

За всички останали AWS услуги, включително тези с най-голям трафик като ECR, CloudWatch Logs, Secrets Manager, KMS и STS, трябва да използвате Interface Endpoints. Обичайният production setup включва 8-12 Interface Endpoints, което струва около $32-48 месечно за фиксираната такса. Но dataprocessing таксите остават 4.5x по-ниски от NAT Gateway ($0.01/GB vs $0.045/GB), плюс премахвате изцяло интернет egress ($0.09/GB) за трафик към AWS услуги.

Gateway Endpoints срещу Interface Endpoints

Изборът между Gateway и Interface endpoints всъщност не е избор. Използвайте и двата, всеки за подходящата услуга. Gateway Endpoints работят чрез route table entries (не консумират ENIs) и са абсолютно безплатни. Interface Endpoints създават Elastic Network Interface (ENI) с частен IP във всеки AZ, което позволява по-фина IAM конфигурация чрез endpoint policies.

Характеристика	Gateway Endpoint	Interface Endpoint (PrivateLink)	NAT Gateway
Почасова цена	$0	$0.01/AZ	$0.045/AZ
Data processing	$0	$0.01/GB	$0.045/GB
Поддържани услуги	Само S3, DynamoDB	100+ AWS услуги	Всички интернет ресурси
Достъп от on-premises	Не	Да, чрез Direct Connect	Не (само egress)
Достъп cross-VPC	Не	Да, чрез VPC Peering	Не
DNS resolution	Manual (S3 endpoint prefix list)	Automatic (private DNS)	Standard
Cross-region	Не	Не (използвайте Multi-Region)	Да, но скъпо

За S3 конкретно има един footgun, който често пропускат: Gateway Endpoint работи само за трафик в същия регион. Ако вашата инстанция в eu-west-1 достъпва S3 bucket в us-east-1, дори с Gateway Endpoint, трафикът излиза през NAT Gateway. Ако имате cross-region S3 workflows, разгледайте оптимизация на data transfer разходите или S3 Multi-Region Access Points с regional replicas.

PrivateLink в практиката: миграция стъпка по стъпка

Миграцията към VPC Endpoints трябва да върви поетапно, за да избегнете production incident. Ето последователността, която препоръчвам за EKS/ECS натоварвания.

Стъпка 1: S3 Gateway Endpoint (безплатен, минимален риск)

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.eu-central-1.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,
  ]
  policy = jsonencode({
    Statement = [{
      Effect    = "Allow"
      Principal = "*"
      Action    = ["s3:*"]
      Resource  = ["*"]
    }]
  })
  tags = {
    Name    = "s3-gateway-endpoint"
    CostOpt = "nat-reduction"
  }
}

След terraform apply, целият S3 трафик от private subnets се маршрутизира директно през endpoint-а. Проверете с aws ec2 describe-route-tables че prefix list pl-6da54004 (S3 за региона) е добавен автоматично.

Стъпка 2: ECR Interface Endpoints (най-висока стойност)

ECR pull трафикът обикновено е top-3 източник на NAT разходи в контейнеризирани среди. ECR изисква ДВА endpoint-а: ecr.api за authentication и ecr.dkr за image layer downloads. Освен това ECR съхранява layer-ите в S3, така че S3 Gateway Endpoint от стъпка 1 е задължителна предпоставка:

locals {
  ecr_services = ["ecr.api", "ecr.dkr"]
}

resource "aws_vpc_endpoint" "ecr" {
  for_each          = toset(local.ecr_services)
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.eu-central-1.${each.value}"
  vpc_endpoint_type = "Interface"
  subnet_ids        = [
    aws_subnet.private_a.id,
    aws_subnet.private_b.id,
    aws_subnet.private_c.id,
  ]
  security_group_ids  = [aws_security_group.vpc_endpoint.id]
  private_dns_enabled = true
  tags = {
    Name = "${each.value}-interface-endpoint"
  }
}

Стъпка 3: Останалите AWS услуги

След ECR добавете endpoints за услугите, които топ дестинациите от Athena заявката са показали. Обичайният production setup включва: logs, monitoring, secretsmanager, kms, sts, ssm, ssmmessages, ec2messages. Последните три са критични за Systems Manager Session Manager. Без тях workflows за bastion-less SSH ще прекратят.

Cross-AZ такси и архитектурни решения

Второто ниво оптимизация след VPC Endpoints е адресиране на cross-AZ такси. NAT Gateway работи в конкретен availability zone, така че ако EC2 инстанция в us-east-1a изпраща трафик през NAT Gateway в us-east-1b, плащате допълнителни $0.01/GB cross-AZ такси в двете посоки, което означава общо $0.02/GB отгоре на NAT processing.

Решението е един NAT Gateway на AZ и правилно маршрутизиране на подмрежите:

resource "aws_nat_gateway" "per_az" {
  for_each      = { for az in local.availability_zones : az => az }
  allocation_id = aws_eip.nat[each.key].id
  subnet_id     = aws_subnet.public[each.key].id
  tags = {
    Name = "nat-gw-${each.key}"
  }
}

resource "aws_route" "private_nat" {
  for_each               = { for az in local.availability_zones : az => az }
  route_table_id         = aws_route_table.private[each.key].id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.per_az[each.key].id
}

Този pattern сам по себе си вече е оптимизация. В миналото ми се е случвало да наследя архитектури с един NAT Gateway в един AZ, обслужващ workloads в три AZ-а. Икономията от единичен NAT Gateway ($33/месец) не си струва cross-AZ таксите (обикновено $50-200/месец за трафик от 5-20 TB).

Кога NAT Instance е по-евтин от NAT Gateway

NAT Instance е "старият" начин преди AWS да пусне managed NAT Gateway през 2015 г. Все още се поддържа и в определени сценарии е значително по-евтин. Ключовият фактор е обемът трафик: NAT Instance не таксува processing данни, само стандартните EC2 такси плюс интернет egress.

Break-even точката за t4g.small (около $12/месец в us-east-1 с 3-year Savings Plan) е приблизително 260 GB/месец. Под този threshold, NAT Instance е по-евтин; над него, NAT Gateway започва да печели поради по-високата производителност и HA характеристиките. За dev/staging среди с над 10 TB/месец трафик, съм имплементирал NAT Instances с fck-nat (Community AMI, поддържа auto-recovery) с 80-90% cost reduction.

Case study: намаляване на разходите с $2,160/месец

През февруари 2026 г. работих с Series C fintech, работеща EKS cluster с 45 nodes в eu-central-1. Месечните им NAT Gateway разходи бяха $2,340, тоест трето най-голямо линейно перо след EC2 и RDS. Анализът показа следната breakdown на трафика:

ECR image pulls: 3.8 TB/месец = $171 processing плюс $180 cross-AZ
CloudWatch Logs (без endpoint): 1.2 TB/месец = $54 плюс $85 cross-AZ
S3 backup restore workflows: 2.1 TB/месец = $95 processing (в допълнение към $189 S3 egress, което трябваше да е $0)
External SaaS API-та (Datadog, Snowflake): 800 GB = $36 плюс $72 egress
Останало (misc updates, DNS, container runtime): 400 GB = $18

Планът за миграция беше 4-седмичен sprint:

Седмица 1: S3 Gateway Endpoint плюс DynamoDB Gateway Endpoint. Незабавно спестяване: $284/месец.
Седмица 2: ECR Interface Endpoints (api плюс dkr) плюс CloudWatch Logs Interface Endpoint. Спестяване: $490/месец допълнително.
Седмица 3: STS, KMS, Secrets Manager, SSM endpoints. Спестяване: $95/месец.
Седмица 4: Консолидиране на Kafka consumers в един AZ (беше архитектурно нужно), премахване на кръстосан NAT трафик. Спестяване: $180/месец.

Крайният месечен разход за NAT Gateway плюс VPC Endpoints беше $180 (от които $48 за Interface Endpoint фиксирани такси и $132 за остатъчен NAT трафик). Обща икономия: $2,160/месец или $25,920/годишно. Работата отне общо 32 инженерни часа плюс 8 часа за pre-production testing.

За допълнителна оптимизация на клъстъра, разгледайте нашето ръководство за Kubernetes cost optimization с Karpenter, KEDA и VPA, което обяснява как right-sizing на node groups може да намали както compute, така и NAT трафик от image pulls (по-малко nodes = по-малко duplicate pulls). Ако тепърва започвате с одит на облачни разходи, полезно е и пълното ръководство за right-sizing на облачни ресурси.

Често задавани въпроси

Колко струва AWS NAT Gateway на месец?

За минимална HA конфигурация с три NAT Gateways (по един на AZ), фиксираната цена е около $99/месец в us-east-1 ($0.045 × 24 × 30 × 3). Към това добавете $0.045/GB за processing, така че типично 10 TB/месец натоварване струва около $560/месец общо. В по-скъпи региони като eu-central-1 фиксираната такса нараства до $115/месец.

Безплатни ли са Gateway VPC Endpoints?

Да, Gateway Endpoints за S3 и DynamoDB са напълно безплатни, тоест нито фиксирана такса, нито data processing. Трябва да платите само стандартните S3/DynamoDB такси за самите заявки. Това ги прави no-brainer за всеки VPC, който комуникира с S3.

Каква е разликата между NAT Gateway и VPC Endpoint?

NAT Gateway позволява на private ресурси да достъпват всеки интернет endpoint (AWS и external), но е скъп. VPC Endpoint позволява директен достъп до конкретна AWS услуга без излизане в интернет, тоест по-евтин и по-сигурен, но само за поддържани AWS услуги. В production трябва да имате и двете: VPC Endpoints за AWS трафик, NAT Gateway за external API-та.

Нужен ли ми е NAT Gateway ако имам VPC Endpoints?

В повечето случаи да, освен ако вашето натоварване общува само с AWS услуги. NAT Gateway е нужен за достъп до Docker Hub, third-party SaaS API-та, external DNS, npm/pip package indices и всеки друг non-AWS endpoint. Оптималната архитектура използва VPC Endpoints за AWS трафик и NAT Gateway само за external трафик.

Как да намаля NAT Gateway processing разходите?

Три основни техники в ред на приоритет: (1) добавете S3 и DynamoDB Gateway Endpoints, безплатно и премахва обикновено 40-60% от трафика; (2) добавете Interface Endpoints за ECR, CloudWatch Logs, Secrets Manager и STS, което дава още 25-35% намаление; (3) консолидирайте workloads в един AZ или използвайте един NAT Gateway на AZ, за да елиминирате cross-AZ такси. Комбинирано, тези три техники редовно постигат 80-90% намаление.

Мога ли да използвам NAT Instance вместо NAT Gateway за икономия?

Само за dev/staging среди с високо dataprocessing (над 10 TB/месец). NAT Instance не таксува processing данни, така че при малък footprint (t4g.nano плюс Community fck-nat AMI) можете да спестите 80-90% спрямо NAT Gateway. За production категорично препоръчвам NAT Gateway заради managed failover и по-високия throughput.