NAT Gateway AWS: קיצוץ 60-90% (מדריך 20…

עודכן: 10 באוגוסט 2026

אופטימיזציית עלויות NAT Gateway ב-AWS מבוססת על שלושה מהלכים ברורים: החלפת תעבורה ל-S3 ו-DynamoDB ב-Gateway Endpoints בחינם, איחוד NAT Gateways בין Availability Zones כדי לחסל תעבורת cross-AZ, וניתוב שירותי AWS מנוהלים דרך VPC Interface Endpoints (PrivateLink) במקום דרך ה-NAT. במרבית ה-VPCs שבדקתי ב-2026, שילוב שלושת המהלכים חתך 60% עד 90% מהחשבון החודשי של NAT Gateway תוך פחות משבועיים עבודה, בלי לגעת בקוד האפליקציה. במדריך הזה אראה בדיוק איך למפות היכן הכסף בורח, ואילו תיקונים מחזירים אותו.

NAT Gateway גובה 0.045$ לשעה לכל Gateway ועוד 0.045$ לכל GB תעבורה מעובדת, כלומר 32.4$ לחודש רק על ה-idle לפני שהעברתם ביט אחד.
Gateway Endpoints ל-S3 ול-DynamoDB חינמיים לחלוטין וחוסכים בממוצע 40% עד 70% מהתעבורה דרך NAT ב-workloads שנוגעים ב-S3.
NAT Gateway אחד לכל AZ מונע חיוב cross-AZ של 0.01$/GB לכל כיוון. זו טעות ארכיטקטונית נפוצה שגורמת להכפלה של החשבון.
Interface Endpoints (PrivateLink) לשירותים כמו ECR, CloudWatch Logs, SSM ו-Secrets Manager מבטלים תעבורה שיוצאת דרך NAT אל endpoints ציבוריים של AWS.
אלטרנטיבות כמו fck-nat על EC2 t4g.nano מציעות NAT ב-3$ עד 5$ לחודש עבור סביבות dev/test, עם ביצועים סבירים לרוב ה-workloads.
VPC Flow Logs עם Athena חושפים אילו pods, containers או Lambda functions צורכים 80% מה-NAT. עקרון פארטו קלאסי.

איך NAT Gateway מחויב ב-AWS ב-2026

לפני שאתם קוצצים עלויות, כדאי להבין בדיוק על מה AWS מחייב. חיוב NAT Gateway ב-us-east-1 מורכב משלושה רכיבים: 0.045$ לשעה לכל NAT Gateway פעיל (בערך 32.85$ לחודש לכל gateway), 0.045$ לכל GB תעבורה מעובדת (נכנסת ויוצאת יחד), ובנוסף, וזה החלק ששוכחים, תעבורת יציאה רגילה מ-AWS לאינטרנט במחיר של 0.05$ עד 0.09$ לכל GB, מעל 100 GB חינם בחודש. במרבית האזורים המחירים דומים או גבוהים ב-10% עד 20%. סביבה מרובת AZs עם 3 NAT Gateways מייצרת 98.55$ בסיס חודשי גם כשה-VPC ישן.

יש כאן טעות קריטית שאני נתקל בה שוב ושוב: מחיר "התעבורה המעובדת" חל על שני הכיוונים גם יחד. אם pod ב-EKS מוריד תמונת Docker בגודל 1 GB מ-ECR ציבורי דרך NAT, אתם משלמים 0.045$ על 1 GB יורד ועוד 0.045$ על אותם 1 GB בכיוון החזרה, כלומר 0.09$ למשיכה אחת. תכפילו את זה במאות pods שמתאתחלים כל יום ותקבלו חשבון קפקאי. פירוט מלא של המבנה הזה מופיע בתיעוד הרשמי של AWS ל-NAT Gateway.

איך למצוא את המקורות שאוכלים את ה-NAT Gateway

אי אפשר לקצץ מה שלא רואים. השלב הראשון הוא הפעלת VPC Flow Logs על ה-ENI של ה-NAT Gateway וניתוח שלהם ב-Athena. הפעילו Flow Logs עם פורמט מותאם שכולל את השדות הבאים: srcaddr, dstaddr, srcport, dstport, protocol, bytes, action, pkt-dstaddr, pkt-srcaddr. השדות pkt-srcaddr ו-pkt-dstaddr קריטיים: הם מגלים איזה pod או container שלח את התעבורה, לא רק ה-NAT עצמו.

הנה שאילתת Athena שאני מריץ בכל חקירה כזאת. היא מזהה את 20 היעדים החיצוניים היקרים ביותר ב-NAT שלכם ב-30 הימים האחרונים:

-- Top 20 external destinations by NAT-egress bytes (last 30 days)
SELECT
  dstaddr,
  ROUND(SUM(bytes) / 1024.0 / 1024.0 / 1024.0, 2) AS gb_out,
  ROUND(SUM(bytes) / 1024.0 / 1024.0 / 1024.0 * 0.045, 2) AS est_usd,
  COUNT(DISTINCT pkt_srcaddr) AS distinct_sources
FROM vpc_flow_logs
WHERE
  interface_id = 'eni-0abc123456789'  -- ENI של ה-NAT Gateway
  AND action = 'ACCEPT'
  AND from_iso8601_timestamp(start_ts) >= current_date - interval '30' day
GROUP BY dstaddr
ORDER BY gb_out DESC
LIMIT 20;

בשלב הבא, בצעו reverse-DNS לכתובות שהתגלו. תופתעו כמה מהן שייכות ל-*.amazonaws.com, כלומר, אתם משלמים ל-AWS על תעבורה שיוצאת מ-AWS חזרה ל-AWS דרך האינטרנט הציבורי. זה בדיוק הכסף ש-VPC Endpoints נועדו להציל. עקרונות דומים של איתור עלויות זליגה מתוארים במדריך שלנו על עלויות Egress בענן והשוואת AWS מול Azure מול GCP.

ניטור ברמת ה-pod ב-EKS

ב-Kubernetes, חבילות כמו kubectl-cost או Kubecost חושפות תעבורת NAT לפי namespace ו-pod, בהתבסס על Flow Logs מועשרים ב-metadata של ה-CNI. הרצת kubectl cost namespace --show-egress מציגה את הנמספייסים היקרים ביותר בחודש האחרון. הסתכלו במיוחד על מערכות observability (Datadog, New Relic, Splunk agents) ו-job containers שמושכים artifacts גדולים. אלה החשודים הרגילים לצריכת NAT מוגזמת.

VPC Endpoints: החיסכון המיידי הגדול ביותר

יש שני סוגים של VPC Endpoints, והבלבול ביניהם עולה כסף. Gateway Endpoints זמינים אך ורק ל-S3 ול-DynamoDB, והם בחינם לחלוטין: ללא חיוב שעתי, ללא חיוב תעבורה. Interface Endpoints (מבוססי PrivateLink) עובדים עם כל שירות AWS אחר, אבל עולים 0.01$ לשעה לכל endpoint ולכל AZ, בתוספת 0.01$ לכל GB תעבורה מעובדת. גם כך, זה עדיין הרבה יותר זול מ-NAT Gateway (0.045$/GB), פי 4.5 בערך.

הנה טבלת ההשוואה שאני משתמש בה בהחלטות יומיומיות:

מאפיין	NAT Gateway	Gateway Endpoint (S3/DDB)	Interface Endpoint (PrivateLink)
עלות שעתית לכל AZ	0.045$	0$	0.01$
עלות לכל GB מעובד	0.045$	0$	0.01$
שירותים נתמכים	הכל	S3, DynamoDB בלבד	>150 שירותי AWS
עקיפת האינטרנט הציבורי	לא	כן	כן (PrivateLink)
נתמך cross-region	לא	לא	לא
יעד עלות/חודש (100 GB)	~37$	0$	~11.30$

איך יוצרים Gateway Endpoint ל-S3 עם Terraform

זה קוד ה-Terraform שאני מפעיל בכל VPC חדש. הוא מוסיף Gateway Endpoint ל-S3 ומחבר אותו לכל טבלאות הניתוב הפרטיות:

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[*].id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = "*"
      Action    = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
      Resource  = ["*"]
    }]
  })

  tags = {
    Name    = "vpce-s3-${var.env}"
    Purpose = "Eliminate NAT egress to S3"
  }
}

אחרי apply, בדקו שהתעבורה עוברת דרך ה-endpoint על ידי הרצת aws s3 cp מ-EC2 בסאבנט הפרטי ובחינת CloudWatch Metric BytesOutToDestination של ה-NAT. הוא צריך לרדת חדות, מיידית. ההגדרות המפורטות של Gateway Endpoints מתועדות במדריך ה-VPC Endpoints הרשמי של AWS.

אילו Interface Endpoints שווים תמיד להוסיף

מהניסיון שלי, הרשימה הבאה מחזירה השקעה תוך פחות מחודש כמעט בכל VPC פרודקשן:

com.amazonaws.REGION.ecr.api ו-com.amazonaws.REGION.ecr.dkr, בשביל משיכת images מ-ECR (הרבה תעבורה!)
com.amazonaws.REGION.logs, בשביל CloudWatch Logs (agents שולחים 24/7)
com.amazonaws.REGION.ssm, ssmmessages, ec2messages, בשביל Session Manager ו-Systems Manager
com.amazonaws.REGION.secretsmanager ו-kms, לסודות ומפתחות
com.amazonaws.REGION.sts, כי IRSA ב-EKS יורה אליו בכל התחלת pod
com.amazonaws.REGION.monitoring, בשביל CloudWatch Metrics

איך לחסוך בעלויות NAT Gateway בין Availability Zones

הטעות הארכיטקטונית היקרה ביותר שאני רואה ב-VPCs היא NAT Gateway יחיד ב-AZ אחד ששולח את כל התעבורה מ-3 AZs דרכו. AWS גובה 0.01$/GB על תעבורה בין AZs לכל כיוון, כלומר 0.02$/GB round-trip. הוסיפו לזה את ה-0.045$/GB של ה-NAT עצמו, ואתם משלמים 0.065$ לכל GB במקום 0.045$: עלייה של 44% מסיבה שקופה לחלוטין.

הפתרון: NAT Gateway אחד לכל AZ פעיל, וטבלת ניתוב פרטית נפרדת לכל AZ שמפנה תעבורת 0.0.0.0/0 ל-NAT באותו ה-AZ. זה מכפיל את עלות ה-idle של ה-NAT (3 × 32.85$ = 98.55$ במקום 32.85$), אבל חוסך את התעבורה cross-AZ. נקודת האיזון: כל workload שיוצא לאינטרנט יותר מ-3,285 GB בחודש (בערך 4.5 MB/s ממוצע) כבר מרוויח מהמעבר לארכיטקטורה per-AZ.

# דוגמת Terraform: NAT Gateway אחד לכל AZ
resource "aws_eip" "nat" {
  count  = length(var.availability_zones)
  domain = "vpc"
}

resource "aws_nat_gateway" "per_az" {
  count         = length(var.availability_zones)
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id

  tags = {
    Name = "nat-${var.env}-${var.availability_zones[count.index]}"
  }
}

resource "aws_route" "private_to_nat" {
  count                  = length(var.availability_zones)
  route_table_id         = aws_route_table.private[count.index].id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.per_az[count.index].id
}

מתי אפשר להסתפק ב-NAT אחד?

בסביבות dev/test עם תעבורה נמוכה (מתחת ל-500 GB חודשיים), NAT אחד עדיף. גם בסביבות פרודקשן שבהן חשופים בעיקר ל-S3/DynamoDB דרך Gateway Endpoints (שהם אזוריים ולא AZ-פיצולים), לא נשארת הרבה תעבורה דרך NAT. תמיד תחשבו: cross_az_gb × 0.02 vs extra_nat_hourly × 730. הזזתם את שיטת הפריסה שלכם ל-Infrastructure-as-Code כבר? התהליך של הערכת עלויות כאלה לפני deploy מתועד במדריך שלנו על Shift-Left FinOps עם Terraform ו-Infracost.

חלופות ל-NAT Gateway: fck-nat, NAT Instance ו-Transit Gateway

NAT Gateway נוח, אבל הוא לא הפתרון היחיד. שלוש חלופות שמקבלות תאוצה ב-2026:

fck-nat על t4g.nano

הפרויקט fck-nat הוא AMI אמון שפורש NAT מלא על EC2. על t4g.nano (Graviton) העלות היא כ-3.06$ לחודש, לעומת 32.85$ ל-NAT Gateway. הוא תומך ב-throughput של עד 5 Gbps ומתאים לרוב סביבות ה-dev/test וחלק ניכר מ-workloads קטנים בפרודקשן. החיסרון: אין HA מובנה. אם ה-instance נופל, התעבורה נחתכת עד שה-ASG משחזר אותו (בדרך כלל דקה-שתיים). ל-workloads קריטיים, שלבו fck-nat עם ASG בגודל 2 ו-eventual consistency ב-failover, או פשוט השאירו NAT Gateway. אגב, השילוב הזה עם Graviton חוסך בערך 15% עד 20% ומתקשר יפה למאמר שלנו על מעבר ל-AWS Graviton וחיסכון של 40% בעלויות EC2.

NAT Instance מסורתי

ה-NAT Instance ה"ישן" של AWS (AMI רשמי) הופסק ב-2020, אבל טכנית עדיין אפשר להריץ instance ב-Amazon Linux 2 עם iptables MASQUERADE ולקבל NAT. פחות מומלץ ב-2026 בגלל תחזוקה. fck-nat עושה את זה טוב יותר.

Transit Gateway עם centralized egress

ארכיטקטורה מתקדמת לארגונים עם עשרות VPCs: VPC מרכזי אחד (egress VPC) עם NAT Gateway יחיד, וכל שאר ה-VPCs מחוברים אליו דרך Transit Gateway. חוסך הרבה עלויות idle של NAT, אבל מוסיף עלויות של Transit Gateway (0.05$/שעה לחיבור בתוספת 0.02$/GB). מתאים לארגונים עם 10+ VPCs; מתחת לזה זה overkill.

ניטור, התראות ו-Cost Anomaly Detection

הצעד האחרון: וודאו שלא תיפלו שוב לאותה מלכודת. הגדירו התראות CloudWatch על שני metrics קריטיים של NAT Gateway: BytesOutToDestination ו-BytesOutToSource. סף סביר לפרודקשן: פי 2 מהממוצע השבועי. הגדירו גם AWS Cost Anomaly Detection על ה-service NAT Gateway עם threshold של 20%.

# CloudWatch alarm: NAT Gateway processed bytes spike
aws cloudwatch put-metric-alarm \
  --alarm-name nat-gw-egress-spike \
  --namespace AWS/NATGateway \
  --metric-name BytesOutToDestination \
  --dimensions Name=NatGatewayId,Value=nat-0abc123 \
  --statistic Sum \
  --period 3600 \
  --evaluation-periods 2 \
  --threshold 53687091200  # 50 GB/hour
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:cost-alerts

בנוסף, הריצו ניתוח חודשי עם AWS Cost and Usage Reports (CUR) מפורקים לפי resource ID. השאילתה הזו ב-Athena מציגה את 10 ה-NAT Gateways היקרים ביותר בכל החשבון בחודש האחרון:

SELECT
  line_item_resource_id AS nat_gateway_id,
  ROUND(SUM(line_item_unblended_cost), 2) AS cost_usd,
  ROUND(SUM(CASE WHEN line_item_usage_type LIKE '%Bytes%'
           THEN line_item_usage_amount END) / 1024, 2) AS gb_processed
FROM cur_report
WHERE
  product_product_name = 'Amazon Virtual Private Cloud'
  AND line_item_usage_type LIKE '%NatGateway%'
  AND year = '2026'
  AND month = '08'
GROUP BY line_item_resource_id
ORDER BY cost_usd DESC
LIMIT 10;

שלבו את השאילתה הזו עם Cost Allocation Tags במולטי-אקאונט כדי לייחס עלויות NAT ל-team או service ולנהל chargeback אמיתי. בפרויקט האחרון שלי, החיבור בין השניים הפחית "witch-hunt sessions" חודשיים בגלל שהאחריות התחלקה מסודר, לפי צוות ולפי סביבה.

שאלות נפוצות

כמה עולה NAT Gateway ב-AWS בחודש?

NAT Gateway יחיד ב-us-east-1 עולה 0.045$ לשעה, כלומר כ-32.85$ לחודש עלות בסיסית, ובנוסף 0.045$ לכל GB תעבורה מעובדת. Workload ממוצע עם 500 GB חודשיים ישלם בערך 55$, ופרודקשן טיפוסי עם 3 AZs ו-2 TB תעבורה יגיע ל-190$ עד 250$ לחודש לפני חיובי egress לאינטרנט.

האם VPC Endpoints באמת חוסכים כסף על NAT Gateway?

כן, ובגדול. Gateway Endpoints ל-S3 ול-DynamoDB חינמיים לחלוטין ומעקפים את ה-NAT לגמרי. Interface Endpoints לשירותים כמו ECR, CloudWatch ו-SSM עולים כ-0.01$/GB לעומת 0.045$/GB דרך NAT, חיסכון של 78% פר-GB. במרבית ה-VPCs, שילוב Endpoints חותך 40% עד 70% מהחשבון החודשי של NAT Gateway תוך שבוע.

מה ההבדל בין NAT Gateway ל-NAT Instance?

NAT Gateway הוא שירות מנוהל של AWS עם HA מובנה, throughput של עד 100 Gbps ותמחור לפי שעה בתוספת GB. NAT Instance הוא EC2 עם iptables, זול משמעותית (fck-nat על t4g.nano עולה כ-3$ לחודש), אבל דורש תחזוקה, ניהול failover ידני, ומוגבל ל-throughput של ה-instance. עבור dev/test, NAT Instance כדאי; לפרודקשן קריטי, NAT Gateway עדיין המומלץ.

איך מזהים מה גורם לעלויות גבוהות ב-NAT Gateway?

הפעילו VPC Flow Logs על ה-ENI של ה-NAT Gateway עם השדות pkt-srcaddr ו-pkt-dstaddr, שלחו אותם ל-S3 ונתחו ב-Athena. שאילתה שמקבצת לפי dstaddr ומחשבת SUM(bytes) חושפת מיד מי היעדים היקרים ביותר. לרוב תגלו ש-30% עד 60% מהתעבורה יוצאת ל-S3 או ל-endpoints של AWS שאפשר להחליף ב-VPC Endpoints.

האם NAT Gateway תומך ב-IPv6?

לא ישירות. NAT Gateway קלאסי הוא IPv4 בלבד. לתעבורת IPv6 יוצאת, AWS מציעה Egress-Only Internet Gateway, שהוא חינמי לחלוטין (חוץ מחיובי data transfer רגילים) ומחליף לחלוטין את הצורך ב-NAT ל-workloads IPv6-only. מעבר לארכיטקטורת dual-stack עם Egress-Only IGW הוא אחת מדרכי החיסכון הפחות מנוצלות ב-2026.