מפתחות AWS Bedrock מוגנים כעת על ידי LLM gateway פנימי המאפשר לכל צוות בחברת פינטק לקרוא למודלים, אך כל בקשה קשורה לתקציב טוקנים (tokens) ייעודי לכל צוות. השינוי עוצר את הפרקטיקה של פיזור אישורי IAM בין מאגרים (repos) ו-Jupyter notebooks, הרגל שכבר איים לרוקן את הוצאות ה-AI של החברה בערך אחר צהריים אחד.
למה חלוקת מפתחות AWS הופכת במהירות לבלגן
קבוצות לא-טכניות בארגון ביקשו גישה ישירה למודלי השפה של החברה. על הנייר, התשובה הפשוטה ביותר הייתה להפעיל את המודלים ב-AWS ולהעניק לכל קבוצה הרשאת IAM. עשר דקות של עבודה, כמה עריכות מדיניות, והעבודה הושלמה — לפחות בתיאוריה.
בפועל, חלוקת אישורי IAM יוצרת שלושה עלויות נסתרות:
- פיזור אישורים (Credential sprawl) – מפתחות מסתיימים בקבצי
.env, בצינורות CI, ב-Jupyter notebooks ובסקריפטים אד-הוק. כל עותק הופך לנקודת כשל כאשר נדרשת החלפה (rotation). - אפס נראות (Zero visibility) – מפתח משותף יחיד אינו נותן שום רמז לאיזה צוות או לחלק קוד מסוים נוצר השימוש. כאשר לולאה בלתי נשלטת מתחילה, ניתן לצרוך את כל התקציב לפני שמישהו בכלל שם לב.
- עומס תפעולי (Operational overhead) – מעקב אחר מי מחזיק באיזו הרשאה, ביטול גישה וביצוע ביקורת (audit) על השימוש הופכים במהירות לתהליך ידני ומועד לטעויות.
צוות הפינטק הבין שה"תיקון המהיר" יהפוך במהרה לסיוט של אבטחה ועלויות.
בניית reverse-proxy gateway במקום זאת
הפתרון היה להכניס reverse proxy דק בין כל אפליקציה פנימית לבין AWS Bedrock. ה-proxy מחזיק את אישורי ה-AWS האמיתיים במיקום אחד מאובטח ב-vault ומנפיק טוקנים קצרי-אורך וקריאים לבני אדם (למשל, lllkey_9f3c) למי שקורא לו.
נקודות עיצוב מרכזיות:
- שום אישורי AWS לא עוזבים את ה-gateway – מפתחים ושירותים לעולם לא רואים את מפתחות ה-IAM האמיתיים.
- אכיפת מדיניות לפי טוקן – ניתן להגביל כל טוקן למשפחת מודלים ספציפית או למכסה מקסימלית של טוקנים.
- תיעוד מלא (Full audit trail) – כל בקשה מתועדת (logged) עם שם.
איך ה-gateway מעבד בקשה
- קבלת טוקן – הלקוח כולל את הטוקן שלו
llmkey_…בכותרת ה-HTTP. - אימות טוקן – ה-gateway בודק את סטטוס הטוקן (פעיל, לא פג תוקף) ואם הבקשה נשארת במסגרת התקציב שהוקצה.
- רשימת מודלים מורשית (Model whitelist) – הוא מאשר שהמודל המבוקש מותר עבור אותו טוקן.
- העברה ל-Bedrock – הבקשה נשלחת ל-AWS באמצעות אישורי ה-IAM השמורים.
- תיעוד וחיוב – השימוש בטוקנים, שם המודל והערכת העלות נכתבים למסד נתונים מרכזי לצורך דיווח.
מכיוון שחברת הפינטק חייבת לשמור את כל הנתונים בתוך הרשת שלה, הצעה של SaaS מצד שלישי לא הייתה רלוונטית.
מה החברה הרוויחה
- שליטה במודלים – ניתן להגביל צוותים שזקוקים רק למודל בעלות נמוכה אליו, ובכך למנוע שימוש מקרי בגרסאות יקרות ובעלות קיבולת גבוהה יותר.
- הגנה על התקציב – לטוקנים יש מכסת טוקנים קשיחה. כאשר מגיעים למכסה, ה-gateway מחזיר שגיאה במקום לצרוך קרדיטים נוספים בשקט.
- ייחוס (Attribution) עבור מחלקת הכספים – לוח בקרה (dashboard) שנבנה על בסיס יומני השימוש מציג בדיוק איזה צוות או שירות הוציאו כמה על AI, והופך גיליון אלקטרוני מעורפל לדוח שקוף.
גם זרימת העבודה התפעולית השתנתה. אין צורך במדיניות IAM חדשה, אין צורך ברוטציה של סודות (secret rotation), ואין סיכון שאישורים ידלפו לבקרת גרסאות (version control).
טיעון נגד: למה לא להשתמש בשירות מנוהל
התנגדות נפוצה היא שבניית gateway מותאם אישית מוסיפה מאמץ הנדסי ותחזוקה. במקרה של חברת הפינטק, הצורך לשמור את כל תעבורת ה-AI ונתוני השימוש מאחורי חומת האש (firewall) של החברה גבר על הנוחות של פתרון מצד שלישי. ה-proxy הפנימי דרש סוף שבוע של פיתוח, אך הוא ביטל חודשים של ניקוי אישורים וחריגות תקציב שהיו באותות בעקבות גישת חלוקת המפתחות הנאיבית.
שורה תחתונה
חלוקת מפתחות AWS Bedrock היא קיצור דרך שהופך במהירות לסיוט של אבטחה ותקציב. reverse-proxy gateway צנוע — שנבנה בסוף שבוע — מרכז את האישורים, אוכף מגבלות לכל צוות ומספק את תיעוד הביקורת (audit trail) שהכספים צריכים. עבור כל ארגון שרוצה לאפשר לקבוצות מרובות להתנסות ב-LLMs מבלי לוותר על השליטה, גישת ה-gateway מחזירה את ההשקעה שלה באמצעות מניעת תקריות ונראות ברורה יותר של ההוצאות.