Дата публикации
ai_products

Как Amazon Bedrock AgentCore Gateway пускает AI-агентов в приватные VPC без выхода в интернет

Что нового

Amazon добавила в Bedrock AgentCore Gateway полноценный выход в приватные сети (VPC egress) для AI-агентов и MCP‑серверов:

  1. Поддержка приватных ресурсов в VPC
    Агент может ходить к:

    • приватным Amazon API Gateway endpoint’ам;
    • MCP‑серверам в Amazon EKS;
    • любым приватным REST API внутри Amazon VPC;
    • другим внутренним сервисам, доступным через VPC Lattice / VPC endpoints.

  2. Два режима подключения к приватным ресурсам

    • Managed VPC Resource — AgentCore сам создаёт Resource Gateway и Elastic Network Interface (ENI) в вашем VPC.
    • Self‑Managed Lattice Resource — вы сами создаёте и управляете Resource Gateway и Resource Configuration в Amazon VPC Lattice, а AgentCore лишь использует их.

  3. Resource Gateway как управляемая точка входа

    • Для каждого указанного subnet — один ENI.
    • Resource Gateway живёт внутри вашего VPC, трафик не выходит в интернет.
    • Можно ограничить доступ на уровне конкретного домена или IP, а не всей сети.

  4. Чёткое разделение аккаунтов

    • Есть понятие AgentCore Gateway account (где живёт сам Gateway) и Resource VPC (где живут приватные сервисы).
    • В managed‑режиме кросс‑аккаунт достигается через VPC peering / Transit Gateway.
    • В self‑managed‑режиме можно делиться ресурсами через AWS Resource Access Manager (AWS RAM).

  5. Прозрачная тарификация

    • Managed VPC Resource: только per‑GB плата за трафик через Resource Gateway.
    • Self‑Managed Lattice Resource:
      1. почасовая оплата за Service Network association;
      2. per‑GB за трафик.

  6. Ограничение по TLS

    • AgentCore Gateway доверяет только публично подписанным TLS‑сертификатам.
    • Сертификаты от частного CA или self‑signed сейчас не проходят без дополнительных обходных решений (есть пример на GitHub).

  7. Автоматическое управление ресурсами (в managed‑режиме)

    • AgentCore создаёт, переиспользует и удаляет Resource Gateway сам.
    • Вы видите Resource Gateway в своём аккаунте, но только read‑only.
    • Конфигурации доступа (Resource Configuration) живут в сервисном аккаунте Bedrock и в вашей консоли не отображаются.

Как это работает

Базовые сущности

Чтобы не запутаться, важно четыре термина:

  • Resource VPC — тот VPC, где живёт ваш приватный ресурс: API, база, MCP‑сервер. Сюда должен попасть трафик от AgentCore Gateway.
  • AgentCore Gateway account — AWS‑аккаунт, где вы создаёте и управляете самим Gateway и его таргетами.
  • Resource Gateway — управляемая точка входа в Resource VPC. При создании в указанных subnet’ах поднимаются ENI. Через них AgentCore гоняет трафик к вашим приватным endpoint’ам.
  • Resource Configuration — точечное правило, к какому домену или IP Resource Gateway даёт доступ. Это не доступ ко всему VPC, а к одному endpoint’у.

Дополнительно используется Service Network Resource Association — связь между Resource Configuration и сервисной сетью AgentCore. Её создаёт и ведёт сам AgentCore.

Два режима VPC egress

1. Managed VPC Resource

Вы передаёте в AgentCore Gateway:

  • VPC ID;
  • список subnet ID;
  • список security group ID;
  • тип IP‑адресов (сейчас IPv4).

Дальше AgentCore делает за вас:

  • создаёт Resource Gateway в вашем аккаунте;
  • поднимает по одному ENI в каждый subnet;
  • привязывает к ним указанные security group’ы;
  • настраивает маршрутизацию трафика до нужного приватного endpoint’а (например, execute‑api VPC endpoint).

Особенности:

  • IP‑потребление фиксировано: один IP на ENI, менять нельзя.
  • Если несколько Gateway Targets используют одинаковый VPC + набор subnet’ов + security group’ов + теги + тип IP — AgentCore переиспользует один Resource Gateway и его ENI.
  • Кросс‑аккаунт / кросс‑VPC вы решаете через VPC peering или AWS Transit Gateway.

Пример потока для приватного Amazon API Gateway:

  1. AgentCore Gateway получает запрос от агента.
  2. Отправляет его в Resource Gateway в Resource VPC.
  3. Трафик выходит в ваш приватный subnet через ENI.
  4. Security group решает, можно ли идти дальше.
  5. Запрос попадает в execute‑api VPC endpoint, который ведёт к приватному API Gateway.

2. Self‑Managed Lattice Resource

Здесь вы работаете руками с Amazon VPC Lattice:

  • сами создаёте Resource Gateway;
  • сами создаёте Resource Configuration (какие домены/IP доступны, сколько IPv4‑адресов на ENI, какие subnet’ы и security group’ы использовать);
  • при создании Gateway Target в AgentCore передаёте ID Resource Configuration.

Особенности:

  • Можно задать ipv4AddressesPerEni — сколько IPv4‑адресов будет на каждом ENI Resource Gateway.
    Для AgentCore это минимум один IP на subnet, но если Resource Gateway ещё подключён к другим сервисным сетям VPC Lattice, IP‑потребление растёт.
  • Полная видимость: вы видите Resource Configuration, ассоциации с Service Network и домены в консоли VPC Lattice.
  • Можно делиться ресурсами между аккаунтами через AWS RAM и тонко отзывать доступ.

Пример потока для приватного REST API:

  1. Вы заранее создаёте Resource Gateway и Resource Configuration.
  2. Вызов CreateGatewayTarget в AgentCore привязывает таргет к этому Resource Configuration.
  3. При запросе агентом Resource Gateway пропускает трафик через ENI в вашем subnet.
  4. Дальше запрос идёт к execute‑api VPC endpoint или к ALB/NLB, в зависимости от архитектуры.

Требования и ограничения

  • IAM‑принципалу нужен iam:CreateServiceLinkedRole для bedrock-agentcore.amazonaws.com, чтобы AgentCore мог создать service‑linked роль.
  • По умолчанию используется default security group, если вы не передали свой при создании Gateway Target.
  • AgentCore Gateway не доверяет приватным CA и self‑signed сертификатам. Для таких сценариев есть workaround’и в GitHub‑репозитории.

Что это значит для вас

Когда это полезно

  1. Вы строите AI‑агентов, которые должны работать с внутренними данными
    Примеры задач:

    • агент‑оператор, который ходит в внутренний CRM‑API;
    • техподдержка, которая читает из приватной базы и REST‑сервисов;
    • аналитический ассистент, который дергает внутренние микросервисы.

    AgentCore Gateway VPC egress позволяет дать агенту доступ к этим ресурсам без экспонирования в интернет.

  2. У вас уже есть сеть на VPC peering / AWS Transit Gateway
    В этом случае проще всего использовать Managed VPC Resource.
    Вы даёте AgentCore VPC ID + subnet’ы + security group, и он сам поднимет Resource Gateway.

  3. Нужен строгий контроль и аудит
    Если важно видеть, какие домены доступны, кому вы раздали кросс‑аккаунт доступ, и уметь его отозвать — выбирайте Self‑Managed Lattice Resource.
    Вся конфигурация прозрачна в консоли VPC Lattice, можно строить аудит и процессы безопасности.

  4. Интеграция с Kubernetes через MCP
    Если вы крутите MCP‑сервер в Amazon EKS, AgentCore может ходить к нему через приватный NLB, Route 53 private hosted zone и Resource Gateway.
    Это вариант, когда вы строите сложную внутреннюю инфраструктуру инструментов для агентов.

Где это неудобно или не подойдёт

  • Нет AWS‑инфраструктуры. Если вы не используете Amazon VPC, EKS, API Gateway и VPC Lattice, эта функциональность вам не пригодится.
  • Только on‑prem без гибридного подключения. Если у вас нет VPN / Direct Connect / Transit Gateway до AWS, AgentCore не доберётся до ваших внутренних систем.
  • Требуются приватные или self‑signed TLS‑сертификаты. Сейчас AgentCore Gateway их не доверяет. Можно обойти через прокси или другие паттерны, но это дополнительная сложность.
  • Жёсткие ограничения по IP‑адресам. В managed‑режиме вы не можете уменьшить количество IP: один ENI = один IP на subnet. В сильно фрагментированных VPC это может быть критично.

Доступность из России

Amazon Bedrock и связанные сервисы, включая AgentCore и AgentCore Gateway, работают в регионах AWS. Для доступа из России чаще всего нужен VPN или инфраструктура в другом регионе/юридическом лице. Планируйте это заранее.

Место на рынке

Amazon здесь решает специфичную задачу: безопасный выход AI‑агентов в приватные сети внутри AWS. Прямых количественных сравнений с продуктами от OpenAI, Anthropic или других облаков в исходных данных нет.

По сути, это конкурирует не с GPT‑4o или Claude 3.5, а с:

  • самописными прокси‑слоями для агентов;
  • API‑шлюзами и сервис‑мешами, которые вы могли бы настроить вручную;
  • кастомными решениями поверх VPC Lattice или API Gateway.

Ключевые отличия по параметрам:

  • Уровень интеграции с AWS
    AgentCore Gateway напрямую использует Amazon VPC, VPC Lattice, ENI, Route 53, API Gateway, ALB/NLB. Для команд, которые уже живут в AWS, это уменьшает количество «самописной» инфраструктуры.

  • Контроль vs простота

    • Managed VPC Resource — минимум настроек, но нет тонкого контроля над Resource Configuration и IP‑пулом.
    • Self‑Managed Lattice Resource — полный контроль, но вы сами управляете жизненным циклом Resource Gateway и Resource Configuration.

  • Ценообразование
    Нет отдельной платы за сам AgentCore Gateway VPC egress как фичу. Важны:

    • per‑GB трафик через Resource Gateway (в обоих режимах);
    • в self‑managed добавляется почасовая оплата за Service Network association в VPC Lattice.

Если вы уже строите агентов на Amazon Bedrock, этот подход логично дополняет стек. Если вы используете GPT‑4o или Claude 3.5 в другом облаке и не сидите на AWS‑инфраструктуре, выгоды от AgentCore Gateway меньше.

Установка

Ниже — практический минимум, чтобы запустить AgentCore Gateway и подключить приватные ресурсы в managed VPC resource режиме.

1. IAM и подготовка

  • Убедитесь, что у IAM‑принципала есть право:
    • iam:CreateServiceLinkedRole для bedrock-agentcore.amazonaws.com.
  • Настройте VPC:
    • выберите VPC, где живут ваши приватные ресурсы;
    • подготовьте минимум два приватных subnet’а (рекомендуется для отказоустойчивости);
    • создайте security group для Resource Gateway (или используйте default, если вас устраивают его правила).

2. Настройка security group

Security group для Resource Gateway определяет, куда ENI может отправлять трафик внутри VPC.
Если вы не укажете его в CreateGatewayTarget, AgentCore использует default security group VPC.

Обычно правила такие:

  • outbound: разрешить трафик к VPC endpoint’ам, ALB/NLB и нужным портам (443, 80, 8000 и т.д.);
  • inbound: зависит от вашей схемы, но чаще всего Resource Gateway инициирует соединение, поэтому основной фокус — на outbound.

3. Создать AgentCore Gateway

Если Gateway ещё нет, создайте его через AWS CLI:

aws bedrock-agentcore create-gateway \
 --name my-gateway \
 --role-arn arn:aws:iam::<account-=id>:role/AgentCoreGatewayRole

Сохраните gatewayId из ответа — он нужен для создания целей (targets).

Для более детальных примеров Amazon отсылает к GitHub‑репозиторию с кодом и ноутбуками.

Как запустить: приватный Amazon API Gateway

Этот сценарий показывает, как дать агенту доступ к приватному Amazon API Gateway через managed VPC resource.

  1. У вас уже должен быть приватный API Gateway, доступный через VPC endpoint формата:
    https://{api-id}-{vpce-id}.execute-api.{region}.amazonaws.com/{stage}
  2. Подготовьте OpenAPI‑схему этого API.
  3. Запустите команду create-gateway-target:
aws bedrock-agentcore-control create-gateway-target \
 --region us-west-2 \
 --cli-input-json '{
 "gatewayIdentifier": "<GATEWAY_ID>",
 "name": "private-apigw",
 "description": "Private API Gateway",
 "targetConfiguration": {
   "mcp": {
     "openApiSchema": {
       "inlinePayload": "..."
     }
   }
 },
 "credentialProviderConfigurations": [...],
 "privateEndpoint": {
   "managedVpcResource": {
     "vpcIdentifier": "<VPC_ID>",
     "subnetIds": ["<SUBNET_ID_1>", "<SUBNET_ID_2>"],
     "endpointIpAddressType": "IPV4",
     "securityGroupIds": ["<VPCE_SG_ID>"]
   }
 }
}'

После выполнения:

  • AgentCore через service‑linked роль создаёт Resource Gateway в вашем VPC;
  • в каждом указанном subnet появляется по одному ENI;
  • запросы агентов к этому target’у идут через эти ENI к VPC endpoint execute-api.

Как запустить: приватный MCP‑сервер в Amazon EKS

Этот сценарий нужен, если вы поднимаете MCP‑сервер внутри Kubernetes‑кластера в EKS и хотите, чтобы AgentCore общался с ним по HTTPS через приватный NLB.

  1. Настроен Amazon EKS, NGINX Ingress Controller, Network Load Balancer и Route 53 private hosted zone, которая резолвит домен MCP‑сервера на внутренний NLB.
  2. MCP‑сервер доступен по URL, например: https://internal.example.com/csm/mcp.
  3. Запустите:
aws bedrock-agentcore-control create-gateway-target \
 --region us-west-2 \
 --cli-input-json '{
 "gatewayIdentifier": "<GATEWAY_ID>",
 "name": "private-apigw",
 "description": "Private API Gateway",
 "targetConfiguration": {
   "mcp": {
     "mcpServer": {
       "endpoint": "https://internal.example.com/csm/mcp"
     }
   }
 },
 "credentialProviderConfigurations": [...],
 "privateEndpoint": {
   "managedVpcResource": {
     "vpcIdentifier": "<VPC_ID>",
     "subnetIds": ["<SUBNET_ID_1>", "<SUBNET_ID_2>"],
     "endpointIpAddressType": "IPV4",
     "securityGroupIds": ["<VPCE_SG_ID>"]
   }
 }
}'

Дальше цепочка выглядит так:

  • AgentCore Gateway отправляет HTTPS‑запрос к internal.example.com;
  • Route 53 private hosted zone резолвит домен в IP внутреннего NLB;
  • запрос входит в Resource VPC через Resource Gateway и ENI;
  • NLB завершает TLS на порту 443, используя публичный сертификат из ACM;
  • дальше запрос по HTTP на порт 80 идёт в NGINX Ingress Controller и попадает в pod MCP‑сервера.

Как запустить: приватный REST API

Этот сценарий похож на предыдущие, но таргет — любой REST API внутри VPC, например микросервис за внутренним ALB.

  1. У вас есть OpenAPI‑схема REST API.
  2. API доступен через внутренний Application Load Balancer, домен резолвится через Route 53 private hosted zone.
  3. Вызываете CreateGatewayTarget с OpenAPI‑схемой и тем же блоком managedVpcResource.

После создания:

  • AgentCore Gateway отправляет HTTPS‑запрос на внутренний домен;
  • Route 53 private hosted zone резолвит домен в ALB;
  • запрос входит в VPC через Resource Gateway и ENI;
  • ALB завершает TLS на порту 443 с публичным сертификатом ACM;
  • дальше по HTTP на порт 8000 запрос идёт в target group с вашими backend‑серверами.

Self‑managed Lattice Resource: когда нужно больше контроля

Если вам мало возможностей managed‑режима, вы можете:

  • сами создать Resource Gateway в VPC Lattice;
  • задать ipv4AddressesPerEni, subnet placement и security group’ы;
  • создать несколько Resource Configuration для разных доменов/endpoint’ов;
  • расшарить их через AWS RAM в другие аккаунты;
  • при создании Gateway Target в AgentCore передавать нужный resourceConfigurationIdentifier.

В этом режиме:

  • несколько Resource Configuration могут использовать один и тот же Resource Gateway и его ENI;
  • вы видите все ассоциации с сервисными сетями и можете точечно отзывать доступ;
  • платите дополнительно почасовую ставку за Service Network association.

Очистка ресурсов

Чтобы не платить лишнее, после экспериментов удалите всё, что создали:

  • Gateway Targets;
  • кластеры Amazon EKS;
  • load balancer’ы (ALB/NLB);
  • приватные API Gateway endpoints;
  • Resource Gateway и Resource Configuration (если вы их создавали сами);
  • вспомогательную инфраструктуру из GitHub‑примеров (через cleanup‑секцию в ноутбуках).

Для managed‑режима достаточно удалить Gateway Target — связанный Resource Gateway исчезнет автоматически:

aws bedrock-agentcore delete-gateway-target \
 --gateway-identifier <gateway-id> \
 --target-id <target-id>

Если вы управляете Resource Gateway сами (self‑managed), его нужно удалить вручную в VPC Lattice.

Кому это особенно полезно

  • Командам, которые уже используют Amazon Bedrock AgentCore и строят агентов вокруг внутренних API и MCP‑серверов.
  • Архитекторам, которые хотят перенести логику доступа к приватным ресурсам из самописных прокси в управляемый сервис AWS.
  • Безопасникам, которым нужен понятный контроль: какие домены доступны агентам, как устроен кросс‑аккаунт доступ, как быстро его отключить.

Если вы строите AI‑системы внутри AWS и боитесь открывать приватные сервисы в интернет, AgentCore Gateway VPC egress — один из самых прямых путей дать агентам доступ к этим сервисам без лишних компромиссов по безопасности.

Читайте также

#amazon-bedrock#ии-агенты#aws#mcp#api
🔗 Источник: https://aws.amazon.com/blogs/machine-learning/configuring-amazon-bedrock-agentcore-gateway-for-secure-access-to-private-resources/
← Все новости