Amazon Prime Video: Serverless Back to a Monolith
also called Prime Video Audio/Video Monitoring
A distributed serverless pipeline was consolidated into a single process, reducing cost by over 90% — for one component, for specific reasons that do not generalise.
What happened
In 2023 an Amazon Prime Video team published an account of their audio and video quality monitoring service. The original design was a distributed serverless architecture: orchestration through Step Functions, processing in Lambda functions, and intermediate frames passed between components via S3.
They rebuilt it as a monolith running on container instances, and reported a cost reduction of over 90%.
Why the original design was expensive
The work is a tight pipeline: split a stream into frames, analyse each frame, aggregate the results. That produces very high volumes of small, short-lived intermediate data.
In the distributed design, every frame had to be written to S3 and read back by the next component, and every step transition was an orchestration state change. The actual analysis was cheap; the data movement and orchestration between components dominated the cost, and both scaled with the number of frames.
Moving the components into a single process turned network and storage round trips into in-memory function calls. The work did not change; the overhead disappeared.
What this does and does not prove
It was widely reported as "Amazon abandons microservices", which it is not. This is one component of one service, and the general point is narrower and more useful:
When components exchange high volumes of data at high frequency, the cost and latency of moving that data between them can exceed the cost of the work itself. Distribution has a per-boundary tax, and that tax scales with chattiness.
The transferable lesson
Distribution boundaries should follow change and ownership, not diagram aesthetics. A pipeline whose stages always run together, always scale together, are owned by one team and pass large volumes of intermediate data between them has no reason to be distributed — and every network hop between them is pure cost.
The useful diagnostic: for each service boundary, ask what data crosses it, how often, and what that crossing costs in latency, money and failure modes. If the answer is "a great deal, constantly, for no independence benefit", the boundary is in the wrong place.