מדריך מעשי להחלטה בין Savings Plans ל-Reserved Instances ב-AWS לשנת 2026. השוואה בין הסוגים, חישוב נקודת איזון, תהליך רכישה עם CLI, וטעויות נפוצות שראיתי בכל אודיט FinOps.
עודכן: 15 ביוני 2026
Savings Plans ו-Reserved Instances הם שני מנגנוני התחייבות של AWS שמעניקים הנחה של 40%–72% תמורת התחייבות לצריכה של שנה או שלוש שנים. ההבדל המרכזי ב-2026 הוא הגמישות: Compute Savings Plans מכסים EC2, Fargate ו-Lambda באוטומציה מלאה ללא צורך לבחור משפחת מכונה, בעוד ש-Reserved Instances מציעים את ההנחה העמוקה ביותר אך נעולים על מפרט ספציפי. במאמר הזה אני שובר את ההחלטה לפי סוג עומס עבודה, ומראה את החישוב המדויק שבו אני משתמש בכל לקוח FinOps.
שני המנגנונים פותרים את אותה בעיה: AWS מוכן להוריד לך משמעותית את המחיר אם תתחייב מראש לצריכה. ההבדל הוא איך מנוסחת ההתחייבות. ב-Reserved Instances אתה מתחייב על קיבולת מסוימת, לדוגמה שלוש מכונות m6i.large באזור us-east-1a לשלוש שנים. ב-Savings Plans אתה מתחייב על הוצאה כספית בדולר לשעה, לדוגמה 12$ לשעה של compute, ו-AWS מחיל את ההנחה אוטומטית על כל מכונה שמתאימה למסגרת.
בפרקטיקה זה משנה הכל. ב-2024 ראיתי לקוח שאחז ב-180 RI שונים על משפחות m5 ו-c5, וכל פעם שצוות פיתוח שדרג לדור חדש, הם איבדו את ההנחה. עברנו ל-Compute Savings Plans וההנחה עברה איתם אוטומטית כשהם קפצו ל-m7i ול-Graviton. הקיצוץ נטו היה 31% בחשבון EC2 החודשי בלי שינוי בעומס. בכנות, זה היה אחד הפרויקטים הקלים ביותר עם ה-ROI הכי גבוה שעשיתי באותה שנה.
חשוב להבין: Savings Plans אינם מבטיחים קיבולת. Reserved Instances מסוג Zonal כן מבטיחים קיבולת ב-AZ ספציפי (capacity reservation). אם אתה מריץ עומס שאתה חייב שיהיה לו מקום באירוע של DR, אז RI Zonal הוא הכלי, לא SP. בכל מקרה אחר, התעלם מההיבט הזה והתמקד בהנחה.
ריכזתי את ההבדלים המרכזיים שבהם אני משתמש כשאני יושב עם מנכ"לים שצריכים להחליט. כשמסתכלים על הטבלה, קל לראות למה רוב הארגונים נוטים היום ל-Compute Savings Plans כברירת מחדל:
| פרמטר | Compute Savings Plans | EC2 Instance Savings Plans | Standard Reserved Instances |
|---|---|---|---|
| הנחה מקסימלית | עד 66% | עד 72% | עד 72% |
| שירותים מכוסים | EC2, Fargate, Lambda | EC2 בלבד | EC2 בלבד |
| גמישות משפחת מכונה | מלאה (כל משפחה) | נעול למשפחה | נעול למשפחה |
| גמישות אזורית | בין אזורים | אזור בודד | אזור או AZ |
| גמישות OS / Tenancy | מלאה | מלאה | נעול |
| הבטחת קיבולת | לא | לא | רק ב-Zonal RI |
| אפשרות מכירה ב-Marketplace | לא | לא | כן (Standard בלבד) |
| ניהול שוטף | מינימלי | בינוני | גבוה |
השורה התחתונה שלי: אם אין לך סיבה ספציפית לבחור RI, פשוט בחר Compute Savings Plans. בכל ביקורת FinOps שעשיתי השנה, מעל 70% מההתחייבויות שראיתי "תקועות" היו RI ישנים שהיו צריכים להיות SP מההתחלה. ה-3% הפרש בהנחה לא שווה את עומס הניהול.
AWS מציעה שלושה סוגים של Savings Plans, וכל אחד מתאים לתרחיש אחר. ההחלטה הזו נעשית פעם אחת בכל מחזור תכנון, אבל היא הגדולה ביותר מבחינת השפעה כספית, ולכן שווה להבין לעומק.
אלה הברירת המחדל ל-2026. הם מכסים EC2 ללא תלות במשפחה, גודל, אזור, מערכת הפעלה או Tenancy. הם גם מכסים אוטומטית Fargate ו-Lambda. ההנחה היא עד 66% לעומת On-Demand. ראיתי לקוחות שעוברים מ-Intel ל-Graviton וההנחה נשארת בתוקף. אם אתה מתלבט בין הסוגים, התחל כאן.
גמישים פחות (נעולים למשפחה ולאזור) אבל זולים יותר, עד 72% הנחה. שווים את זה רק אם יש לך עומס יציב ב-EC2 שאתה יודע שלא יעבור משפחה (לדוגמה, אשכול MySQL גדול שתוכנן ספציפית ל-r6i). אצל לקוח אחד חישבנו שההפרש של 6% על 4M$ בשנה זה 240K$, וזה הצדיק את הנעילה.
סוג נפרד שמכסה SageMaker training, inference ו-notebook instances. ההנחה דומה ל-Compute SP. אם אתה מריץ ML בקנה מידה, קח אותם. למידע מעמיק על אופטימיזציית עלויות AI, יש לי מדריך מלא על FinOps לבינה מלאכותית וחיסכון בעלויות GPU שמכסה גם תקציבי SageMaker.
למרות שאני נוטה ל-SP, יש ארבעה תרחישים שבהם RI עדיין הבחירה הנכונה ב-2026:
חוץ מארבעת המקרים האלה, לך עם Savings Plans.
שני מטריקות שאני בודק בכל לקוח ב-FinOps Reviews החודשיים. אם אתה לא עוקב אחרי שניהם, אתה משלם יותר ממה שצריך.
אחוז מהשעות שלך שנהנות מהנחת התחייבות. מטרה: 70%–85% מהבסיס היציב (steady-state baseline). למה לא 100%? כי אתה לא יכול לחזות את הצמיחה במדויק, ועדיף לשלם 5% On-Demand מאשר להחזיק SP בלתי מנוצל ב-30%.
אחוז מההתחייבות שאתה באמת ממש את ההנחה עבורה. מטרה: 95%+. ניצולת של 80% משמעותה ש-20% מההתחייבות אתה משלם בלי לקבל כלום. זו הסיבה למה SP מנצח RI, כי הוא "זורם" אוטומטית לעבר עומסים אחרים אם מכונה אחת נכבית.
הנוסחה שאני משתמש בה לחישוב אם להתחייב או לא:
# Break-even hours per month
# מספר השעות בחודש שצריך להריץ את העומס כדי שההתחייבות תשתלם
hourly_on_demand = 0.0832 # m6i.large us-east-1
hourly_sp_3yr = 0.0349 # 58% off with 3yr All Upfront
upfront_cost = 0.0349 * 24 * 365 * 3
# חישוב נקודת איזון
hours_per_month = upfront_cost / (hourly_on_demand * 36)
print(f"Need {hours_per_month:.0f} hours/month to break even")
# Output: Need 504 hours/month to break even (out of ~730)
אם המכונה רצה 504 שעות מתוך 730 בחודש (69%) או יותר, ההתחייבות משתלמת. פחות מזה, תישאר On-Demand או Spot. למידע על אופטימיזציה לעומסים יציבים, ראה את המדריך rightsizing ב-Kubernetes. חצי מהבעיות שאני רואה הן לא בעיית התחייבות אלא בעיית גודל.
הנה התהליך המדויק שאני מבצע כשאני קונה SP חדש עבור לקוח. אני עושה הכל ב-CLI כדי שיהיה רישום אוטומטי ובדיק.
# שלוף המלצות Compute Savings Plans ל-3 שנים, No Upfront
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" \
--query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[*].[HourlyCommitmentToPurchase,EstimatedSavingsAmount,EstimatedSavingsPercentage]' \
--output table
אני אף פעם לא סומך על המלצה אחת. אני מריץ את הפקודה שלוש פעמים, עם SEVEN_DAYS, THIRTY_DAYS, ו-SIXTY_DAYS, ובוחר את הסכום הנמוך מהשלושה. זה מגן מפני קפיצות זמניות שיגרמו לי לקנות יותר מדי.
# רכישת Compute Savings Plan
aws savingsplans create-savings-plan \
--savings-plan-offering-id "offering-id-from-step-1" \
--commitment "8.50" \
--upfront-payment-amount "0" \
--client-token "$(uuidgen)"
aws ce get-savings-plans-coverage \
--time-period Start=2026-06-14,End=2026-06-15 \
--granularity DAILY \
--metrics "SpendCoveredBySavingsPlans" \
--query 'SavingsPlansCoverages[*].Coverage'
כדי לחבר את התהליך הזה לתכנון מראש ולתת לצוותי הפיתוח את העלות הצפויה לפני merge, אני משלב את זה עם Shift-Left FinOps עם Terraform ו-Infracost בפייפליין ה-CI.
הנה חמש טעויות שאני רואה חוזרות על עצמן בכל לקוח חדש. אם אתה מצליח להימנע מהן, אתה כבר ב-90% מהדרך לאופטימיזציית רייט מצוינת.
הסיכוי שהצמיחה תפנה אותך לסולוואלות שלא תכננת היא גבוה. תחילה תקנה ל-65%, חכה רבעון, מדוד, וקנה עוד. עדיף לרכוש מדורגות.
Compute SP לא מכסה את אלה. שמור על תוכנית RI נפרדת לכל מסד נתונים מנוהל. שילוב של SP + RDS RI הוא הסטנדרט.
Convertible RI היו רלוונטיים ב-2020. היום SP פותרים את אותה בעיה בלי החלפות ידניות. אם יש לך Convertible RI פעילים, בדוק אם כדאי לחכות שיפוגו ולעבור.
קניית EC2 Instance SP ל-3 שנים על משפחת m5 ב-2026 זה הימור גרוע, כי AWS דוחפים לכיוון m7i ו-Graviton. השתמש ב-Compute SP כדי שההנחה תעבור איתך. למידע מעמיק על המעבר, ראה מעבר ל-AWS Graviton 2026.
All Upfront נותן 1.5%–4% הנחה נוספת מעבר ל-No Upfront. אם עלות ההון של הארגון שלך (WACC) גבוהה מהדלתא הזו, No Upfront הוא הבחירה הפיננסית הנכונה. ב-2026 רוב הקרנות נסחרות עם WACC של 8%–12%, מה שהופך את All Upfront לסבירה רק לארגונים ללא חוב.
כדי להעביר את כל מה שאני מתאר כאן לתהליך חוזר, אני משתמש בלוח זמנים רבעוני שמתועד ב-FinOps Foundation Rate Optimization Framework. בכל רבעון: (1) משוך נתוני שימוש 90 יום, (2) חשב baseline צפוי, (3) בדוק SP/RI נוכחיים מול הצפי, (4) קנה דלתא חסרה, (5) עקוב אחרי כיסוי וניצולת. זה מקצר את הוויכוח עם ה-CFO ל-30 דקות במקום שבוע.
למקורות רשמיים מומלץ לעיין ב-תיעוד הרשמי של AWS Savings Plans ובמדריך של AWS על Reserved Instances. שניהם מתעדכנים בקצב גבוה, ושווה לעיין בהם לפני כל רכישה גדולה.
Savings Plans הם התחייבות להוצאה כספית בדולר לשעה, ההנחה חלה אוטומטית על כל מכונה תואמת. Reserved Instances הם התחייבות לקיבולת ספציפית של משפחת מכונה ואזור. SP גמישים יותר, RI מציעים הנחה עמוקה יותר בכמה אחוזים.
לא, אין המרה ישירה. ניתן למכור Standard RI ב-RI Marketplace ולקנות במקומם SP, או לחכות שה-RI יפוג ולא לחדש אותו. Convertible RI גם לא ניתנים להמרה ישירה ל-SP.
Compute Savings Plans מכסים Lambda, Fargate ו-EC2, אבל לא מכסים RDS, ElastiCache, OpenSearch, Redshift או MemoryDB. עבור השירותים האלה עדיין נדרשים Reserved Instances ייעודיים.
השימוש שלך חוזר אוטומטית למחיר On-Demand. AWS שולחים התראה 60 ו-30 יום לפני התפוגה. מומלץ לתכנן רכישה חדשה לפחות 30 יום מראש כדי להימנע מקפיצה בחשבון.
תמיד שיש סבירות שתשנה משפחת מכונה, אזור, או שאתה מריץ גם Fargate או Lambda. ההפרש של עד 6% הנחה ל-EC2 Instance SP לא שווה את הסיכון של נעילה. בחר EC2 Instance SP רק כשיש לך עומס ענק וצפוי לגמרי על משפחה ספציפית.
70%–85% מהבסיס היציב. כיסוי גבוה מ-90% חושף אותך לסיכון של התחייבות בלתי מנוצלת אם השימוש יורד. כיסוי נמוך מ-60% משאיר חיסכון על השולחן. מדוד חודשית והתאם.
מדריך מעשי למעבר מ-x86 ל-AWS Graviton בשנת 2026 עם שלבי מיגרציה, benchmark, תמונות Docker רב-ארכיטקטוניות, NodePool של Karpenter ושילוב עם Savings Plans.