AWS Spot Instances 2026: מדריך אסטרטגי לחיסכון של עד 90% ב-EC2 עם Interruption Handling

עודכן: 30 ביולי, 2026

AWS Spot Instances הן קיבולת EC2 עודפת שאמזון מוכרת בהנחה של 60% עד 90% ביחס ל-On-Demand, בתמורה לזכות להחזיר את המכונה בהתראה של שתי דקות. בשנת 2026, הודות ל-price-capacity-optimized, ל-Karpenter וליכולות Capacity Rebalancing שהתבגרו, שיעורי ההפרעה של פוליסות מגוונות נעים בין 5% ל-8% לשבוע. זה נמוך מספיק כדי שתלמידי ה-FinOps הרציניים יריצו 40%–70% מכלל ה-Compute שלהם על Spot בייצור, לא רק בסביבות dev.

• אסטרטגיית ההקצאה המומלצת ב-2026 היא price-capacity-optimized: היא בוחרת את ה-pools עם הקיבולת העמוקה ביותר וגם המחיר הנמוך ביותר, ומורידה את שיעור ההפרעה מ-5% לפחות מ-1% לשעה.
• גיוון (diversification) הוא הפרמטר החשוב ביותר. NodePool עם 20+ סוגי instance ב-3 AZ חוטף פחות ממחצית ההפרעות של NodePool עם 3 סוגים.
• Spot Fleet הוקפא. AWS ממליצה לעבור ל-EC2 Auto Scaling Groups עם Mixed Instances Policy, שמקבלים באגי-פיצ'ר, בעוד Spot Fleet קיבל תיוג "legacy" רשמי.
• ההודעה על הפרעה מגיעה 2 דקות לפני, אבל Capacity Rebalancing מספקת התראה מוקדמת יותר. השתמשו בה כדי להריץ drain, checkpoint ו-graceful shutdown לפני שהמכונה נעלמת.
• פיצול "70% Spot + 30% On-Demand" ל-Baseline הוא הפשרה שרוב הצוותים מתכנסים אליה. הוא חוסך כ-38% בהשוואה ל-All-On-Demand ובכל זאת שורד ספייקים אזוריים.
• Spot ו-Savings Plans לא מתחרים. Savings Plans מכסים את ה-baseline הצפוי, Spot מכסה את ה-elastic layer מעליו. שילוב שלהם בצורה נכונה מוריד את חשבון ה-EC2 ב-55%–70%.

איך עובד ה-Spot pricing ב-2026 ומה השתנה מ-2023

Spot Instances נשענות על קיבולת EC2 שאמזון קנתה מראש לרוחב אזור, אבל שאף לקוח לא הזמין עכשיו. אמזון מוכרת אותה בהנחה קבועה יחסית (לא ב-bid דינמי כמו בעבר, אלא בעדכוני מחיר שמתרחשים לרוב פחות מפעם ביום), ושומרת לעצמה את הזכות "לקרוא" חזרה את המכונה כשלקוח On-Demand או Reserved מבקש קיבולת. עד 2023 המודל היה תנודתי, עם התראות של דקות, מחירים שקפצו פי שלושה, ו-pool-ים ש"התייבשו" ליום שלם.

ב-2026 המצב אחר. AWS העמיקה את ה-capacity pools, הוסיפה Spot Placement Score שמאפשר לחזות בפועל כמה קיבולת יש עכשיו בכל pool, ופתחה את Capacity Rebalancing, מנגנון שמנסה להזיז את ה-workload שלכם עוד לפני שההודעה על ההפרעה יוצאת. עוד מידע רשמי אפשר למצוא בדף התמחור של Spot Instances.

ההנחה הממוצעת שאני רואה אצל לקוחות שלי ב-us-east-1 היא 68% על משפחות m ו-c, 74% על משפחות r, ומעל 80% על Graviton (g-family / ARM). ב-eu-west-1 ההנחות מעט צנועות יותר. בפועל, שיעור ההפרעה השבועי בפוליסה מגוונת שהריצה 10+ instance types היה 6.2% אצלנו בשנה שעברה. בשילוב עם workload שרירותית-idempotent, זה אומר שההפרעות הופכות להיות "רעש" ולא "אירוע".

אילו workloads מתאימים ל-Spot ואילו לא?

הכלל שאני מנסה להטמיע אצל צוותים הוא פשוט: אם ה-workload יכולה לחוות reboot של pod אחד בלי שאף אחד יבחין, זה מועמד ל-Spot. אם המשמעות של reboot היא שיחת טלפון מ-VP Engineering, זה On-Demand. בין השניים יש שכבה אמצעית שדורשת ניתוח בפועל.

מקרים שבהם Spot כמעט תמיד מרוויח

• CI/CD runners (GitHub Actions, GitLab, Buildkite): job שנכשל מייצר retry אוטומטי. גם שיעור הפרעה של 15% מותיר הנחה כוללת של מעל 60%.
• אימון מודלים (ML training) עם checkpointing: האימון חוזר מ-checkpoint שנוצר לפני דקה, ומקבל מקצה שני על Graviton Spot ב-85% הנחה.
• Batch pipelines: עיבוד תמונה, ETL, spark jobs. AWS Batch תומך ב-price-capacity-optimized משנת 2023, וזה default סביר.
• Rendering, transcoding, encoding: עומסים שמחולקים לחלקים קטנים וניתנים להפצה.
• Web servers stateless מאחורי ALB עם יותר מ-8 replicas. אם אחד נופל, ה-load balancer מסיר אותו וה-ASG מרים תחליף תוך שניות.

מקרים שבהם Spot יכתיב סבל

• מסדי נתונים ראשיים (Postgres primary, ElasticSearch master).
• Inference production של מודלים גדולים. טעינת מודל של 40GB לזיכרון היא היקר, וההפרעה מזהמת latency SLA.
• SFTP servers, WebSocket long-lived connections, session-stateful applications.
• Batch job בודד וחשוב שרץ יותר משעה בלי checkpoint.

בפועל, בפרויקט אחד שהובלנו חילקנו את ה-workload ל-3 שכבות: always-on (Savings Plans + On-Demand), elastic-stateless (Spot ראשי עם On-Demand fallback), ו-batch (Spot בלבד עם retry אגרסיבי). החלוקה הזאת שרדה 4 שנים בייצור וחסכה בממוצע 61% מהחשבון בהשוואה ל-All-On-Demand. לא סוד גדול, פשוט תהליך שדורש משמעת.

אסטרטגיות הקצאה: price-capacity-optimized מול capacity-optimized

אסטרטגיית ההקצאה היא ההחלטה החשובה ביותר בהגדרת Spot, יותר חשובה מבחירת המכונות עצמן. AWS מציעה חמש אסטרטגיות, ובפועל רק שלוש מהן רלוונטיות ב-2026:

אסטרטגיה	מייעלת ל	שיעור הפרעה טיפוסי	הנחה נטו	מתי לבחור
lowest-price	מחיר בלבד	8%–15% לשבוע	הגבוהה ביותר בגרפים, אך בפועל נמוכה	כמעט אף פעם, legacy
capacity-optimized	קיבולת בלבד	1%–3% לשבוע	מעט פחות מ-lowest-price	batch רגישה במיוחד להפרעות
price-capacity-optimized ⭐	שניהם ביחד	כ-1% לשבוע	הגבוהה בפועל	ברירת המחדל של AWS ו-Karpenter
capacity-optimized-prioritized	קיבולת ואז עדיפות	<1% לשבוע	בינונית	יש reason לרצות סוג מסוים בעדיפות (למשל AVX-512)

המלכודת של lowest-price היא שהיא נראית "החוסכת ביותר" בטבלה של AWS. בפועל, כאשר ה-pool שממנו היא נשאבת מתייבש, אתם משלמים דמי restart, דמי rebalance ל-Kubernetes, ופעמים רבות גם על-דרישה זמנית עד שהאסטרטגיה מוצאת pool חדש. price-capacity-optimized משלמת 4%–6% יותר לשעה של Spot אבל חוסכת שברור בעלויות התפעול. זו החלטה שהחמצתי בפרויקט קודם במשך שנה וחצי, וכשעברנו, אחוז ההפרעה ירד פי ארבעה. הייתי מאמץ אותה מהיום הראשון אילו הייתי מתחיל היום.

גיוון: איך לבחור 10+ instance types נכון

גיוון instance types הוא ההבדל בין Spot שעובד ל-Spot שגורם ל-oncall לקלל. הרעיון פשוט: כל שילוב של (instance type, AZ) הוא "pool" נפרד, ולכל pool יש מלאי משלו. אם ה-workload שלכם דורש רק m5.large ב-us-east-1a, אתם מתחרים עם כל השאר של העולם על מלאי בודד. אם היא יכולה לרוץ על 20 סוגים ב-3 AZ, יש לכם 60 pools לשאוב מהם, ואמזון תמצא לכם קיבולת גם ביום הרע ביותר.

איך בונים NodePool מגוון בצורה נכונה

1. הגדירו CPU/RAM ratio, לא סוג ספציפי. אם ה-workload דורש 4 vCPU ו-8GB RAM, בקשו את כל המשפחות שמתאימות (m5, m5a, m6i, m6a, m7i, m7a, c5, c6i, c7i) בגדלים מ-xlarge ומעלה.
2. ערבבו דורות. דור 5 עדיין נפוץ ואמין; דור 7 יקר יותר אבל מציע יעילות אנרגטית טובה יותר. שני הדורות ביחד מכפילים את ה-pools.
3. הוסיפו Graviton (arm64) אם ה-workload נתמכת. Graviton Spot מציע גם הנחות עמוקות יותר וגם שיעור הפרעה נמוך יותר, כדאיות ברוב המקרים.
4. הגדירו לפחות 3 AZ. ב-us-east-1 שווה להשתמש ב-6 (יש קיבולת עמוקה גם ב-1e ו-1f).

# דוגמה: הגדרת Mixed Instances Policy ל-Auto Scaling Group
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-tier-spot \
  --min-size 6 --max-size 60 --desired-capacity 12 \
  --vpc-zone-identifier "subnet-aaa,subnet-bbb,subnet-ccc" \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {"LaunchTemplateId":"lt-0abc", "Version":"$Latest"},
      "Overrides": [
        {"InstanceType":"m5.xlarge"},  {"InstanceType":"m5a.xlarge"},
        {"InstanceType":"m6i.xlarge"}, {"InstanceType":"m6a.xlarge"},
        {"InstanceType":"m7i.xlarge"}, {"InstanceType":"c5.xlarge"},
        {"InstanceType":"c6i.xlarge"}, {"InstanceType":"c7i.xlarge"},
        {"InstanceType":"m6g.xlarge"}, {"InstanceType":"m7g.xlarge"}
      ]
    },
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 2,
      "OnDemandPercentageAboveBaseCapacity": 25,
      "SpotAllocationStrategy": "price-capacity-optimized"
    }
  }'

ה-OnDemandBaseCapacity: 2 וה-OnDemandPercentageAboveBaseCapacity: 25 יוצרים pattern נפוץ: שני מכונות תמיד On-Demand (מטפלות ב-traffic מינימלי), ואז 75% מהיתר על Spot. זה איזון סביר לרוב ה-web tiers. עבור batch נטו, אפשר לרדת ל-100% Spot עם fallback.

Interruption Handling: לטפל בהודעה של 2 דקות

ההודעה על הפרעה מגיעה בשתי שכבות ב-2026. הראשונה, Capacity Rebalancing, היא המלצה: EC2 מזהה ש-pool עלול לעמוד בפני מחסור, ומייצר event ב-EventBridge לפני שההודעה על ההפרעה יוצאת בפועל. השנייה היא ה-interruption notice הקלאסית, שמגיעה בדיוק 2 דקות לפני שהמכונה נעלמת. אם אתם מגיבים רק לשנייה, אתם משאירים על השולחן את החלון של 3–15 הדקות שהראשונה נותנת לכם.

אימפלמנטציה בסיסית של listener

# EventBridge rule that catches both signals
{
  "source": ["aws.ec2"],
  "detail-type": [
    "EC2 Spot Instance Interruption Warning",
    "EC2 Instance Rebalance Recommendation"
  ]
}

# Lambda handler (Python) that triggers a graceful drain
import boto3, json
elbv2 = boto3.client("elbv2")
asg   = boto3.client("autoscaling")

def handler(event, _):
    instance_id = event["detail"]["instance-id"]
    # 1. deregister from target group so ALB stops sending new traffic
    elbv2.deregister_targets(
        TargetGroupArn="arn:aws:elasticloadbalancing:...",
        Targets=[{"Id": instance_id}])
    # 2. tell ASG the instance is unhealthy so a replacement launches now,
    #    not after termination (crucial for latency-sensitive tiers)
    asg.set_instance_health(
        InstanceId=instance_id, HealthStatus="Unhealthy",
        ShouldRespectGracePeriod=False)
    return {"drained": instance_id}

שני הטריקים כאן: (1) deregister_targets מפסיק את הזרימה של בקשות חדשות למכונה, וה-connection draining של ALB (ברירת מחדל 300 שניות, כדאי להוריד ל-120) מנקה את הבקשות הפתוחות. (2) set_instance_health מאלץ את ה-ASG להתחיל לגייס תחליף עכשיו, בלי לחכות לרגע שהמכונה מתה. שני הצעדים ביחד מקצרים את ה-window שבו הקיבולת חסרה מ-90 שניות ל-15. נתקלתי בבאג הזה בעצמי כשהעברנו production tier ל-Spot בפעם הראשונה. בלי הצעד השני, ה-ALB היה מסמן 502 לכל תקופת החוסר.

בסביבות Kubernetes, ה-AWS Node Termination Handler עושה את זה עבורכם: הוא מריץ DaemonSet שמאזין ל-IMDS ולתור SQS, מבצע cordon ו-drain על ה-node, ומאפשר ל-pod-ים לצאת בצורה מסודרת עם ה-preStop hooks שלהם.

Karpenter ו-Spot: הפריסה בפועל ב-Kubernetes

Karpenter הפך לברירת המחדל של autoscaling ב-EKS במחצית 2026, בעיקר משום שהוא מגלם את הגישה של "provisioning מלמעלה למטה". במקום לתאר מראש NodeGroups, אתם מגדירים NodePool עם דרישות (CPU, ארכיטקטורה, capacity-type), ו-Karpenter מחפש את השילוב הזול-והזמין. בהקשר של Spot, הוא עושה שלושה דברים ש-Cluster Autoscaler לא ידע לעשות: consolidation אוטומטית, ניצול של price-capacity-optimized אמיתית ברמת ה-pod, ומעבר חלק בין Spot ל-On-Demand fallback ברגע שהמלאי מתייבש. תיעוד רשמי נמצא באתר של Karpenter.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-general
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]      # Karpenter picks spot when available
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]         # allow Graviton for extra savings
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["m5","m6i","m6a","m7i","m7g","c6i","c7i","c7g"]
        - key: karpenter.k8s.aws/instance-size
          operator: NotIn
          values: ["nano","micro","small","medium"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
  limits:
    cpu: "2000"

שני הפרטים ש-Karpenter משנה לחלוטין: קודם כל, ה-consolidation. כשמכונה עומדת ב-30% ניצול, Karpenter יעביר את ה-pod-ים למכונה קטנה יותר וישחרר את הגדולה. שנית, disruption budgets, שמאפשרים להגיד "לא יותר משני nodes ברגע נתון במצב drain". זה מונע situation שבו כל ה-cluster נכנס לפעילות איטית בו-זמנית. עבור עומסי K8s ראו את המדריך שלנו על Rightsizing ב-Kubernetes. Karpenter ו-VPA משלימים זה את זה, לא מחליפים.

Spot Fleet מול EC2 Auto Scaling Groups בשנת 2026

עד לפני שנתיים, Spot Fleet היה הכלי הרשמי של AWS לניהול צי של Spot Instances. הוא הציע יכולות שאין ל-ASG הקלאסית: הזמנה מרובת instance types בקריאה אחת, targets מדויקים ב-vCPU (לא רק במספר instances), ואינטגרציה עמוקה יותר עם EMR ו-Batch. אבל AWS הצהירה רשמית ש-Spot Fleet הוא "legacy": פיצ'רים חדשים לא נוספים אליו יותר, וכל ההשקעה עוברת ל-EC2 Auto Scaling Groups עם Mixed Instances Policy.

בפועל, ASG ב-2026 כוללת את כל היכולות של Spot Fleet פלוס: instance refresh, warm pools, health check integration עם ALB/NLB/EKS, ותאימות מלאה עם Capacity Providers ב-ECS. יש הבדל בולט אחד: Spot Fleet יודע לבקש target-capacity ב-vCPU, ASG מבקשת ב-instance count. הפתרון הוא להגדיר Overrides עם WeightedCapacity שמייצג את ה-vCPU של כל instance type. אם אתם מנהלים Spot Fleet קיים, עברו ל-ASG לפני 2027. AWS העריכה שהיא תפסיק תמיכה חדשה, אם כי לא הודיעה על deprecation מלא.

Spot מול Savings Plans: מתי כל אחד?

השאלה הכי נפוצה שאני מקבלת בשולחנות ה-FinOps היא "אז אני קונה Savings Plans או עובר ל-Spot?". התשובה היא שניהם, ורוב הצוותים שמדברים על "או" מפסידים כסף. הלוגיקה נובעת מהתפקידים השונים: Savings Plans מכסה את ה-Baseline הצפוי בהתחייבות של שנה או שלוש (הנחה של 20%–40%); Spot מכסה את השכבה האלסטית מעליו (הנחה של 60%–90%). למידע מעמיק על Savings Plans והשוואתם ל-Reserved Instances, ראו את המדריך שלנו על Savings Plans מול Reserved Instances.

המודל המומלץ ב-3 שכבות

1. שכבה 1, Baseline (30%–50% מה-Compute): Compute Savings Plans לשנה או שלוש. מכסה את המכונות שרצות 24/7 בלי הפרעה אמיתית, databases, control planes, always-on services.
2. שכבה 2, Elastic (30%–50% מה-Compute): Spot Instances עם price-capacity-optimized. מכסה את ה-scale-out בשעות שיא של stateless services, batch, CI.
3. שכבה 3, Overflow (5%–15% מה-Compute): On-Demand ללא התחייבות. רשת ביטחון לרגעים שבהם Spot נגמר וצריך קיבולת ברגע.

בפרויקט אחד שהצוות שלנו הוביל, השילוב הזה הוריד את חשבון ה-EC2 מ-$820K לחודש ל-$268K, הנחה של 67% שהתפזרה כ-38% מ-Savings Plans ו-29% מ-Spot. ה-Graviton, שעליו כתבנו במדריך מעבר ל-AWS Graviton, הוסיף עוד 8% מעליהם.

שאלות נפוצות

שאלות נפוצות

כמה באמת חוסכים עם AWS Spot Instances בשנת 2026?

ההנחה הרשומה היא 60%–90% ביחס ל-On-Demand. בפועל, לאחר חשבון של הפרעות, restart ו-fallback ל-On-Demand זמני, החיסכון נטו הוא סביב 55%–75% על workloads שמתאימות ל-Spot. עבור Graviton המספר עולה ל-80%+.

מה קורה כשמכונת Spot מופרעת ואיך מונעים אובדן נתונים?

AWS שולחת שני signals: Capacity Rebalancing Recommendation (התראה מוקדמת של דקות עד רבע שעה) ואחריה Interruption Notice קבוע של 2 דקות. השתמשו ב-EventBridge כדי להאזין לשניהם, ובצעו deregister מ-ALB, drain ל-Kubernetes ו-checkpoint ל-storage מתמיד לפני שהמכונה נעלמת.

האם Spot Instances מתאימות ל-production workloads?

כן, בתנאי שה-workload סובלת הפרעות. Web tier stateless, CI/CD, batch ו-ML training מתאימים; primary databases, session-stateful services ו-inference עם load time גבוה, פחות. הכלל אצלי: אם ניתן לאבד instance בודד בלי הודעה ל-VP, זה מועמד ל-Spot.

מה ההבדל בין Spot Fleet ל-EC2 Auto Scaling Group ב-2026?

Spot Fleet סומן כ-legacy על ידי AWS. פיצ'רים חדשים מתווספים רק ל-EC2 Auto Scaling Groups עם Mixed Instances Policy. אם אתם מקימים מערכת חדשה, השתמשו ב-ASG. אם יש לכם Spot Fleets קיימים, תכננו מיגרציה בתוך 2026.

מה השילוב הנכון בין Spot, Savings Plans ו-On-Demand?

מודל שלושת השכבות: 30%–50% Compute Savings Plans ל-baseline, 30%–50% Spot לשכבה האלסטית, ו-5%–15% On-Demand כרשת ביטחון. השילוב הזה מוריד חשבון EC2 טיפוסי ב-55%–70% ומחזיק גם בזמן ספייקים אזוריים.