AWS открыл Web Search API для агентов: один вызов без шлюза и ключей

Модель не знает, что случилось на прошлой неделе. Чтобы агент отвечал про свежие релизы, цены или законы, ему нужен поиск. В AWS такой поиск был, но только через AgentCore Gateway: создаёшь шлюз, добавляешь цель веб-поиска и вызываешь инструмент из MCP-клиента. Для платформенной команды с общими правилами это нормально. Для разработчика, которому нужны просто результаты поиска, это лишний слой.

Теперь AWS выпустил отдельный Web Search API. Это операция InvokeWebSearch в data plane сервиса bedrock-agentcore. Ничего заранее создавать не нужно: берёте учётные данные IAM, вызываете, получаете выдачу.

Как это выглядит на практике

В Boto3 это один метод invoke_web_search. Вы передаёте строку запроса (до 200 символов), число результатов от 1 до 25 и фильтры. Например, можно ограничить поиск доменами aws.amazon.com и kubernetes.io и попросить страницы, опубликованные после 1 января 2026 года. В ответ приходит ранжированный список. У каждого результата есть текстовый фрагмент, а заголовок, URL и дата публикации есть, если индекс их знает. Поэтому читать их нужно через get, а не по ключу.

Аутентификация идёт через SigV4, то есть API-ключей нет. Если код крутится в Lambda, ECS, EC2 или EKS, достаточно добавить роли одно право: bedrock-agentcore:InvokeWebSearch на управляемый ресурс web-search.v1. Это то же право, что использует сервисная роль шлюза, так что одна политика покрывает оба пути.

Проверить можно и без кода: в CloudShell хватает одной команды aws bedrock-agentcore invoke-web-search. Для Python нужен Boto3 не старше 1.43.127.

Где это пригодится

AWS называет несколько сценариев, где шлюз избыточен:

• свой агентный цикл или фреймворки вроде LangChain и LlamaIndex;
• не-агентные задачи: дашборды, проверка фактов, обогащение контента, мониторинг;
• случаи, когда ретраи, кеш и обработку ошибок вы хотите вести сами;
• приложения, у которых уже есть свой API-слой.

Для LangChain есть готовый тулкит в langchain-aws 1.9.3 и новее. В нём можно зафиксировать правила, которые модель не может поменять: исключённые домены, нижнюю границу по дате и бюджет поиска. Это полезно, когда не хочется, чтобы агент сам расширял себе область поиска. Есть и обёртка WebSearchClient в AgentCore Python SDK 1.26.0.

Безопасность и ограничения

Главный аргумент для корпоративных команд в том, что запросы обслуживаются индексом, которым управляет Amazon, и не уходят в сторонний поисковик. Тот же индекс стоит за Alexa+, Kiro и Quick. Доступ регулируется через IAM и SCP, вызовы можно вести через PrivateLink без выхода в интернет. Через условие aws:SourceVpce можно разрешить поиск только из вашего VPC.

Есть нюансы:

• CloudTrail пишет вызовы как data events, но по умолчанию они выключены. Нужно вручную добавить селектор для ресурса AWS::BedrockAgentCore::WebSearch. Сам текст запроса и фильтры в логи не попадают.
• Лимит по умолчанию составляет 10 запросов в секунду на регион на аккаунт. Для массовых пайплайнов придётся просить повышение.
• Условия использования обязывают сохранять и показывать ссылки на источники вместе с результатами. Если ваш продукт скрывает источники, это проблема.
• Интерфейсные VPC-эндпоинты оплачиваются по стандартным тарифам PrivateLink.
• Индекс принадлежит Amazon, поэтому покрытие и свежесть стоит проверить на своих запросах, прежде чем отказываться от Brave, Tavily или Bing.

Что делать

Если вы уже на AWS и хотите добавить агенту веб-grounding, начните с прямого API: это пять минут, и не нужно разворачивать шлюз. Если у вас много агентов и общая политика инструментов, остаётся шлюз. Для сравнения с другими поисковыми API прогоните на обоих один и тот же набор запросов, а в проде сразу включите CloudTrail data events и ограничьте домены в тулките.