OpenAI Codex інтегрується з Amazon Bedrock для корпоративного використання моделей

Amazon Web Services опублікувала настанови щодо запуску OpenAI Codex із Amazon Bedrock як серверною частиною виведення для підтримуваних моделей OpenAI. У публікації описано три шляхи розгортання, які дають платформним командам зберегти наявні практики AWS з ідентифікації, безпеки та спостережуваності, водночас надаючи розробникам доступ до Codex на їхніх робочих станціях.

Три шляхи розгортання Codex на Bedrock

Найпростіший шлях - Native AWS Access, який використовує IAM Identity Center для входу співробітників і тимчасових облікових даних. Розробники входять через свого постачальника ідентичності, а Codex викликає Amazon Bedrock Runtime безпосередньо. Другий шлях, AgentCore Gateway, забезпечує керовану AWS інфраструктуру шлюзу для централізованої маршрутизації та Amazon Bedrock Guardrails. Третій шлях, LLM Gateway, підходить організаціям, які вже експлуатують шлюз або хочуть застосовувати контролі в шляху запиту; власна інтеграція є розширеною версією цього підходу. Кожен шлях пов'язує різні потреби контролю з командою-власником, а настанови рекомендують починати з найменш складного шляху, який задовольняє вимогу.

Перевірка пілота та ізоляція ідентичності

Настанови починаються з невеликого пілота з мінімальними правами. Передумови включають додавання пілотних користувачів до окремої групи в системі ідентичності співробітників, підготовку групи в IAM Identity Center, вибір регіону Amazon Bedrock і доступної моделі OpenAI, наприклад GPT-5.6 Sol, а також надання лише необхідних прав на виведення моделі. Пілот перевіряє доступ AWS прямим викликом Bedrock Runtime, налаштовує постачальника Codex на використання затвердженої моделі та профілю, а також виконує безпечне завдання лише для читання в непродуктивному сховищі. Перевірка ізоляції ідентичності для двох користувачів гарантує, що окремі пілотні користувачі створюють окремі сеанси прийнятої ролі, записи аудиту та телеметрію, водночас використовуючи спільний затверджений шлях Codex і Bedrock.

Спостережуваність, розподіл витрат і керування

Спостережуваність використовує збірник AWS Distro for OpenTelemetry та керовану інформаційну панель CloudWatch для збору метрик клієнта Codex, таких як використання токенів, обміни, запити API та виклики інструментів. Метрики сервісу Amazon Bedrock, записи ідентичності AWS і звіт про вартість та використання дають дані про активність на боці сервісу, атрибуцію та оплачуване використання. Настанови наголошують на зіставленні цих джерел для розгорнутого шляху та на тому, що обсяг токенів не слід подавати як звіт про вартість. Контрольні тести включають сповіщення для виявлення, контролі IAM і керованого клієнта для меж доступу, а також політику шлюзу для застосування контролів у шляху запиту, наприклад жорсткі бюджети або обмеження швидкості.

Поетапне розширення та межі конфігурації

Після того як інфраструктурний шлях працює, розгортання стандартизує досвід розробників за допомогою плагінів, гачків і затверджених серверів Model Context Protocol, що належать організації. Плагіни розповсюджують спільні навички та інтеграції MCP з версіонуванням і перевіркою. Гачки застосовують команди політики на подіях PreToolUse, PostToolUse або SessionStart. Сервери MCP створюють окремі межі довіри і вимагають обмеженого доступу, затвердженого керування обліковими даними та підтвердження користувача для зовнішніх змін. Контрольний список запуску адміністратора фіксує вибраний шлях, команду-власника, регіон, модель і права пілота, а також вимагає непродуктивного тесту, що охоплює вхід, доступність моделі та безпечне завдання Codex. Очищення видаляє конфігурацію Codex, призначення IAM, доступ до шлюзу, збірники телеметрії та пілотні інформаційні панелі, перевіряючи, що нові виклики відхиляються.

Джерела: AWS Machine Learning Blog