AWS מחייבת אותך בתעריפי on-demand עד שתבצע התחייבות. Reserved Instances (RI) ו-Savings Plans (SP) הם המנגנונים להתחייבות זו. עם ניתוח נכון, החיסכון ב-EC2, RDS ו-Lambda נע בין 40% ל-72% בהשוואה ל-on-demand. אם טועים, אתם נועלים כסף בהזמנות שלא מנוצלות. חשבון הענן החודשי של חברה טיפוסית מכיל בזבוז נסתר—סביר שאתם משלמים יותר ב-30–40% עקב שימוש לא אופטימלי בהזמנות. עבור לקוח עם חשבון חודשי של $50,000, קיצצנו עלויות ל-$25,000 לאחר יישום Compute SP. הארכיטקטים המוסמכים של AWS בחברה שלנו בעלי ניסיון של למעלה מ-5 שנים וביצעו 50+ פרויקטים עם חיסכון ממוצע של 45%. אנו מבטיחים חיסכון מינימלי של 20% על ההוצאה הזכאית או שנשפר את האסטרטגיה ללא עלות נוספת. צרו קשר לניתוח החשבון שלכם—נעריך את הפרויקט ביום אחד.
לכן, המטרה אינה "קניית RI" אלא זיהוי עומס הבסיס היציב וכיסויו בהזמנות, תוך השארת החלק המשתנה ל-Spot או ל-on-demand.
Reserved Instances ו-Savings Plans: הבדלים עיקריים
Reserved Instances מקושרות לסוג מופע ספציפי, אזור, ובאופן אופציונלי ל-Availability Zone. RI סטנדרטיות מציעות את ההנחה המקסימלית אך אינן ניתנות להמרה. RI ניתנות להמרה מאפשרות לשנות משפחת מופע, מערכת הפעלה או tenancy במהלך התקופה—שימושי אם אתם מתכננים הגירה ל-Graviton.
Savings Plans גמישות יותר. Compute Savings Plans מכסות EC2 (כל משפחת מופע, אזור, מערכת הפעלה), Fargate ו-Lambda עם התחייבות שעתית אחת בדולרים. EC2 Instance Savings Plans מקושרות למשפחת מופע ספציפית באזור אך מציעות הנחה מעט גדולה יותר.
עבור רוב החברות, אנו ממליצים כעת על Compute SP: הגמישות חשובה יותר, במיוחד אם אתם מתכננים מעבר ל-Graviton או שינוי סוגי מופעים. הפרש ההנחה בין Compute ל-EC2 Instance SP הוא בדרך כלל 5–8%. Compute SP גמיש פי 2 מ-EC2 Instance SP בשל כיסוי שירותים שונים. כמו כן, תשלום No Upfront פחות מסוכן ב-5% מ-All Upfront מכיוון שאתם נמנעים מנעילת הון.
כיצד לנתח עומס עבודה עבור Savings Plans?
הכלי המרכזי הוא AWS Cost Explorer עם המלצות Savings Plans מופעלות. אך ההמלצות ברירת המחדל של AWS מסתכלות על 30 הימים האחרונים. אם החודש האחרון היה לא טיפוסי (חגים, השקת קמפיין שיווקי, בדיקות עומס)—ההמלצות יהיו לא מדויקות.
הגישה הנכונה: נתחו היסטוריה של 3–6 חודשים. בנו התפלגות אחוזונים של הצריכה—p50 (חציון) הוא בערך מה שצריך לכסות בהזמנות. ההפרש בין p50 ל-p90 הוא מועמד ל-Spot. כל מה שמעל p90—on-demand או קנה מידה אוטומטי.
Базовая нагрузка (p50) → Savings Plans / RI (1-year No Upfront)
Переменная нагрузка (p50-p90) → Spot Instances + Spot Fleet
Пики (>p90) → On-demand (Auto Scaling)ב-Cost Explorer, יש Базовая нагрузка (p50) → Savings Plans / RI (1-year No Upfront) Переменная нагрузка (p50-p90) → Spot Instances + Spot Fleet Пики (>p90) → On-demand (Auto Scaling) —הסתכלו על מדד זה לאורך זמן, לא רק בתמונות יומיות.
מידע נוסף על אחוזונים
p50 הוא הערך שמתחתיו נמצאות 50% מהתצפיות. לדוגמה, אם שעה אחת צורכת 10 יחידות EC2 והשעה הבאה 20, אז p50 = 15. השתמשו ב-p50 כעומס הבסיס להזמנה. p90 הוא הערך שמתחתיו נמצאות 90% מהתצפיות—כסו זאת עם Spot.מדוע Compute Savings Plans לרוב עדיפות?
הן מכסות לא רק EC2 אלא גם Fargate ו-Lambda. אם הארכיטקטורה שלכם כוללת קונטיינרים או serverless, זה נותן גישת אופטימיזציה אחידה. לפי תיעוד AWS Compute Savings Plans, התחייבות אחת מכסה את כל שלושת השירותים, מה שמפשט את הניהול. לדוגמה, חברה עם 30% עומס על ECS ו-10% על Lambda יכולה לחסוך בכל השירותים עם התחייבות אחת, במקום לקנות RI נפרדות לסוגי מופעים שונים.
באיזו אפשרות תשלום לבחור?
| סוג תשלום | הנחה נוספת לעומת No Upfront | מתי זה משתלם |
|---|---|---|
| All Upfront | ~5% | אם יש לכם מזומנים עודפים ועומס יציב ל-3 שנים |
| Partial Upfront | ~2–3% | פשרה: חיסכון קטן ללא תשלום מקדמה מלא |
| No Upfront | קו בסיס | הטוב ביותר לרוב—גמישות וללא הון מוקדם |
No Upfront הוא אופטימלי ברוב המקרים: ללא נעילת הון, הפסד מינימלי אם סוגרים את החשבון או משנים ארכיטקטורה.
השוואה בין RI ל-SP
| מאפיין | Reserved Instances | Savings Plans |
|---|---|---|
| גמישות | נמוכה (מקושרת לסוג מופע) | גבוהה (Compute SP מכסה שירותים מרובים) |
| הנחה מקסימלית | עד 72% | עד 72% (תלוי בתקופה ובתשלום) |
| כיסוי | EC2, RDS, ElastiCache | EC2, Fargate, Lambda |
| מכירה ב-Marketplace | כן | לא |
תקופה: שנה אחת לעומת 3 שנים
שנה אחת היא הבחירה הסטנדרטית. 3 שנים מציעות הנחה גדולה עוד יותר (~15% נוסף), אך אופק תכנון של שלוש שנים בתשתית ענן הוא נדיר. בשלוש שנים, משפחות מופעים יכולות להתיישן, אזורים משתנים, והארכיטקטורה עשויה לנוע לכיוון serverless.
חריג: RDS RI עבור מסדי נתונים בייצור. אם PostgreSQL או MySQL על RDS פועלים ביציבות מספר שנים ואין תוכניות הגירה—RI ל-3 שנים מוצדקת.
שלב אחר שלב: הגדרת Savings Plans
- איסוף נתונים: ייצוא דוחות Cost and Usage למשך 3–6 חודשים.
- קביעת עומס הבסיס: חישוב p50 של צריכת EC2, Fargate, Lambda.
- בחירת סוג SP: Compute או EC2 Instance, בהתאם ליציבות העומס.
- בחירת תקופה ותשלום: שנה אחת, No Upfront לרוב.
- רכישת SP דרך Console או AWS CLI.
- הגדרת התראות ב-Cost Explorer: הודעה כאשר הכיסוי < 80%.
מה כלול בשירות זה
- ייצוא וניתוח דוחות Cost and Usage למשך 3–6 חודשים
- המלצות המבוססות על שיעור ניצול בפועל
- הערכת הזמנות לא מנוצלות למכירה ב-Marketplace
- ביצוע רכישה דרך Console או CLI
- הגדרת התראות לניטור כיסוי
- תיעוד אסטרטגיה ותוכנית ניטור
- הדרכת צוות על Cost Explorer
- תמיכה בסקירת אסטרטגיה לאחר 6 חודשים
- הגדרת גישה ל-AWS Cost Explorer ואופטימיזציה
- תיעוד מלא של האסטרטגיה ותמיכה שוטפת
לוחות זמנים משוערים
ניתוח והכנת המלצות—יום אחד. אישור ורכישה—חצי יום. סה"כ: 2–3 ימי עסקים, כולל איטרציות לדיון באסטרטגיה עם הצוות שלכם. התמחור נקבע לאחר הערכה ראשונית.
רוצים לקצץ בעלויות AWS שלכם ב-40–72%? הזמינו ניתוח של החשבון שלכם—נעריך את הפרויקט ביום אחד. קבלו ייעוץ על אופטימיזציית עלויות AWS עכשיו.