دليل عملي لتفعيل AWS Compute Optimizer على مستوى Organizations، وقراءة توصياته لـ EC2 وEBS وLambda وGraviton، وأتمتة تطبيقها عبر EventBridge وSSM لخفض فاتورة AWS بنسبة تصل إلى 45% دون تأثير على الأداء.
آخر تحديث: 22 أغسطس 2026
AWS Compute Optimizer هو محرك توصيات مجاني من AWS يستخدم التعلم الآلي لتحليل استخدام موارد EC2 وAuto Scaling Groups وEBS وLambda وECS on Fargate، ثم يقترح تغييرات محددة (نوع المثيل، حجم القرص، ذاكرة Lambda) توفر عادةً بين 20% و45% من فاتورتك دون التأثير على الأداء. في هذا الدليل سأشرح لك كيف أفعّله عبر المؤسسة، كيف أفسر توصياته، وكيف أطبقها تلقائيًا عبر EventBridge وSystems Manager، مع أرقام حقيقية من عمليات ترحيل نفّذتها بنفسي خلال 2026.
AWS Compute Optimizer خدمة توصيات مستقلة أطلقتها AWS عام 2019، وتوسّعت تدريجيًا حتى وصلت في 2026 إلى تغطية سبع فئات من الموارد: EC2 instances، وAuto Scaling Groups، وEBS volumes، وLambda functions، وECS services on Fargate، وRDS DB instances (Preview موسّع)، بالإضافة إلى Idle resource detection. تعتمد الخدمة على تحليل مقاييس CloudWatch (CPU، Memory، Network، Disk IOPS) على مدى 14 يومًا افتراضيًا، ثم تُشغّل نموذج تعلم آلي مُدرَّب على ملايين مثيلات AWS لتحديد أنواع الأجهزة المكافئة أو الأصغر التي تستوعب حمل عملك.
ما يميز Compute Optimizer عن أدوات الحجم الصحيح التقليدية أنه لا يعتمد فقط على قواعد ثابتة مثل «إذا كان CPU أقل من 40% خفّض النوع بمقدار درجة». بدلاً من ذلك، يبحث عن المثيل المكافئ في عائلات مختلفة (m5 ← m6i ← m7i ← m7g)، ويقارن نسبة السعر إلى الأداء لكل خيار. صراحة، أول مرة شغّلته على أحد أعباء عملي في 2026، اقترح ترحيل مجموعة m5.2xlarge إلى m7g.xlarge (Graviton) مع خفض النواة إلى النصف. النتيجة؟ وفّر ذلك 38% دون أي تدهور في زمن الاستجابة p99.
البيانات المُحلَّلة تشمل بشكل افتراضي CPUUtilization وNetworkIn/Out وDiskReadOps/WriteOps من CloudWatch. لتوصيات دقيقة للذاكرة يجب تثبيت CloudWatch agent وتفعيل mem_used_percent، لأن Hypervisor لا يرى استخدام ذاكرة الضيف. هذه الخطوة مهمة جدًا؛ بدونها ستحصل على توصيات محافظة تُقلّل التوفير بنسبة قد تصل إلى 15%.
نعم، التوصيات القياسية في Compute Optimizer مجانية بالكامل. تشمل هذه التوصيات تحليل EC2 وASGs وEBS وLambda وECS on Fargate اعتمادًا على 14 يومًا من مقاييس CloudWatch الأساسية. الشيء الوحيد المدفوع هو ميزة Enhanced Infrastructure Metrics، التي تكلف 0.0003360215 دولار لكل ساعة مثيل EC2 عند تفعيلها، وتوسّع نافذة التحليل إلى 93 يومًا بدلاً من 14، وتلتقط أنماط الحمل الأسبوعية والشهرية (نهاية الشهر، أيام الجمعة السوداء، إلخ).
هل تستحق Enhanced Metrics؟ في تجربتي: نعم للأحمال ذات الموسمية الواضحة (تجارة إلكترونية، بث، معالجة رواتب شهرية)، ولا للأحمال ذات الحمل الثابت. لحساب مثيل m5.xlarge يعمل 730 ساعة/شهر، التكلفة الإضافية تقريبًا 0.245 دولار/شهر، أي أقل من 0.2% من فاتورة المثيل نفسه. اقتصاديًا مبرّر تمامًا، خصوصًا حين يمنعك من ترحيل خاطئ أثناء ذروة موسمية.
راجع تفاصيل التسعير المحدّثة في صفحة تسعير AWS Compute Optimizer الرسمية. تختلف الأسعار قليلاً بين المناطق، ومنطقة af-south-1 مثلاً أعلى بنسبة 10% من us-east-1.
لتفعيل Compute Optimizer على مستوى المؤسسة بأكملها بحساب واحد مركزي، تحتاج إلى حساب إدارة (Management Account) أو تفويض حساب مسؤول عبر Delegated Administrator. الميزة الحاسمة هنا أن التوصيات تظهر مجمعة في مكان واحد بدل الحاجة لتسجيل الدخول لكل حساب. الأمر التالي يفعّل الخدمة عبر جميع الحسابات:
# 1) من حساب الإدارة، تفعيل Compute Optimizer كخدمة موثوقة داخل Organizations
aws organizations enable-aws-service-access \
--service-principal compute-optimizer.amazonaws.com
# 2) تفويض حساب FinOps مسؤولاً عن Compute Optimizer (اختياري لكن موصى به)
aws compute-optimizer put-delegated-administrator \
--account-id 111122223333
# 3) من حساب FinOps المفوّض، الاشتراك على مستوى المؤسسة
aws compute-optimizer update-enrollment-status \
--status Active \
--include-member-accounts
# 4) التحقق من حالة الاشتراك عبر الحسابات
aws compute-optimizer get-enrollment-statuses-for-organization \
--query 'accountEnrollmentStatuses[?status==`Active`].[accountId,status]' \
--output table
بعد التفعيل، يحتاج Compute Optimizer إلى 12 ساعة على الأقل لجمع بيانات كافية قبل ظهور أول توصية. للحصول على أعلى دقة، انتظر 14 يومًا كاملة. راجع تفاصيل الأذونات الدقيقة في دليل AWS Compute Optimizer الرسمي.
يصنّف Compute Optimizer كل مثيل EC2 إلى إحدى أربع فئات: Under-provisioned (المثيل صغير جدًا لحمله)، وOver-provisioned (كبير جدًا)، وOptimized (مناسب)، أو Not optimized (يحتاج تغيير عائلة). لكل توصية يقدم النظام حتى ثلاثة خيارات مرتبة حسب «Performance risk» من 1 (مخاطر منخفضة) إلى 5 (مخاطر عالية)، مع تقدير للتوفير الشهري.
لجلب جميع توصيات EC2 عبر CLI مع فلترة على تلك التي توفر أكثر من 20%:
aws compute-optimizer get-ec2-instance-recommendations \
--filters name=Finding,values=Overprovisioned \
--query 'instanceRecommendations[?recommendationOptions[0].estimatedMonthlySavings.value > `20`].{
Instance: instanceArn,
Current: currentInstanceType,
Recommended: recommendationOptions[0].instanceType,
Savings: recommendationOptions[0].estimatedMonthlySavings.value,
Risk: recommendationOptions[0].performanceRisk
}' \
--output table
الحقل performanceRisk يستحق الاهتمام: قيمة 1 تعني أن Compute Optimizer واثق بنسبة أعلى من 95% أن التوصية آمنة، بينما قيمة 4 أو 5 تعني أن هناك تباينًا في الحمل (bursts) قد يتأثر بالتغيير. سياستي الشخصية؟ طبّق تلقائيًا كل توصية بمخاطر ≤ 2، وراجع يدويًا 3، واختبر في staging لأي شيء ≥ 4.
ميزة أضيفت في 2026 هي Migration effort، التي تصنّف صعوبة الترحيل (Low/Medium/High) بناءً على تغييرات معمارية محتملة. على سبيل المثال، الانتقال من x86 إلى Graviton يُصنّف Medium لأنه قد يتطلب إعادة بناء الحاويات، بينما الانتقال من m5 إلى m6i يُصنّف Low لأنه شفاف تمامًا.
هذه أسهل مكسب سريع في AWS في 2026. أعلنت AWS منذ 2020 أن gp3 توفر نفس أداء gp2 (IOPS وthroughput) بسعر أقل بنسبة 20%، لكن كثيرًا من المؤسسات لم تُنفّذ الترحيل لأنه غير أوتوماتيكي. Compute Optimizer يُظهر لك بالضبط أي أقراص gp2 يجب ترحيلها ويقدر التوفير.
الترحيل نفسه غير مُعطِّل، ويتم مباشرة عبر modify-volume دون إعادة تشغيل. سكربت للترحيل الجماعي بناءً على توصيات Compute Optimizer:
#!/bin/bash
# ترحيل جميع أقراص gp2 التي أوصى Compute Optimizer بتحويلها إلى gp3
aws compute-optimizer get-ebs-volume-recommendations \
--filters name=Finding,values=NotOptimized \
--query 'volumeRecommendations[?volumeRecommendationOptions[0].configuration.volumeType==`gp3`].volumeArn' \
--output text | tr '\t' '\n' | while read arn; do
VOLUME_ID=$(echo $arn | awk -F'/' '{print $NF}')
echo "Migrating $VOLUME_ID from gp2 to gp3..."
aws ec2 modify-volume \
--volume-id "$VOLUME_ID" \
--volume-type gp3 \
--iops 3000 \
--throughput 125
# الانتظار حتى يكتمل التعديل قبل التالي (لتجنب حدود API)
aws ec2 wait volume-in-use --volume-ids "$VOLUME_ID"
sleep 2
done
ملاحظة مهمة: القيم الافتراضية لـ gp3 هي 3000 IOPS و125 MB/s throughput، وهي مجانية. إذا كان قرص gp2 القديم أكبر من 1TB، فسيوفر لك gp3 حتى مع IOPS إضافية مدفوعة (لأن gp2 يربط IOPS بحجم القرص). راجع توصيات Compute Optimizer بعناية، فهي تحسب لك النقطة الاقتصادية المثلى.
Lambda مثال كلاسيكي على الحدس المضلل: زيادة الذاكرة قد تُقلّل التكلفة لأن CPU مرتبط خطيًا بالذاكرة، فمعالجة أسرع تعني وقت تشغيل أقصر يعني فاتورة أقل. Compute Optimizer يحلل استدعاءات Lambda الفعلية ويقترح إعداد الذاكرة الأمثل بين 128 MB و10240 MB.
لكي تعمل التوصيات، تحتاج الدالة إلى ما لا يقل عن 50 استدعاءً خلال 14 يومًا. لجلب توصيات Lambda:
aws compute-optimizer get-lambda-function-recommendations \
--query 'lambdaFunctionRecommendations[?finding!=`Optimized`].{
Function: functionArn,
CurrentMB: currentMemorySize,
RecommendedMB: memorySizeRecommendationOptions[0].memorySize,
SavingsPct: memorySizeRecommendationOptions[0].savingsOpportunity.savingsOpportunityPercentage
}' \
--output table
في مؤسسة تعمل معها، وجد Compute Optimizer أن 340 من أصل 890 دالة Lambda كانت Over-provisioned بذاكرة 1024 MB بينما 512 MB كافية، والتوفير الشهري المتوقع كان 4700 دولار. لكن الأهم؟ اكتشف 27 دالة Under-provisioned (128 MB) كان يجب رفعها إلى 512 MB، مما رفع سرعتها 3× وخفّض تكلفتها في نفس الوقت بسبب زمن تشغيل أقصر.
أضافت AWS في 2023 توصيات الانتقال إلى معالجات Graviton (ARM64) داخل Compute Optimizer، وتوسّعت في 2026 لتشمل m7g وc7g وr7g وx2gd. تقدم Graviton في المتوسط تحسنًا في نسبة السعر إلى الأداء بنسبة 40% مقابل مثيلات x86 المكافئة. لا تعتبرها «قفزة إيمان»؛ Compute Optimizer يعرض احتمالية النجاح المستندة إلى تحليل استخدام CPU الفعلي وأنماط SIMD.
سكربت لاستخراج جميع التوصيات التي تقترح Graviton مع مقارنة تفصيلية:
aws compute-optimizer get-ec2-instance-recommendations \
--query 'instanceRecommendations[?recommendationOptions[?instanceType && contains(instanceType, `g.`) == `true`]].{
Current: currentInstanceType,
GravitonOption: recommendationOptions[?contains(instanceType, `g.`)] | [0].instanceType,
SavingsUSD: recommendationOptions[?contains(instanceType, `g.`)] | [0].estimatedMonthlySavings.value,
MigrationEffort: recommendationOptions[?contains(instanceType, `g.`)] | [0].migrationEffort
}' \
--output table
قبل الترحيل، تحقق من أن حاوياتك مبنية multi-arch عبر docker buildx، وأن اعتمادياتك (وخاصة أدوات npm الأصلية وjni وbindings لـ Python) لها بناء ARM64. راجع صفحة AWS Graviton الرسمية للحصول على قائمة الأعباء المتوافقة وأفضل ممارسات الترحيل، ودراسات حالة موثقة (Twitter وSnap وDatadog، جميعها هاجرت أعباء إنتاجية كاملة).
مسح Compute Optimizer دون تطبيق يعني أن التوفير يبقى على الورق. البنية العملية التي أنشرها لعملائي: Compute Optimizer ← S3 Export ← Lambda مُشغَّل بجدول EventBridge ← Systems Manager Automation Runbook ← تنفيذ التغيير أثناء نافذة الصيانة.
الخطوة الأولى: تصدير التوصيات إلى S3 يوميًا كي يمكن معالجتها:
aws compute-optimizer export-ec2-instance-recommendations \
--s3-destination-config bucket=finops-recommendations-2026,keyPrefix=daily/ec2/ \
--file-format Csv \
--fields-to-export CurrentInstanceType RecommendationOptionsInstanceType \
RecommendationOptionsEstimatedMonthlySavingsValue \
RecommendationOptionsPerformanceRisk AccountId
الخطوة الثانية: قاعدة EventBridge تُشغّل Lambda كل ليلة السبت، والدالة تقرأ CSV وتُصدر تعليمات StartAutomationExecution إلى AWS-ResizeInstance runbook فقط للتوصيات ذات performanceRisk ≤ 2 وsavings ≥ 50 دولار شهريًا. المثيلات الحرجة (وسم Environment=production-critical) تُستثنى تلقائيًا وتُرسل إلى Slack للموافقة اليدوية.
الأمان: استخدم علامات AWS لتطبيق الأتمتة فقط على الموارد ذات AutoRightsizing=enabled. هذا يمنع التعديل غير المقصود على أعباء غير موصفة. راجع مقالنا حول علامات توزيع التكاليف في AWS 2026 لبنية علامات قابلة للتوسع.
سؤال أتلقاه أسبوعيًا من الفرق التي تبدأ مع FinOps: «لدينا Trusted Advisor، هل نحتاج Compute Optimizer؟». الإجابة: نعم، فالأدوات تكمّل بعضها. يعرض الجدول التالي الفروق الحقيقية:
| الميزة | Compute Optimizer | Trusted Advisor | Cost Explorer Rightsizing |
|---|---|---|---|
| التسعير | مجاني (Enhanced Metrics مدفوع) | مجاني في الأساس، ميزات كاملة مع Business Support | مجاني |
| عمق تحليل EC2 | ML وتوصيات عبر عائلات (Graviton) | قواعد ثابتة (CPU < 10% لـ 14 يوم) | توصيات على مستوى العائلة فقط |
| دعم EBS | نعم (gp2←gp3، io1←io2) | حجم فقط (Under-utilized) | لا |
| دعم Lambda | نعم (تحسين الذاكرة) | لا | لا |
| توصيات Graviton | نعم (منذ 2023) | لا | لا |
| عبر Organizations | نعم (Delegated Admin) | نعم | نعم |
| نافذة التحليل | 14 يوم افتراضيًا، 93 يوم مع Enhanced | 14 يوم | 14 يوم |
سير عملي الشخصي: أستخدم Cost Explorer للاتجاهات الشهرية والتنبؤات، وTrusted Advisor للفحوصات الأمنية والحدود، وCompute Optimizer كمصدر الحقيقة الوحيد لقرارات الحجم الصحيح. للاستفادة القصوى، ادمج توصيات الحجم الصحيح مع استراتيجية الالتزام. راجع مقارنتنا التفصيلية بين AWS Spot Instances كتكميل لخفض تكلفة الأحمال المرنة بعد الحجم الصحيح.
هذه الأخطاء رأيتها في كل عملية اعتماد قمت بها تقريبًا، وتجنّبها يوفر عليك أشهرًا من إعادة العمل:
mem_used_percent يفترض Compute Optimizer الأسوأ حالة للذاكرة، وتصبح توصياته محافظة جدًا. ثبّت CloudWatch agent عبر SSM State Manager على كل مثيل.نعم، منذ 2024 توسع Compute Optimizer ليشمل توصيات RDS DB instances لمحركات MySQL وPostgreSQL وMariaDB. يحلل CPU وMemory وIOPS ويقترح تغيير الفئة (db.r6i ← db.r7g)، مع دعم توصيات Graviton لخفض التكلفة بنسبة تصل إلى 40%. الميزة عامة اعتبارًا من 2026 وتُفعّل تلقائيًا مع Compute Optimizer.
يحتاج إلى 12 ساعة على الأقل بعد التفعيل لجمع بيانات كافية، لكن التوصيات الموثوقة تظهر عادة بعد 14 يومًا كاملة لأنها المدة الافتراضية لتحليل مقاييس CloudWatch. لأعباء ذات أنماط موسمية، فعّل Enhanced Infrastructure Metrics لتحصل على تحليل 93 يومًا وتوصيات أكثر دقة.
Compute Optimizer يعرض توصيات على مستوى تعريف Auto Scaling Group بصرف النظر عن نوع الشراء (On-Demand/Spot). لكنه لا يوصي بالتحويل بين Spot وOn-Demand، فهذا قرار استراتيجي منفصل. استخدم توصيات Compute Optimizer لتحديد نوع المثيل الأمثل أولاً، ثم فكّر في Spot لتلك الأحمال المرنة.
Trusted Advisor يعتمد على قواعد ثابتة (CPU < 10% لمدة 14 يومًا يُصنّف Idle)، بينما Compute Optimizer يستخدم نماذج ML لاقتراح مثيلات مكافئة عبر عائلات مختلفة، بما فيها Graviton. Compute Optimizer أعمق بكثير، ويدعم Lambda وEBS وgp2←gp3 التي لا يغطيها Trusted Advisor. الأول لتوصيات دقيقة، والثاني لفحوصات صحة عامة.
نعم، عبر تصدير التوصيات إلى S3 يوميًا، ثم Lambda يقرأ الملف ويستدعي Systems Manager Automation runbook مثل AWS-ResizeInstance أو AWS-ModifyEBSVolume. الأفضل تطبيق فلاتر: performanceRisk ≤ 2، وتوفير ≥ 50$ شهريًا، ووسم AutoRightsizing=enabled. البيئات الحرجة يجب أن ترسل إلى قناة موافقة يدوية.
عمومًا نعم، فـ Compute Optimizer يفحص بصمة استخدام CPU الفعلية قبل التوصية. لكن قبل التطبيق تحقق من: (1) بناء متعدد المعمارية للحاويات عبر docker buildx، (2) توفر مكتبات ARM64 لجميع الاعتماديات الأصلية، (3) اختبار الأداء في بيئة staging. الترحيل يحقق عادة توفيرًا 20-40% لكن يتطلب جهد Medium حسب تصنيف Migration effort في التوصية.
تعلم كيف توفر حتى 90% على تكاليف AWS Spot Instances في 2026 مع استراتيجيات التعامل الذكي مع الانقطاعات وأكواد عملية جاهزة للتطبيق الفوري.