Настройка Amazon Bedrock AgentCore Gateway для безопасного VPC-доступа к приватным ресурсам | AiManual
AiManual Logo Ai / Manual.
30 Апр 2026 • Гайд

Как затащить Amazon Bedrock AgentCore в VPC и не обжечься: гайд по настройке Gateway для приватных ресурсов

Полный гайд по настройке Amazon Bedrock AgentCore Gateway для безопасного доступа к приватным ресурсам через VPC: два режима, три сценария, пошаговая инструкция

Сценарий из ада: как выглядит типичная боль

Ты неделю настраиваешь AI-агента на Bedrock, обучаешь его крутым действиям, а он в ответ — "Access Denied". Потому что твоя база данных, внутренний API или модель лежат в приватной VPC. Агент по умолчанию живёт в публичной сети AWS. И да, он не видит твои приватные ресурсы. Звучит знакомо?

Типичная ошибка: разработчики пытаются открыть Security Group нараспашку или тянуть публичные эндпоинты. Но это убивает всю идею приватности и комплаенса. Не делай так.

Решение — Amazon Bedrock AgentCore Gateway. С апреля 2025 года (и в 2026-м функционал только прокачался) есть два режима подключения к VPC: Resource Gateway и Elastic Network Interfaces (ENI). Разберёмся, какой и когда использовать, на трёх реальных сценариях: API Gateway, EKS и REST API.

Два зверя: Resource Gateway vs ENI — кого выбрать

Прежде чем лезть в код, надо понять разницу. Если коротко:

ПараметрResource GatewayENI (Elastic Network Interface)
Когда появилсяКонец 2024С самого старта AgentCore
Что делаетПроксирует HTTP/HTTPS трафик к ресурсам внутри VPCСоздаёт прямой сетевой интерфейс в твоей VPC
Простота настройки😊 Просто: указываешь эндпоинт и VPC😬 Сложно: надо разбираться с подсетями, Security Groups, маршрутами
БезопасностьХорошая: только к указанным ресурсамБолее гибкая: полный доступ к VPC через Security Groups
Поддержка не-HTTP протоколов❌ Нет (только HTTP/HTTPS)✅ Да (любой TCP/UDP)
Когда выбиратьЕсли нужно быстро и безопасно подключить REST API или API GatewayЕсли нужно подключаться к EKS, RDS, RabbitMQ или другому не-HTTP сервису

Я обычно начинаю с Resource Gateway — он проще, меньше шансов прострелить себе ногу. ENI беру только когда упрусь в лимит.

Три сценария, которые покроют 90% кейсов

1 Сценарий: API Gateway (REST) внутри VPC

Задача: у тебя есть приватный API Gateway (например, для внутреннего сервиса поиска товаров). Агент должен дёргать его по HTTPS, но через интернет — нельзя. Решение — Resource Gateway.

Как НЕ надо делать

В логах я видел такое: разработчик создавал ENI, открывал Security Group на 0.0.0.0/0, а потом удивлялся, почему комплаенс-отдел в ярости. Или пытался добавить IP агента в белый список — но IP у Bedrock динамические, так себе идея.

Правильный путь

  1. Создай Resource Gateway в той же VPC, где висит API Gateway.
  2. Укажи целевой эндпоинт: https://my-internal-api.execute-api.region.amazonaws.com
  3. В агенте в Bedrock AgentCore при создании действия (action group) выбери тип Resource Gateway и укажи созданный Gateway.
  4. Настрой IAM-роль агента, чтобы разрешить bedrock:InvokeResourceGateway.

Готово. Трафик пойдёт через VPC, не вылезая наружу.

2 Сценарий: EKS с микросервисами

Задача: внутри EKS крутится сервис рекомендаций, он говорит на gRPC. Resource Gateway не умеет gRPC (только HTTP/HTTPS). Значит, берём ENI.

Как НЕ надо делать

Самая популярная ошибка — не настроить Security Group для ENI, оставить всё по дефолту. В итоге ENI блокирует весь трафик, агент не видит ничего. Или наоборот — открыть все порты.

Правильный путь

  1. Создай ENI в одной из приватных подсетей, где находятся поды EKS.
  2. Назначь Security Group, которая разрешает входящий трафик от самого ENI (да, ты не ослышался — ENI сам инициирует соединение, но ответный трафик должен проходить). Лучше разрешить исходящий трафик к портам сервисов (например, 443, 50051).
  3. При создании действия в AgentCore выбери тип Elastic Network Interface и укажи ENI ID.
  4. Укажи эндпоинт: http://recommendation-service.namespace.svc.cluster.local:50051 (агент будет резолвить через VPC DNS, если настроен).

Нюанс: чтобы DNS внутри VPC работал, убедись, что в VPC есть Route53 Resolver или включены enableDnsHostnames и enableDnsSupport.

3 Сценарий: REST API за ALB/NLB внутри VPC

Задача: твой внутренний REST API висит за Application Load Balancer в приватной подсети. Агент должен вызывать его. Тут можно использовать и Resource Gateway (если API чисто HTTP), и ENI. Но я рекомендую Resource Gateway — проще в поддержке.

💡
Лучшая практика: если ALB доступен через DNS-имя (например, internal-alb-123.region.elb.amazonaws.com), используй его как эндпоинт Resource Gateway. Security Group для ALB должна разрешать трафик от подсетей, где развёрнут Gateway.
# Пример конфигурации Resource Gateway через AWS CLI
aws bedrock-agent create-resource-gateway \
    --name my-rest-api-gateway \
    --vpc-id vpc-0abcd1234 \
    --subnet-ids subnet-123 subnet-456 \
    --target "https://internal-alb-123.region.elb.amazonaws.com" \
    --region us-east-1

Грабли, на которые наступили мы (и вы тоже наступите)

Расскажу о трёх подводных камнях, которые я видел в продакшнах клиентов.

1. Resource Gateway не умеет в мутные сертификаты

Если твой внутренний API использует самоподписанный сертификат — Resource Gateway его не примет. Решение: либо используй ACM для выпуска приватного CA, либо переходи на ENI, где можно отключить проверку сертификата (но это риск).

2. ENI требует ручного управления

При удалении/создании нового агента ENI не удаляется автоматически — висит мёртвым грузом в твоей VPC. Это и дополнительные счета, и потенциальные дыры в безопасности. Автоматизируй очистку через Lambda или Terraform.

3. Timeout при холодном старте

Если твой API долго отвечает (больше 30 секунд), Resource Gateway может оборвать соединение. Настрой таймауты в агенте и API (или используй ENI с собственными настройками).

Хочешь защитить агентов от опасных запросов? Обязательно настрой Amazon Bedrock Guardrails параллельно с Gateway — это слои безопасности, которые работают вместе.

Собираем всё вместе: автоматизация через CI/CD

Создавать Gateway и ENI вручную — путь в ад. Правильный подход — описать инфраструктуру как код (Terraform, CloudFormation, CDK) и деплоить через пайплайн. В нашем гайде по CI/CD для Bedrock AgentCore мы показываем, как зашить создание Gateway в шаги GitHub Actions. Это избавит от ручного копирования ID и ошибок.

Пример Terraform для Resource Gateway

resource "aws_bedrock_agent_resource_gateway" "example" {
  name        = "my-gateway"
  vpc_id      = var.vpc_id
  subnet_ids  = var.private_subnet_ids
  target_urls = [var.internal_api_url]
}

Кстати, если ты используешь Agentic AI-архитектуры с автономными агентами, рекомендую изучить реальный кейс автоматизации публикации контента — там как раз используется связка Gateway + Guardrails.

Неочевидный совет (запиши на лбу)

Многие думают, что Resource Gateway — это просто прокси. Но у него есть скрытая фишка: он автоматически реплицирует конфигурацию в несколько Availability Zones (если указать несколько подсетей). Это даёт отказоустойчивость на уровне сети — твой агент продолжит работать, если одна AZ упадёт. В случае с ENI такой репликации нет, ты сам отвечаешь за мульти-AZ развёртывание.

Прогноз на 2027: ждите поддержку приватных DNS-зон в Resource Gateway (чтобы резолвить имена в VPC без лишнего геморроя). Уже сейчас это можно организовать через ENI, но хочется удобства.

Хочешь проверить настройки? Создай тестового агента с одним действием, которое вызывает пустой эндпоинт внутри VPC и смотри логи в CloudWatch. Если видишь AccessDeniedException — проверяй IAM и Security Groups. Если таймаут — проверяй доступность эндпоинта и DNS.

P.S. У нас в блоге есть ещё материал про браузер агента в Bedrock — если твой сценарий связан с веб-скрапингом, глянь, пригодится.

Подписаться на канал

←
На главную