OpenAI en Amazon Bedrock: simulé la migración desde mi stack actual y los números no cierran como promete el anuncio

La solución correcta para reducir costos de OpenAI es dejar de llamar a OpenAI directamente. Sé que suena raro. Dejame explicar por qué Bedrock puede costarte más caro, más lento y con más fricción que quedarte exactamente donde estás.

Cuando salió el anuncio —CEOs de OpenAI y AWS en el mismo escenario, 274 puntos en HN, todo el mundo emocionado— mi primer instinto fue el mismo que tuve cuando migré de Vercel a Railway: voy a probarlo yo antes de opinar. La migración de Vercel me duró un fin de semana y aprendí más sobre infraestructura real que meses leyendo docs. Con Bedrock me llevó menos tiempo llegar a una conclusión, pero fue igual de instructiva.

Spoiler: no migré. Y no fue por comodidad.

OpenAI Amazon Bedrock migración costos: qué promete el anuncio y qué encontré yo

El pitch es limpio: accedés a los modelos de OpenAI (GPT-4o, o1, o3-mini) desde tu infraestructura AWS existente, con el mismo IAM que ya usás, sin manejar API keys de terceros, con facturación consolidada y con las garantías de disponibilidad de Bedrock. Para una empresa con equipo de seguridad y compliance, eso vale oro.

Para mí, que tengo un stack en Railway, Next.js y PostgreSQL con llamadas directas a la API de OpenAI, eso vale... calculémoslo.

Mi stack actual tiene estas características medibles:

• ~4.200 llamadas/mes a GPT-4o con contextos de 2k-8k tokens
• Latencia promedio medida: 380ms para el primer token (p50), 720ms en p95
• Costo real últimos 30 días: $18.40 USD entre input y output tokens
• Zero overhead de auth: API key en variable de entorno, una línea de config

Antes de simular la migración, documenté ese baseline en frío. No quería engañarme después comparando peras con manzanas.

La simulación: migrar mis llamadas reales a Bedrock

Para simular la migración usé una cuenta AWS que ya tenía activa (herencia de cuando trabajaba con infra en 2022) y activé el modelo GPT-4o en Bedrock desde la consola. El proceso de habilitación en sí ya tiene fricción: hay que aceptar términos específicos, esperar aprobación por modelo, y configurar los permisos IAM correctos. Eso me llevó 40 minutos la primera vez.

El cliente SDK cambia:

// Stack actual: llamada directa a OpenAI
// Simple, predecible, sin sorpresas
import OpenAI from 'openai';

const cliente = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

const respuesta = await cliente.chat.completions.create({
  model: 'gpt-4o',
  messages: [{ role: 'user', content: prompt }],
  max_tokens: 500,
});

// Mismo llamado vía Bedrock
// Notá el cambio de firma y el overhead de credenciales AWS
import { BedrockRuntimeClient, InvokeModelCommand } from '@aws-sdk/client-bedrock-runtime';

// Las credenciales AWS se resuelven en runtime desde el entorno
// IAM role, env vars o ~/.aws/credentials — cada una con su latencia propia
const bedrockCliente = new BedrockRuntimeClient({
  region: 'us-east-1', // GPT-4o en Bedrock solo disponible en us-east-1 al momento de esta prueba
});

// El body tiene que ir serializado — no hay azúcar sintáctica
const comando = new InvokeModelCommand({
  modelId: 'openai.gpt-4o', // formato diferente al directo
  contentType: 'application/json',
  accept: 'application/json',
  body: JSON.stringify({
    messages: [{ role: 'user', content: prompt }],
    max_tokens: 500,
  }),
});

const respuestaBruta = await bedrockCliente.send(comando);
// Necesitás deserializar manualmente — otro paso que falla en silencio si te olvidás
const respuesta = JSON.parse(new TextDecoder().decode(respuestaBruta.body));

Ese cambio de firma no es solo cosmético. Es un punto de ruptura para cualquier wrapper genérico que hayas construido arriba de la SDK oficial de OpenAI.

Los números reales de la simulación

Corrí el mismo conjunto de 50 prompts contra los dos endpoints —mismos textos, mismo modelo, mismo max_tokens— y medí:

Métrica	OpenAI directo	OpenAI vía Bedrock	Delta
Latencia p50 (ms)	382	534	+40%
Latencia p95 (ms)	718	1.240	+72%
Costo por 1M input tokens	$2.50	$3.00*	+20%
Cold start IAM (primer req)	0ms	340ms	—
Setup inicial	~2 min	~40 min	—

*Pricing estimado con el markup de Bedrock al momento de la prueba. Bedrock aplica un sobrecosto sobre el precio base de OpenAI; no es pass-through puro.

El cold start de IAM es el que más me sorprendió. La primera llamada de cada sesión tiene un overhead de resolución de credenciales que con OpenAI directo no existe. En un contexto serverless —que es donde Bedrock tiene más sentido teórico— ese 340ms se suma al cold start de la función. Si vengo del post sobre cómo el acuerdo entre Microsoft y OpenAI afecta los costos de API reales, esto es el mismo patrón: los acuerdos corporativos generan capas, y cada capa tiene latencia.

Los errores que no aparecen en el anuncio

1. El lock-in se invierte pero no desaparece

El argumento de venta de Bedrock es escapar del lock-in de OpenAI. Mi punto: lo que hacés es cambiar lock-in de modelo por lock-in de plataforma. Ahora dependés de que AWS habilite los modelos que necesitás, a los precios que AWS negocie, con la disponibilidad regional que AWS decida.

Cuando OpenAI lanzó o3-mini, yo lo tenía disponible en mi stack en 20 minutos: cambié una línea de config. En Bedrock, los modelos nuevos de OpenAI tienen que pasar por el proceso de habilitación de AWS, que históricamente toma días o semanas. Para un proyecto donde itero modelos seguido, eso es fricción real.

El tema del lock-in en infra ya lo analicé cuando simulé el ataque de hijacking de dominio en GoDaddy — la dependencia de un tercero para algo crítico siempre tiene un precio que no aparece en el pricing page.

2. IAM es un vector de complejidad, no solo de seguridad

Me pasé 25 minutos depurando un error AccessDeniedException que resultó ser una política IAM incompleta. El mensaje de error no te dice qué permiso falta; te dice que algo falló. Tuve que ir al CloudTrail, filtrar por el timestamp exacto y reconstruir la cadena de permisos desde ahí.

Con OpenAI directo, si la API key está mal, el error es claro, inmediato y autoexplicativo. La simplicidad de debugging no es un detalle menor cuando estás solo y son las 11pm.

3. El precio "consolidado" tiene un piso mínimo

Para proyectos chicos —menos de $50/mes de gasto en LLMs— el overhead operacional de mantener una cuenta AWS activa, las IAM policies bien configuradas, el monitoring de Bedrock en CloudWatch y el billing separado por servicio consume tiempo de un dev que vale más que el 20% de markup que te ahorrás... que de hecho no te ahorrás porque Bedrock es más caro que directo.

Esto conecta con algo que entendí durante mi migración de Railway: la infraestructura "enterprise" tiene un costo de operación que no escala hacia abajo. Bedrock es infraestructura enterprise. Para un equipo de 10+ personas con compliance y billing centralizado, tiene sentido. Para mí hoy, no.

4. Streaming tiene comportamiento diferente

Probé llamadas con streaming activado —que uso para la experiencia UX de mis features de generación de texto— y el comportamiento de chunks en Bedrock no es idéntico al de la SDK oficial. Los chunks llegan en tamaños distintos, lo que rompió mi lógica de parseado de markdown en el cliente. No es un bug, es una diferencia de implementación que ningún anuncio menciona.

Algo similar encontré cuando analicé el robo de datos de voz de Mercor: los detalles de implementación que no aparecen en el anuncio son exactamente los que terminan mordiéndote.

FAQ: OpenAI en Amazon Bedrock para devs independientes

¿Los precios de OpenAI en Bedrock son iguales que en la API directa?
No. Bedrock aplica un markup sobre el precio base de OpenAI. Al momento de mi simulación, GPT-4o en Bedrock costaba ~$3.00 por millón de tokens de entrada contra $2.50 en la API directa. El markup exacto puede variar y AWS no lo documenta de forma prominente; hay que hacer la comparación manual desde el pricing calculator.

¿Necesito una cuenta AWS para acceder a OpenAI vía Bedrock?
Sí, obligatoriamente. No hay acceso a Bedrock sin cuenta AWS, con IAM configurado y con los modelos habilitados individualmente. Si ya tenés infraestructura en AWS, ese costo ya está pagado. Si no, es un costo nuevo.

¿La latencia de OpenAI en Bedrock es comparable a la API directa?
En mis pruebas, no. El p50 fue un 40% más alto y el p95 fue un 72% más alto. El overhead de IAM y la capa de proxy adicional de Bedrock suman latencia que no existe en el llamado directo. En casos de uso donde la latencia importa —chat en tiempo real, streaming de respuestas— esa diferencia es perceptible para el usuario.

¿Bedrock soporta todos los modelos de OpenAI?
Al momento de publicar esto, no. GPT-4o y algunos modelos de la familia o1/o3 están disponibles, pero no todos los modelos del catálogo de OpenAI. Los modelos nuevos tienen que pasar por el proceso de habilitación de AWS antes de estar disponibles en Bedrock, lo que genera un lag respecto a la disponibilidad directa.

¿Tiene sentido migrar si ya uso otros modelos de Bedrock (Claude, Llama)?
Sí, este es el caso donde la propuesta de valor más se sostiene. Si ya tenés infraestructura Bedrock activa, el IAM configurado y billing consolidado, agregar GPT-4o al mismo stack tiene un costo marginal bajo. El problema es para alguien que empieza desde cero solo por OpenAI.

¿El streaming funciona igual en Bedrock que en la SDK de OpenAI?
No exactamente. Los chunks de streaming en Bedrock tienen un comportamiento de tamaño diferente al de la SDK oficial. Si tenés lógica de UI que depende del tamaño o timing de los chunks —parseado de markdown progresivo, indicadores de escritura— vas a necesitar ajustar esa lógica. No es un bloqueante, pero es trabajo no mencionado en la documentación de migración.

Mi postura: el acuerdo es real, la propuesta de valor para devs independientes no lo es

Mi tesis, sin rodeos: el acuerdo OpenAI-AWS es genuinamente interesante para empresas con equipo de infra, compliance activo y billing centralizado en AWS. Para un dev independiente o un equipo chico que ya llama a la API de OpenAI directamente, Bedrock suma fricción, suma costo y suma latencia sin dar nada a cambio que importe en ese contexto.

Lo que el anuncio vende es simplicidad operacional para quien ya tiene complejidad operacional instalada. Si el problema que resuelve Bedrock es "manejar múltiples API keys de múltiples vendors", ese problema existe cuando tenés múltiples vendors y un equipo de seguridad que audita cada credencial. Si tenés una API key en una variable de entorno y Railway la gestiona por vos, ese problema no existe y Bedrock no resuelve nada.

Hay algo más que me resulta incómodo: cada vez que dos gigantes anuncian una integración en el mismo escenario, los números que aparecen en el deck son los que les quedan bien a ambos. Los números que encontré yo —40% más de latencia, 20% más de costo, 40 minutos de setup contra 2— no aparecen en ningún press release.

Esto conecta con el análisis de pgbackrest y los cambios de mantenimiento: las decisiones de infraestructura que parecen neutras raramente lo son. Alguien siempre gana más.

¿Mi decisión hoy? Me quedo en la API directa. Si en seis meses el markup de Bedrock baja, el cold start de IAM desaparece y el catálogo de modelos está en paridad, lo reevalúo. Pero no migro por el anuncio; migro por los números. Y los números de hoy dicen que no.

Si llegaste hasta acá y estás evaluando lo mismo, hacé lo que hice yo: medí primero. Tomá tus llamadas reales del último mes, fijate cuánto te cuesta y cuánto te tarda, y recién ahí abrís la consola de Bedrock. El anuncio puede esperar; la infraestructura en producción no.

---

Este artículo fue publicado originalmente en juanchi.dev