AWS Compute Optimizer: راهنمای Right-sizing EC2 و کاهش ۴۰٪ هزینه در ۲۰۲۶

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

AWS Compute Optimizer یک سرویس رایگان یادگیری ماشین است که با تحلیل معیارهای CloudWatch در ۱۴ روز گذشته، اینستنس‌های EC2 با اندازه نادرست را شناسایی کرده و توصیه‌های دقیق right-sizing ارائه می‌دهد که به‌طور معمول بین ۲۵ تا ۴۰ درصد از هزینه compute را کاهش می‌دهد. برای فلوت‌های متوسط (۵۰ تا ۵۰۰ اینستنس)، این معمولاً معادل ۱۵٬۰۰۰ تا ۲۰۰٬۰۰۰ دلار صرفه‌جویی سالانه است، به‌ویژه وقتی با Compute Savings Plans ترکیب شود. راستش، اولین باری که این جریان کاری را روی یک فلوت مشتری اجرا کردم، در سه هفته اول ۳۸ درصد کاهش هزینه ثبت کردیم؛ در این راهنما همان جریان تولید را گام‌به‌گام شرح می‌دهم.

• Compute Optimizer پس از فعال‌سازی ۱۴ روز داده CloudWatch را تحلیل می‌کند تا توصیه‌های right-sizing با درصد اطمینان (Low/Medium/High) ارائه دهد.
• سرویس پایه رایگان است؛ فقط برای Enhanced Infrastructure Metrics هر منبع ۰٫۰۰۳۳۶۹ دلار در ماه هزینه دارد (۹۰ روز lookback به‌جای ۱۴ روز).
• بدون CloudWatch Agent، Compute Optimizer نمی‌تواند مصرف حافظه را ببیند و توصیه‌ها فقط بر اساس CPU و شبکه ساخته می‌شوند، که خطر under-sizing حافظه‌محور را افزایش می‌دهد.
• توصیه‌های Graviton (خانواده m7g, c7g, r7g) به‌طور متوسط ۲۰٪ ارزان‌تر از معادل x86 هستند، اما نیاز به کامپایل مجدد باینری‌ها یا ایمیج‌های کانتینر دارند.
• ترکیب right-sizing با Compute Savings Plans می‌تواند صرفه‌جویی کل را به بیش از ۵۵٪ برساند، اما ترتیب مهم است: اول right-size، بعد commit.
• فعال‌سازی در سطح AWS Organizations توصیه می‌شود تا داده تجمیعی برای تمام حساب‌های عضو در یک داشبورد قابل مشاهده باشد.

AWS Compute Optimizer چیست و چگونه کار می‌کند؟

AWS Compute Optimizer سرویسی است که در نوامبر ۲۰۱۹ عرضه شد و از الگوریتم‌های یادگیری ماشین (مبتنی بر شبکه‌های عصبی گرادیانت‌بوست) برای تحلیل الگوهای مصرف منابع استفاده می‌کند. سرویس هر روز داده معیارهای CloudWatch از EC2، EBS، Lambda، Auto Scaling Groups و ECS on Fargate را جذب کرده و در برابر بیش از ۱۴۰ نوع اینستنس مدل‌سازی می‌کند تا بهترین انطباق قیمت-عملکرد را پیدا کند.

موتور توصیه سه معیار اصلی را می‌سنجد: CPUUtilization (میانگین و p99)، NetworkPacketsIn/Out، و در صورت وجود CloudWatch Agent، mem_used_percent. برای هر منبع، سرویس یک برچسب یکی از سه حالت را می‌زند: Under-provisioned (کمبود منابع، ریسک عملکرد)، Over-provisioned (منابع اضافی، اتلاف هزینه)، یا Optimized. هر توصیه با یک Performance Risk Score بین ۰ تا ۴ همراه است، هر چه پایین‌تر، مطمئن‌تر.

در تجربه من با فلوت‌های تولیدی مشتریان، حدود ۳۵ درصد اینستنس‌های EC2 در حالت پیش‌فرض over-provisioned هستند. این معمولاً نتیجه انتخاب نوع اینستنس بر اساس «حداکثر بار احتمالی» به‌جای پروفایل واقعی است. صادقانه بگویم، Compute Optimizer این شکاف را با داده‌های واقعی پر می‌کند و همان مکالمه ذهنی «شاید یک روز به این RAM نیاز پیدا کنیم» را با عدد جایگزین می‌کند.

فعال‌سازی Compute Optimizer در سطح Organizations

برای سازمان‌های چند حسابی، فعال‌سازی در سطح management account از طریق AWS Organizations توصیه می‌شود. این کار داشبورد تجمیعی می‌سازد که در آن می‌توانید تمام توصیه‌ها را در یک نما ببینید و بر اساس برچسب‌های تخصیص هزینه فیلتر کنید.

# فعال‌سازی در سطح Organization از management account
aws compute-optimizer update-enrollment-status \
    --status Active \
    --include-member-accounts

# تایید وضعیت
aws compute-optimizer get-enrollment-status-for-organization \
    --query 'accountEnrollmentStatuses[?status==`Active`] | length(@)'

# دریافت آخرین وضعیت به‌روزرسانی داده‌ها
aws compute-optimizer get-recommendation-summaries \
    --account-ids 111122223333 \
    --query 'recommendationSummaries[*].[recommendationResourceType,summaries[*]]'

پس از فعال‌سازی، Compute Optimizer نیاز به حداقل ۳۰ ساعت داده CloudWatch دارد تا اولین توصیه‌ها تولید شوند. توصیه‌های با اطمینان High معمولاً پس از ۷ تا ۱۴ روز کامل ظاهر می‌شوند. اگر می‌خواهید window تحلیل را از ۱۴ روز به ۹۳ روز افزایش دهید، باید Enhanced Infrastructure Metrics را برای منابع مورد نظر فعال کنید. این ویژگی برای بارهای کاری فصلی (مثلاً پیک‌های ماه پایان مالی) واقعاً حیاتی است.

# فعال‌سازی Enhanced Infrastructure Metrics فقط برای aggregation-level خاص
aws compute-optimizer put-recommendation-preferences \
    --resource-type Ec2Instance \
    --scope name=Organization,value=o-abcde12345 \
    --enhanced-infrastructure-metrics Active

چگونه معیارهای حافظه را برای Compute Optimizer فعال کنیم؟

خب، بیایید به یکی از دردسرسازترین کاستی‌های پیش‌فرض بپردازیم. بدون داده حافظه، Compute Optimizer نمی‌تواند تفاوت بین یک اینستنس r6i.xlarge (۳۲GB RAM) و c6i.xlarge (۸GB RAM) را تشخیص دهد و ممکن است توصیه‌های خطرناکی برای بارهای کاری memory-bound بدهد. راه‌حل این است که CloudWatch Agent را روی هر اینستنس نصب کنید و متریک mem_used_percent را به namespace CWAgent ارسال کنید.

روش استاندارد در ۲۰۲۶ استفاده از SSM State Manager association است تا نصب و پیکربندی خودکار روی تمام اینستنس‌های جدید انجام شود:

# پیکربندی CloudWatch Agent برای گزارش mem_used_percent
{
  "metrics": {
    "namespace": "CWAgent",
    "metrics_collected": {
      "mem": {
        "measurement": [
          {"name": "mem_used_percent", "unit": "Percent"}
        ],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": ["used_percent"],
        "resources": ["/"],
        "metrics_collection_interval": 60
      }
    },
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    }
  }
}

# استقرار پیکربندی از طریق SSM Parameter Store + State Manager
aws ssm put-parameter \
    --name "/cloudwatch-agent/config" \
    --type String \
    --value file://cwagent-config.json

aws ssm create-association \
    --name "AWS-ConfigureAWSPackage" \
    --targets "Key=tag:Environment,Values=production" \
    --parameters "action=Install,name=AmazonCloudWatchAgent" \
    --schedule-expression "rate(30 days)"

پس از ۴۸ ساعت جمع‌آوری داده، توصیه‌های Compute Optimizer به‌طور خودکار MEMORY را به عنوان دلیل توصیه در فیلد utilizationMetrics شامل می‌کنند و اطمینان توصیه به‌طرز چشمگیری بالا می‌رود. برای مرور جزئیات پیکربندی، به مستندات نصب CloudWatch Agent نگاه کنید.

خواندن توصیه‌ها: Under-provisioned، Over-provisioned و Optimized

توصیه‌های Compute Optimizer در کنسول تحت EC2 instances نمایش داده می‌شوند اما برای اتوماسیون بهتر است از API استفاده کنید. هر توصیه شامل تا سه گزینه جایگزین است که با ranked by savings مرتب شده‌اند.

# دریافت تمام توصیه‌های EC2 با فرمت خلاصه
aws compute-optimizer get-ec2-instance-recommendations \
    --account-ids 111122223333 \
    --filters name=Finding,values=Overprovisioned \
    --query 'instanceRecommendations[*].{
        Id:instanceArn,
        Current:currentInstanceType,
        Recommended:recommendationOptions[0].instanceType,
        SavingsUSD:recommendationOptions[0].savingsOpportunity.estimatedMonthlySavings.value,
        Risk:recommendationOptions[0].performanceRisk
    }' --output table

خواندن خروجی نیاز به قضاوت دارد. یک توصیه با performanceRisk: 0 و savingsOpportunity: 45% تقریباً همیشه امن است. اما اگر performanceRisk: 3 ببینید، احتمالاً بار کاری spike دارد که در window تحلیل ثبت نشده و باید قبل از اجرا به CloudWatch dashboard اصلی مراجعه کنید.

ساختار سناریوی نمونه

در یک پروژه اخیر، ۱۲۰ اینستنس m5.2xlarge در حال اجرای API worker بودند. Compute Optimizer توصیه کرد به m6i.large کاهش پیدا کنند، یعنی کاهش ۴ برابری اندازه. با تحلیل عمیق‌تر، دیدم CPU در p95 فقط ۱۸ درصد و حافظه در p95 ۳۵ درصد بود. مهاجرت در چند مرحله انجام شد و ۶۸ درصد کاهش هزینه ماهانه (از ۵۴۰۰ دلار به ۱۷۵۰ دلار) به دست آمد بدون هیچ SLA breach. خب، این نتیجه بدی نبود برای دو هفته کار.

توصیه‌های Graviton و محاسبه ROI مهاجرت

یکی از قابلیت‌های قدرتمند Compute Optimizer که کمتر مورد استفاده قرار می‌گیرد، توصیه‌های مهاجرت به Graviton است. با فعال‌سازی گزینه --recommendation-preferences، سرویس معادل‌های Graviton برای اینستنس‌های x86 فعلی شما پیشنهاد می‌دهد.

# فعال‌سازی توصیه‌های Graviton به‌طور صریح
aws compute-optimizer put-recommendation-preferences \
    --resource-type Ec2Instance \
    --scope name=Organization,value=o-abcde12345 \
    --inferred-workload-types Active

# فیلتر توصیه‌های شامل خانواده Graviton
aws compute-optimizer get-ec2-instance-recommendations \
    --query 'instanceRecommendations[?
        contains(recommendationOptions[0].instanceType, `g.`) ||
        contains(recommendationOptions[0].instanceType, `7g`)
    ]'

Graviton3 (خانواده‌های m7g، c7g، r7g) در بنچمارک‌های AWS Graviton بین ۲۰ تا ۴۰ درصد قیمت-عملکرد بهتری نسبت به Intel/AMD ارائه می‌دهد. اما قبل از مهاجرت این چک‌لیست را بررسی کنید:

• آیا تمام باینری‌های وابسته (مثل ffmpeg، mysql client، custom C++ modules) نسخه ARM64 دارند؟
• آیا ایمیج‌های کانتینر با --platform linux/arm64 ساخته می‌شوند؟
• آیا AMI پایه شما (مثل Amazon Linux 2023) ARM64 پشتیبانی می‌کند؟
• آیا Java workloads از JVM ۱۱+ استفاده می‌کنند (JVM ۸ عملکرد ضعیف‌تری روی ARM دارد)؟

در تجربه من، مهاجرت stateless microservices به Graviton به‌طور متوسط ۳ روز کار مهندسی می‌برد و بازگشت سرمایه (ROI) در کمتر از یک ماه محقق می‌شود. صادقانه، این یکی از کم‌ریسک‌ترین کارهایی است که می‌توانید انجام دهید، به شرطی که pipeline بیلد شما multi-arch را ساده کرده باشد.

Compute Optimizer برای Lambda، EBS و Auto Scaling Groups

Compute Optimizer فقط EC2 نیست. سه دامنه دیگر که اغلب فراموش می‌شوند:

Lambda Functions

سرویس حافظه اختصاص‌یافته توابع Lambda را تحلیل می‌کند و توصیه می‌دهد چه مقدار حافظه بدهید تا نسبت هزینه-عملکرد بهینه شود. برخلاف تصور رایج، افزایش حافظه Lambda گاهی هزینه را کاهش می‌دهد زیرا CPU proportionally با حافظه scale می‌شود و زمان اجرا کوتاه می‌شود.

aws compute-optimizer get-lambda-function-recommendations \
    --filters name=Finding,values=NotOptimized \
    --query 'lambdaFunctionRecommendations[*].{
        Function:functionArn,
        CurrentMemory:currentMemorySize,
        RecommendedMemory:memorySizeRecommendationOptions[0].memorySize,
        Reason:finding
    }'

EBS Volumes

برای gp2 volumes، Compute Optimizer معمولاً مهاجرت به gp3 را با کاهش ۲۰٪ هزینه توصیه می‌کند. برای io1/io2 volumes، توصیه‌های کاهش IOPS در صورت under-utilization ارائه می‌شود.

Auto Scaling Groups

توصیه‌های ASG جالب هستند زیرا سرویس ترکیب نوع اینستنس‌ها را در mixed instances policy تحلیل می‌کند و Spot Instance opportunity را برجسته می‌کند. اگر می‌خواهید صرفه‌جویی بیشتری داشته باشید، این را با راهنمای بهینه‌سازی هزینه Kubernetes ترکیب کنید که Karpenter را برای بارهای کاری K8s معرفی می‌کند.

ترکیب Right-sizing با Compute Savings Plans

خب، این جایی است که بیشتر تیم‌ها اشتباه می‌کنند: آن‌ها Savings Plans می‌خرند و سپس right-sizing انجام می‌دهند و متوجه می‌شوند تعهد commitment خود را زیاد بستند. ترتیب صحیح دقیقاً برعکس است:

1. هفته ۱–۲: Compute Optimizer را فعال کنید و منتظر داده کامل باشید.
2. هفته ۳–۴: تمام توصیه‌های با performanceRisk ≤ 1 را اعمال کنید (شروع از non-production).
3. هفته ۵–۶: پس از تثبیت هزینه on-demand جدید، Compute Savings Plans به میزان ۷۰ تا ۸۰ درصد از baseline خریداری کنید.

این رویکرد صرفه‌جویی مرکب می‌سازد. یک مثال واقعی از فلوت ۳۰۰ اینستنسه:

مرحله	هزینه ماهانه (USD)	کاهش تجمعی
Baseline (On-demand، اندازه اولیه)	۴۲٬۰۰۰	مرجع
پس از right-sizing (بدون commit)	۲۶٬۵۰۰	۳۷٪
+ Compute Savings Plans 1yr	۱۹٬۰۰۰	۵۵٪
+ Graviton برای بارهای مناسب	۱۵٬۸۰۰	۶۲٪

تفاوت Compute Optimizer با Trusted Advisor و CloudWatch

یکی از سوالات پرتکرار: چرا AWS سه سرویس مختلف برای این کار دارد؟ هر کدام دامنه متفاوتی را پوشش می‌دهد:

ویژگی	Compute Optimizer	Trusted Advisor	CloudWatch
هزینه	رایگان (پایه)	رایگان (پایه، Business+ برای همه چک‌ها)	پرداخت بر اساس متریک
موتور توصیه	ML (Neural Network)	Rule-based	هیچ (فقط داده خام)
نوع منابع	EC2, EBS, Lambda, ASG, ECS	EC2, RDS, ELB, و ۱۰۰+ مورد دیگر	همه سرویس‌های AWS
Right-sizing با ML	بله (اختصاصی)	پایه (فقط CPU threshold)	خیر
پیش‌بینی صرفه‌جویی	دلار دقیق در ماه	عمومی	خیر

خلاصه: از Compute Optimizer برای right-sizing، از Trusted Advisor برای security/reliability best practices، و از CloudWatch برای مانیتورینگ زنده استفاده کنید. برای جزئیات بیشتر، به مستندات رسمی AWS Compute Optimizer مراجعه کنید.

اتوماسیون توصیه‌ها با Terraform و EventBridge

اعمال دستی توصیه‌ها برای بیش از ۵۰ اینستنس عملی نیست. رویکرد pattern-based ما این است:

# EventBridge rule برای تولید هفتگی گزارش
resource "aws_cloudwatch_event_rule" "weekly_report" {
  name                = "compute-optimizer-weekly-export"
  schedule_expression = "cron(0 8 ? * MON *)"
}

# Lambda function که get-recommendations را فراخوانی می‌کند
# و به S3 export می‌کند برای پردازش با Athena
resource "aws_lambda_function" "export_recommendations" {
  function_name = "co-recommendations-exporter"
  runtime       = "python3.12"
  architectures = ["arm64"]  # Graviton برای Lambda نیز!
  memory_size   = 512
  timeout       = 300

  environment {
    variables = {
      OUTPUT_BUCKET = aws_s3_bucket.recommendations.id
      MIN_SAVINGS   = "50"  # فقط توصیه‌های بیش از ۵۰ دلار در ماه
    }
  }
}

سپس با Athena می‌توانید توصیه‌ها را با داده Cost and Usage Report (CUR) join کنید تا اولویت‌بندی مبتنی بر بازگشت سرمایه بسازید. برای درک عمیق‌تر معماری CUR، راهنمای AWS Cost and Usage Report نقطه شروع خوبی است.

دقت توصیه‌ها چقدر است و چه زمانی نباید به آن‌ها اعتماد کرد؟

Compute Optimizer در تحقیق داخلی AWS ادعای دقت ۹۵٪ برای توصیه‌های high-confidence دارد، اما تجربه میدانی من نشان می‌دهد این عدد به شدت به کیفیت داده ورودی وابسته است. سناریوهایی که باید محتاط بود:

• بارهای کاری فصلی: اگر پیک فصلی خارج از window ۱۴ روزه باشد، توصیه احتمالاً اندازه را زیر پیک تخمین می‌زند. راه‌حل: Enhanced Infrastructure Metrics فعال کنید تا window به ۹۳ روز برسد.
• بارهای کاری Burst: اینستنس‌های خانواده T (T2, T3, T4g) بر اساس credit system کار می‌کنند و ممکن است الگوریتم CPU baseline vs burst را اشتباه تفسیر کند.
• Batch processing کوتاه: jobهای زیر ۱۰ دقیقه در متریک‌های ۵ دقیقه‌ای CloudWatch به‌درستی ثبت نمی‌شوند. معیارهای detailed monitoring (۱ دقیقه‌ای) را فعال کنید.
• GPU workloads: Compute Optimizer معیارهای GPU utilization را نمی‌بیند. برای این موارد، به راهنمای بهینه‌سازی هزینه GPU در ابر مراجعه کنید.

قانون طلایی من: هرگز یک توصیه را روی بیش از ۱۰٪ فلوت به‌طور همزمان اعمال نکنید. با ۱ اینستنس canary شروع کنید، ۷۲ ساعت مانیتور کنید (شامل یک weekend cycle)، سپس گسترش دهید. این تنها روشی است که اطمینان می‌دهم شب‌ها با آرامش بخوابم.

سوالات متداول

آیا AWS Compute Optimizer رایگان است؟

بله، سرویس پایه Compute Optimizer برای تمام حساب‌های AWS رایگان است. تنها هزینه اختیاری مربوط به Enhanced Infrastructure Metrics است که ۰٫۰۰۳۳۶۹ دلار به ازای هر منبع در ماه هزینه دارد و window تحلیل را از ۱۴ روز به ۹۳ روز افزایش می‌دهد.

Compute Optimizer پس از چه مدت اولین توصیه‌ها را ارائه می‌دهد؟

حداقل ۳۰ ساعت داده CloudWatch نیاز است، اما توصیه‌های با اطمینان High معمولاً پس از ۷ تا ۱۴ روز کامل تولید می‌شوند. اگر تازه CloudWatch Agent را برای معیارهای حافظه نصب کرده‌اید، ۴۸ ساعت اضافی برای تجمع داده حافظه لازم است.

آیا می‌توانم توصیه‌های Graviton را غیرفعال کنم؟

بله. از طریق put-recommendation-preferences با تنظیم preferred-resources می‌توانید خانواده‌های اینستنس خاصی را از توصیه‌ها حذف کنید. این برای تیم‌هایی مفید است که هنوز آماده مهاجرت به ARM64 نیستند.

تفاوت Compute Optimizer با AWS Cost Explorer's rightsizing recommendations چیست؟

Cost Explorer rightsizing recommendations فقط اینستنس‌های idle یا very-underutilized (CPU زیر ۱٪) را شناسایی می‌کند و از rule-based logic استفاده می‌کند. Compute Optimizer از یادگیری ماشین استفاده می‌کند، Lambda و EBS را نیز پوشش می‌دهد، و توصیه‌های upgrade به Graviton یا نسل جدیدتر می‌دهد.

آیا Compute Optimizer با Reserved Instances موجود من در تضاد است؟

خیر، اما نیاز به دقت دارد. اگر RI با scope=region دارید (نه AZ)، right-sizing به اندازه کوچک‌تر باعث تخصیص خودکار تخفیف به سایر اینستنس‌های مشابه می‌شود. برای RI با scope=AZ یا Convertible RI، ممکن است لازم باشد پس از right-sizing، RI را exchange کنید تا از waste جلوگیری شود.