10 ההכרזות מ-re:Invent שמפתחי AWS חייבים להכיר

530 הכרזות בשבוע אחד הן לא roadmap. הן רעש, עד שמישהו מחבר אותן לבעיה שיש לכם בצוות. איתי שפיר ו-שני קזאז מ-AWS לא מנסים לעבור על כל re:Invent. הם מסננים את ההכרזות שיכולות לשנות החלטה אמיתית: איפה להשאיר workload ב-Lambda, איך לחשוף agents, ואיך להפסיק להפיל את כל מורכבות Kubernetes על המפתחים.

המסר שחוזר לאורך ההרצאה פשוט: כלי חדש לא מוחק ownership. אפשר לתת ל-AI לכתוב קוד, להריץ agent או להקים תשתית, אבל מישהו עדיין צריך להבין מה עלה לפרודקשן ולתחזק אותו כשהוא נשבר. לכן הרשימה כאן אינה “10 פיצ’רים מגניבים”. היא אוסף של tradeoffs עבור מי שבונה על AWS.

לפני ההכרזות: מפתח צריך לחשוב מעבר לשירות אחד

איתי פותח בדמות המפתח המודרני כפי שהוצגה בכנס: סקרנות, חשיבה מערכתית, יכולת להעביר intent לכלי AI, ownership ורוחב מקצועי. זה לא אומר שכל backend developer צריך להפוך ל-DevOps. זה כן אומר שמיקרו-שירות אינו קופסה שאפשר לפתח בלי להבין תלות, תשתית ודרך הפעלה.

הנקודה חדה במיוחד מול code generation. הקוד יכול להיווצר מהר, אבל אין לו owner מעצם זה שהוא נוצר. אם הוא מגיע לפרודקשן, הצוות צריך לדעת למה הוא עושה מה שהוא עושה ואיך בודקים אותו. גם כש-AWS מוסיפה שכבות מנוהלות, האחריות על ההתאמה ל-workload נשארת אצלכם.

חייבים להבין מה הוא עשה, למה הוא עשה, כי בסוף משהו צריך לתמוך בו בפרודקציה.

Lambda מתחילה להחזיק תהליכים שלא נגמרים מיד

ההכרזה הראשונה היא Lambda Durable Functions. במקום לחבר בעצמכם שירותי orchestration או לרוץ מחדש מתחילת flow, ה-SDK מאפשר checkpoints, השהיה, המתנה ל-timer או ל-callback והמשך מאותה נקודה. איתי ממקם את זה ליד מי שכבר מימש saga pattern או תהליך orchestration ורוצה לכתוב אותו בקוד.

חשוב לא להשליך על זה יותר מדי. זו עדיין אותה Lambda, וכל ריצה שלה מוגבלת ל-15 דקות. ההרחבה אינה הופכת Lambda ל-worker אינסופי. היא נותנת דרך לשמור state ולחזור לתהליך ארוך, כולל קריאות Lambda מקוננות, בלי לאבד את מה שכבר הושלם.

Lambda Managed Instances מטפלת באילוץ אחר: workload שזקוק ל-CPU, אבל עד היום אילץ אתכם לבחור הרבה memory כדי לקבל אותו. כאן אפשר לקבוע יחס CPU ל-memory ולהריץ את Lambda על instances בתוך ה-VPC. לפי ההרצאה, זו דרך להעביר workloads מ-burstable ליותר predictable - למשל end-to-end testing שרץ ברצף לאורך היום - בלי לבצע מיד מיגרציה לקונטיינרים.

הבחירה עדיין מתחילה בפרופיל העבודה. אם התנועה קופצנית, Lambda הקלאסית נשארת הגיונית. אם העומס קבוע והמחיר או יחס המשאבים לא הגיוניים, Managed Instances פותחת חלופה. זה לא “Serverless בכל מחיר”. זה עוד מנוף לפני שמחליפים runtime.

Multi-tenant בלי שיתוף שלא ביקשתם

Tenant Isolation Mode נוגעת בשאלה רגישה יותר: מה בדיוק משותף בין לקוחות באותה סביבת Lambda. Firecracker כבר סיפקה בידוד, אבל ההכרזה מוסיפה הבטחה שלפיה tenant עם מזהה ייחודי יקבל Lambda משלו, בלי sharing של storage או memory מול tenants אחרים.

אין שום שיירינג בין ה-Storage, ה-Memory, לבין כל טננט וטננט בסביבה שלכם.

זה רלוונטי במיוחד לארגונים שעובדים ב-multi-tenancy ובתחומים מפוקחים. ההרצאה לא מציגה אותו כשדרוג ביצועים כללי, אלא כתשובה לדרישת בידוד. זה הבדל חשוב: לפני שמדליקים את היכולת, צריך לדעת איזה סיכון מוצרי או רגולטורי אתם באמת פותרים.

API Gateway הופך לשכבה פעילה יותר

אחרי שנים שבהן API Gateway קיבל פחות תשומת לב, שלוש הכרזות מכוונות לחוויית הפיתוח ולמערכות agentic. MCP Proxy Support מחבר בין API Gateway ל-Agent Core Gateway. הרעיון הוא לרכז agents ב-gateway אחד, לבצע ביניהם orchestration, ואז לחשוף אותם כ-MCP לצריכה בתוך הארגון או מחוצה לו. החיבור מוסיף גם semantic search כדי שקליינט יוכל למצוא אילו כלים זמינים לו.

ההכרזה השנייה היא response streaming. שאר ה-stack כבר תמך ב-streaming, אבל API Gateway היה החוליה שחסרה. עכשיו אפשר להחזיר תוכן בהדרגה, גם עבור LLMs, במקום לחכות שכל התשובה תסתיים. מבחינת המשתמש, זה בעיקר time to first byte. מבחינת המערכת, עדיין צריך לחשוב על timeout, טיפול בשגיאות ומה קורה אם הזרם נקטע.

השלישית היא Developer Portal. בארגון עם עשרות microservices, מפתח חדש לא בהכרח יודע אילו APIs פנימיים קיימים ואיך להשתמש בהם. הפורטל מרכז סכמות, תיעוד ואפשרות להתנסות ב-APIs. זו לא תשתית שמחליפה חוזה API טוב, אבל היא יכולה להפסיק את החיפוש בין repositories, Slack ואנשים שיודעים במקרה מה קיים.

התמיכה הרשמית ב-Rust ב-Lambda משלימה את הצד הזה. היא מצטרפת לשפות שכבר נתמכות סביב Lambda ו-CDK. גם כאן, השפה אינה סיבה לכתוב מחדש שירות עובד. היא אופציה למי שכבר בחר ב-Rust ורוצה להישאר באותו מודל הפעלה.

EKS Capabilities: Platform Engineering במקום טופס תשתית

שני מעבירה את השיחה לקונטיינרים ול-EKS Capabilities. EKS הוא Kubernetes מנוהל, אבל Kubernetes מנוהל עדיין יכול להיות מערכת מורכבת מאוד למפתח. ההגדרה שלה ל-Platform Engineering היא מוצר פנימי שנותן למפתחים עצמאות להרים תשתית דרך פורטל, CLI או קוד, במקום לפתוח בקשה לכל רכיב.

היעד אינו להסתיר הכול. הוא להסתיר את ההחלטות שכבר התקבלו על ידי צוות הפלטפורמה, ולהשאיר למפתח את הבחירות ששייכות לאפליקציה. היא מביאה דוגמה לחברה שהורידה זמן שירות משלושה שבועות לשלוש שעות. זה לא קסם של UI: זה קורה רק כשהמוצר הפנימי מקודד guardrails, תבניות ותהליך הקמה.

EKS Deployments הוא Argo CD מנוהל עבור GitOps. במקום להתקין, לעדכן ולתחזק את Argo CD, אפשר לפרוס מקלאסטר אחד לקלאסטרים ול-VPCs אחרים, כולל cross-account. משמעות GitOps כאן היא שהמצב ב-Git repository אמור להיות המצב בפרודקשן. זה מקצר את מסלול הפריסה, אבל לא פוטר אתכם מבדיקת שינויים לפני merge.

כשה-control plane שולט גם ב-S3

Cloud Resource Orchestration ו-Cloud Resource Composition מטפלות בפיצול שמוכר לכל צוות Kubernetes: ה-manifests של הפודים נמצאים במקום אחד, ו-S3 או SQS שהתוכנה צריכה מוקמים דרך Infrastructure as Code ו-pipeline אחר. שני מתארת יכולת לשלוט ממשאבי Kubernetes גם במשאבי ענן, כך שאפשר לנהל S3 דרך אותו control plane.

אני יכולה לשלוט ב-S3 בדיוק כמו שאני שולטת ב-Pod.

Composition מוסיפה את הצורך בסדר: קלאסטר דורש VPC, ורכיבים שונים צריכים פרמטרים זה מזה. המטרה היא להגדיר את הממשק הפשוט למפתח, בזמן שצוות הפלטפורמה קבע מאחוריו את סדר ההקמה וההחלטות. אם הצוות שלכם כבר מחזיק Terraform מסודר, זו אינה בהכרח סיבה להחליף הכול. אם הפיצול בין הכלים הפך ל-overhead, זו נקודת בדיקה טובה.

בסיום, השניים מציגים MCP מנוהל ל-EKS ול-ECS, ואינטגרציה של Q Developer בקונסול. המטרה היא לתת דרך שיחתית לחקור באג בקלאסטר. גם כאן כדאי להיזכר בפתיחה: כלי חקירה יכול לקצר זמן, אבל הוא לא מחליף הבנה של המערכת.

השורה התחתונה

• Durable Functions מתאימות ל-orchestration שמצריך state, checkpoint והמשך עבודה, לא לריצה בלתי מוגבלת.
• Managed Instances ו-Tenant Isolation פותחות אפשרויות חדשות ל-workloads צפויים ולמוצרי multi-tenant, אבל כל אחת פותרת כאב אחר.
• MCP Proxy, streaming ו-Developer Portal הופכים API Gateway לשימושי יותר גם עבור agents וגם עבור מפתחים אנושיים.
• EKS Capabilities מבטיחות פחות חיכוך רק אם צוות הפלטפורמה מגדיר מוצר פנימי, guardrails ובעלות ברורה.

להרצאות נוספות על ארכיטקטורה ותשתיות, אפשר לחזור למיטאפים. ההרצאה המלאה שווה צפייה למי שצריך להחליט מה לבדוק עכשיו, ומה להשאיר כרגע ברשימת המעקב.