Video at Serverless Scale: FFmpeg on AWS Lambda

Six contracts with one client between 2016 and 2018: FFmpeg encoding pipelines on Lambda, auto-scaling EC2 for the heavy jobs, and the operational discipline to keep media infrastructure boring.

The Brief

In 2016, running FFmpeg inside AWS Lambda was an odd idea. The runtime was constrained, binaries had to be packaged by hand, and most teams defaulted to always-on servers. A client with a media product wanted encoding that cost nothing while idle and scaled instantly under load.

What I Built

FFmpeg-on-Lambda encoding: packaged binaries, tuned memory/duration trade-offs, S3 in, S3 out, API Gateway in front.
An EC2 overflow tier for jobs beyond Lambda's limits, scaled up and torn down automatically.
Successive revisions across six contracts as formats, volumes and AWS itself changed, December 2016 to February 2018, then a seventh contract for their Laravel application on the same AWS account.
Adjacent serverless work the pattern unlocked: ImageMagick GIF pipelines, Python ETL, DynamoDB backends, Zoho integrations.

Architecture: upload to S3, API Gateway, encode routed by file size to AWS Lambda with FFmpeg or to an EC2 tier for large files, output to S3

7contracts with the same client on this pipeline

5 yrsrelationship span, 2016-2021

20+AWS contracts delivered since 2016

$0idle cost. The point of going serverless

Why It Holds Up

Media infrastructure earns trust by being boring: predictable costs, observable failures, retries that work. The measure of this system is not a benchmark. It is a client who came back six times in fourteen months to grow it.

Message me on the platform where you found this and I will answer there.