مقایسه Spot Instances در AWS، Azure و GCP: راهنمای کاهش تا ۹۰٪ هزینه در ۲۰۲۶

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

Spot Instance ظرفیت مازاد و اضافه‌ای است که AWS، Azure و GCP با تخفیف ۶۰ تا ۹۱ درصد نسبت به قیمت on-demand می‌فروشند و در ازای آن حق دارند هر زمان با اخطار ۳۰ ثانیه تا ۲ دقیقه پس بگیرند. در بارهای کاری stateless، batch، CI/CD و آموزش مدل با checkpoint، همین ظرفیت ارزان می‌تواند صورتحساب ابری شما را در ۲۰۲۶ تا ۷۷٪ کاهش دهد. اما پالیسی eviction، نوسان قیمت و پنجره اخطار سه ابر آنقدر متفاوت است که یک انتخاب اشتباه به‌جای صرفه‌جویی، یک آخر هفته rebuild برای تیم SRE می‌سازد (و بله، خودم چنین آخر هفته‌ای را از نزدیک تجربه کرده‌ام).

• AWS EC2 Spot تا ۹۰٪ تخفیف با پنجره اخطار ۲ دقیقه‌ای می‌دهد، اما بیشترین نوسان قیمت را دارد (میانگین ۱۹۷ تغییر قیمت در ماه).
• Azure Spot VM تا ۹۰٪ تخفیف، اخطار ۳۰ ثانیه‌ای و دو پالیسی eviction (Deallocate یا Delete) و امکان تعیین Max Price دارد.
• GCP Spot VM تخفیف ثابت ۶۰ تا ۹۱ درصد و پایدارترین قیمت را دارد (میانگین یک تغییر در سه ماه) و برخلاف Preemptible قدیمی، سقف ۲۴ ساعتی ندارد.
• Karpenter از نسخه v0.19 به بعد به‌طور نیتیو با SQS و EventBridge از interruption handling پشتیبانی می‌کند؛ Node Termination Handler را در کنارش اجرا نکنید.
• ترکیب برنده در ۲۰۲۶: Savings Plans یا Reserved Instance برای پایه‌ی on-demand، به‌علاوه Spot متنوع (Diversified) برای بار متغیر و batch.
• H100 روی p5.48xlarge نرخ قطع زیر ۵٪ دارد، اما A100 روی p4d.24xlarge بین ۱۵ تا ۲۰٪ نوسان می‌کند؛ همیشه از Spot Instance Advisor قبل از commit استفاده کنید.

Spot Instance چیست و چرا تا ۹۱٪ ارزان‌تر است؟

خب، بیایید از پایه شروع کنیم. Spot Instance ظرفیت مازادی است که ابر سازنده در دیتاسنترهای خود دارد و به‌جای بی‌کار نگه‌داشتن، آن را با تخفیف عمیق به مشتری اجاره می‌دهد. در ازای این تخفیف، ابر حق دارد هر زمان که ظرفیت برای مشتریان on-demand یا reserved لازم شد، اینستنس شما را با اخطار کوتاه پس بگیرد. AWS این مکانیزم را از ۲۰۰۹ راه‌اندازی کرد و از ۲۰۱۷ مدل مزایده‌ای (bidding) را حذف کرد؛ حالا قیمت spot توسط عرضه و تقاضا در هر Availability Zone و هر instance type تعیین می‌شود و در دوره‌های اوج به قیمت on-demand نزدیک می‌شود.

Azure در ۲۰۲۰ Spot VMs را عمومی کرد و همان مدل ظرفیت مازاد را ارائه داد، اما یک قابلیت مهم افزود: امکان تعیین Max Price. اگر قیمت spot از سقف شما بگذرد، VM قبل از eviction ظرفیتی، به دلیل قیمت evict می‌شود. GCP در سال ۲۰۲۱ Preemptible VMs قدیمی (که سقف عمر ۲۴ ساعته داشت) را با Spot VMs جایگزین کرد که سقف عمر ندارد و ساختار قیمت‌گذاری ثابت‌تری دارد. برای درک بهتر رابطه Spot با سایر مدل‌های تعهد، راهنمای مقایسه AWS Savings Plans و Reserved Instances را ببینید که سه لایه on-demand، commitment و spot را کنار هم چیده است.

مقایسه هزینه و نوسان قیمت AWS، Azure و GCP

راستش، عمق تخفیف در هر سه ابر مشابه است، اما اختلاف اصلی در پیش‌بینی‌پذیری قیمت است. برای بار کاری که هزینه‌اش را باید به مشتری داخلی showback کنید، پایداری قیمت مهم‌تر از عمق تخفیف است. جدول زیر نکات کلیدی هر سه ابر را در سپتامبر ۲۰۲۶ کنار هم گذاشته است:

ویژگی	AWS EC2 Spot	Azure Spot VM	GCP Spot VM
حداکثر تخفیف نسبت به on-demand	تا ۹۰٪	تا ۹۰٪	۶۰ تا ۹۱٪
پنجره اخطار قبل از قطع	۲ دقیقه	۳۰ ثانیه	۳۰ ثانیه
مکانیزم قیمت‌گذاری	بر اساس عرضه/تقاضا، نوسان بالا	نیمه‌ثابت با Max Price اختیاری	تخفیف ثابت (fixed discount)
میانگین تغییر قیمت	~۱۹۷ بار در ماه	<۱ بار در ماه	~۱ بار در سه ماه
پالیسی eviction	فقط terminate/stop/hibernate	Deallocate یا Delete	فقط terminate
سقف عمر (Max Lifetime)	ندارد	ندارد	ندارد (Preemptible قدیمی ۲۴ ساعت داشت)
ابزار تحلیل نرخ قطع	Spot Instance Advisor + Placement Score	Eviction rate در پرتال	Availability advisor در Console
پشتیبانی GPU spot	گسترده (H100, A100, L4)	محدودتر	گسترده (A100, H100 در برخی مناطق)

در بنچمارک‌های داخلی که سال گذشته روی کلاسترهای EKS، AKS و GKE اجرا کرده‌ام، برای بار stateless یکسان (یک Python worker با Redis queue) صرفه‌جویی خالص AWS بیشتر بود ولی cost variance ماهانه ۱۸٪ داشت. GCP کمترین صرفه‌جویی اسمی (حدود ۶۵٪) را داد اما variance زیر ۲٪ بود که برای forecast مالی و chargeback بسیار راحت‌تر است. Azure در میانه ماند و مزیت اصلی‌اش Max Price برای cap کردن سقف هزینه ساعتی است. برای درک نحوه‌ی رفتار GPU spot در بار AI، راهنمای بهینه‌سازی هزینه GPU در ابر اعداد نرخ قطع را برای H100 و A100 در سه ابر تفکیک کرده است.

نرخ قطع، پنجره اخطار و پالیسی eviction

نرخ قطع مهم‌تر از عمق تخفیف است، چون یک قطعی ناهنگام می‌تواند ساعت‌ها کار training یا batch را از دست بدهد. AWS Spot Instance Advisor نرخ قطع ۳۰ روز گذشته را برای هر instance type و منطقه منتشر می‌کند و شفاف‌ترین منبع تصمیم‌گیری است. برای اطلاعات رسمی صفحه AWS EC2 Spot را ببینید. Azure نرخ eviction هر VM size را در پرتال Azure در بخش «Size + Image» و GCP در Compute Engine Availability Advisor نمایش می‌دهد.

پنجره اخطار AWS دو دقیقه است که برای یک shutdown script منظم کافی است: می‌توانید checkpoint را روی S3 بنویسید، pod را drain کنید و connection‌های active را graceful ببندید. Azure و GCP تنها ۳۰ ثانیه اخطار می‌دهند که برای بار stateless مثل web worker کافی است، اما برای training سنگین باید frequency checkpoint را بالا ببرید (مثلاً هر ۵ دقیقه). Azure برای دریافت این اخطار از Scheduled Events API استفاده می‌کند که هر پنج ثانیه باید poll شود؛ جزئیات را در مستندات Azure Spot VMs ببینید.

پالیسی eviction: تفاوت مهم Azure

Azure تنها ابری است که دو پالیسی eviction دارد: Deallocate (متوقف کردن VM و نگه داشتن disk، قابلیت restart بعد از بازگشت ظرفیت) و Delete (حذف کامل VM و منابع مرتبط). Deallocate برای stateful workloadی که نیاز به resume دارد ایده‌آل است، در حالی که Delete برای worker pool که به‌سرعت جایگزین می‌شود بهتر است. AWS و GCP این انعطاف را ندارند و همیشه اینستنس terminate می‌شود (AWS اخیراً stop و hibernate را برای Spot افزوده اما محدودیت‌های خاص خود را دارد).

بهترین بارهای کاری برای Spot در هر ابر

Spot برای بار کاری مناسب است که سه ویژگی داشته باشد: fault-tolerant، stateless یا checkpoint شده، و flexible در instance type. اگر بار شما هر سه را دارد، spot تا ۷۷٪ صرفه‌جویی می‌دهد. اگر یکی را ندارد، spot معمولاً هزینه پنهان بیشتری تحمیل می‌کند.

بارهای کاری ایده‌آل برای Spot

• Batch processing و ETL: Spark، Flink، AWS Batch، Azure Batch، GCP Dataflow. همه با restart از checkpoint سازگارند.
• CI/CD runners: GitHub Actions self-hosted، GitLab runners، Buildkite. یک قطعی یعنی یک retry، نه از دست رفتن state.
• Stateless web workers پشت load balancer: با HPA و PDB مناسب، قطع یک node تجربه کاربر را خراب نمی‌کند.
• Training مدل با checkpointing: Hugging Face Trainer، PyTorch Lightning و MosaicML همه checkpoint خودکار دارند؛ در AWS نرخ قطع H100 روی p5.48xlarge زیر ۵٪ است که برای training بلندمدت قابل قبول است.
• Data pipeline لایه‌ی پردازش: ingest و transform معمولاً retryable هستند؛ فقط لایه‌ی write باید idempotent باشد.

بارهای کاری نامناسب برای Spot

• Real-time inference با SLA سخت (استفاده از on-demand یا Reserved Capacity)
• Database primary node (PostgreSQL، MySQL، MongoDB primary)
• Session store غیر توزیع‌شده مثل Redis single-node بدون replica
• Training بدون checkpoint یا با checkpoint‌های خیلی گران
• Long-lived stateful process مثل message broker با in-memory queue

راه‌اندازی Spot در Kubernetes با Karpenter

Karpenter از نسخه v0.19 به بعد به‌طور نیتیو interruption را از طریق SQS + EventBridge مدیریت می‌کند و در v1.0 (منتشر شده در ۲۰۲۴) این معماری stable شد. برخلاف کلاستر autoscaler که با node group کار می‌کند، Karpenter مستقیم روی EC2 Fleet API صحبت می‌کند و از استراتژی price-capacity-optimized برای انتخاب pool با کمترین نرخ قطع استفاده می‌کند. برای دیپ‌دایو کامل روی K8s cost، راهنمای بهینه‌سازی هزینه Kubernetes در ۲۰۲۶ را ببینید.

NodePool نمونه برای Spot در Karpenter v1

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-workers
spec:
  template:
    metadata:
      labels:
        capacity-type: spot
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]  # fallback to on-demand
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["m6i", "m6a", "m7i", "c6i", "c7i", "r6i"]
        - key: karpenter.k8s.aws/instance-size
          operator: NotIn
          values: ["nano", "micro", "small"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      terminationGracePeriod: 30s
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
  limits:
    cpu: 1000
    memory: 1000Gi

نکات مهم این پیکربندی: (۱) فهرست instance-family را وسیع نگه دارید تا Karpenter از pool عمیق‌تر انتخاب کند و نرخ قطع پایین بیاید؛ (۲) هر دو spot و on-demand را در requirements قرار دهید تا در صورت اتمام ظرفیت spot، fallback خودکار به on-demand فعال شود؛ (۳) consolidationPolicy: WhenEmptyOrUnderutilized spot-to-spot consolidation را فعال می‌کند که در نسخه‌های اخیر Karpenter اضافه شده و صرفه‌جویی را دو‌برابر می‌کند. برای جزئیات معماری interruption handling، راهنمای EKS Best Practices برای Karpenter منبع رسمی است.

بهترین شیوه‌های پایداری روی Spot

صرفه‌جویی ۷۰٪ روی spot تنها زمانی دست می‌آید که قطعی‌ها را graceful مدیریت کنید. یک قطع بد می‌تواند هزینه‌ی rebuild یک روزه‌ای تحمیل کند که تمام صرفه‌جویی ماه را از بین ببرد. این شش الگو در بنچمارک‌های خودم بیشترین اثر را داشتند:

1. تنوع instance family: حداقل ۱۵ تا ۲۰ instance type در NodePool مجاز کنید. هر چه فهرست وسیع‌تر، عمق pool بیشتر و نرخ قطع پایین‌تر.
2. PodDisruptionBudget بگذارید: برای هر Deployment مهم minAvailable یا maxUnavailable تعریف کنید تا قطع همزمان چند node سرویس را down نکند.
3. Annotation karpenter.sh/do-not-disrupt: "true": روی pod‌های stateful یا batch job طولانی بگذارید تا Karpenter تا پایان کار node را نگه دارد.
4. Checkpoint هر ۵ تا ۱۰ دقیقه: برای training یا batch job طولانی، checkpoint frequency بالا هزینه‌ی از دست رفته را در بدترین حالت به یک بازه کوتاه محدود می‌کند.
5. Fallback on-demand: در NodePool هم spot و هم on-demand را مجاز کنید. اگر ظرفیت spot تمام شد، workload بلاک نمی‌شود.
6. Diversification بین AZ: در سه AZ توزیع کنید. AWS spot capacity در هر AZ مستقل است و قطع همزمان همه AZها بسیار بعید است.

در بار GPU، یک الگوی اضافی هم توصیه می‌شود: از Capacity Blocks برای بخش critical training (مثلاً epoch نهایی) و Spot برای exploration و hyperparameter tuning استفاده کنید. این ترکیب در بنچمارک اخیر ما هزینه‌ی یک run کامل ResNet-50 روی H100 را ۵۸٪ کاهش داد بدون آنکه training بیش از ۱۰ دقیقه به تاخیر بیفتد.

چه زمانی Spot را با Savings Plans ترکیب کنیم؟

Spot و Savings Plans رقیب نیستند، مکمل‌اند. الگوی برنده در FinOps مدرن، سه لایه است: (۱) Compute Savings Plans یا Reserved Instances برای پوشش پایه‌ی ثابت (base load) که همیشه در حال اجراست. این لایه ۷۲٪ تا ۷۵٪ صرفه‌جویی می‌دهد و SLA کامل on-demand دارد. (۲) On-demand برای بار متغیر با SLA سخت که spot مناسبش نیست. (۳) Spot برای بار elastic، batch، dev/test و worker pool که تولرانس قطع دارد. مستندات رسمی GCP Spot VMs هم همین توصیه چند‌لایه را می‌کند.

در تعیین سهم spot، قاعده تجربی ۲۰۲۶ این است: اگر workload شما stateless و checkpointable است، تا ۸۰٪ ظرفیت را می‌توانید spot کنید و ۲۰٪ را on-demand fallback. اگر mixed workload دارید (بخشی stateful)، ۴۰ تا ۶۰٪ spot معمولاً شیرین‌ترین نقطه است. برای مدیریت هزینه در سطح سازمانی و اطمینان از اینکه هر تیم فقط سهم مناسب خود از spot و SP را می‌بیند، راهنمای برچسب تخصیص هزینه AWS و حاکمیت ساختار tagging مورد نیاز را توضیح می‌دهد.

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

تفاوت اصلی Spot Instance با On-Demand چیست؟

Spot Instance ظرفیت مازاد ابر است با تخفیف ۶۰ تا ۹۱ درصد نسبت به on-demand، اما ابر می‌تواند با اخطار ۳۰ ثانیه تا ۲ دقیقه پس بگیرد. On-Demand هیچ تعهد قیمتی یا زمانی ندارد اما هیچ تخفیفی هم نمی‌دهد و اینستنس تا زمانی که خودتان stop کنید در دست شماست.

آیا Spot Instance برای بار پروداکشن مناسب است؟

بله، اما فقط برای بارهای stateless، fault-tolerant و flexible در نوع اینستنس. Netflix، Pinterest و Airbnb سال‌هاست بخش بزرگی از پروداکشن خود را روی Spot می‌برند. کلید کار PodDisruptionBudget، diversification بین ۱۵+ instance type و fallback خودکار به on-demand است. برای database primary، session store یا real-time inference با SLA سخت مناسب نیست.

GCP Spot VM با Preemptible چه فرقی دارد؟

Preemptible VM محصول قدیمی GCP بود که سقف عمر ۲۴ ساعته داشت و بعد از این مدت حتماً terminate می‌شد. Spot VM که در ۲۰۲۱ جایگزین شد این سقف را ندارد و می‌تواند روزها اجرا شود اگر ظرفیت باشد. قیمت‌گذاری هم ثابت‌تر است (۶۰ تا ۹۱٪ تخفیف اعلام‌شده) به‌جای مکانیزم مزایده‌ای قدیمی.

Karpenter چگونه از قطع Spot جلوگیری می‌کند؟

Karpenter نمی‌تواند از قطع جلوگیری کند، اما با استراتژی price-capacity-optimized بهترین pool را انتخاب می‌کند تا نرخ قطع پایین بیاید. از SQS + EventBridge اخطار ۲ دقیقه‌ای AWS را می‌گیرد، node را cordon و drain می‌کند و pod را روی node جایگزین منتقل می‌کند. اگر spot تمام شود، به on-demand fallback می‌کند.

کدام ابر برای Spot در ۲۰۲۶ بهترین است؟

پاسخ به بار کاری بستگی دارد. AWS برای بار batch با tolerance بالا و نیاز به عمیق‌ترین تخفیف بهترین است. GCP برای بار stateless که پیش‌بینی‌پذیری قیمت مهم است (مثل chargeback داخلی) بهترین است. Azure برای بار stateful که نیاز به Deallocate و restart دارد یا می‌خواهد Max Price را cap کند بهترین است.

آیا می‌توان Savings Plans و Spot را همزمان استفاده کرد؟

بله، این ترکیب توصیه‌شده FinOps است. Compute Savings Plans پایه‌ی on-demand ثابت را پوشش می‌دهد و Spot بار elastic اضافی را می‌گیرد. صرفه‌جویی نهایی می‌تواند به ۶۵ تا ۸۰٪ کل صورتحساب compute برسد بدون آنکه SLA سرویس اصلی آسیب ببیند.