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 fija. La economía cruza, y conviene saber dónde está el cruce antes de firmar.
Algunos servicios managed son geniales por su precio. Cobran solo cuando los usás. No mantenés infraestructura. Escalan sin que pienses. Y a una cierta escala, te están cobrando 10× lo que cuesta correr lo mismo vos.
La trampa no es que el managed sea malo. Es que su precio compra simplicidad, y a partir de cierto volumen esa simplicidad ya no vale el múltiplo.
La cuenta antes de integrar
Tomá un servicio managed con cobro por output (transcoding de video, transformaciones de imagen, OCR, lo que sea). 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é (procesamiento de archivos multimedia: video, imágenes, PDFs, audio), los números daban 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 apenas se mueve. El managed escala exactamente con el uso.
A bajo volumen, el managed gana, no estás pagando un servidor mayormente idle. A medida que el volumen sube, el cobro por output se acumula, y el self-hosted, con su base casi fija, te queda muy abajo.
La forma del self-hosted
El patrón que funciona para cargas similares: SQS al medio, EC2 con auto-scaling group debajo.
upload → SQS → ASG (on-demand baseline + scaling por queue depth) → output
SQS desacopla. El upload termina rápido y el procesamiento se toma cuando hay capacidad. CloudWatch mira la profundidad de la cola y el ASG escala out cuando se acumula trabajo, escala in cuando la cola se vacía. Una instancia baseline on-demand garantiza capacidad mínima en horario de uso.
Sobre spot: tentador por el precio (50-70% menos que on-demand), pero AWS puede recuperar la instancia con dos minutos de aviso. Para un job que está procesando un archivo, eso significa que el mensaje queda invisible hasta que vence el visibility timeout y vuelve a la cola. Funciona si los jobs son idempotentes y cortos: que el reintento sea seguro, que no dejen estado parcial en S3 sin limpiar. Es una decisión separada de la arquitectura general. Arrancá con on-demand, sumá spot después si los números lo justifican y la idempotencia está bien armada.
El twist: si tu carga tiene horarios, apagá el ASG fuera de horario
La carga de la mayoría de los productos B2B no es 24/7 uniforme. Pico durante horas de oficina, casi cero a la noche, cero los fines de semana. La base on-demand cuesta lo mismo a las 3 AM que a las 3 PM, aunque a las 3 AM no esté procesando nada.
Scheduled actions del ASG resuelven esto sin cambiar el patrón:
- A la mañana:
min_size = 1, ASG arranca la baseline antes del horario de uso. - A la noche:
min_size = 0, ASG apaga todo. - Si llega algún mensaje fuera de horario, las scaling policies por queue depth pueden levantar capacidad igual, asumiendo que tolerás unos minutos de cold-start para ese job tardío.
Eso recupera buena parte del costo idle sin sacrificar latencia en horario de uso. Es el equivalente self-hosted del pay-per-use pero centrado alrededor de cuándo realmente trabajás, no del primer mensaje del día.
Lambda no era opción para esta carga: timeout a los 15 minutos, y los archivos más grandes tardaban más. Si tu workload entra en 15 minutos, Lambda + SQS quizá te alcance.
Lo que el self-hosted te factura por afuera
El precio del cloud no es el precio total. Cuando construís en lugar de comprar, te hacés cargo de cosas que el managed escondía:
- Configuración y tuning del ASG, políticas de scale-up/down, métricas de queue depth, períodos de warmup.
- Reintentos y DLQ, los errores ya no son problema del proveedor.
- Spot interruptions, replanificar el job cuando AWS te saca la instancia.
- Updates del stack de procesamiento, codecs nuevos, parches de seguridad, librerías que rompen.
- On-call, cuando algo se rompe un domingo.
Esa complejidad operacional es real y se concentra en pocas manos. Hoy mantenés el pipeline. Mañana es deuda latente: si aparece un requerimiento que el managed resolvía con un toggle (DRM, HLS multi-bitrate, ad insertion server-side), te lleva semanas implementarlo.
Cuándo build, cuándo buy
La regla que uso:
- Volumen bajo o impredecible → buy. El managed te cobra cuando se usa, no pagás base fija idle.
- Volumen alto y predecible, con cobro lineal del managed → build. La base fija se vuelve insignificante.
- Requerimientos exóticos del managed (DRM, formatos especiales, compliance) → buy a menos que tengas equipo dedicado.
- Equipo chico, on-call sin redundancia → buy. La complejidad operacional pesa más que el costo.
La regla del pulgar para decidir rápido: si el managed sale ≥5× más caro que el cómputo equivalente y escala lineal con la demanda, construilo vos. Hacé la cuenta antes del integrate, no después.
El precio de cada lado
El managed te cobra por minuto de output. El self-hosted te cobra en complejidad operacional. Ninguno de los dos es gratis.
El error es no hacer la cuenta y asumir que el managed es la opción default. A veces lo es. A veces no, y la diferencia se acumula.