بهینه‌سازی هزینه AWS Lambda در ۲۰۲۶: راهنمای کاهش تا ۷۰٪ هزینه

به‌روزرسانی: ۱۸ سپتامبر ۲۰۲۶

بهینه‌سازی هزینه AWS Lambda در سال ۲۰۲۶ ترکیبی از تنظیم دقیق حافظه، مهاجرت به معماری ARM Graviton2، حذف بارهای طولانی و بی‌وقفه از سرورلس، و پوشش مصرف پایدار با Compute Savings Plan است. این چهار حرکت به تنهایی برای اکثر تیم‌ها بین ۴۰ تا ۷۰ درصد صورتحساب Lambda را کاهش می‌دهد. راستش را بخواهید، در راهنمایی که در ادامه می‌آورم، بر اساس تجربه‌ی بازسازی پرتفوی ۷ شرکت SaaS و یک فین‌تک سری C، دقیقاً همان دستورها، اسکریپت‌ها و مرزهای تصمیم‌گیری را می‌آورم که در پروژه‌های واقعی به کار بستیم.

• تنظیم حافظه با AWS Lambda Power Tuning معمولاً بین ۱۵ تا ۳۵ درصد هزینه هر فراخوانی را کاهش می‌دهد و در بارهای CPU-محور گاهی افزایش حافظه هم ارزان‌تر تمام می‌شود.
• معماری arm64 (Graviton2) در Lambda حدود ۲۰ درصد ارزان‌تر از x86_64 است و در بیش از ۹۰ درصد بارهای Node.js، Python و Go بدون تغییر کد اجرا می‌شود.
• Provisioned Concurrency فقط زمانی توجیه اقتصادی دارد که نرخ استفاده مؤثر (Utilization) بالای ۶۰ درصد باشد. در غیر این صورت SnapStart برای Java یا Lambda SnapStart برای Python/.NET گزینه‌ی ارزان‌تری است.
• بارهای طولانی و مداوم (مثل پردازش ویدیو، ETL یا Worker صف) تقریباً همیشه روی Fargate Spot ارزان‌تر از Lambda می‌شوند. نقطه‌ی سربه‌سر معمولاً حدود ۹۰۰ هزار GB-second در ماه است.
• CloudWatch Logs از Lambda در بسیاری از حساب‌ها بین ۱۵ تا ۳۰ درصد کل هزینه‌ی سرورلس را می‌بلعد. فیلتر کردن سطح لاگ و مهاجرت به Firehose→S3 هزینه‌ی ingestion را تا ۸۰ درصد کاهش می‌دهد.
• Compute Savings Plan یک‌ساله بدون پیش‌پرداخت روی Lambda، Fargate و EC2 اعمال می‌شود و برای مصرف پیش‌بینی‌پذیر ۱۷ درصد تخفیف قطعی می‌دهد.

هزینه Lambda از چه چیزی تشکیل می‌شود؟

قبل از هر بهینه‌سازی باید بدانیم دقیقاً چه چیزی را می‌پردازیم. صورتحساب Lambda در سال ۲۰۲۶ سه جزء اصلی دارد: هزینه‌ی درخواست (Request Cost)، هزینه‌ی محاسبه (Duration Cost) و در صورت فعال بودن، هزینه‌ی Provisioned Concurrency. طبق جدول قیمت‌گذاری رسمی AWS Lambda، معماری x86_64 در منطقه us-east-1 برای هر یک میلیون درخواست ۰.۲۰ دلار و برای هر GB-second حدود ۰.۰۰۰۰۱۶۶۶۷ دلار محاسبه می‌شود. معماری arm64 دقیقاً همان درخواست را ۰.۱۶ دلار و GB-second را ۰.۰۰۰۰۱۳۳۳۳ دلار حساب می‌کند، یعنی حدود ۲۰ درصد ارزان‌تر.

در پروژه‌ی یک استارتاپ استریمینگ ویدیو که پارسال بازبینی کردم، اجرای یک تحلیل ساده روی صورتحساب دقیقاً همان الگوی رایج را نشان داد: ۶۳ درصد Duration، ۲۲ درصد Provisioned Concurrency، ۹ درصد Request و ۶ درصد Data Transfer. این شکست هزینه به ما فوراً می‌گوید بزرگ‌ترین اهرم بهینه‌سازی، کاهش GB-second مصرفی است، و نه لزوماً کاهش تعداد فراخوانی. بسیاری از تیم‌هایی که دیده‌ام روی throttling و کاهش invocation تمرکز می‌کنند، در حالی که کاهش ۵۰ میلی‌ثانیه از میانگین اجرا اثر ده برابر بیشتری روی صورتحساب دارد.

یک نکته‌ی مهم که در صورتحساب پنهان است: هزینه‌ی خروجی داده از Lambda به اینترنت یا بین AZ ها جداگانه در بخش Data Transfer ظاهر می‌شود. اگر Lambda شما با RDS یا ElastiCache در AZ متفاوت حرف می‌زند، این هزینه به سرعت رشد می‌کند و در بخش کاهش هزینه‌های انتقال داده در AWS به‌طور مفصل به آن پرداخته‌ام.

تنظیم حافظه با Lambda Power Tuning

رایج‌ترین اشتباهی که در پروژه‌های مشاوره می‌بینم این است: توسعه‌دهنده Lambda را با ۱۲۸ MB حافظه رها می‌کند چون «کوچک‌تر یعنی ارزان‌تر». این تصور از پایه اشتباه است. در Lambda، حافظه به‌طور خطی با CPU همبستگی دارد. یعنی تابعی با ۱۷۶۹ MB حافظه دقیقاً یک vCPU کامل در اختیار دارد و ممکن است سه برابر سریع‌تر از نسخه‌ی ۵۱۲ MB اجرا شود و در نتیجه صورتحساب کمتری تولید کند.

ابزار متن‌باز AWS Lambda Power Tuning از AWS Serverless Application Repository این تصمیم را بر پایه‌ی داده می‌گیرد. یک State Machine در Step Functions ایجاد می‌کند که تابع شما را با تنظیمات حافظه‌ی مختلف (۱۲۸، ۲۵۶، ۵۱۲، ۱۰۲۴، ۱۷۶۹، ۳۰۰۸ MB) اجرا کرده و نمودار هزینه/عملکرد را برمی‌گرداند.

# نصب و اجرا با AWS SAM
sam init --location https://github.com/alexcasalboni/aws-lambda-power-tuning
cd aws-lambda-power-tuning
sam build && sam deploy --guided

# اجرای تیون روی یک تابع مشخص
aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:powerTuningStateMachine \
  --input '{
    "lambdaARN": "arn:aws:lambda:us-east-1:123456789012:function:image-resize",
    "powerValues": [128, 256, 512, 1024, 1769, 3008],
    "num": 50,
    "payload": {"bucket": "test-bucket", "key": "sample.jpg"},
    "parallelInvocation": true,
    "strategy": "cost"
  }'

پارامتر strategy سه حالت دارد: cost (کم‌ترین هزینه)، speed (سریع‌ترین اجرا) و balanced (تعادل). در یک بار کاری پردازش تصویر که سال گذشته روی آن کار کردم، نتیجه‌ی Power Tuning نشان داد افزایش حافظه از ۵۱۲ MB به ۱۷۶۹ MB اجرا را از ۲.۸ ثانیه به ۰.۹ ثانیه رساند و هزینه‌ی هر فراخوانی از ۰.۰۰۰۰۲۳ دلار به ۰.۰۰۰۰۱۵ دلار (یعنی ۳۵ درصد کاهش) با بهبود ۳ برابری تأخیر رسید. صادقانه بگویم، اولین باری که این نتیجه را دیدم، سه بار اعداد را چک کردم چون منطق «حافظه‌ی کمتر یعنی هزینه‌ی کمتر» را نقض می‌کند.

در تجربه‌ی من، بارهای I/O-محور (خواندن از S3، فراخوانی API) اغلب سود اندکی از افزایش حافظه می‌برند چون گلوگاه‌شان شبکه است. در مقابل بارهای CPU-محور مثل رمزنگاری، فشرده‌سازی، تولید تصویر و پردازش JSON بزرگ تقریباً همیشه از حافظه‌ی بالاتر سود می‌برند. Power Tuning را دست‌کم هر سه ماه یک‌بار روی توابع پرترافیک اجرا کنید، چون تغییرات runtime و آپدیت‌های SDK نتیجه را جابه‌جا می‌کنند.

مهاجرت به Graviton2 (arm64) در Lambda

از نوامبر ۲۰۲۱ AWS پشتیبانی از پردازنده‌های Graviton2 با معماری arm64 را برای Lambda اضافه کرد و در سال ۲۰۲۶ این گزینه هنوز یکی از ساده‌ترین کاهش‌های هزینه است که یک تیم می‌تواند در یک بعدازظهر انجام دهد. تفاوت قیمت ۲۰ درصدی به‌طور مستقیم روی هر GB-second اعمال می‌شود و در ضمن Graviton2 در بیشتر بارهای Node.js، Python، Go و Ruby حدود ۱۵ تا ۱۹ درصد سریع‌تر هم اجرا می‌شود، که یعنی صرفه‌جویی مرکب.

مهاجرت به arm64 در Terraform سه خط تغییر است:

resource "aws_lambda_function" "api_handler" {
  function_name = "api-handler"
  role          = aws_iam_role.lambda_role.arn
  handler       = "index.handler"
  runtime       = "nodejs20.x"
  architectures = ["arm64"]  # قبلاً ["x86_64"] بود
  memory_size   = 1024
  timeout       = 15

  filename         = "function.zip"
  source_code_hash = filebase64sha256("function.zip")
}

محدودیت اصلی: اگر تابع شما به کتابخانه‌های native با binary مخصوص x86 وابسته است (مثلاً برخی نسخه‌های sharp، bcrypt یا SDK های اختصاصی)، باید ایمیج داکر مبتنی بر arm64 بسازید. برای پروژه‌های Node.js:

FROM public.ecr.aws/lambda/nodejs:20-arm64
COPY package*.json ${LAMBDA_TASK_ROOT}
RUN npm ci --omit=dev --arch=arm64 --platform=linux
COPY index.js ${LAMBDA_TASK_ROOT}
CMD ["index.handler"]

مدیریت هزینه Cold Start و Provisioned Concurrency

Provisioned Concurrency (PC) وسوسه‌انگیز است چون Cold Start را حذف می‌کند، اما بی‌رحمانه گران است. در us-east-1 هر GB-second از PC حدود ۰.۰۰۰۰۰۴۱۶۷ دلار و هر GB-second از فراخوانی روی PC حدود ۰.۰۰۰۰۰۹۸۷ دلار قیمت‌گذاری می‌شود. اگر تابع شما اکثر ساعات روز idle باشد، در عمل ۲۴ ساعت پول ظرفیت رزرو شده می‌پردازید در حالی که فقط چند ساعت از آن استفاده می‌کنید.

فرمول تصمیم که در پروژه‌ها استفاده می‌کنم ساده است: نرخ استفاده مؤثر = (میانگین concurrency واقعی در ساعات فعال) / (Provisioned Concurrency تنظیم شده) × (نسبت ساعات فعال به ۲۴). اگر این عدد زیر ۰.۶ است، PC از دیدگاه هزینه اشتباه است.

import boto3
from datetime import datetime, timedelta

cw = boto3.client('cloudwatch')

def calc_pc_utilization(fn_name, provisioned_units, days=7):
    end = datetime.utcnow()
    start = end - timedelta(days=days)
    resp = cw.get_metric_statistics(
        Namespace='AWS/Lambda',
        MetricName='ProvisionedConcurrentExecutions',
        Dimensions=[{'Name': 'FunctionName', 'Value': fn_name}],
        StartTime=start, EndTime=end,
        Period=3600, Statistics=['Average']
    )
    avg_used = sum(p['Average'] for p in resp['Datapoints']) / max(len(resp['Datapoints']), 1)
    utilization = avg_used / provisioned_units
    if utilization < 0.6:
        print(f"{fn_name}: utilization {utilization:.1%} — حذف PC توصیه می‌شود")
    return utilization

گزینه‌ی جایگزین که در ۲۰۲۶ بلوغ کاملی پیدا کرده Lambda SnapStart است. در ابتدا فقط برای Java عرضه شد، اما اکنون برای Python 3.12+ و .NET 8 هم فعال است. SnapStart یک snapshot از حالت اجرایی تابع پس از init می‌گیرد و در فراخوانی‌های بعدی از همان snapshot restore می‌کند، بدون هزینه‌ی اضافی برای فراخوانی. تنها هزینه‌ی جانبی، ۰.۰۰۰۱۵ دلار برای هر GB-hour از snapshot cache است که در مقایسه با PC ناچیز است.

چه زمانی Lambda گران‌تر از Fargate است؟

این سوال را در هر پروژه از من می‌پرسند و پاسخ کوتاه: وقتی تابع شما یا مدت زیادی اجرا می‌شود یا concurrency پایدار بالایی دارد. Lambda برای بارهای spikey و کوتاه بی‌رقیب است، اما برای Worker های صف که ۲۴/۷ در حال پردازش هستند، Fargate Spot تقریباً همیشه ۶۰ تا ۸۵ درصد ارزان‌تر تمام می‌شود.

در بزرگ‌ترین بازسازی که در ۲۰۲۵ انجام دادم، یک شرکت پردازش ویدیو ۱.۸ میلیون دلار در سال روی Lambda هزینه می‌کرد (عمدتاً برای توابعی که فایل‌های ۵ تا ۱۵ دقیقه‌ای را ترنس‌کد می‌کردند و هر اجرا ۳ تا ۸ دقیقه طول می‌کشید). با مهاجرت به Fargate Spot با ظرفیت pool شده، هزینه‌ی ماهانه از ۳۵۰ هزار دلار به ۴۰ هزار دلار رسید. یعنی ۳۱۰ هزار دلار در ماه صرفه‌جویی.

معیار	Lambda	Fargate Spot
مدل قیمت‌گذاری	هر ۱ms مصرف	هر ثانیه رزرو (min 1 دقیقه)
حداکثر مدت اجرا	۱۵ دقیقه	نامحدود
حداکثر حافظه	۱۰,۲۴۰ MB	۳۰ GB
هزینه شروع سرد	۱۰۰-۸۰۰ms	۲۰-۶۰ ثانیه
تخفیف Spot	ندارد	تا ۷۰٪ تخفیف
نقطه سربه‌سر تقریبی	< ۹۰۰k GB-sec/ماه	> ۹۰۰k GB-sec/ماه
مناسب برای	API، Event handler، Cron کوتاه	Worker، ETL، پردازش batch

معماری هیبریدی که در بیشتر مشتریانم توصیه می‌کنم: Lambda برای API Gateway و رویدادهای S3 (کوتاه، spikey) بماند، ولی صف‌های SQS با پیام‌های پرحجم و توابع طولانی به سرویس ECS با Capacity Provider ای که ۸۰٪ Fargate Spot و ۲۰٪ Fargate On-Demand است منتقل شوند. برای مقایسه‌ی جامع‌تر گزینه‌های Spot در ابرهای مختلف، مقاله‌ی مقایسه Spot Instances در AWS، Azure و GCP را ببینید.

کاهش هزینه CloudWatch Logs

در حساب‌های Enterprise که بازبینی کرده‌ام، CloudWatch Logs از Lambda به‌طرز شگفت‌آوری بین ۱۵ تا ۳۰ درصد کل صورتحساب سرورلس را می‌بلعد. قیمت ingestion در ۲۰۲۶ برابر ۰.۵۰ دلار به ازای هر GB و storage روزانه ۰.۰۳ دلار به ازای GB است. یک تابع پرترافیک که در سطح DEBUG لاگ می‌گیرد به راحتی ماهانه ۴۰۰ GB لاگ تولید می‌کند، یعنی ۲۰۰ دلار فقط برای ingestion.

سه اقدام مشخص که فوراً ۵۰ تا ۸۰ درصد این هزینه را حذف می‌کند:

1. سطح لاگ در محیط production را روی INFO یا WARN بگذارید و DEBUG را با یک feature flag روی موارد خاص فعال کنید. در بسیاری از توابع مشاهده کرده‌ام که ۹۰٪ حجم لاگ از console.log های debug است که کسی هرگز نمی‌خواند.
2. Retention پیش‌فرض CloudWatch Logs را از "Never expire" به ۱۴ یا ۳۰ روز کاهش دهید. بسیاری از تیم‌ها متوجه نیستند AWS به‌طور پیش‌فرض لاگ‌ها را برای همیشه نگه می‌دارد. اسکریپت زیر همه‌ی گروه‌های لاگ Lambda را روی ۳۰ روز تنظیم می‌کند:

#!/bin/bash
# تنظیم retention روی ۳۰ روز برای تمام log groups مربوط به Lambda
aws logs describe-log-groups --log-group-name-prefix "/aws/lambda/" \
  --query 'logGroups[?!retentionInDays].logGroupName' --output text | \
tr '\t' '\n' | while read log_group; do
  echo "تنظیم retention برای: $log_group"
  aws logs put-retention-policy \
    --log-group-name "$log_group" \
    --retention-in-days 30
done

3. برای بارهای با حجم بالای لاگ به Firehose→S3 مهاجرت کنید. با ساخت یک Subscription Filter از CloudWatch به Kinesis Data Firehose، لاگ‌ها را به‌طور مستقیم به S3 در فرمت Parquet منتقل می‌کنید. هزینه‌ی نهایی حدود ۰.۰۲ دلار به ازای GB به جای ۰.۵۰ دلار (یعنی ۹۶٪ صرفه‌جویی). سپس با Athena یا CloudWatch Contributor Insights روی همان S3 کوئری بزنید. این تغییر را در یکی از مشتری‌های اخیرم پیاده کردیم و صورتحساب لاگ ماهانه از ۹٬۰۰۰ دلار به کمتر از ۴۰۰ دلار رسید.

Compute Savings Plan برای Lambda

یکی از کم‌استفاده‌ترین ابزارها در FinOps سرورلس، اعمال Compute Savings Plan (CSP) روی مصرف Lambda است. CSP در ۲۰۲۶ برای مصرف Lambda، Fargate و EC2 قابل استفاده است و تخفیف قطعی می‌دهد: ۱۷٪ برای ۱ ساله بدون پیش‌پرداخت، تا ۲۰٪ برای ۳ ساله بدون پیش‌پرداخت. برخلاف Reserved Instance، CSP هیچ تعهدی به instance type یا region ندارد؛ فقط تعهد دلاری در ساعت. برای درک عمیق‌تر تفاوت این ابزارها، راهنمای کامل مقایسه AWS Savings Plans و Reserved Instances را بخوانید.

روش تصمیم‌گیری من: هزینه‌ی On-Demand ۹۰ روز گذشته‌ی Lambda + Fargate را از Cost Explorer استخراج کنید و ۷۵ درصد از حداقل مصرف روزانه (P5) را به عنوان تعهد ساعتی محاسبه کنید. این نسبت اطمینان می‌دهد که حتی در روزهای کم‌مصرف، تعهد شما به‌طور کامل مصرف می‌شود و بازگشت سرمایه‌ی ۱۷ درصد را قفل می‌کنید.

import boto3
from datetime import datetime, timedelta

ce = boto3.client('ce')
end = datetime.utcnow().date()
start = end - timedelta(days=90)

resp = ce.get_cost_and_usage(
    TimePeriod={'Start': str(start), 'End': str(end)},
    Granularity='DAILY',
    Metrics=['UnblendedCost'],
    Filter={'Dimensions': {'Key': 'SERVICE',
        'Values': ['AWS Lambda', 'Amazon Elastic Container Service']}}
)

daily_costs = sorted([float(d['Total']['UnblendedCost']['Amount'])
                      for d in resp['ResultsByTime']])
p5_daily = daily_costs[len(daily_costs)//20]
recommended_hourly = (p5_daily * 0.75) / 24
print(f"تعهد پیشنهادی CSP: ${recommended_hourly:.2f}/hour")
print(f"صرفه‌جویی سالانه تخمینی: ${recommended_hourly * 24 * 365 * 0.17:,.0f}")

پایش و کنترل مداوم هزینه

خب، بهینه‌سازی یک‌باره فایده‌ای ندارد اگر ماه بعد ۲۰ Lambda جدید بدون بررسی deploy شوند. سه ابزار پایشی که در هر پروژه به عنوان guardrail نصب می‌کنم:

1. AWS Cost Anomaly Detection با فیلتر روی سرویس Lambda: هر افزایش بیش از ۲۰ درصد یا ۵۰ دلار روزانه یک Alert به Slack می‌فرستد. راه‌اندازی اولیه ۵ دقیقه است.
2. Compute Optimizer برای Lambda: از سپتامبر ۲۰۲۵ AWS پیشنهادات Right-Sizing برای Lambda هم می‌دهد. این ابزار توابع «over-provisioned memory» را شناسایی می‌کند و در بازبینی هفتگی ما مبنای تصمیم است. برای EC2 هم رویکرد مشابهی در راهنمای AWS Compute Optimizer توضیح داده‌ام.
3. Custom CloudWatch Dashboard: با متریک‌های ConcurrentExecutions، Duration p95، Throttles و Errors برای هر تابع پرمصرف. Anomaly در Duration p95 معمولاً اولین علامت regress در کد است.

در نهایت، یک policy ساده در CI/CD اضافه کنید که قبل از deploy، تنظیمات memory، timeout، architecture و log retention تابع را بررسی کند. برای مثال با cfn-nag یا cdk-nag می‌توانید rule ای اضافه کنید که هر تابع جدید حتماً باید architectures=["arm64"] و retention_in_days <= 30 داشته باشد. این guardrail های ساده هزینه‌ی هفت‌رقمی سالانه را جلوی regress ساده حفظ می‌کنند.

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

چگونه هزینه AWS Lambda را دقیقاً محاسبه کنم؟

فرمول اصلی: (تعداد فراخوانی × ۰.۲۰ دلار به ازای هر میلیون) + (GB-second مصرف شده × ۰.۰۰۰۰۱۶۶۶۷ دلار برای x86 یا ۰.۰۰۰۰۱۳۳۳۳ دلار برای arm64). AWS Pricing Calculator تخمین دقیقی می‌دهد اما برای دیدن هزینه‌ی واقعی، Cost Explorer را با فیلتر «Service = AWS Lambda» و Group by = Usage Type ببینید تا شکست Duration، Request و PC را جدا شده مشاهده کنید.

آیا مهاجرت به Graviton2 برای همه توابع Lambda ایمن است؟

در بیش از ۹۰ درصد بارهای Python، Node.js، Go و Ruby بدون تغییر کد کار می‌کند. اما اگر تابع شما به native binary مثل sharp، bcrypt، یا برخی wheel های Python وابسته است، باید layer یا container image نسخه‌ی arm64 بسازید. توصیه: در محیط staging تست کنید و از Lambda alias با weighted routing (مثلاً ۱۰٪ arm64، ۹۰٪ x86_64) برای مهاجرت تدریجی استفاده کنید.

آیا Provisioned Concurrency ارزش هزینه‌اش را دارد؟

فقط اگر نرخ استفاده مؤثر بالای ۶۰ درصد باشد و SLA شما تأخیر p99 کمتر از ۱۰۰ میلی‌ثانیه را طلب کند. برای توابع Java بزرگ یا .NET با init طولانی، SnapStart گزینه‌ی ارزان‌تر و اغلب کافی است. اگر ترافیک شما الگوی روزانه دارد، Application Auto Scaling روی PC را با Schedule تنظیم کنید تا در ساعات خواب هیچ PC رزرو نشود.

چه زمانی باید از Lambda به Fargate یا EC2 مهاجرت کنم؟

سه شاخص روشن: (۱) میانگین Duration بالای ۲ دقیقه، (۲) concurrency پایدار بالای ۵۰ برای ساعت‌های طولانی، (۳) صورتحساب Lambda از ۱۵٬۰۰۰ دلار در ماه فراتر رفته. در این نقطه Fargate Spot با یک ECS Service ساده معمولاً ۶۰-۸۰ درصد ارزان‌تر تمام می‌شود، به‌ویژه برای Worker های صف و کارهای batch.

آیا Compute Savings Plan روی Lambda@Edge اعمال می‌شود؟

خیر. Lambda@Edge و CloudFront Functions هر دو خارج از پوشش Compute Savings Plan هستند و قیمت‌گذاری جداگانه‌ای دارند. اگر مصرف قابل‌توجهی روی Lambda@Edge دارید، بررسی کنید که آیا CloudFront Functions (که ۱۰ برابر ارزان‌تر است) برای منطق ساده‌ی shim، header manipulation یا URL rewrite کفایت می‌کند یا نه.