AWS показала корпоративный gateway для Codex на LiteLLM, ECS и Bedrock

Gateway контролирует inference, но не получает shell разработчика

AWS представила reference architecture, в которой OpenAI Codex отправляет запросы к OpenAI model в Amazon Bedrock через управляемый заказчиком LiteLLM gateway. Сам Codex продолжает работать на компьютере разработчика: читает локальные файлы, запускает разрешённые инструменты и соблюдает выбранные sandbox и approval settings. LiteLLM находится только на пути model inference и не получает универсальный shell в AWS-аккаунте. Это разделяет исполнение кода и централизованную политику доступа к модели.

Каждый turn идёт на endpoint `/v1/responses`, затем проходит через Application Load Balancer и при необходимости AWS WAF. LiteLLM проверяет вызывающего, разрешённый alias модели и лимиты потребления, после чего использует task role ECS для обращения к Bedrock. Если модель запрашивает tool call, Codex выполняет его локально и отправляет результат следующим Responses-запросом. Поэтому gateway видит и учитывает model traffic, но локальные полномочия по-прежнему задаются на рабочей станции.

Reference stack делает политику частью инфраструктуры

Основной deployment использует LiteLLM в Amazon ECS на AWS Fargate, PostgreSQL в Amazon RDS для состояния, usage и budget data, Secrets Manager и KMS для credentials, CloudWatch для логов и метрик, ECR для immutable image. AWS также описывает опциональные managed protections WAF и source-IP rate limiting. Для production рекомендованы TLS, ограничение ALB корпоративными или VPN CIDR, private subnets для ECS и RDS и отсутствие публичного доступа к портам 4000 и 5432.

Разработчикам не следует выдавать master key LiteLLM. Reference helper создаёт identity пользователя или команды, назначает разрешённую модель, бюджет и RPM/TPM limits, а затем сохраняет scoped key в зашифрованном секрете. Конфигурация Codex получает bearer token через отдельную команду аутентификации, поэтому credential не требуется записывать в `config.toml`. Такой дизайн позволяет отозвать одного пользователя или изменить лимит команды, не меняя общий доступ всей организации.

Совместимость Responses API проверяется отдельным контрактом

Обычный ответ на короткий prompt не доказывает, что gateway подходит агенту. Codex зависит от структуры Responses object, streaming, function calls и продолжения через `previous_response_id`. AWS включает строгий probe, который проверяет обязательные поля, завершение server-sent event stream, forced tool call с call ID и семантическое продолжение. В последнем тесте первая реплика содержит уникальный marker, а следующая должна восстановить его через сохранённое состояние.

Это существенная инженерная оговорка: proxy может синтаксически принять `previous_response_id`, но потерять контекст, или вернуть текст, не поддержав корректный tool-call loop. После contract test AWS советует отдельно нагрузить concurrent sessions, длинные streams, cancellation, key revocation, recovery и ожидаемый peak traffic. В LiteLLM Request Logs нужно видеть успешные вызовы, alias scoped key, выбранную модель, длительность, token count и стоимость; секреты и реальные prompts в screenshots публиковать нельзя.

Дополнительный контроль оплачивается операционной сложностью

LiteLLM даёт единые aliases, hard budgets, rate limits, routing, fallback и gateway-level attribution, но команда берёт на себя доступность сервиса, жизненный цикл базы, upgrades, incident response и capacity planning. Bedrock видит общий ECS task role, поэтому исходную identity необходимо сохранять в scoped key, журналах LiteLLM и экспортируемой telemetry. Отдельно нужно решить, допустимо ли логировать prompts и ответы, как их шифровать, редактировать и удалять по retention policy.

AWS сравнивает этот путь с двумя альтернативами. Прямой provider `amazon-bedrock` через IAM Identity Center проще и сохраняет пользовательскую AWS identity в CloudTrail, но не добавляет gateway-level бюджеты и routing policy. Managed или hybrid Portkey снимает часть эксплуатации, однако требует такой же проверки полного Responses contract, data handling и failure modes. Практический выбор поэтому начинается не с популярности gateway, а с того, какие контроли действительно нельзя выразить нативными средствами AWS.