کاهش هزینه‌های انتقال داده در AWS: راهنمای عملی Egress در ۲۰۲۶

به‌روزرسانی: ۳۰ ژوئن ۲۰۲۶

کاهش هزینه‌های انتقال داده در AWS با ترکیب VPC Endpoints، CloudFront، طراحی هوشمندانه ترافیک Cross-AZ و حذف NAT Gateway‌های غیرضروری معمولاً بین ۴۰ تا ۷۰ درصد از صورت‌حساب شبکه را پایین می‌آورد. در ۲۰۲۶ که قیمت Egress عمومی AWS هنوز در محدوده ۰٫۰۹ دلار به ازای هر گیگابایت برای ۱۰ ترابایت اول باقی مانده، کوچک‌ترین خطا در توپولوژی شبکه می‌تواند ماهانه ده‌ها هزار دلار هزینه پنهان ایجاد کند. این راهنما بر اساس تجربه میدانی نوشته شده و دقیقاً نشان می‌دهد چه چیزی را کجا برش بزنید.

• هزینه Egress عمومی AWS در ۲۰۲۶ همچنان ۰٫۰۹ دلار/گیگابایت برای ۱۰ ترابایت اول است؛ ترافیک Cross-AZ هر طرف ۰٫۰۱ دلار/گیگابایت محاسبه می‌شود.
• افزودن یک Gateway VPC Endpoint برای S3 و DynamoDB رایگان است و می‌تواند بلافاصله هزینه NAT Gateway را برای این سرویس‌ها به صفر برساند.
• NAT Gateway هم هزینه ساعتی ۰٫۰۴۵ دلار دارد و هم ۰٫۰۴۵ دلار به ازای هر گیگابایت پردازش، و معمولاً گران‌ترین کامپوننت شبکه در حساب‌های متوسط است.
• انتقال داده از طریق CloudFront به اینترنت در سطح Edge با AWS Private Pricing Tier تا ۶۰ درصد ارزان‌تر از Egress مستقیم EC2 است.
• قرار دادن مصرف‌کننده و تولیدکننده در یک AZ، هزینه ۰٫۰۲ دلار/گیگابایت Cross-AZ را حذف می‌کند، و این بزرگ‌ترین برد آسان برای خوشه‌های Kafka و Elasticsearch است.
• گزارش CUR 2.0 با ستون line_item_usage_type دقیقاً مشخص می‌کند کدام جریان داده هزینه‌بر است. بدون این داده، هر تلاش بهینه‌سازی حدسی است.

آناتومی صورت‌حساب انتقال داده AWS

صادقانه بگویم، قبل از اینکه چیزی را بهینه‌سازی کنید، باید دقیقاً بدانید AWS بابت چه چیزی پول می‌گیرد. من بارها تیم‌هایی را دیده‌ام که ماه‌ها روی هزینه EC2 خود کار می‌کنند و خبر ندارند ۴۰ درصد صورت‌حساب آنها در واقع DataTransfer-Out-Bytes و DataTransfer-Regional-Bytes است. شش لایه قیمت‌گذاری وجود دارد که باید همیشه در ذهن داشته باشید:

• Egress به اینترنت عمومی: ۰٫۰۹ دلار/GB برای ۱۰ TB اول در ماه (us-east-1)؛ پلکانی تا ۰٫۰۵ دلار برای بیش از ۱۵۰ TB.
• Cross-Region: بین ۰٫۰۲ تا ۰٫۰۹ دلار/GB بسته به مبدا و مقصد.
• Cross-AZ (هر دو طرف): ۰٫۰۱ دلار/GB در هر جهت، یعنی ۰٫۰۲ دلار برای رفت و برگشت.
• NAT Gateway Processing: ۰٫۰۴۵ دلار/GB علاوه بر هزینه‌های بالا.
• VPC Endpoint (Interface): ۰٫۰۱ دلار/ساعت به اضافه ۰٫۰۱ دلار/GB پردازش.
• VPC Endpoint (Gateway برای S3/DynamoDB): رایگان.

ترکیب این لایه‌هاست که شگفت‌انگیز می‌شود. ارسال یک گیگابایت از یک EC2 در یک AZ خصوصی به S3 از طریق NAT Gateway (به جای Gateway Endpoint) برابر است با ۰٫۰۴۵ دلار پردازش NAT، بدون اینکه حتی یک سنت ارزش به شما اضافه کند. روی پتابایت‌ها، این ۴۵٬۰۰۰ دلار خالص خرج هدر رفته است. در یک حسابرسی که اوایل ۲۰۲۶ انجام دادم، یک شرکت SaaS متوسط ماهانه ۱۲۰٬۰۰۰ دلار فقط برای پردازش NAT می‌پرداخت و ۹۲ درصد آن قابل حذف بود.

چرا NAT Gateway گران‌ترین جزء شبکه شماست؟

در بیشتر حساب‌هایی که حسابرسی کرده‌ام، NAT Gateway به‌تنهایی بین ۲۵ تا ۴۵ درصد کل هزینه شبکه را تشکیل می‌دهد. مشکل دوگانه است: هم پایه‌ای ساعتی دارد (حدود ۳۲٫۴ دلار در ماه برای هر NAT در هر AZ) و هم هزینه پردازشی که از هزینه Egress عمومی نزدیک‌تر است تا یک سرویس کمکی. اگر سه AZ دارید و در هر کدام یک NAT Gateway برای High Availability، شما قبل از انتقال حتی یک بایت داده، ماهانه حدود ۹۷ دلار می‌پردازید.

اولین کاری که باید بکنید این است که با AWS CLI یا کوئری Athena روی CUR، حجم پردازش‌شده NAT را به تفکیک سرویس مقصد ببینید. اگر اکثر ترافیک به S3، DynamoDB، ECR، یا API گذرگاه‌های AWS است، شما در حال پرداخت برای NAT بدون دلیل هستید. این تماماً قابل حذف است با Endpoint مناسب. در پروژه‌ای که اواخر ۲۰۲۵ روی آن کار می‌کردم، با یک تغییر ساده برای تیم Data Engineering، هزینه ماهانه NAT از ۱۸٬۰۰۰ دلار به ۲٬۲۰۰ دلار کاهش یافت. بدون تغییر کد، فقط با اضافه کردن Endpointهای مناسب.

# بررسی حجم ترافیک عبوری NAT با AWS CLI
aws ec2 describe-nat-gateways \
  --query 'NatGateways[*].[NatGatewayId,VpcId,State]' \
  --output table

# مشاهده پردازش NAT در CloudWatch (BytesOutToDestination)
aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name BytesOutToDestination \
  --dimensions Name=NatGatewayId,Value=nat-0abc123 \
  --start-time 2026-06-01T00:00:00Z \
  --end-time 2026-06-30T00:00:00Z \
  --period 86400 \
  --statistics Sum

VPC Endpoints: اولین برد بزرگ

خب، دو نوع VPC Endpoint وجود دارد و تفاوت اقتصادی آنها زیاد است. Gateway Endpoints فقط برای S3 و DynamoDB در دسترس هستند و کاملاً رایگان‌اند. هیچ هزینه ساعتی، هیچ هزینه پردازش. تنها کاری که می‌کنند این است که یک ورودی به Route Table اضافه می‌کنند تا ترافیک به این سرویس‌ها از مسیر شبکه ستون‌فقرات AWS عبور کند، نه از NAT. اگر هنوز این را در هر VPC خود ندارید، الان متوقف شوید و آن را اضافه کنید. بازگشت سرمایه آن لحظه‌ای است.

برای جزئیات قیمت‌گذاری به‌روز و سرویس‌های پشتیبانی‌شده، می‌توانید به صفحه قیمت‌گذاری رسمی AWS PrivateLink مراجعه کنید.

Interface Endpoints (مبتنی بر PrivateLink) برای سایر سرویس‌ها مانند ECR، Secrets Manager، SQS، KMS، SSM و غیره استفاده می‌شوند. اینها ۰٫۰۱ دلار/ساعت در هر AZ به اضافه ۰٫۰۱ دلار/GB پردازش هزینه دارند. ریاضی ساده: اگر بیش از حدود ۴٫۵ GB در ساعت از NAT به یک سرویس AWS می‌فرستید، Interface Endpoint قطعاً ارزان‌تر است. در عمل، تقریباً همیشه ارزش دارد، چون از زمان توقف NAT برای DNS، KMS و ECR هم بهره‌مند می‌شوید.

# ساخت Gateway Endpoint برای S3 با Terraform
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({
    Statement = [{
      Effect    = "Allow"
      Principal = "*"
      Action    = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
      Resource  = ["arn:aws:s3:::my-data-bucket/*",
                   "arn:aws:s3:::my-data-bucket"]
    }]
  })
}

# Interface Endpoint برای ECR (Pull کانتینر بدون NAT)
resource "aws_vpc_endpoint" "ecr_dkr" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${var.region}.ecr.dkr"
  vpc_endpoint_type   = "Interface"
  subnet_ids          = aws_subnet.private[*].id
  security_group_ids  = [aws_security_group.endpoints.id]
  private_dns_enabled = true
}

یک تله کلاسیک که خودم در پروژه قبلی به آن خوردم: حتماً private_dns_enabled = true را برای Interface Endpointها فعال کنید، وگرنه SDK‌های شما همچنان از طریق نام DNS عمومی به سرویس متصل می‌شوند و Endpoint را دور می‌زنند.

کاهش هزینه ترافیک Cross-AZ

هزینه ۰٫۰۲ دلار/GB برای رفت‌وبرگشت Cross-AZ ممکن است کوچک به نظر برسد، اما در workload‌های پرحجم مانند Kafka، Cassandra، Elasticsearch یا حتی یک کلاستر Postgres با Read Replica، می‌تواند به بزرگ‌ترین خط در صورت‌حساب شما تبدیل شود. یک خوشه Kafka با ۱ گیگابیت در ثانیه ترافیک تولید، اگر Producer و Consumer در AZ‌های مختلف باشند، ماهانه حدود ۶۵٬۰۰۰ دلار فقط برای جابه‌جایی داده بین AZها هزینه می‌کند.

سه استراتژی کاهش وجود دارد:

1. Topology-aware Routing: در Kubernetes، از قابلیت Topology Aware Hints (پایدار از ۱.۲۷) استفاده کنید تا Service Mesh ترافیک را در همان AZ نگه دارد. برای Istio، حتماً localityLbSetting را فعال کنید.
2. Rack Awareness در Kafka: broker.rack را برابر AZ تنظیم کنید و در Consumer از client.rack برای Fetch from Closest Replica (KIP-392) استفاده کنید. این قابلیت در Kafka 3.0+ موجود است. جزئیات بیشتر در پروپوزال رسمی KIP-392 آمده است.
3. Same-AZ Deployment Constraints: برای workload‌های stateless پرترافیک که نیاز به HA ندارند، با podAntiAffinity و nodeSelector تمام رپلیکا‌ها را به یک AZ محدود کنید و در عوض از Auto Scaling Group در یک AZ دیگر برای failover استفاده کنید.

برای راهنمایی بیشتر در مورد طراحی شبکه‌ای که هزینه Cross-AZ را به حداقل می‌رساند، مقاله بهینه‌سازی هزینه کوبرنتیز در ۲۰۲۶ به‌طور مفصل به این بحث می‌پردازد.

آیا CloudFront واقعاً هزینه Egress را کاهش می‌دهد؟

بله، اما به شیوه‌ای که اغلب اشتباه فهمیده می‌شود. وقتی محتوا را از طریق CloudFront ارائه می‌دهید، انتقال داده از مبدا (مثلاً S3 یا ALB) به CloudFront کاملاً رایگان است. سپس مشتری شما هزینه Data Transfer Out از CloudFront را می‌پردازد که در آمریکای شمالی از ۰٫۰۸۵ دلار/GB شروع می‌شود و در ترافیک‌های بالا با CloudFront Security Savings Bundle می‌تواند تا ۰٫۰۲ دلار/GB کاهش یابد.

برای محتوای کشینگ‌پذیر (تصاویر، JS، CSS، ویدیو، فایل‌های دانلودی)، CloudFront تقریباً همیشه ارزان‌تر از Egress مستقیم است. اما برای API‌های دینامیک با Cache Hit Ratio پایین، صرفه‌جویی محدودتر است و باید با Origin Shield و TTL‌های مناسب آن را افزایش دهید.

روش انتقال	قیمت/GB (us-east-1، حجم متوسط)	مناسب برای
EC2 به اینترنت مستقیم	۰٫۰۹ دلار	API‌های B2B، Webhook‌ها
CloudFront به اینترنت	۰٫۰۵ تا ۰٫۰۸۵ دلار	محتوای استاتیک، رسانه، CDN
CloudFront با Security Bundle	تا ۰٫۰۲ دلار	ترافیک بالای ۱۰ TB/ماه
S3 Transfer Acceleration	۰٫۰۴ تا ۰٫۰۸ دلار اضافه	آپلود از مناطق دور
Direct Connect Dedicated	۰٫۰۲ دلار به اضافه کارمزد پورت	بالای ۵۰ TB/ماه به DC شرکتی
Cross-Region Replication	۰٫۰۲ دلار	DR و backup

تنظیمات کلیدی CloudFront برای صرفه‌جویی

چند تنظیم که اغلب فراموش می‌شوند ولی تأثیر مستقیم بر هزینه دارند: Compress Objects Automatically را فعال کنید (تا ۸۰٪ کاهش حجم برای JSON/HTML)، Origin Shield را در نزدیک‌ترین Region به مبدا فعال کنید (Cache Hit Ratio را تا ۲۰٪ افزایش می‌دهد)، و برای محتوای کاملاً ثابت TTL را به حداقل یک سال تنظیم کنید با استفاده از Cache Versioning در URL.

چه زمانی Direct Connect مقرون‌به‌صرفه می‌شود؟

اگر بیش از حدود ۵۰ TB در ماه بین AWS و دیتاسنتر یا دفتر شرکتی خود انتقال می‌دهید، AWS Direct Connect ارزش بررسی دارد. هزینه آن دو بخش دارد: کرایه پورت ساعتی (از ۰٫۳ دلار/ساعت برای ۱ Gbps در ایالات متحده تا چندین دلار برای ۱۰ یا ۱۰۰ Gbps) و هزینه Data Transfer Out که به ۰٫۰۲ دلار/GB کاهش می‌یابد، یعنی کمتر از یک‌چهارم نرخ اینترنت عمومی.

نقطه شکست در عمل حدود ۸۰ تا ۱۲۰ TB در ماه است وقتی که هزینه پورت ۱ Gbps را در نظر بگیرید. زیر آن، CloudFront با Security Bundle معمولاً ارزان‌تر است. بالاتر از ۵۰۰ TB، Direct Connect همیشه برنده است. اما حواستان به Egress Channel و Hosted Connections از طریق پارتنر باشد، چون مدل قیمت‌گذاری متفاوت است و در برخی موارد ارزان‌تر برای حجم‌های پایین‌تر است.

مشاهده‌پذیری: یافتن گران‌ترین جریان‌های داده

بدون داده دقیق، هر بهینه‌سازی فقط حدس است. ابزار طلایی ۲۰۲۶ گزارش Cost and Usage Report 2.0 (CUR 2.0) است که در فرمت Parquet ذخیره می‌شود و توسط Athena قابل پرس‌وجوست. این گزارش حالا با FOCUS specification 1.1 از طریق Data Exports قابل خروجی است که تجزیه و تحلیل چندابری را به‌شدت ساده‌تر می‌کند.

-- یافتن گران‌ترین انواع انتقال داده در ماه جاری
SELECT
  line_item_usage_type,
  product_region,
  ROUND(SUM(line_item_usage_amount), 2) AS gb_transferred,
  ROUND(SUM(line_item_unblended_cost), 2) AS cost_usd,
  ROUND(SUM(line_item_unblended_cost) / NULLIF(SUM(line_item_usage_amount), 0), 4) AS cost_per_gb
FROM cur2_db.cur2_table
WHERE year = '2026' AND month = '6'
  AND line_item_product_code IN ('AmazonEC2', 'AWSDataTransfer', 'AmazonCloudFront')
  AND line_item_usage_type LIKE '%Bytes%'
GROUP BY line_item_usage_type, product_region
ORDER BY cost_usd DESC
LIMIT 25;

این کوئری به شما دقیقاً می‌گوید کدام جریان (DataTransfer-Regional-Bytes، NatGateway-Bytes، CloudFront-Out-Bytes و غیره) بزرگ‌ترین هزینه را تولید می‌کند. آن را با VPC Flow Logs ترکیب کنید تا به سطح IP/Port برسید و تشخیص دهید کدام workload خاص مسئول است.

طراحی Multi-Region بدون انفجار هزینه

معماری‌های Active-Active در چند Region شیک به نظر می‌رسند، اما هزینه‌های پنهان زیادی دارند. هر Cross-Region Replication در S3، هر DynamoDB Global Table، هر RDS Read Replica در Region دیگر، ترافیک Cross-Region را تحمیل می‌کند که بسته به جفت Region بین ۰٫۰۲ تا ۰٫۰۹ دلار/GB است. در یک حسابرسی اخیر، یک تیم متوجه شد ۳۰ درصد صورت‌حساب خود را برای داده‌های replication می‌پردازد در حالی که در عمل از قابلیت failover هرگز استفاده نکرده بودند.

اصول طلایی:

• قبل از replication، تصمیم بگیرید RTO و RPO شما واقعاً چقدر است. اگر RTO شما ۴ ساعت است، احتمالاً نیاز به Continuous Replication ندارید و Daily Snapshot کافی است (با یک‌دهم هزینه).
• برای S3، از Same-Region Replication به یک Bucket با Lifecycle Policy استفاده کنید به جای Cross-Region، مگر اینکه واقعاً به DR Region نیاز داشته باشید.
• برای داده‌های log و backup، Glacier Deep Archive در همان Region اغلب جایگزین Cross-Region Replication است با هزینه ۱ تا ۲ درصد.
• برای Database، از Aurora Global Database به جای ساخت دستی Cross-Region Replica استفاده کنید. هزینه شبکه آن به‌طور قابل‌توجهی کمتر است چون از زیرساخت اختصاصی AWS بهره می‌برد.

اگر این رویکرد را همراه با تکنیک‌های Reserved Capacity در نظر می‌گیرید، مقایسه دقیق در راهنمای AWS Savings Plans و Reserved Instances ابعاد مالی آن را پوشش می‌دهد.

الگوی توصیه‌شده: Hub-and-Spoke با Transit Gateway

برای حساب‌هایی با چندین VPC در یک Region، Transit Gateway در مقایسه با VPC Peering یا VPN Mesh هم ساده‌تر است و هم اغلب ارزان‌تر. TGW با ۰٫۰۵ دلار/ساعت برای attachment به اضافه ۰٫۰۲ دلار/GB پردازش کار می‌کند. در حساب‌های متوسط با بیش از ۵ VPC، صرفه‌جویی عملیاتی به‌تنهایی ارزش آن را دارد، حتی قبل از در نظر گرفتن کاهش پیچیدگی شبکه.

پرسش‌های متداول

آیا انتقال داده در همان Region AWS رایگان است؟

تنها در صورتی رایگان است که در همان AZ و از طریق Private IP باشد. ترافیک Cross-AZ ۰٫۰۱ دلار/GB در هر جهت هزینه دارد (مجموع ۰٫۰۲ دلار/GB رفت‌وبرگشت) و ترافیک از طریق Public IP حتی در همان AZ به‌عنوان Regional محاسبه می‌شود.

ارزان‌ترین راه برای انتقال داده به خارج از AWS چیست؟

برای حجم‌های زیر ۱۰ TB/ماه، CloudFront با کش مناسب ارزان‌ترین است. بین ۱۰ تا ۵۰ TB، CloudFront Security Savings Bundle بهترین قیمت/GB را دارد. بالای ۵۰ TB، Direct Connect Dedicated را با ۰٫۰۲ دلار/GB در نظر بگیرید. AWS Snowball برای انتقال یک‌باره چندین پتابایت ارزان‌تر از هر گزینه شبکه‌ای است.

آیا حذف NAT Gateway به‌طور کامل امکان‌پذیر است؟

در بسیاری از معماری‌ها بله. با ترکیب Gateway Endpoints برای S3/DynamoDB و Interface Endpoints برای سایر سرویس‌های AWS، اگر workload شما فقط با سرویس‌های AWS صحبت می‌کند، می‌توانید NAT را حذف کنید. اگر نیاز به دسترسی به API‌های شخص ثالث دارید، Egress-Only Internet Gateway برای IPv6 رایگان است و راه‌حل خوبی است.

آیا VPC Peering ارزان‌تر از Transit Gateway است؟

برای دو یا سه VPC، Peering ارزان‌تر است چون فقط هزینه انتقال داده دارد، نه هزینه ساعتی attachment. اما تعداد ارتباطات با O(n²) رشد می‌کند و مدیریت آن سخت می‌شود. از حدود ۵ VPC به بالا، Transit Gateway هم از نظر عملیاتی و هم اغلب از نظر هزینه کلی برنده است.

چگونه می‌توان هزینه‌های انتقال داده غیرمنتظره را پیش‌بینی کرد؟

از AWS Cost Anomaly Detection با ML برای کشف خودکار جهش‌های ترافیکی استفاده کنید و آستانه‌های Budget برای DataTransfer-Out به تفکیک سرویس تنظیم کنید. همچنین VPC Flow Logs را به CloudWatch Logs Insights ارسال کنید تا بتوانید در زمان واقعی هر تغییر در الگوی ترافیک را مشاهده کنید.