AWS Savings Plans یا Reserved Instances؛ تخفیف برابر، قفل متفاوت

برای بار EC2 که در یک خانوادهٔ instance و یک منطقه پایدار می‌ماند، EC2 Instance Savings Plan و Standard Reserved Instance با مدت و شیوهٔ پرداخت یکسان می‌توانند نرخ برابر داشته باشند؛ مقایسهٔ نرخ m5.xlarge در Xplorr برای Linux با tenancy مشترک در us-east-1 همین برابری را نشان می‌دهد. در چنین شرایطی، ارزان‌ترین انتخاب به میزان استفاده از تعهد و نیاز به ظرفیت رزروشده وابسته است، نه فقط نرخ درج‌شده در جدول.

اگر بار ممکن است به خانواده یا منطقه‌ای دیگر برود، یا بخشی از مصرف EC2 به Fargate یا Lambda منتقل شود، Compute Savings Plan دامنهٔ پوشش گسترده‌تری دارد. بهای این انعطاف در نمونهٔ مقایسه‌شده نرخ بالاتری است. در مقابل، تعهدی با نرخ پایین‌تر زمانی هزینهٔ نهایی را کاهش می‌دهد که مصرف واجد شرایط در ساعت‌های دوره برای جذب آن باقی بماند.

نرخ یک نمونهٔ هم‌شرایط چقدر است؟

اعداد این مقایسه برای m5.xlarge در منطقهٔ us-east-1، با Linux و tenancy مشترک بررسی شده‌اند. نرخ‌های ساعتیِ بررسی‌شده در سپتامبر ۲۰۲۶ با فرض ۷۳۰ ساعت مصرف در ماه چنین‌اند؛ در هر مقایسهٔ تعهدی، مدت و شیوهٔ پرداخت یکسان است:

• On-Demand: ساعتی ۰٫۱۹۲ دلار و برای ۷۳۰ ساعت، ماهانه ۱۴۰٫۱۶ دلار.
• تعهد یک‌ساله بدون پیش‌پرداخت: Standard RI و EC2 Instance Savings Plan هر دو ساعتی ۰٫۱۲۱ دلار، معادل ماهانه ۸۸٫۳۳ دلار؛ Compute Savings Plan ساعتی ۰٫۱۴۱ دلار، معادل ماهانه ۱۰۲٫۹۳ دلار.
• تعهد سه‌ساله بدون پیش‌پرداخت: Standard RI و EC2 Instance Savings Plan هر دو ساعتی ۰٫۰۸۳ دلار، معادل ماهانه ۶۰٫۵۹ دلار؛ Compute Savings Plan ساعتی ۰٫۰۹۷ دلار، معادل ماهانه ۷۰٫۸۱ دلار.

برای مصرف کاملِ معادل یک m5.xlarge، تفاوت Compute Savings Plan با دو گزینهٔ هم‌نرخ در تعهد یک‌ساله ۱۴٫۶۰ دلار و در تعهد سه‌ساله ۱۰٫۲۲ دلار در ماه است. این اختلاف قیمتِ انعطاف در همین پیکربندی است؛ نمی‌توان آن را به همهٔ خانواده‌ها، منطقه‌ها یا سیستم‌عامل‌ها تعمیم داد. AWS نیز برای نمونه تصریح می‌کند که قیمت Savings Plans روی SLES با قیمت RI متناظر تفاوت دارد.

پرداخت کامل یا جزئی در آغاز دوره، نرخ مؤثر دیگری می‌سازد. بنابراین مقایسهٔ یک RI با پیش‌پرداخت کامل و یک Savings Plan بدون پیش‌پرداخت، اثر محصول و اثر شیوهٔ پرداخت را با هم مخلوط می‌کند. نرخ ساعتی مؤثر برای مقایسه مفید است، اما زمان خروج پول از بودجه نیز برای تیم مالی اهمیت دارد.

نقطهٔ سربه‌سر چه چیزی را نشان می‌دهد؟

در فرض ساده‌ای که فقط همان m5.xlarge مصرف واجد شرایط ایجاد می‌کند، نقطهٔ سربه‌سر از تقسیم نرخ تعهد ساعتی بر نرخ On-Demand به دست می‌آید. برای تعهد یک‌سالهٔ بدون پیش‌پرداخت، حاصل تقسیم ۰٫۱۲۱ بر ۰٫۱۹۲ حدود ۶۳٪ است. اگر ماشین کمتر از این سهمِ ساعت‌های دوره کار کند، پرداخت On-Demand از تعهد هم‌نرخ RI یا EC2 Instance Savings Plan ارزان‌تر می‌شود.

برای Compute Savings Plan یک‌ساله، نسبت ۰٫۱۴۱ به ۰٫۱۹۲ حدود ۷۳٫۴٪ است. در گزینه‌های سه‌سالهٔ همین نمونه، آستانهٔ حسابی Standard RI و EC2 Instance Savings Plan حدود ۴۳٫۲٪ و آستانهٔ Compute Savings Plan حدود ۵۰٫۵٪ است. این نسبت‌ها پیش‌بینی مصرف نیستند؛ فقط نشان می‌دهند هر نرخ تا چه حد افتِ استفاده از یک بار مشخص را تحمل می‌کند.

برای Savings Plans، مصرف واجد شرایط الزاماً به روشن‌ماندن همان ماشین محدود نیست. تعهدِ مبلغیِ ساعتی می‌تواند روی مصرف دیگری در دامنهٔ همان طرح اعمال شود؛ ازاین‌رو خاموش‌شدن m5.xlarge لزوماً به معنی بی‌استفاده‌ماندن تعهد نیست. در عوض، مصرف زیاد در یک ساعت، سهم استفاده‌نشدهٔ تعهد در ساعت کم‌مصرف دیگر را به گذشته منتقل نمی‌کند. برای سبدی از بارهای کاری، باید کف مصرف واجد شرایط را در مقیاس ساعت سنجید، نه فقط میانگین هزینهٔ ماهانه را.

مدت طولانی‌تر آستانهٔ حسابی پایین‌تری در این نمونه دارد، ولی فرصت بیشتری هم برای تغییر معماری، حذف بار یا انتقال آن ایجاد می‌کند. اگر بار پس از بخشی از دوره از دامنهٔ پوشش تعهد خارج شود، نرخ پایینِ ساعات مصرف‌شده به‌تنهایی هزینهٔ ساعات باقی‌مانده را جبران نمی‌کند. این همان تفاوت میان تخفیف اسمی و صرفه‌جویی تحقق‌یافته در صورتحساب است.

هر تعهد کدام تغییرات را پوشش می‌دهد؟

طبق تعریف انواع Savings Plans در AWS، EC2 Instance Savings Plan به یک خانوادهٔ instance در یک منطقه بسته می‌شود، اما در همان دامنه تغییر اندازه، سیستم‌عامل و tenancy را پوشش می‌دهد. Compute Savings Plan به خانواده یا منطقهٔ معینی محدود نیست و برای مصرف واجد شرایط EC2، Fargate و Lambda اعمال می‌شود. بنابراین انتقال بار از خانوادهٔ m5 به خانواده‌ای دیگر، یا انتقال آن از EC2 به Fargate، می‌تواند مصرف مناسب برای Compute Savings Plan باقی بگذارد.

Standard RI بر مشخصات instance، از جمله خانواده، پلتفرم و tenancy، تکیه دارد. با این حال، انعطاف اندازه برای RI منطقه‌ای در برخی پیکربندی‌ها وجود دارد؛ پس نمی‌توان هر RI را تعهدی به یک اندازهٔ تغییرناپذیر دانست. برای Linux/Unix با tenancy پیش‌فرض، RI منطقه‌ای می‌تواند تخفیف را در اندازه‌های دیگر همان خانواده اعمال کند، در حالی که RI ناحیه‌ای چنین انعطافی ندارد.

در نتیجه، برابری نرخ EC2 Instance Savings Plan و Standard RI در نمونهٔ بالا به معنی برابری ریسک عملیاتی نیست. اگر بار در همان خانواده و منطقه می‌ماند اما احتمال تغییر سیستم‌عامل یا tenancy دارد، دامنهٔ اعمال تخفیف EC2 Instance Savings Plan مهم می‌شود. اگر خانواده یا منطقه هم ممکن است تغییر کند، نرخ بالاتر Compute Savings Plan را باید در برابر احتمال بی‌استفاده‌ماندن تعهد محدودتر سنجید.

رزرو ظرفیت چه زمانی انتخاب را عوض می‌کند؟

قواعد RI منطقه‌ای و ناحیه‌ای در AWS تفاوت ظرفیت را مشخص می‌کند: RI منطقه‌ای ظرفیت رزرو نمی‌کند و تخفیف آن می‌تواند در ناحیه‌های دسترس‌پذیری همان منطقه اعمال شود؛ RI ناحیه‌ای در Availability Zone انتخابی ظرفیت رزرو می‌کند، اما به همان ناحیه و اندازهٔ instance محدود است. انتخاب دامنهٔ منطقه‌ای یا ناحیه‌ای به‌خودی‌خود قیمت RI را تغییر نمی‌دهد.

در مقایسهٔ رسمی Savings Plans و RI، AWS سقف تخفیف Compute Savings Plans را تا ۶۶٪ و سقف EC2 Instance Savings Plans و Standard RI را تا ۷۲٪ نسبت به On-Demand اعلام می‌کند. همان مقایسه روشن می‌کند که Savings Plans ظرفیت رزرو نمی‌کند، هرچند می‌تواند همراه با On-Demand Capacity Reservation به کار رود. این درصدها سقف‌های اعلامی‌اند، نه نرخ تضمین‌شده برای m5.xlarge یا هر پیکربندی دیگر.

اگر اجرای بار در یک Availability Zone مشخص به دسترسی به ظرفیت وابسته است، صرفِ برابری نرخ دو تعهد پاسخ کافی نیست: RI ناحیه‌ای علاوه بر تخفیف، ظرفیت همان ناحیه را رزرو می‌کند. اگر چنین نیازی وجود ندارد، ظرفیت رزروشده مزیتی برای آن بار ایجاد نمی‌کند و دامنهٔ اعمال تخفیف اهمیت بیشتری می‌یابد.

انتخاب برای بار ثابت، مهاجرتی و چندسرویسی

برای بار ثابت در یک خانواده و منطقه، نخست گزینه‌های دارای مدت و شیوهٔ پرداخت یکسان را کنار هم بگذارید. اگر مانند نمونهٔ m5.xlarge نرخ EC2 Instance Savings Plan و Standard RI برابر باشد، تغییر احتمالی سیستم‌عامل یا tenancy به سود دامنهٔ پوشش Savings Plan است. اگر رزرو ظرفیت در یک ناحیهٔ مشخص شرط اجرای بار باشد، RI ناحیه‌ای امتیازی دارد که خود Savings Plan فراهم نمی‌کند.

برای بار مهاجرتی، پرسش اصلی این است که پس از تغییر خانواده یا منطقه چه مقدار مصرف واجد شرایط باقی می‌ماند. Compute Savings Plan می‌تواند تخفیف را روی بار منتقل‌شده نگه دارد، اما در نمونهٔ محاسبه‌شده هزینهٔ هر ساعت پوشش آن بیشتر است. وقتی زمان یا مقصد مهاجرت نامطمئن است، تعهد به بخشی از کف مصرف قابل‌اتکا می‌تواند هزینهٔ استفاده‌نشدن از تعهد را محدود کند؛ بخش متغیر مصرف همچنان می‌تواند با On-Demand پرداخت شود.

برای سبدی از EC2، Fargate و Lambda، Compute Savings Plan دامنهٔ مشترک گسترده‌تری دارد. این مزیت فقط وقتی به هزینهٔ نهایی کمک می‌کند که مصرف واجد شرایط در ساعت‌های کافی برقرار بماند. توضیح AWS دربارهٔ تحلیل خرید نیز می‌گوید محاسبه بر مصرف تاریخی دورهٔ انتخابی متکی است و مصرف آینده را پیش‌بینی نمی‌کند؛ برای تصمیم بودجه‌ای، سناریوی پس از مهاجرت باید جدا از الگوی گذشته دیده شود.

بیشتر بخوانید:

• ChatGPT Plus یا Claude Pro؛ قیمت برابر، سقف ابزارها متفاوت است
• عامل‌های OpenAI داخل AWS اجرا می‌شوند؛ پیش‌نمایش فقط در سه منطقه است
• Paddle یا Lemon Squeezy؛ کارمزد برابر، زمان تسویه متفاوت