בפוסט שפורסם בבלוג של AWS מציג אסוואת רם א' סריניוואסן מודל תפעולי בן חמישה שלבים לניהול עלויות ב-Amazon Bedrock. לפי המחברים, ניהול עלויות עבור בינה מלאכותית יוצרת (Generative AI) הוא אחריות משותפת של הצוותים שבונים יישומים ושל הצוותים שאחראים על הוצאות הענן. צוותים רבים מתחילים מהשוואת תעריפי טוקנים לפי מודל ומבקשים לקצר הנחיות (prompts), אך צעדים אלה אינם עונים על השאלות שמציגים מובילי כספים והנדסה ככל שהשימוש מתרחב: איזה צוות הוציא את הסכום, על איזה עומס עבודה (workload), והאם ההוצאה הייתה בתוך תקציב מאושר. עומסי עבודה של סוכנים (agentic workloads) מחדדים שאלות אלה, כיוון שעוזר שיחתי טיפוסי מוציא קריאה אחת למודל בכל תור של משתמש, בעוד שתהליך סוכני מוציא קריאות רבות לכל משימה ונושא הקשר (context) גדול יותר בכל קריאה. צריכת הטוקנים גדלה עם מידת האוטונומיה שניתנת לתהליך וגודל ההקשר שהוא נושא, ולא לפי מספר האינטראקציות של המשתמש.
שלב 1: שיוך כל דולר לבעלים (Attribute)
הבסיס לניהול הוצאות הוא שיוך עלויות גרנולרי ב-Amazon Bedrock. השירות משייך עלויות הסקה (inference) ישירות לישות ה-IAM (AWS Identity and Access Management principal) שביצעה את הקריאה, בכל המודלים, ללא צורך בניהול משאבים ייעודיים. ה-ARN של הקורא נרשם בעמודת line_item_iam_principal בדוח העלויות והשימוש (CUR 2.0), והכיסוי כולל משתמשי IAM, תפקידים (roles), זהויות מאוחדות (federated identities) ומפתחות API. הגדרת השיוך כוללת ארבעה צעדים:
- הפעלת נתוני ישויות IAM בייצוא הנתונים של CUR 2.0.
- תיוג ישויות ה-IAM בממדים עסקיים כגון צוות, יישום ומרכז עלות (cost center). בגישה מאוחדת, הגדרת ספק הזהויות להעברת שמות הפעלות (session names) ותגים דרך OIDC או תביעות SAML.
- הפעלת התגים הללו כתגי הקצאת עלויות (cost allocation tags) ב-AWS Billing.
- ניתוח התגים: הם מופיעים ב-CUR 2.0 עם הקידומת iamPrincipal/ ומוצגים ב-AWS Cost Explorer תחת קטגוריית IAM תוך 24 עד 48 שעות מההפעלה, ומאפשרים סינון וקיבוץ לפי צוות, יישום או מרכז עלות.
כאשר שער מודלי שפה (LLM gateway) קורא ל-Amazon Bedrock דרך תפקיד IAM יחיד, נוצרת בעיית שיתוף תפקידים שמבטלת את הנראות לפי משתמש. הפתרון הוא ניהול הפעלות לפי משתמש: השער מקבל את תפקיד ההרצה של Bedrock (באמצעות sts:AssumeRole) פעם אחת עבור כל משתמש, מעביר את זהות המשתמש כ-role session name ואת מאפייניו כתגי הפעלה (session tags), ושומר את האישורים במטמון (cache) למשך עד שעה אחת (קריאת STS אחת למשתמש בכל שעה, במקום קריאה בכל בקשה). בנוסף למנגנון זה, קיימים שני מנגנונים נוספים: פרופילי הסקה ליישומים (Application inference profiles) בנקודת הקצה bedrock-runtime הנושאים תגי עלויות ומתאימים לקבוצה קטנה ויציבה של יישומים, ופרויקטים וסביבות עבודה (Projects and workspaces) בנקודת הקצה bedrock-mantle המתאימים לעומסי עבודה תואמי OpenAI.
שלב 2: הפיכת כל בקשה לברת-צפייה (Observe)
דוחות CUR מציגים מי הוציא את התקציב, אך יומני קריאות (invocation logs) מסבירים מה התרחש בפועל. Amazon Bedrock תומך ברישום יומני הסקה של נתוני בקשות, נתוני תגובות ומטא-דאטה ל-Amazon CloudWatch Logs, ל-Amazon S3, או לשניהם. יומני CloudWatch מיועדים לשאילתות תפעוליות מהירות, ו-S3 בשילוב Amazon Athena מיועדים לניתוח נתונים ובינה עסקית (BI) לטווח ארוך.
בנוסף, בעוד שנתוני CUR מגיעים בעיכוב של כ-24 שעות, שילוב CloudWatch ו-OpenTelemetry מאפשר בניית לוחות בקרה קרובים לזמן אמת המציגים הוצאה לפי מפתח תוך דקות. כדי להשיג שיוך ברמת עומס העבודה (איזו תכונה, תהליך או דייר יצרו את הטוקנים), ניתן לצרף מטא-דאטה של בקשה (requestMetadata) בכל קריאה ל-Converse API. שדות אלה כוללים application, workflow, tenant ו-agent. מאחר ש-Bedrock אינו אוכף מטא-דאטה זו באופן אוטומטי, המחברים ממליצים שצוות הפלטפורמה יזריק מטא-דאטה אחידה דרך עטיפת SDK משותפת או שער. באמצעות CloudWatch Logs Insights ניתן להריץ שאילתות שמזהות את הקוראים שצורכים את מספר הטוקנים הגבוה ביותר, או לקבץ לפי יישום ותהליך כדי לבנות טבלת מובילים (leaderboard).
שלב 3: אכיפת תקציבים בשלוש רמות (Enforce)
אכיפת תקציבים ניתנת למימוש בשלוש רמות ארכיטקטוניות בהתאם לקצב ההוצאה ורמת הסיכון:
- רמה 1: ניטור והתראה (ללא חסימה). שימוש ב-AWS Budgets לשליחת התראות חריגה ובלוחות OpenTelemetry לנראות שוטפת. אין רכיבים שיש לפרוס ואין השהיה נוספת על קריאות ההסקה, אך לא מתבצעת חסימה קשיחה וההוצאה מתגלה לאחר התרחשותה. מתאים לשלבי אימוץ ראשוניים.
- רמה 2: אכיפת תגי IAM (חסימה לאחר חריגה). פונקציית AWS Lambda מחשבת מונים של טוקנים ודולרים מיומני ההסקה ב-Amazon DynamoDB. כאשר משתמש חורג מהסף, הפונקציה מוסיפה את זהותו למדיניות שלילת גישה ב-IAM (המונעת bedrock:*) עד לאיפוס חודשי או התערבות מנהל. האכיפה פועלת באופן אסינכרוני: החסימה נכנסת לתוקף שניות עד דקות לאחר הקריאה שחרגה בעדכון מדיניות IAM, או ברענון האישורים הבא כאשר מיושמת בדיקת מגבלות בעת הנפקת אישורים.
- רמה 3: אכיפה מבוססת שער (חסימה סינכרונית). שער המוצב בנתיב הנתונים של ההסקה ואוכף תקציבים בזמן אמת על ידי החזרת קוד שגיאה HTTP 429 ברגע שמשתמש או צוות חורגים מהמגבלה. רמה זו מספקת חסימה בפחות משנייה, רשימות מודלים מורשים (allowlists), מגבלות קצב טוקנים וכללי ניתוב מרכזיים, אך דורשת פריסה, ניהול אבטחה וניתוב הבקשות דרך השער. עבור ציי Claude Code ו-Claude Desktop, שער Claude apps gateway for AWS רץ כמכל יחיד (container) מבוסס PostgreSQL. עבור מודלים מעורבים, ניתן להשתמש ב-LiteLLM על גבי Amazon ECS ב-AWS Fargate.
הבחירה בין הרמות תלויה בקישוריות (אם מפתחים פונים ישירות ל-Bedrock ללא פרוקסי, רק רמות 1 ו-2 ישימות) ובקצב ההוצאה.
שלב 4: מיטוב ברירות המחדל של הפלטפורמה (Optimize)
מרבית הבזבוז אינו נובע מחוסר זהירות של מפתחים, אלא מברירות מחדל של הפלטפורמה שאיש לא הגדיר. שני המנופים המרכזיים הם:
- ניתוב מודלים (Model routing): משימות שגרתיות (כגון השלמת תבניות, הצעות linting ושינויי קוד קלים) יכולות לרוץ על מודלים קטנים וזולים יותר, בעוד מודלים מובילים נשמרים להסקה מורכבת. הדבר מתבצע באמצעות ניתוב הנחיות חכם (Intelligent Prompt Routing) או חוקי ניתוב בשער. בציים של כתיבת קוד על ידי סוכנים, יעד בר-השגה הוא הפניית יותר ממחצית מהקריאות למודלים זולים יותר.
- שמירת הנחיות במטמון (Prompt caching): התכונה מתגמלת קידומות יציבות וחוזרות. נכון לאוקטובר 2026, לפי התמחור של Amazon Bedrock שפורסם עבור דגמי Anthropic Claude באזור US East (צפון וירג'יניה), כתיבה למטמון מתומחרת בפי 1.25 מתעריף הקלט הבסיסי עם TTL של 5 דקות (ופי 2 עם TTL של שעה אחת). קריאה מהמטמון מתומחרת בפי 0.1 מתעריף הקלט ב-Claude Sonnet 4.6 ו-Claude Haiku 4.5, ובפי 0.05 ב-Claude Sonnet 5.5 ו-Claude Opus 5.5. ב-TTL של 5 דקות, שימוש חוזר יחיד מכסה את עלות הכתיבה, ועשר קריאות מול קידומת יציבה עולות כחמישית ממחיר ללא מטמון. המצב המפסיד היחיד הוא כתיבה שלעולם אינה נקראת שוב, המוסיפה 25% לעלות ב-TTL של 5 דקות ומכפילה אותה ב-TTL של שעה.
מיטוב ברמת היישום (כגון שליפה במועד הצורך במקום context מנופח או דחיסת שיחות) נמצא באחריות צוותי הפיתוח, וצוות הפלטפורמה תומך בכך באמצעות חשיפת מדדי הצריכה והגדרת מגבלות טוקנים.
שלב 5: הפעלת הלולאה ומדדי ביצועים (Operate)
שלב זה מתרגם את הנתונים להחלטות שוטפות. צוות הפלטפורמה מפעיל לוח בקרה עם ארבעה אותות: תמהיל מודלים (אילו מודלים נקראים ובאיזו תדירות), שיעורי בקשות שנכשלו (שגיאות, ויסות/throttles ופקיעת זמן, כאשר ניסיון חוזר עלול לגרום לחיוב כפול), יעילות המטמון (יחס קריאה מול כתיבה), וכיסוי מטא-דאטה (אחוז הקריאות בסביבת הייצור הנושאות מטא-דאטה מלאה).
צוות ה-FinOps מנהל את בדיקות החריגות וחלוקת העלויות (chargeback) לפי צוות ויישום. לשם כך הוצג לוח מדדים (Scorecard) הכולל ארבעה ממדים עם ספי ביצועים (ירוק, צהוב, אדום):
- כלכלת יחידה (Unit economics): עלות לתוצאה מוצלחת – ירוק כאשר קטן או שווה לתקציב, צהוב בטווח של פי 1 עד 1.5 מהתקציב, ואדום מעל פי 1.5 מהתקציב.
- עלות למפתח (Per-dev cost): הוצאה יומית למפתח – ירוק מתחת ל-100 דולר, צהוב בין 100 ל-300 דולר, ואדום מעל 300 דולר.
- ניתוב מודלים (Model routing): אחוז הקריאות למודלים חסכוניים – ירוק מעל 50%, צהוב בין 30% ל-50%, ואדום מתחת ל-30%.
- יעילות מטמון (Cache efficiency): יחס פגיעה בקריאה מהמטמון – ירוק מעל 60%, צהוב בין 30% ל-60%, ואדום מתחת ל-30%.
המחברים מדגישים כי ספים אלה מהווים נקודת מוצא ולא הנחיה מחייבת, ויש לכיילם בהתאם לנתוני הצי ותעריפי התמחור. בנוסף, בפוסט מודגשת ההבחנה בין עלות לתוצאה מוצלחת לבין עלות לקריאה יחידה, שכן תהליך עבודה יכול להיות יעיל לחלוטין מבחינת עלויות ועדיין לא כדאי להפעילו ללא מדידת הסוכן בהשוואה לתהליך האנושי שהוחלף.