AWS מציעה דרך חדשה לבדוק מראש עד כמה תצורת EC2 גמישה מבחינת קיבולת, ולמדוד לאחר מכן מה באמת סופק. בפוסט רשמי שפורסם ב-4 בנובמבר 2026 הציגה החברה יכולות חדשות ב-Amazon EC2 Capacity Manager: ציוני Supportability לתכנון מוקדם ומדדי Capacity Fulfillment לניתוח בקשות הפעלה שבוצעו בפועל.
המטרה היא להתמודד עם בעיה מוכרת: תצורה שתלויה בסוג מופע יחיד ובאזור זמינות אחד עלולה להיתקל במחסור זמני. עד היום ארגונים גילו לעיתים את מגבלת הגמישות בזמן scale-out או אירוע תפעולי. הכלים החדשים מאפשרים לקבל אינדיקציה עוד לפני השקת מופעים, ולאחר מכן לבדוק כמה מהקיבולת המבוקשת אכן סופקה ומאילו שילובים.
Supportability: בדיקת אפשרויות בלי להפעיל מופעים
בדיקת Supportability מאפשרת להעריך שילובים של instance types ו-Availability Zones בלי ליצור מופעים או הזמנת קיבולת. התוצאה מוצגת כציון High, Medium או Low. לפי AWS, הציון הוא הנחיה תכנונית ולא התחייבות לכך שהקיבולת תהיה זמינה ברגע מסוים.
אפשר לבדוק עד עשרה אזורי זמינות, יותר מאזור גאוגרפי אחד ועד מאה שילובים. כך ניתן להשוות, למשל, האם קבוצת Auto Scaling המבוססת על משפחה אחת של מופעים גמישה פחות מתצורה שמכילה מספר משפחות וגדלים בעלי ביצועים דומים.
Capacity Fulfillment: מה קרה בזמן אמת?
החלק השני מנתח בקשות הפעלה אמיתיות. Capacity Manager מציג כמה vCPU התבקשו, כמה סופקו, מהו שיעור המימוש המשוקלל וכמה שילובים של סוג מופע ואזור זמינות השתתפו. הנתונים עוזרים לזהות אם שיעור מימוש נמוך נבע מתלות באפשרות צרה או מבעיה נקודתית.
- Fulfillment rate: היחס בין הקיבולת שהתבקשה לזו שסופקה.
- גיוון התצורה: מספר השילובים של סוגי מופעים ואזורי זמינות.
- מקור הקיבולת: היכן נמצאו המשאבים שהשלימו את הבקשה.
- סינון ארגוני: אפשר להפעיל את היכולת בחשבון יחיד או ברמת ארגון, ולהשתמש בתגיות לפי הצורך.
איך להשתמש במידע בפועל?
הציון אינו אמור להישאר בדוח. AWS ממליצה להזין את הממצאים בחזרה לתצורות שמבצעות את ההשקה: Auto Scaling Groups, EC2 Fleet או Karpenter. אם סוג מופע מסוים מקבל ציון נמוך, ניתן להוסיף חלופות שמתאימות לאותה מעטפת ביצועים. אם אזור זמינות יחיד יוצר תלות, אפשר להרחיב את הפיזור.
ב-Kubernetes, לדוגמה, צוות יכול להגדיר ל-Karpenter מספר משפחות וגדלים במקום instance type יחיד. ב-EC2 Fleet אפשר להגדיל את מגוון האפשרויות ולבחון אם אלגוריתם ההקצאה מנצל אותן. בקבוצות Auto Scaling כדאי לוודא שהדרישות מבוססות מאפיינים מאפשרות מספיק חלופות ואינן מצמצמות את הבחירה בלי צורך.
ציון גבוה אינו שריון
חשוב להבין את גבולות הכלי. Supportability משקף תמונת מצב ומספק כיוון, אך אינו שומר קיבולת. עבור עומסים שבהם יש צורך בוודאות גבוהה, AWS מפנה לשירותי Capacity Reservations. בנוסף, ציון נמוך אינו בהכרח סיבה להחליף ארכיטקטורה מיד; הוא סימן לבדוק עד כמה העומס יכול להתרחב, האם קיימות חלופות ומהי עלות הכשל.
רשימת בדיקה לצוותי ענן
- הריצו בדיקת Supportability על תצורות הייצור הקריטיות ועל תרחישי scale-out.
- הוסיפו לפחות כמה חלופות שקולות מבחינת זיכרון, CPU, ארכיטקטורה ומאפייני רשת.
- בדקו מדדי Fulfillment אחרי אירועי גידול, deployments גדולים או עומסי שיא.
- שלבו בדיקת גמישות בתהליך change management, ולא רק בתחקיר אחרי כשל.
- בחנו את הנתונים מדי שבוע, כפי שממליצה AWS, כדי לזהות שחיקה לפני אירוע.
זמינות ותמחור תפעולי
AWS מציינת ששתי היכולות כלולות במסגרת תוכנית התמיכה AWS Unified Operations. לכן ארגונים צריכים לבדוק אם החשבונות הרלוונטיים משויכים לתוכנית ומהי מדיניות הגישה לנתונים ברמת הארגון.
השורה התחתונה
Capacity Manager הופך את גמישות הקיבולת למשהו שניתן למדוד לפני ואחרי ההשקה. במקום להסתפק בהמלצה כללית "להשתמש ביותר מסוג מופע אחד", צוותי ענן יכולים לראות אילו שילובים נראים נתמכים יותר, למדוד את שיעור המימוש בפועל ולשנות את תצורת ההקצאה. זו אינה הבטחת קיבולת, אבל היא שכבת תכנון שימושית שמחברת בין ארכיטקטורה, תפעול ונתוני אמת.
מקורות: AWS Compute Blog, 4 בנובמבר 2026; תמונת המקור ב-Unsplash.
צילום: Patrick Federi (@federi), Unsplash. התמונה היא המחשה מטפורית בלבד, בהתאם לרישיון Unsplash.
