Noticia8 min

OpenAI y Codex ya están GA en Amazon Bedrock: dónde sí baja fricción y dónde el detalle del endpoint te puede romper el rollout

AWS confirmó el 1 de junio de 2026 la disponibilidad general de GPT-5.5, GPT-5.4 y Codex en Amazon Bedrock. Lo útil para builders no es solo correr OpenAI sobre AWS: es combinar Responses API, aislamiento, auditoría y consumo contra compromisos existentes sin olvidar que el path y el estado de sesión cambian.

AWSOpenAI
Blog oficial de AWS anunciando la disponibilidad general de OpenAI y Codex en Amazon Bedrock

Por qué importa

Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.

La alianza entre OpenAI y AWS ya no se queda en anuncio de partnership. AWS confirmó el 1 de junio de 2026 que GPT-5.5, GPT-5.4 y Codex ya están en general availability dentro de Amazon Bedrock. Para equipos que ya viven en AWS, la noticia útil no es “otro lugar donde invocar un modelo”. La noticia útil es que ya puedes correr OpenAI y Codex con el contrato operativo de Bedrock: Responses API, IAM, CloudTrail, VPC, PrivateLink y gasto imputado al mismo marco de gobernanza.

Eso sí: si lees el release solo como “OpenAI pero con otra factura”, te pierdes los detalles que sí cambian un rollout real.

Documentación oficial de Bedrock mostrando Responses API, regiones y endpoint bedrock-mantle para OpenAI

La mejora importante no es el logo; es la superficie de ejecución

AWS dice varias cosas concretas en el anuncio:

  • GPT-5.5 y GPT-5.4 están disponibles vía Responses API.
  • Codex también entra con disponibilidad general y cobro por token.
  • El tráfico corre sobre la infraestructura de inferencia de Bedrock.
  • Las llamadas heredan IAM, KMS, CloudTrail, VPC y PrivateLink.
  • Los prompts y respuestas no se usan para entrenar modelos.

Para un builder de agentes, eso importa porque Bedrock no está vendiendo solo acceso a modelo. Está vendiendo un runtime más fácil de aprobar dentro de organizaciones que ya operan sobre AWS.

El detalle que más fácil rompe una integración

La documentación de Bedrock deja un matiz que no conviene pasar por alto: para estos modelos el camino no es el OpenAI endpoint típico sin más. Hay una ruta específica sobre bedrock-mantle, y en el caso de GPT-5.5 la model card remarca que el path es openai/v1/responses sobre ese endpoint.

Eso parece menor, pero no lo es.

Si tu equipo asume que todo SDK OpenAI-compatible se comporta igual por defecto, puedes romper:

  • variables de entorno;
  • manejo de estado de conversación;
  • pruebas de compatibilidad;
  • y observabilidad de requests.

La misma guía de Responses API también aclara otra pieza útil: cuando dejas store: true, Bedrock guarda el estado de la conversación para continuar respuestas multi-turno; si pones store: false, no retiene esos datos y tampoco puedes seguir la conversación con previous_response_id.

Ahí aparece la pregunta correcta:

¿quieres continuidad conversacional, o quieres cero retención dentro de esa sesión?

Dónde sí le veo valor real

Yo lo pondría en evaluación seria en tres casos.

1. Equipos que ya tienen el perímetro de AWS resuelto

Si ya operas compliance, red privada, auditoría y acceso con AWS, mover OpenAI y Codex a Bedrock te evita montar otro carril lateral solo para contentarte con el proveedor del modelo.

2. Builders que quieren Responses API sin salir del marco Bedrock

AWS empuja una compatibilidad bastante explícita con el estilo OpenAI. Eso baja fricción para equipos que no quieren reescribir todo el cliente y al mismo tiempo necesitan infraestructura Bedrock.

3. Coding agents con presión de gobernanza

El anuncio conecta bien con búsquedas tipo codex amazon bedrock, openai bedrock responses api o gpt-5.5 bedrock. No es tráfico casual; es gente que ya está decidiendo dónde correr agentes con requisitos reales de plataforma.

Model card oficial de GPT-5.5 en Bedrock con capacidades, endpoint soportado y acceso programático

Dónde no lo vendería como bala de plata

No lo leería como victoria automática de AWS sobre el endpoint first-party.

Hay tradeoffs reales:

  • el comportamiento exacto depende del contrato Bedrock, no del de OpenAI puro;
  • el almacenamiento conversacional tiene sus propias reglas;
  • algunas rutas y paths cambian;
  • y mover la inferencia al perímetro AWS no corrige por sí solo un agente mal diseñado.

También conviene separar esta noticia de la otra gran promesa de AWS: Managed Agents y runtimes largos. Aquí la mejora fuerte es más básica y más útil: OpenAI y Codex ya son consumibles dentro del mismo tejido de seguridad y operación que muchas empresas ya usan.

Mi lectura práctica

La disponibilidad general importa porque convierte una integración “interesante” en una opción operable para producción. Pero la ejecución buena no depende del press release. Depende de revisar:

  1. endpoint y path exactos;
  2. cómo manejarás store y continuidad;
  3. qué permisos AWS necesita cada app;
  4. si Codex realmente vive mejor ahí que en tu proveedor actual;
  5. y qué presupuesto de token y observabilidad exige el caso de uso.

Si todavía estás poniendo orden antes de tocar despliegue y tools, empieza por el curso gratis. Y si tu siguiente problema ya es dónde correr trabajo largo con aislamiento fuerte, esta pieza conversa directo con AWS AgentCore para hosting de coding agents.

La conclusión corta es esta: OpenAI y Codex en Bedrock ya no son una promesa de partnership; son una ruta concreta para meter agentes dentro del perímetro AWS sin desmontar tu stack.