AWS MediaConvert era x10 más caro — y empeora cuanto más crecés.
Cuando un servicio managed cuesta diez veces más que la alternativa, la pregunta no es si reemplazarlo — es cómo. SQS, EC2, y una cola que se escala sola.
La factura de AWS no miente. Cuando un servicio managed empieza a costarte diez veces más que la alternativa, la pregunta no es si reemplazarlo — es cómo.
Estábamos usando AWS MediaConvert para procesar archivos multimedia que subían los usuarios. Videos, imágenes, PDFs, audio — lo que el usuario suba. MediaConvert existe exactamente para esto: un servicio managed de transcoding, sin infraestructura que mantener, se paga por minuto de output. En papel, la opción obvia.
Los números lo hacen concreto. MediaConvert cobra por minuto de output. Para nuestro volumen real de procesamiento, eso nos estaba costando alrededor de $6.000 por año. Hoy, con la misma carga, el costo de cómputo está en alrededor de $600: una instancia t4g.large on-demand como base siempre activa — unos $590 por año — más instancias spot para los picos de procesamiento a aproximadamente un 70% por debajo del precio on-demand, lo que agrega un par de dólares por mes. Eso es el diez veces — y la diferencia crece con la demanda. MediaConvert escala lineal: el doble de procesamiento, el doble de costo, sin techo. La solución con EC2 no. La base es fija independientemente del volumen. Las instancias spot agregan unos centavos por pico, ya sean diez jobs en la cola o mil. Cuanto más procesás, más grande se vuelve el múltiplo a tu favor.
| Volumen | MediaConvert | EC2 (base + spot) |
|---|---|---|
| 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. MediaConvert escala exactamente con vos.
La primera alternativa fue Lambda. Serverless, escala a cero, se dispara con el upload — suena bien para un job de procesamiento. Pero tiene un límite duro: Lambda tiene timeout a los 15 minutos. Algunos de nuestros archivos tardan más que eso en procesarse. Lambda quedó descartada.
Lo que armamos: SQS se sienta entre el upload del usuario y el procesamiento. Cuando alguien sube un archivo, entra un mensaje a la cola. Ese desacoplamiento hace que el upload termine rápido, el usuario no espera, y el trabajo se toma cuando hay capacidad disponible. Instancias EC2 — t4g, basadas en ARM — toman los jobs de la cola y corren el stack de procesamiento — FFmpeg para video, Sharp para imágenes, Ghostscript para documentos, sin ningún límite de tiempo. Pueden correr todo lo que el archivo necesite. CloudWatch mira la profundidad de la cola y avisa al Auto Scaling Group para levantar instancias spot cuando los jobs se acumulan, y vuelve a bajar cuando la cola se vacía.
La base siempre activa: una t4g.large. Todo lo que está por encima son spots, aparecen cuando se necesitan y desaparecen cuando no.
Construir esto tiene un tradeoff. Ahora sos dueño de lo que MediaConvert ocultaba: la configuración de la cola, las políticas de escalado, el ciclo de vida de las instancias, la lógica de reintentos. Esa complejidad operacional es real y es tuya.
Y para ser honesto sobre el otro lado: si estás en bajo volumen o demanda impredecible — un MVP, un producto temprano — el modelo pay-per-use de MediaConvert probablemente es la decisión correcta. No estás pagando una base fija por infraestructura que está mayormente idle. La economía solo se invierte cuando tu volumen de procesamiento hace que esa base fija sea irrelevante comparada con los cargos por minuto que se acumulan.
El punto no es que los servicios managed siempre estén mal. Es que su precio compra simplicidad — y en cierta escala, esa simplicidad ya no vale el múltiplo.
Leé la factura. Preguntate qué te está dando el servicio managed. A veces la respuesta es "diez veces lo que tiene sentido gastar."
¿Te encontraste con una decisión parecida en AWS? Escribime a hello@sebastianfermanelli.com.