AWS Savings Plans vs RIs: دليل 2026

لنكن صريحين للحظة: إذا كنت تدير عبء عمل ثابتاً على AWS وما زلت تدفع أسعار On-Demand، فأنت ببساطة تترك ما بين 30% و72% من فاتورتك على الطاولة. وهذا ليس مبالغة. الخيار بين Savings Plans وReserved Instances (RIs) ليس مجرد تفصيل محاسبي تتركه لفريق المالية؛ بل هو قرار استراتيجي يحدد مرونة بنيتك التحتية لثلاث سنوات قادمة.

لقد رأيتُ شركات تخسر أكثر من 200,000$ سنوياً لمجرد أنها اشترت RI الخطأ في الوقت الخطأ. والمؤلم في الأمر أن القرار كان يمكن تجنبه بساعتين من التحليل.

في هذا الدليل لعام 2026، سنفكك الفروق الجوهرية بين الخيارين بأرقام وأمثلة حسابية حقيقية، وسنقدم لك إطار قرار عملي (وليس نظرياً)، مع أكواد CLI جاهزة للاستخدام لشراء وإدارة الالتزامات.

لماذا تهم Savings Plans و RIs أكثر من أي وقت مضى في 2026؟

وفقاً لتقرير Flexera State of the Cloud 2026، يُهدر 32% من الإنفاق السحابي في المؤسسات الكبيرة. ثلث الفاتورة. تخيل ذلك. وقد رفعت AWS أسعار العديد من فئات EC2 بنسبة 3-7% في يناير 2026 (نعم، حتى السحابة لم تنجُ من التضخم)، ما يجعل خصومات الالتزام (Commitment Discounts) السلاح الأكثر فعالية لتخفيف الأثر.

الخصم الأقصى لعام 2026 يصل إلى:

Standard RIs لمدة 3 سنوات (دفع كامل مقدماً): حتى 72%
EC2 Instance Savings Plans لمدة 3 سنوات: حتى 72%
Compute Savings Plans لمدة 3 سنوات: حتى 66%
Convertible RIs لمدة 3 سنوات: حتى 54%
التزام سنة واحدة (جميع الأنواع): 28-43%

ما هي Reserved Instances؟

Reserved Instances هي ببساطة التزام بدفع رسوم محددة مسبقاً مقابل استخدام نوع معين من EC2 (مثل m6i.large) في منطقة محددة لمدة سنة أو ثلاث سنوات. وهي تنقسم إلى نوعين رئيسيين، ولكل منهما شخصيته الخاصة:

Standard Reserved Instances

توفر أعلى نسبة خصم (تصل إلى 72%) لكنها مقيدة بفئة Instance ومنطقة محددة. يمكنك تعديل بعض الخصائص (مثل Availability Zone والحجم داخل نفس العائلة لـ Linux)، لكن لا يمكنك تغيير العائلة أو نظام التشغيل. باختصار: خصم رائع، مرونة محدودة.

Convertible Reserved Instances

تسمح بتبديل خصائص Instance خلال فترة الالتزام (تغيير العائلة، نظام التشغيل، Tenancy)، مقابل خصم أقل (حتى 54%). مفيدة عندما تتوقع تغير احتياجاتك التقنية، لكن صدقني، في معظم الحالات، Compute Savings Plans أصبحت تتفوق عليها.

خيارات الدفع للـ RIs

All Upfront (دفع كامل مقدماً): أعلى خصم
Partial Upfront (دفع جزئي): خصم متوسط
No Upfront (بدون دفعة مقدمة): أقل خصم لكن بدون رأس مال أولي

ما هي Savings Plans؟

أطلقت AWS خدمة Savings Plans في 2019 كبديل أكثر مرونة للـ RIs، وكانت — بصراحة — استجابة طال انتظارها لشكاوى عملاء المؤسسات. الفكرة بسيطة: أنت تلتزم بإنفاق مبلغ بالدولار في الساعة (مثلاً 10$/ساعة) لمدة سنة أو 3 سنوات، وتحصل على خصم تلقائي على أي استخدام مشمول. هناك ثلاثة أنواع رئيسية:

Compute Savings Plans (الأكثر مرونة)

يغطي EC2 وFargate وLambda عبر جميع المناطق وجميع العائلات وجميع أنظمة التشغيل. الخصم يصل إلى 66%، وهو أقل من EC2 SP بست نقاط مئوية، لكنه الخيار الأمثل عندما تكون خططك المعمارية متغيرة (وأي شركة لا تعتقد أنها متغيرة، تكذب على نفسها غالباً).

EC2 Instance Savings Plans

مقتصر على عائلة Instance محددة في منطقة محددة (مثل m6i في us-east-1)، لكنه يسمح بتغيير الحجم ونظام التشغيل والـ Tenancy. خصم يصل إلى 72% — مساوٍ تقريباً للـ Standard RIs.

SageMaker Savings Plans

مخصص لأعباء التعلم الآلي على Amazon SageMaker، بخصم يصل إلى 64%. ضروري إذا كنت تشغل تدريباً مستمراً أو نقاط نهاية inference دائمة. ومع ازدهار LLMs في 2026، أصبح هذا النوع من SP تقريباً إلزامياً لأي فريق ML جاد.

المقارنة الشاملة: Savings Plans vs Reserved Instances في 2026

الجدول التالي يلخص الفروق الجوهرية (احفظه في bookmarks، ستعود إليه كثيراً):

المعيار	Standard RI	Convertible RI	EC2 Instance SP	Compute SP
أقصى خصم (3 سنوات)	72%	54%	72%	66%
تغيير العائلة (Family)	لا	نعم	لا	نعم
تغيير المنطقة (Region)	لا	نعم	لا	نعم
يشمل Fargate / Lambda	لا	لا	لا	نعم
إمكانية البيع في AWS Marketplace	نعم	لا	لا	لا
التزام بالساعة بالدولار	لا (التزام بـ Instance)	لا	نعم	نعم
Capacity Reservation	نعم (إقليمي/Zone)	نعم (إقليمي/Zone)	لا	لا

متى تختار Reserved Instances؟

اختر RIs في الحالات التالية (وفقط في هذه الحالات، لتجنب الندم لاحقاً):

تحتاج Capacity Reservation مضمون: إذا كنت تشغل عبء عمل في منطقة عالية الطلب (مثل Tokyo) وتخشى نفاد السعة، فالـ Zonal RI يضمن لك حجز السعة فعلياً. هذه قصة طويلة عشتُها بنفسي عام 2024 — لن أعيدها.
عبء العمل ثابت ومتوقع لمدة 3 سنوات: قاعدة بيانات RDS Production، Domain Controllers، أو خوادم تطبيق ذات تكوين ثابت لا يتغير.
قد تحتاج لبيع الالتزام لاحقاً: Standard RIs قابلة للبيع في AWS Marketplace (للحسابات الأمريكية فقط)، بينما Savings Plans غير قابلة للإلغاء أو البيع نهائياً.
RDS, ElastiCache, Redshift, OpenSearch: هذه الخدمات لا تدعم Savings Plans حتى الآن، لذا الـ RI هو الخيار الوحيد المتاح. لا حول ولا قوة.

متى تختار Savings Plans؟

Savings Plans هي الخيار الافتراضي للأغلبية في 2026، خاصة في الحالات التالية:

بنية تحتية متطورة: تخطط للانتقال من m5 إلى m7i أو من x86 إلى Graviton — Compute SP يتبعك تلقائياً دون أي إجراء يدوي.
تستخدم Lambda أو Fargate: Compute SP يغطيهما، بينما RIs لا. هذا الفرق وحده يكفي لقلب القرار.
أعباء عبر مناطق متعددة: فريق DR في us-west-2 وفريق Production في us-east-1 — Compute SP ينطبق على كليهما.
تريد تجنب إدارة محفظة معقدة: 100 RI تحتاج تتبعاً يدوياً (وكوابيس Excel)، بينما SP واحد يغطي كل شيء.

أمثلة حسابية بأسعار 2026

المثال 1: شركة SaaS متوسطة الحجم

الإنفاق الحالي On-Demand: 50,000$ شهرياً على EC2 (موزعة بين m6i, c6i, r6i في us-east-1). شركة حقيقية، أسماء مغيرة:

الخيار	التزام بالساعة	الخصم	التكلفة الشهرية	التوفير السنوي
On-Demand	—	0%	50,000$	—
Compute SP (3 سنوات، No Upfront)	~57$/h	~50%	25,000$	300,000$
EC2 SP (3 سنوات، All Upfront)	~46$/h	~60%	20,000$	360,000$
Standard RI (3 سنوات، All Upfront)	—	~62%	19,000$	372,000$

الفرق بين Compute SP و Standard RI هو 72,000$ سنوياً. يبدو رقماً كبيراً، أليس كذلك؟ لكن إذا قررت ترقية أسطولك من m6i إلى m7i في السنة الثانية (وستفعل غالباً، صدقني)، فإن RI يصبح بلا قيمة فعلية بينما SP يستمر في توفير الخصم. التكلفة الحقيقية للمرونة المفقودة قد تبتلع كل ذلك الفارق.

المثال 2: استراتيجية الطبقات (Layered Strategy)

أفضل ممارسة في 2026 هي بناء استراتيجية متعددة الطبقات بدلاً من اختيار نوع واحد. فكّر فيها كأنها محفظة استثمارية:

الطبقة 1 — الأساس (50-60% من الاستخدام): EC2 Instance Savings Plans لمدة 3 سنوات لـ baseline ثابت معروف.
الطبقة 2 — المرونة (20-30%): Compute Savings Plans لمدة سنة واحدة لتغطية النمو والأعباء المتغيرة.
الطبقة 3 — المتذبذبة (10-20%): On-Demand و Spot Instances للذروة وأعباء التطوير.

كيفية شراء Savings Plans عبر AWS CLI

قبل الشراء، استخدم AWS Cost Explorer للحصول على توصية بناءً على استخدامك التاريخي (لا تشتري أبداً دون هذه الخطوة):

aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years THREE_YEARS \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --account-scope PAYER

الإخراج سيعطيك Hourly Commitment الموصى به والتوفير المتوقع. للتحقق من الأسعار قبل الشراء:

aws savingsplans describe-savings-plans-offering-rates \
  --savings-plan-offering-ids <offering-id> \
  --filters name=region,values=us-east-1

لشراء Savings Plan فعلياً (وهنا تحبس أنفاسك للحظة):

aws savingsplans create-savings-plan \
  --savings-plan-offering-id "abc123-def456-..." \
  --commitment "10.00" \
  --upfront-payment-amount "0" \
  --client-token "$(uuidgen)"

للقيد الأمثل، يجب أن تستخدم --client-token فريداً لتجنب الشراء المزدوج عند إعادة المحاولة. هذه نصيحة مكتوبة بدماء فِرَق DevOps حول العالم.

كيفية شراء Reserved Instances عبر AWS CLI

# الخطوة 1: ابحث عن العروض المتاحة
aws ec2 describe-reserved-instances-offerings \
  --instance-type m6i.large \
  --product-description "Linux/UNIX" \
  --offering-type "All Upfront" \
  --availability-zone us-east-1a \
  --filters Name=duration,Values=94608000

# الخطوة 2: اشترِ العرض
aws ec2 purchase-reserved-instances-offering \
  --reserved-instances-offering-id "abc123..." \
  --instance-count 5

قياس الأداء: تتبع تغطية والتزام Savings Plans

هناك مؤشران رئيسيان يجب مراقبتهما أسبوعياً (نعم، أسبوعياً، وليس فقط عند نهاية الربع):

Coverage (التغطية)

نسبة الاستخدام المؤهل المغطى بـ SP. الهدف 70-85%. أعلى من ذلك يعرضك للهدر إذا انخفض الاستخدام، وأقل يعني أنك تترك خصومات على الطاولة.

aws ce get-savings-plans-coverage \
  --time-period Start=2026-04-01,End=2026-04-28 \
  --granularity MONTHLY \
  --metrics SpendCoveredBySavingsPlans

Utilization (الاستخدام)

نسبة التزامك المستخدم فعلياً. يجب أن تكون 95%+. أقل من ذلك يعني أنك تدفع مقابل خصم لا تستهلكه — وهذا أسوأ سيناريو ممكن.

aws ce get-savings-plans-utilization \
  --time-period Start=2026-04-01,End=2026-04-28 \
  --granularity DAILY

الأخطاء الشائعة التي يجب تجنبها

الالتزام بـ 100% من الاستخدام الحالي: أعباء العمل تتقلب. التزام 65-75% من الـ baseline يحمي من الهدر. هذا الخطأ وحده تسبب في إفلاس مشاريع رأيتها بعيني.
تجاهل خطط Graviton: الانتقال من x86 إلى Graviton يوفر 20-40% إضافية. RI x86 يحبس قرارك ويمنعك من الاستفادة.
عدم استخدام Consolidated Billing: SP و RIs تتشارك عبر حسابات الـ Organization تلقائياً، مما يعظّم الاستخدام.
شراء All Upfront دون تحليل تكلفة الفرصة البديلة: الفرق بين All Upfront و No Upfront قد يكون 5-10% فقط، لكنك تحبس مئات الآلاف من رأس المال — رأس مال كان يمكن استثماره في أشياء أهم.
إهمال SageMaker Savings Plans: فرق LLM Inference دون SP يدفعون 60% أكثر دون داعٍ. ولا يكتشفون ذلك إلا عند مراجعة الفاتورة في نهاية الشهر.

أتمتة إدارة Savings Plans في 2026

بدلاً من الشراء اليدوي، فِرَق FinOps الناضجة تستخدم منصات مثل Vantage، ProsperOps، أو Spot.io's Eco التي تشتري SPs لمدة سنة واحدة بشكل دوري متداخل (laddering)، مما يحقق:

خصم أعلى من سنة واحدة دون قفل 3 سنوات.
تجديد تلقائي بناءً على الاستخدام الفعلي.
ضمان استرداد الأموال إذا انخفضت Utilization تحت عتبة معينة.

هذه المنصات تستحوذ على 5-15% من التوفير المحقق، لكنها توفر مرونة لا يمكن تحقيقها يدوياً (وأنا شخصياً أعتبرها استثماراً يدفع نفسه خلال شهرين).

الأسئلة الشائعة (FAQ)

هل يمكن إلغاء Savings Plan بعد الشراء؟

لا. Savings Plans غير قابلة للإلغاء أو البيع أو التعديل بمجرد التفعيل، تماماً مثل Convertible RIs. لذا يجب التحليل الدقيق قبل الشراء، والبدء بالتزامات صغيرة قابلة للنمو.

هل تعمل Savings Plans على Spot Instances؟

لا. Spot Instances لها نموذج تسعير منفصل (خصم تلقائي يصل إلى 90%) ولا تتراكم خصومات SP فوقها. استراتيجياً: استخدم SP لـ baseline والـ Spot للأعباء المرنة.

ما الفرق بين Savings Plans و Compute Savings Plans و EC2 Instance Savings Plans؟

"Savings Plans" مصطلح عام. هناك ثلاثة أنواع: Compute SP (الأكثر مرونة، يغطي EC2 + Fargate + Lambda)، EC2 Instance SP (مقتصر على عائلة ومنطقة، خصم أعلى)، وSageMaker SP (لأعباء التعلم الآلي).

هل تنطبق Savings Plans على RDS و Aurora؟

لا. RDS و Aurora و ElastiCache و Redshift و OpenSearch تدعم فقط Reserved Instances/Reserved Nodes. إذا كانت قواعد بياناتك تشكل جزءاً كبيراً من فاتورتك، فستحتاج إلى استراتيجية مزدوجة: SP للحوسبة و RIs لقواعد البيانات.

هل أحتاج لشراء Savings Plans في كل حساب على حدة؟

لا. عند تفعيل Consolidated Billing في AWS Organizations، تنطبق فوائد SP و RIs تلقائياً عبر جميع الحسابات الفرعية المسجلة. هذا يبسط الإدارة بشكل كبير ويزيد Utilization لأن الالتزام يستفيد من أوسع قاعدة استخدام.

كم من الوقت يستغرق تفعيل Savings Plan؟

يبدأ التفعيل خلال دقائق من الشراء. ستلاحظ بدء تطبيق الخصم في فاتورتك في الساعة التالية. تقارير Cost Explorer قد تتأخر 24-48 ساعة في إظهار التغطية، فلا تقلق إذا لم تَرَ الأرقام فوراً.

الخاتمة

القرار بين Savings Plans و Reserved Instances في 2026 ليس خياراً ثنائياً (أبيض أو أسود)، بل مزيجاً استراتيجياً. ابدأ بـ Compute Savings Plans لمدة سنة واحدة لتغطية 60-70% من baseline، أضف EC2 Instance SP لمدة 3 سنوات للأعباء الأكثر استقراراً، واحتفظ بـ RIs لقواعد البيانات والخدمات غير المدعومة بـ SP.

راقب Coverage و Utilization أسبوعياً، وأعد تقييم الالتزامات كل ربع سنة. مع التطبيق الصحيح، يمكنك تحقيق 40-60% توفيراً مستداماً دون التضحية بالمرونة المعمارية. التوفير الذي تحققه ليس مجرد أرقام في الفاتورة — بل هو رأس مال يمكن إعادة استثماره في الابتكار، في توظيف مهندس إضافي، أو ببساطة في مهلة تنفس مالية لشركتك. اختر بحكمة.