عرضت AWS كيف يربط Amazon Bedrock AgentCore Gateway واجهات API والخدمات الخاصة

أظهرت AWS كيفية تكوين Amazon Bedrock AgentCore Gateway للوصول الآمن لوكلاء الذكاء الاصطناعي إلى الموارد الخاصة داخل VPC. في أساس العمارة يوجد Resource Gateway، الذي ينشئ Elastic Network Interfaces في الشبكات الفرعية ويوفر مسارًا محكومًا إلى واجهات برمجية خاصة والخدمات والنقاط النهائية الداخلية.

كيفية عمله

الفكرة الرئيسية هي أن الوكلاء لا يحتاجون إلى الخروج إلى الإنترنت العام للوصول إلى خدمة داخلية. ينشر Resource Gateway واحدة ENI في كل شبكة فرعية محددة من Amazon VPC ويستخدمها كنقطة دخول إلى البنية التحتية الخاصة. لهذا السبب، تنتقل الطلبات من AgentCore Gateway عبر الشبكة الداخلية لـ AWS، والفريق يحصل على آليات تحكم مألوفة: مجموعات الأمان، وإدارة جداول التوجيه، وتقسيم الشبكات الفرعية.

بالنسبة للشركات التي لا تريد الكشف عن واجهات برمجية داخلية علنًا، هذا هو السيناريو الأكثر عملية. هذا النهج مهم بشكل خاص لوكلاء الذكاء الاصطناعي الذين يجب أن يعملوا ليس فقط مع النماذج العامة، بل أيضًا مع أدوات الأعمال الملكية. قد يعني هذا أنظمة إدارة علاقات العملاء الداخلية، وخدمات إدارة المستندات، ونقاط نهاية الاستدلال الخاصة، أو واجهات برمجية يمكن الوصول إليها فقط من داخل VPC. بدلاً من بناء أنظمة بديلة باستخدام وكلاء البروكسي والبوابات العامة، توفر AWS قناة وصول أصلية داخل شبكتها الخاصة. هذا يبسط العمارة ويساعد في الحفاظ على متطلبات الأمان والتدقيق والعزل الشبكي في مكان واحد.

وضعا النشر

توفر AWS خيارين للتطبيق: مدار وموضع تحكم ذاتي. في الوضع المدار، يتم إنشاء ومراقبة معظم البنية التحتية للشبكة بواسطة الخدمة، بحيث يصل الفريق إلى اتصال يعمل بشكل أسرع ويقضي وقتًا أقل على البنية التحتية الروتينية. وضع التحكم الذاتي مخصص لأولئك الذين يحتاجون إلى التحكم الكامل في مخطط النشر وإعدادات الشبكة والتكامل مع سياسات الشركة الموجودة.

الاختيار بينهما لا يعتمد على وظيفة الوكيل، بل على مدى رغبة الشركة في إدارة طبقة الشبكة بشكل مستقل.

• الوضع المدار مناسب للبدايات السريعة والسيناريوهات النمطية.
• يوفر التحكم الذاتي مزيدًا من التحكم على الشبكة والنموذج التشغيلي.
• يتم إنشاء واجهات الشبكة في شبكات VPC الفرعية، مما يساعد على الحفاظ على توجيه حركة المرور الخاصة.
• يمكن دمج سياسات الوصول مع مجموعات الأمان والمسارات الموجودة.

المعنى العملي لهذا الفصل بسيط: Bedrock AgentCore Gateway لا يفرض طريقة اتصال صارمة واحدة. إذا كان الفريق يقدر سرعة إثبات المفهوم، فيمكنه الاعتماد على النموذج المدار. إذا كانت الأولوية هي الطوبولوجيا المخصصة أو المتطلبات المؤسسية أو قواعد الوصول الخاصة بين قطاعات الشبكة، فيمكنك بناء المخطط بنفسك. بالنسبة لفرق المؤسسات، هذه إشارة مهمة: الخدمة مصممة ليس فقط للعروض التوضيحية، بل للبيئات الإنتاجية الحقيقية ذات القيود الداخلية.

ثلاثة سيناريوهات عملية

توضح AWS ثلاثة سيناريوهات توضح بوضوح سبب احتياجنا إلى Resource Gateway.

الأول هو الاتصال بنقطة نهاية خاصة في Amazon API Gateway، عندما يحتاج الوكيل إلى استدعاء واجهة برمجية غير متاحة خارجيًا. الثاني هو العمل مع خادم MCP في Amazon EKS، أي خادم الأدوات المنتشر في مجموعة Kubernetes داخل الشبكة السحابية. الثالث هو الوصول إلى واجهة برمجية REST خاصة قد تخدم التطبيقات الداخلية أو قواعس المعرفة أو المنطق التجاري.

• استدعاء Amazon API Gateway خاص دون نشر النقطة النهائية علنًا.
• التكامل مع خادم MCP في Amazon EKS لأدوات الوكيل.
• الاتصال بواجهة برمجية REST داخلية توجد فقط داخل VPC.

تغطي هذه الأمثلة طيفًا واسع جدًا من المهام. في حالة واحدة، يحصل الوكيل على وصول إلى بوابات واجهة برمجية موجودة بالفعل، وفي حالة أخرى إلى البنية التحتية Kubernetes مع أدواتها الخاصة، وفي الحالة الثالثة إلى أي خدمة ويب داخلية بواجهة REST. في الأساس، تعرض AWS نمطًا: إذا كان لديك خدمة داخل شبكة خاصة، يمكنك جعلها متاحة بشكل نظيف لـ AgentCore Gateway دون تعريضها للإنترنت. يقلل هذا المقابل بين الأمان والفائدة من الوكلاء.

ماذا يعني هذا

تقوم AWS تدريجياً بتحويل AgentCore Gateway إلى جسر بين وكلاء LLM والبنية التحتية للشركة المغلقة. بالنسبة للشركات، يزيل هذا أحد الحواجز الرئيسية للاعتماد: يمكن ربط الوكلاء بواجهات برمجية داخلية وخدمات Kubernetes والأدوات الملكية دون تعريض خارجي غير ضروري، مما يعني انتقالات أسرع من إثبات المفهوم إلى الإنتاج.