AWS showed how Amazon Bedrock AgentCore Gateway connects to private APIs and services

AWS показала, как настроить Amazon Bedrock AgentCore Gateway для безопасного доступа AI-агентов к приватным ресурсам внутри VPC. В основе схемы — Resource Gateway, который создает Elastic Network Interfaces в подсетях и дает контролируемый путь к закрытым API, сервисам и внутренним эндпоинтам.

Как это устроено

Главная идея в том, что агенту не нужно выходить в публичный интернет, чтобы обратиться к внутреннему сервису. Resource Gateway разворачивает по одному ENI в каждой выбранной подсети Amazon VPC и использует их как точку входа к приватной инфраструктуре. За счет этого запросы от AgentCore Gateway проходят по внутренней сети AWS, а команда получает привычные механизмы контроля: security groups, маршрутизацию по таблицам маршрутов и сегментацию по подсетям.

Для компаний, которые не хотят раскрывать внутренние API наружу, это самый практичный сценарий. Такой подход особенно важен для AI-агентов, которые должны работать не только с публичными моделями, но и с закрытыми инструментами бизнеса. Речь может идти о внутренних CRM, сервисах документооборота, приватных эндпоинтах инференса или API, доступных только из VPC.

Вместо того чтобы строить обходные схемы с прокси и публичными шлюзами, AWS предлагает нативный канал доступа внутри своей сети. Это упрощает архитектуру и помогает держать требования по безопасности, аудиту и сетевой изоляции в одном месте.

Два режима работы AWS предлагает два варианта внедрения: managed и self-managed.

В managed-режиме большая часть сетевой обвязки создается и поддерживается сервисом, поэтому команда быстрее доходит до рабочего подключения и тратит меньше времени на рутинную инфраструктуру. Self-managed-режим нужен тем, кому важен полный контроль над схемой развертывания, настройками сети и интеграцией с уже существующими правилами компании. Выбор между ними зависит не от функциональности агента, а от того, насколько глубоко бизнес хочет управлять сетевым слоем самостоятельно.

• Managed подходит для быстрого старта и типовых сценариев.
• Self-managed дает больше контроля над сетью и операционной моделью.
• ENI создаются в подсетях VPC, что помогает сохранить приватный маршрут трафика.
• Политики доступа можно сочетать с существующими security groups и маршрутами. Практический смысл этого разделения простой: Bedrock AgentCore Gateway не навязывает один жесткий способ подключения. Если команде важна скорость пилота, можно опереться на управляемую модель. Если приоритет — кастомная топология, корпоративные требования или особые правила доступа между сегментами сети, можно собрать схему самостоятельно. Для enterprise-команд это важный сигнал: сервис рассчитан не только на демо, но и на реальные продовые контуры с внутренними ограничениями.

Три практических сценария 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-сервисам и собственным инструментам без лишней экспозиции наружу, а значит — быстрее переносить пилоты в прод.