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

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

كيف يعمل الحل

الفكرة الأساسية أن الوكيل لا يحتاج إلى الخروج إلى الإنترنت العام للوصول إلى خدمة داخلية. ينشر Resource Gateway واجهة ENI واحدة في كل شبكة فرعية مختارة ضمن Amazon VPC، ويستخدمها كنقطة دخول إلى البنية التحتية الخاصة. وبذلك تمر طلبات AgentCore Gateway عبر شبكة AWS الداخلية، ويحصل الفريق على آليات التحكم المعتادة: مجموعات الأمان (security groups)، والتوجيه عبر جداول المسارات، والتقسيم حسب الشبكات الفرعية. وبالنسبة إلى الشركات التي لا ترغب في كشف واجهات API الداخلية للعالم الخارجي، فهذا هو السيناريو الأكثر عملية.

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

وضعا التشغيل

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

• يناسب وضع managed البدء السريع والسيناريوهات النمطية.
• يمنح وضع self-managed تحكمًا أكبر في الشبكة ونموذج التشغيل.
• تُنشأ واجهات ENI في الشبكات الفرعية لـ VPC، مما يساعد على إبقاء مسار الحركة خاصًا.
• يمكن الجمع بين سياسات الوصول ومجموعات الأمان والمسارات القائمة.

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

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

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

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

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

ما الذي يعنيه ذلك

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