Amazon Bedrock AgentCore: 45 דקות מבוזבזות על כל תקלה

ה-30–45 דקות שאתם לא מחשיבים

כל מי שעבד ב-DevOps או SRE מכיר את הריטואל. תקלה ב-production. פותחים Management Console, נכנסים ל-CloudWatch, מחפשים ב-documentation, גולשים ב-re:Post, פותחים support case. שלושה-ארבעה כלים שונים, שלושה-ארבעה ממשקים שונים, אפס הקשר משותף ביניהם.

התוצאה: 30–45 דקות של חקירה ידנית לפני שמתחילים בכלל לעבוד על פתרון. זה לא זמן תגובה — זה זמן בזבוז נטו.

AWS פרסמה לאחרונה שני מדריכים טכניים שמציגים פתרון לבעיה הזו — ועוד אחת שכנראה לא ידעתם שיש לכם. שניהם מבוססים על Amazon Bedrock AgentCore, פלטפורמה מנוהלת להרצת סוכני AI ב-production.

מה AgentCore נותן לכם?

AgentCore מטפל בכל המורכבות התפעולית שאתם לא רוצים לגעת בה: בידוד sessions, auto-scaling, אבטחה ו-observability. שלושה רכיבים מרכזיים:

• Agent Runtime — מארח את הסוכן, מטפל ב-concurrency ו-session state
• AgentCore Gateway — משטח הכניסה שמאמת JWT tokens ומריץ קריאות ל-Runtime
• AgentCore Identity — שומר credentials כדי שלא יחיו בקוד הסוכן

הכול עוטף ב-managed service אחד. אתם כותבים את הלוגיקה, AWS מטפלת בתשתית.

---

המקרה הראשון: Support Companion

המדריך הראשון מציג Support Companion — סוכן שמאחד את כל תהליך חקירת התקלות לתוך ממשק שיחה אחד.

מה הסוכן עושה?

במקום לקפוץ בין קונסולות, הסוכן:

• מנתח CloudWatch logs ו-metrics
• מחפש ב-AWS documentation
• שולף ידע קהילתי מ-AWS re:Post
• פותח support cases עם severity מתאים
• מצרף evidence ו-context ל-case

הכול מתוך שיחה אחת. בלי מעבר בין כלים, בלי context-switching.

הארכיטקטורה

הסוכן כתוב ב-Python ומשתמש ב-Strands Agents כ-framework לאורכסטרציה. הוא מתחבר ל-AWS services דרך Model Context Protocol (MCP) — פרוטוקול סטנדרטי שמאפשר לסוכני AI לקבל הקשר מכלי חוץ.

שלושה MCP servers מחוברים:

1. aws-documentation-mcp-server — גישה ל-documentation
2. aws-support-mcp-server — גישה ל-Support APIs (דורש AWS Business Support ומעלה)
3. aws-api-mcp-server — גישה ל-service APIs

חיתוך חשוב: האתחול של שלושת ה-MCP servers מתבצע במקביל עם asyncio.gather במקום ברצף, מה שמפחית משמעותית cold start:

results = await asyncio.gather(
    init_aws_docs(),
    init_aws_support(),
    init_aws_api(),
    return_exceptions=True
)

זיכרון חכם עם timeout

הסוכן משתמש ב-AgentCore Memory לשמירת הקשר השיחה. בכל בקשה הוא מאחזר את שלושת תורות השיחה האחרונים עם timeout של שתי שניות. אם האחזור נכשל — ממשיך בלעדיו במקום לחסום את התגובה. אחרי תגובה — שומר א-סינכרונית. הזיכרון מבודד לפי session ID, כך שכל שיחת משתמש שומרת על ההקשר שלה.

רענון טוקנים אוטומטי

לקוח ה-AgentCore Gateway מאמת עם Cognito JWT tokens מ-Secrets Manager. הסוכן מאמת תפוגה לפני כל קריאת gateway ומרענן אוטומטית כשהטוקן במרחק חמש דקות מתפוגה. מחזור חיים של שעה לטוקן — בלי רענון, קריאות gateway מתחילות להיכשל באופן לסירוגין.

אבטחה בשכבות

הפתרון מגיע עם שכבות אבטחה מרובות שמחוברות כברירת מחדל:

• Amazon Cognito עם מדיניות סיסמאות תואמת NIST SP 800-63B
• AWS WAF עם rate limiting ו-managed rule sets על ה-API Gateway
• IAM roles עם least privilege לכל רכיב בנפרד
• Amazon Bedrock Guardrails שמסננים תוכן מזיק, חוסמים prompt injection (ברמה HIGH), מסתירים PII (AWS keys, כרטיסי אשראי, SSN), ומגבילים את הסוכן לתחומי AWS support בלבד
• CloudTrail ל-capture API calls עם 90 יום retention

ה-Lambda שמזמינה את הסוכן גם מסירה דפוסי credentials מהתגובות לפני שהן חוזרות למשתמש.

פריסה בסקריפט אחד

CloudFormation template אחד מפריס את הכול. סקריפט הפריסה מטפל ב:

• הגדרת סביבת Python עם uv
• בדיקות אבטחה טרום-פריסה (CloudTrail check, template validation, credential type check)
• יצירת ECR repository
• בניית Docker image
• פריסת CloudFormation stack

ה-frontend ב-React על AWS Amplify עם Cognito authentication. מעדכנים קונפיגורציה עם הערכים מ-CloudFormation output (User Pool ID, Client ID, Identity Pool ID, Runtime ARN), יוצרים חשבון, מאמתים אימייל — ומתחילים לעבוד.

דרישות מקדימות: Python 3.11+, Docker עם buildx support ל-ARM64, חשבון AWS עם הרשאות ל-Bedrock, IAM ו-CloudFormation, גישה ל-Amazon Nova Pro (או מודל נתמך אחר), ו-AWS Business Support לפחות.

---

המקרה השני: Customer 360 עם שכבת סמנטיקה

המדריך השני הולך למקום אחר לגמרי — אנליטיקה עסקית עם AI agents. השאלה כאן לא "איך מתקנים תקלה" אלא "איך עונים על שאלות עסקיות מורכבות שנפרשות על פני כמה מאגרי נתונים?"

הבעיה: נתונים מפוזרים, הגדרות סותרות

שאלה פשוטה לכאורה — "מי הלקוחות הכי רווחיים בוויסקונסין?" — דורשת חיבור בין:

• טבלאות לקוחות ב-Aurora PostgreSQL (פרופיל, כתובת, כרטיס אשראי, נאמנות)
• טבלאות רכישות ב-Amazon Redshift (הזמנות, מוצרים, קטגוריות, ספקים)

שתי המערכות מגדירות "לקוח" אחרת, עם שדות שונים, ושום SQL constraint שמחבר ביניהם (כי הן חיות במנועים שונים). סוכן AI עם גישה ישירה לנתונים האלה יכתוב שאילתות תקפות טכנית שמחזירות תשובות שגויות, סותרות, או בלתי ניתנות להסבר. הביטחון בתוצאות מתפרק בפעם הראשונה ששני סוכנים מחזירים שני מספרים שונים לאותה שאלה.

שכבת סמנטיקה: מה זה ולמה זה חשוב?

שכבת סמנטיקה היא מבט מונע-אונטולוגיה על הנתונים הארגוניים. שלושה רכיבים:

• אונטולוגיה — מגדירה מושגים (:Customer, :Order, :Product), קשרים, תכונות וכללים
• Mappings — מכריזים איך המושגים האלה ממופים לשורות בכל מקור נתונים
• שאילתות — הסוכן שואל את השכבה, השכבה מתרגמת ל-SQL נגד המערכות, מחזירה תוצאות

הנתונים נשארים במקום. המשמעות נתפסת פעם אחת ומשתמשים בה מחדש.

שכבת סמנטיקה לא מחליפה RAG — היא משלימה אותו. RAG עובד טוב כשמדובר בנתונים טקסטואליים (policy documents, manuals, support tickets). פחות טוב כשצריך לחבר רשומות חיות ממערכות שונות, להחיל חוקי business באופן עקבי, ולכבד מדיניות גישה ברמת שורה או עמודה.

Stardog: גרף ידע פדרטיבי

Stardog מיישמת את שכבת הסמנטיקה כגרף ידע פדרטיבי. כמה מושגי מפתח:

• Named graph — תת-קבוצה מתויגת של הגרף, מזוהה לפי IRI משלה. Stardog משתמשת ב-named graphs כיחידת בקרת גישה
• Virtual graph — named graph שהתוכן שלו לא שמור ב-Stardog. חי במערכת חיצונית (Aurora, Redshift, Athena) ו-Stardog שולפת שורות לפי דרישה דרך ה-mappings
• IRI — מזהה ייחודי בסגנון URL לכל ישות. לקוח עם cid=42 הופך ל-urn:stardog:demos:c360:customer:42

הטריק הארכיטקטוני המרכזי: שני ה-mappings (גם של Aurora וגם של Redshift) מייצרים את אותו IRI לאותו לקוח. הסוכן רואה ישות אחת. המחסנים לא השתנו. אין SQL JOIN שחוצה מחסנים. ה"חיבור" הוא הסכמת ה-IRI.

שלוש שכבות לסוכן אמין

המאמר מגדיר שלוש שכבות שכל סוכן AI אנליטי צריך לעבוד איתן:

1. שכבת מודל (Model Layer) — מודל בסיס שיכול לתכנן ולכתוב. הם משתמשים ב-Anthropic Claude Sonnet 4.6 דרך Amazon Bedrock. המודל יודע שפה — הוא לא יודע את העסק שלכם.

2. שכבת משמעות (Meaning Layer) — שכבת הסמנטיקה שנותנת למודל גישה מהימנה ומנוהלת לנתונים מאחורי השאלות העסקיות. Stardog מעל Aurora ו-Redshift.

3. שכבת Runtime של הסוכן — החישוב שמארח את הסוכן, מפסיק בקשות נכנסות, מנהל credentials, ומספק משטח תפעולי לאבטחה וממשל. כאן נכנס AgentCore.

מתוך השלושה, שכבת המשמעות היא הפער שרוב הצוותים לא מודעים אליו. שכבת ה-Runtime היא זו שרוב הצוותים ממעיטים בחשיבותה: איך הסוכן נקרא, איך הוא מאמת, איפה ה-credential שלו, ואיך הוא סקייל. AgentCore אורז תשובות לכל השאלות האלה ב-managed service אחד.

מה שכבת הסמנטיקה מוסיפה

חיבור בין מערכות באמצעות משמעות משותפת. הלקוח ב-Aurora והרכישות ב-Redshift מקבלים את אותו IRI דרך אותו cid. החיבור מבוטא דרך המודל הסמנטי, לא דרך pipeline פיזי. בלי זה, צריך maintained pipeline שמייצר עותק שלישי של הנתונים ושומר אותם מסונכרנים.

עובדות נגזרות כחוקים, לא כשאילתות. הגדרה כמו "Big Spender" (לקוח שביצע הזמנה מעל סף מסוים) מוגדרת פעם אחת באונטולוגיה כחוק. כל שאילתה שמשתמשת במונח מקבלת את אותה הגדרה. כשהסף משתנה — אין עותקים שנסחפים.

בקרת גישה ברמת גרף. Named graph security שולטת בגישה ברמת הגרף, כך שתפקידים שונים רואים תת-קבוצות שונות של גרף הידע.

שתי אפשרויות חיבור ל-Stardog

Path A: כלי SPARQL ישיר. כלי Python קטן שמקיף את pystardog client וחשוף לסוכן דרך Strands tool decorator. הסוכן כותב SPARQL, הכלי מריץ, מחזיר שורות. עובד על כל מופע Stardog נגיש ב-HTTPS, כולל ה-Free tier של Stardog Cloud. זו השיטה ב-POC, כי היא דורשת enablement מיוחד בחשבון Stardog.

Path B: Stardog Cloud MCP server כ-Gateway tool target. Stardog מפרסמת MCP server רשמי (stardog-union/stardog-cloud-mcp) שחשוף את Voicebox — שכבת שאילתה בשפה טבעית עם reasoning chain ו-provenance — כשלושה כלים. AgentCore Gateway רושם את ה-MCP server כ-target. הסוכן רואה את Voicebox בלי קוד הדבקה, ו-Agent Identity מזריק את הטוקן ב-Gateway hop.

Path A עובד עכשיו ונותן שליטה מלאה על יצירת ה-SPARQL. Path B דורש Voicebox API access שמוגבל לחשבונות מסוימים, אבל נותן reasoning chain ו-provenance ללא עלות נוספת.

דוגמה מעשית: בקרת גישה

נתוני Customer 360 מוסדרים. משתמשי HR ו-fraud צריכים לראות PII (SSN, מספר כרטיס מלא). אנשי marketing ו-analytics — לא.

הפתרון עם Stardog: מפצלים את מיפוי ה-Aurora לשני virtual graphs:

• aurora_c360_safe — פרופיל לקוח בלי PII (הכל חוץ מ-:ssn ו-:cardNumber)
• aurora_c360_pii — רק ה-PII triples, עם אותו customer IRI

ה-mapping של Redshift נשאר גרף אחד: redshift_c360.

יוצרים שני תפקידים:

• hr_user — גישה לשלושת הגרפים
• marketing_user — גישה רק ל-aurora_c360_safe ו-redshift_c360

כש-marketing_user מבקש SSN בשאילתה, מתכנן ה-Stardog מתייחס ל-aurora_c360_pii כאילו הוא לא קיים למשתמש הזה. ה-JDBC pushdown לעמודת ה-SSN לא קורה. אין application-level filter, אין שינוי בצד המחסן, אין סיכוי לדליפה. אותה שאילתה, שני תפקידים, שני sets שונים של תוצאות.

Stardog Cloud לעומת self-managed על EKS

שתי אפשרויות הרצה:

Stardog Cloud (SaaS) — Stardog מפעילה שירות SOC 2 compliant עם SLA של 99.9%. אתם מביאים מקורות נתונים ו-credentials. מתכונת Free, Essentials ו-Enterprise. מתאימה כשלא רוצים operations, וכשאפשרויות הנתונים נגישים מ-Stardog Cloud (אינטרנט ציבורי או AWS PrivateLink ל-Enterprise).

Self-managed על Amazon EKS — container images ו-Helm charts. אתם מפעילים את ה-cluster, מנהלים שדרוגים, מטפלים בגיבוי. מתאים כשצריך data plane traffic בתוך ה-VPC, שליטה בגרסאות, או compliance ספציפי.

הרחבה למקורות נוספים

מנגנון ה-virtual graph של Stardog לא ספציפי ל-Aurora או Redshift. אפשר להוסיף:

• Amazon Athena (data lake על S3)
• מנועי Amazon RDS אחרים עם JDBC driver
• מקורות מחוץ ל-AWS: Snowflake, Google BigQuery, MongoDB, SAP HANA

העיקרון הארכיטקטוני לשמר: כל עוד ה-mappings החדשים מייצרים IRIs שתואמים ל-existingים לאותה ישות לוגית, המקור החדש משתתף בגרף הפדרטיבי בלי לשנות אונטולוגיה או שאילתות קיימות. Stardog קוראת לזה "cooperation without coordination": כל צוות מחזיק את המקור שלו ואת ה-mappings שלו, והגרף מתרכב.

---

מה זה אומר למהנדסים ולמפתחים כאן?

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

למהנדסי DevOps ו-SRE: ה-Support Companion חוסך 30–45 דקות חקירה ידנית לכל תקלה. זה לא רק יעילות — זה מהירות תגובה ב-production. בצוות של עשרה מהנדסים שכל אחד חוקר שתי תקלות בשבוע, מדובר ב-10–15 שעות עבודה שהולכות על context-switching במקום על פתרון.

לאנשי data ואנליסטים: שכבת הסמנטיקה עם Stardog מאפשרת לסוכן AI לענות על שאלות עסקיות מורכבות שנפרשות על פני מספר מקורות — בלי ETL, בלי עותק שלישי של הנתונים, ובלי שהגדרות סותרות יחזרו ויעקצו אתכם.

המכשול: עדיין צריך AWS Business Support לפחות ל-Support MCP server, ו-Voicebox API access של Stardog מוגבל לחשבונות מסוימים. לא הכול זמין לכל אחד עדיין.

אבל הכיוון ברור: סוכני AI ב-production הופכים מנישה ל-toolbox סטנדרטי. AgentCore הופך לפלטפורמה ש-AWS מובילה אליה. ומי שמחכה שהכול יהיה GA לפני שלומד — מפספס את היתרון של מי שכבר יודע לשאול את הסוכן את השאלות הנכונות.

ושווה לזכור: גם את ה-45 דקות האלה שאתם חוסכים — מישהו עדיין צריך לשלם על ה-Token usage.