Codex ya funciona a través de Amazon Bedrock: AWS muestra un piloto con IAM sin un stack nuevo

Cuando una empresa quiere dar a sus desarrolladores un agente de IA para programar, suele acabar con una segunda infraestructura: claves aparte, facturas aparte, auditoría aparte. Para el equipo de plataforma es un quebradero de cabeza innecesario. AWS ha publicado una guía detallada sobre cómo canalizar Codex a través de Amazon Bedrock sin crear un stack paralelo.

Codex sigue ejecutándose en la máquina de trabajo del desarrollador. Lo único que cambia es la ruta: las peticiones a los modelos compatibles de OpenAI pasan por Bedrock. Los ejemplos usan GPT-5.6 Sol, pero antes de empezar conviene comprobar por separado si Sol, Terra o Luna están disponibles en la cuenta, la región y la ruta de inferencia que se vayan a usar. La disponibilidad puede variar entre ellos.

Tres caminos, uno por defecto

AWS propone tres opciones.

• Native AWS Access. Inicio de sesión mediante IAM Identity Center, sin servicios adicionales. Es el punto de partida recomendado.
• AgentCore Gateway. Un gateway administrado de AWS para el enrutamiento y Bedrock Guardrails.
• LLM Gateway, como LiteLLM en ECS o Portkey. Encaja si ya tiene un gateway de este tipo o si necesita presupuestos y límites estrictos directamente en la ruta de la petición.

AWS califica abiertamente la integración personalizada como una variante avanzada de gateway, no como un arranque rápido. Es un servicio más que habrá que diseñar, proteger y mantener.

La regla es sencilla: elija el camino más ligero que cubra sus requisitos. Para un piloto, normalmente basta con el acceso nativo.

Cómo es un piloto seguro

Los empleados inician sesión a través de su proveedor habitual, por ejemplo Okta con SAML. Este proveedor entrega usuarios y grupos a IAM Identity Center mediante SCIM, y IAM Identity Center emite claves temporales de AWS para Codex. En el propio Codex no se configura ningún proveedor de identidad.

La verificación consta de tres pasos.

1. Iniciar sesión con aws sso login y llamar directamente a bedrock-runtime converse con el modelo elegido. Si algo falla, así se detecta de inmediato un problema en el perfil, la región o los permisos de IAM, y no en Codex.
2. Definir en ~/.codex/config.toml el proveedor amazon-bedrock, el modelo, el perfil y la región.
3. Ejecutar una tarea segura en un repositorio que no sea de producción.

Lo mejor es guardar la configuración en un archivo de usuario o administrado, para que el repositorio no pueda sustituir el proveedor. Antes de empezar, también hay que designar a una persona responsable del rollback.

AWS pide además comprobar el aislamiento de identidades. Un solo usuario demuestra únicamente que el inicio de sesión funciona. Si dos usuarios ejecutan la misma tarea inofensiva, sus sesiones, su auditoría y su telemetría deben permanecer separadas. El rollback también se prueba: se elimina la configuración o la asignación en Identity Center, se espera a que expire la sesión y se comprueba que una nueva llamada es rechazada.

Observabilidad y coste: no mezclar las fuentes

Lo más útil de la guía es que no mezcla distintos tipos de datos.

• La telemetría de Codex mediante OpenTelemetry muestra la actividad del cliente: tokens, turnos, llamadas a herramientas. Solo se puede asociar a personas una vez que un colector local añada atributos de identidad verificados.
• Las métricas y los logs de Bedrock muestran lo que ocurrió en el lado del servicio.
• La identidad y el dinero salen de la auditoría de AWS y del informe CUR. Con el acceso nativo, CUR 2.0 con asignación por caller identity puede mostrar el principal de SSO.

El volumen de tokens no se puede presentar como un informe de gasto. El precio real debe tomarse de la facturación, y cualquier asignación estimada debe etiquetarse como estimación.

Para el piloto, el repositorio incluye una configuración lista del colector ADOT y un dashboard de CloudWatch.

Limitaciones y qué hacer

La guía la ha escrito el equipo de plataforma de AWS para sus propios servicios, así que no dice nada sobre alternativas ajenas a su ecosistema. La telemetría no demuestra que el código sea correcto, de modo que la revisión y las pruebas de los cambios generados siguen siendo obligatorias. Los secretos y los datos confidenciales no deben enviarse a través del modelo mientras no esté aprobado de forma explícita.

Antes de desplegarlo en los equipos conviene estandarizar el entorno. Los plugins de la organización distribuyen skills y hooks, y cada uno debe tener un responsable y una versión. Los servidores MCP abren una frontera de confianza distinta: permita el acceso solo a las personas y herramientas necesarias, y mantenga las credenciales fuera de la configuración del proveedor del modelo. Los hooks como PreToolUse deben probarse en escenarios de allow, deny, timeout y endpoint desactivado.

La conclusión práctica para el equipo de plataforma es esta. Empiece con dos personas, acceso nativo y un plan de rollback claro. Amplíe solo cuando las pruebas sobre identidad, llamadas y costes coincidan. Añada un gateway cuando necesite límites estrictos, no simplemente porque exista.