Codex теперь работает через Amazon Bedrock: AWS показала пилот на IAM без нового стека

Когда в компании хотят раздать разработчикам AI-агента для кода, обычно получается вторая инфраструктура: отдельные ключи, отдельные счета, отдельный аудит. Платформенной команде это лишняя головная боль. AWS выпустила подробное руководство о том, как провести Codex через Amazon Bedrock и не плодить параллельный стек.

Сам Codex по-прежнему запускается на рабочей машине разработчика. Меняется только маршрут: запросы к поддерживаемым моделям OpenAI идут через Bedrock. В примерах используется GPT-5.6 Sol, но перед стартом стоит отдельно проверить, доступны ли Sol, Terra или Luna в нужном аккаунте, регионе и пути инференса. Доступность у них может отличаться.

Три пути, один по умолчанию

AWS предлагает три варианта.

• Native AWS Access. Вход через IAM Identity Center, никаких дополнительных сервисов. Это рекомендуемая точка старта.
• AgentCore Gateway. Управляемый шлюз AWS для маршрутизации и Bedrock Guardrails.
• LLM Gateway вроде LiteLLM на ECS или Portkey. Подходит, если у вас уже есть такой шлюз или нужны жёсткие бюджеты и лимиты прямо в пути запроса.

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

Правило простое: берите самый лёгкий путь, закрывающий ваши требования. Для пилота обычно хватает нативного доступа.

Как выглядит безопасный пилот

Сотрудники входят через привычный провайдер, например Okta по SAML. Пользователей и группы он выдаёт в IAM Identity Center через SCIM, а тот выпускает временные AWS-ключи для Codex. В самом Codex провайдер идентификации не настраивается.

Проверка идёт в три шага.

1. Войти через aws sso login и напрямую вызвать bedrock-runtime converse с нужной моделью. Если что-то сломано, это сразу покажет проблему в профиле, регионе или IAM-правах, а не в Codex.
2. Прописать в ~/.codex/config.toml провайдера amazon-bedrock, модель, профиль и регион.
3. Запустить безопасную задачу в непродуктовом репозитории.

Конфиг лучше держать в пользовательском или управляемом файле, чтобы репозиторий не мог подменить провайдера. Ещё до старта нужно назначить человека, отвечающего за откат.

Отдельно AWS просит проверить изоляцию личностей. Один пользователь доказывает только то, что вход работает. Двое запускают одну и ту же безобидную задачу, и их сессии, аудит и телеметрия должны остаться раздельными. Откат тоже проверяют: убрали настройку или назначение в Identity Center, подождали окончания сессии, убедились, что новый вызов отклоняется.

Наблюдаемость и стоимость: не путать источники

Самое полезное в руководстве то, что оно не смешивает разные виды данных.

• Телеметрия Codex через OpenTelemetry показывает активность клиента: токены, ходы, вызовы инструментов. Привязывать её к людям можно только после того, как локальный коллектор добавит проверенные атрибуты идентичности.
• Метрики и логи Bedrock показывают, что происходило на стороне сервиса.
• Идентичность и деньги берутся из AWS-аудита и отчёта CUR. Для нативного доступа CUR 2.0 с аллокацией по caller identity может показать SSO-принципала.

Объём токенов нельзя выдавать за отчёт о расходах. Реальную цену берите из биллинга, а любую оценочную аллокацию помечайте как оценку.

Для пилота в репозитории есть готовая конфигурация коллектора ADOT и дашборд CloudWatch.

Ограничения и что делать

Гайд написан платформенной командой AWS для своих сервисов, поэтому про альтернативы вне экосистемы в нём ничего нет. Телеметрия не доказывает корректность кода, так что ревью и тесты сгенерированных изменений остаются обязательными. Секреты и закрытые данные нельзя отправлять через модель, пока это не одобрено явно.

Перед раскатыванием на команды стоит стандартизировать окружение. Плагины организации распространяют навыки и хуки, у каждого должны быть владелец и версия. MCP-серверы открывают отдельную границу доверия: пускайте к ним только нужных людей и инструменты, а креды держите вне конфигурации провайдера модели. Хуки вроде PreToolUse проверьте на сценариях allow, deny, таймаута и отключённого эндпоинта.

Практический вывод для платформенной команды такой. Начните с двух человек, нативного доступа и чёткого плана отката. Расширяйтесь только после того, как доказательства по идентичности, вызовам и затратам сходятся. Шлюз добавляйте тогда, когда вам нужны жёсткие лимиты, а не просто потому, что он есть.