Blog · Ingeniería
Build vs buy en AWS: cuándo el cómputo propio le gana al managed.
Los servicios managed cobran por output; el cómputo propio tiene una base casi fija. Las dos curvas se cruzan en algún punto, y conviene saber dónde antes de firmar.
Algunos servicios managed tienen un precio difícil de discutir: pagás solo cuando los usás, no mantenés infraestructura y escalan sin que tengas que pensarlo. Hasta que el volumen crece y, a cierta escala, te cobran diez veces lo que costaría correr lo mismo por tu cuenta.
La trampa no es que el managed sea malo. Es que su precio compra simplicidad, y pasado cierto volumen esa simplicidad deja de valer el múltiplo.
¿Cuánto cuesta cada opción a medida que crece el volumen?
Tomá un servicio managed que cobre por output (transcodificación de video, transformación de imágenes, OCR, lo que sea) y hacé la cuenta:
Costo managed = pricing oficial × volumen proyectado
Costo self-hosted = compute on-demand baseline + scale-out por queue depth
Para una carga real que dimensioné (archivos multimedia: video, imágenes, PDFs y audio), salió así:
| Volumen | Managed (proyectado) | Self-hosted (medido) |
|---|---|---|
| Carga actual | ~$6.000/año | ~$600/año |
| 2× carga | ~$12.000/año | ~$625/año |
| 5× carga | ~$30.000/año | ~$680/año |
La base casi no se mueve. El managed escala exactamente con el uso.
A bajo volumen gana el managed: no pagás un servidor que casi no trabaja. A medida que el volumen sube, el cobro por output se acumula y el self-hosted, con su base casi fija, queda muy por debajo.
¿Cómo se arma el self-hosted en AWS?
El patrón que me funcionó para cargas de este tipo: SQS en el medio y EC2 con un auto-scaling group (ASG) abajo.
upload → SQS → ASG (on-demand baseline + scaling por queue depth) → output
SQS desacopla: el upload termina rápido y el procesamiento arranca cuando hay capacidad. CloudWatch mide la profundidad de la cola; el ASG suma instancias cuando se acumula trabajo y las saca cuando la cola se vacía. Una instancia on-demand de base garantiza capacidad mínima en horario de uso.
Spot es tentador por el precio (entre 50 % y 70 % menos que on-demand), pero AWS puede recuperar la instancia con solo dos minutos de aviso. Si en ese momento estabas procesando un archivo, el mensaje queda invisible hasta que vence el visibility timeout y vuelve a la cola.
Funciona si los jobs son cortos e idempotentes: que reintentar sea seguro y que no dejen estado parcial en S3 sin limpiar. Es una decisión aparte de la arquitectura. Arrancá con on-demand y sumá spot después, si los números lo justifican y la idempotencia está bien resuelta.
Un ajuste que cambia la cuenta: apagá el ASG fuera de horario
La carga de la mayoría de los productos B2B no es pareja las 24 horas: pico en horario de oficina, casi nada a la noche y nada los fines de semana. La instancia de base cuesta lo mismo a las 3 de la mañana que a las 3 de la tarde, aunque de madrugada no procese nada.
Las scheduled actions del ASG lo resuelven sin cambiar el patrón:
- A la mañana:
min_size = 1. El ASG levanta la instancia de base antes del horario de uso. - A la noche:
min_size = 0. El ASG apaga todo. - Si llega un mensaje fuera de horario, las políticas de scaling por profundidad de cola pueden levantar capacidad igual, siempre que toleres unos minutos de cold start para ese job tardío.
Con eso recuperás buena parte del costo ocioso sin perder latencia en horario de uso. Es el equivalente self-hosted del pago por uso, pero medido contra tus horas de trabajo reales y no contra el primer mensaje del día.
Lambda no era una opción para esta carga: el timeout es de 15 minutos y los archivos más grandes tardaban más. Si lo tuyo entra en 15 minutos, quizás Lambda + SQS te alcance.
¿Qué costos no aparecen en la factura de AWS?
El precio del cloud no es el precio total. Cuando construís en lugar de comprar, te hacés cargo de lo que el managed te escondía:
- Configuración y ajuste del ASG: políticas de scale-up y scale-down, métricas de profundidad de cola, tiempos de warmup.
- Reintentos y DLQ: los errores dejan de ser problema del proveedor.
- Interrupciones de spot: replanificar el job cuando AWS te saca la instancia.
- Actualizaciones del stack de procesamiento: codecs nuevos, parches de seguridad, librerías que rompen.
- Guardia (on-call): cuando algo se cae un domingo.
Esa complejidad operativa es real y se concentra en pocas manos. Hoy mantenés el pipeline; mañana puede ser deuda latente. Si aparece un requisito que el managed resolvía con un toggle (DRM, HLS multi-bitrate, inserción de publicidad del lado del servidor), implementarlo te lleva semanas.
¿Cuándo conviene construir y cuándo comprar?
La regla que uso:
- Volumen bajo o impredecible → buy. El managed cobra cuando se usa; no pagás una base fija ociosa.
- Volumen alto y predecible, con cobro lineal del managed → build. La base fija se vuelve insignificante.
- Requisitos exóticos (DRM, formatos especiales, compliance) → buy, salvo que tengas un equipo dedicado.
- Equipo chico, guardia sin redundancia → buy. La complejidad operativa pesa más que el costo.
Y la regla del pulgar para decidir rápido: si el managed sale 5 veces más caro o más que el cómputo equivalente y escala linealmente con la demanda, armalo vos. Hacé la cuenta antes de integrar, no después.
El precio de cada lado
El managed te cobra por minuto de output. El self-hosted te cobra en complejidad operativa. Ninguno es gratis.
El error es no hacer la cuenta y dar por hecho que el managed es la opción por defecto. A veces lo es. A veces no, y la diferencia se acumula.