Prime Video's Move Back to a Monolith

What was published

In March 2023 the Prime Video Video Quality Analysis team published "Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%". The original design used AWS Step Functions to orchestrate, Lambda functions to analyse individual video frames, and S3 to pass intermediate data between them.

It worked, and it did not scale economically. Two constraints dominated:

• Orchestration cost. Step Functions charged per state transition, and the workflow performed a transition per second of video analysed. The bill scaled with content duration, not with value.
• Data transfer cost and latency. Frames were written to S3 by one component and read back by another. At the frame rates involved, the intermediate storage traffic dominated everything else.

They hit a hard ceiling at around 5% of the expected load.

The rewrite moved every component into one process running on ECS/EC2. Frames stayed in memory rather than round-tripping through S3, and orchestration became function calls. The reported result was a 90%+ cost reduction and the ability to scale to full load.

What it actually demonstrates

Not "microservices are bad". Three narrower and more useful lessons:

1. Distribution has a per-hop cost that dominates chatty, data-heavy workloads. Serialising, storing and re-reading data between components is nearly free when hops are rare and payloads are small. It is the whole bill when a hop happens per video frame. The design question is not "should these be separate services" but "how much data crosses this boundary, how often?"

2. Serverless orchestration is priced for coordination, not computation. Step Functions is excellent for a workflow with tens of steps and human-scale timing; it is the wrong instrument for a tight inner loop. The failure was matching the tool to the shape of the work.

3. Architecture is evolutionary and reversal is legitimate. Werner Vogels' response made this point explicitly: the team built, measured, learned the cost model and changed the design. That sequence is the intended behaviour, not an admission of error.

The caveats that get dropped in retellings

It was one component inside Amazon, not a company-wide reversal. The result was a single-process service, still deployed independently, still owned by one team — a modular monolith, not a return to a shared enterprise application. And the original serverless design was a reasonable starting point that let them learn the workload cheaply before committing.

The transferable question

For any proposed boundary: what crosses it, how often, and what does that cost? Chatty boundaries with large payloads should be in-process. Boundaries with independent scaling profiles, different failure requirements or different owning teams should be services — and the second set of reasons is about organisations, not about performance.