AWS MediaConvert was 10x more expensive — and gets worse as you grow.
When a managed service costs ten times what the alternative would, the question isn't whether to replace it — it's how. SQS, EC2, and a queue that scales itself.
The AWS bill doesn't lie. When a managed service starts costing you ten times more than the alternative, the question isn't whether to replace it — it's how.
We were using AWS MediaConvert to process media files uploaded by users. Videos, images, PDFs, audio — whatever users upload. MediaConvert is built exactly for this: a managed transcoding service, no infrastructure to maintain, pay per minute of output. On paper, the obvious choice.
The numbers make it concrete. MediaConvert charges per minute of output. For our actual processing volume, that was landing at around $6,000 per year. Today, with the same load, our compute cost sits at around $600: a t4g.large on-demand instance as the always-on base — about $590 per year — plus spot instances for processing bursts at roughly 70% below on-demand rates, which adds single digits per month. That's the ten times — and the gap widens as demand grows. MediaConvert scales linearly: double the processing, double the cost, no ceiling. The EC2 approach doesn't. The base is fixed regardless of volume. The spot instances add a few cents per burst, whether there are ten jobs in the queue or a thousand. The more you process, the larger the multiple in your favor.
| Volume | MediaConvert | EC2 (base + spot) |
|---|---|---|
| Current load | ~$6,000/yr | ~$600/yr |
| 2× load | ~$12,000/yr | ~$625/yr |
| 5× load | ~$30,000/yr | ~$680/yr |
The base barely moves. MediaConvert scales exactly with you.
The first alternative was Lambda. Serverless, scales to zero, triggers on upload — sounds right for a processing job. But there's a hard limit: Lambda times out at 15 minutes. Some of our files take longer than that to process. Lambda was out.
What we built: SQS sits between the user upload and the processing. When someone uploads a file, a message goes into the queue. That decoupling means the upload finishes fast, the user doesn't wait, and the work gets picked up when capacity is available. EC2 instances — t4g, ARM-based — pick up jobs from the queue and run the processing stack — FFmpeg for video, Sharp for images, Ghostscript for documents, with no timeout constraint. They can run for as long as the file needs. CloudWatch watches the queue depth and signals the Auto Scaling Group to bring up spot instances when jobs stack up, then scales back down when the queue drains.
The base is always-on: one t4g.large. Everything above that is spot, appears when needed, and disappears when it doesn't.
Building this comes with a tradeoff. You now own what MediaConvert was hiding: queue configuration, scaling policies, instance lifecycle, retry logic. That operational complexity is real and it's yours.
And to be honest about the other direction: if you're at low or unpredictable volume — an MVP, an early product — MediaConvert's pay-per-use model is probably the right call. You're not paying a fixed base for infrastructure that sits mostly idle. The economics only flip when your processing volume makes that fixed base irrelevant compared to the per-minute charges stacking up.
The point isn't that managed services are always wrong. It's that their price premium buys you simplicity — and at some scale, that simplicity is no longer worth the multiple.
Read the bill. Ask what the managed service is actually giving you. Sometimes the answer is "ten times what makes sense to spend."
Have you hit a similar decision on AWS? Write me at hello@sebastianfermanelli.com.