Amazon's Microservices-to-Monolith Epic: How Prime Video Cut Costs by 90%

In 2023, the Amazon Prime Video team published a case study that sent shockwaves through the software architecture world. After years of building with microservices, they restructured a critical monitoring service into a modular monolith — and slashed infrastructure costs by over 90%.

This wasn't a small experiment. The Prime Video team monitors the quality of thousands of live streams in real time, detecting issues like block corruption, video freeze, and audio-video synchronization problems. Their story challenges the industry dogma that microservices are always the right default and offers a masterclass in pragmatic architecture decisions.

The core insight: microservices and serverless components are tools, not religion. Choosing the right abstraction for the right workload matters more than following trends.

Footnotes

1. Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% - Amazon Prime Video Tech Blog, March 2023. ↩

2. Even Amazon can't make sense of serverless or microservices - David Heinemeier Hansson (DHH), May 2023. ↩

The Original Serverless Architecture

Prime Video's initial Video Quality Analysis (VQA) system was built as a distributed system using serverless components. This was a deliberate choice — serverless allowed the team to build the service quickly, and in theory, scale each component independently.

The architecture had three major components:

1. Media Converter — Extracted frames and audio from incoming video streams
2. Defect Detector — Analyzed the extracted data for quality issues using ML
3. Real-time Notification — Alerted teams when defects were found

The orchestration between these components was managed by AWS Step Functions, with individual processing steps running as AWS Lambda functions. Intermediate data (video frames, audio snippets) was passed between services by writing to and reading from Amazon S3 buckets.

At first, this architecture worked well. But as they scaled to monitor more streams simultaneously, they encountered crippling bottlenecks.

Footnotes

1. Prime Video Microservices - System Design Newsletter - Neo Kim, detailed architecture breakdown. ↩

2. Amazon Prime Video Monitoring Service - ByteByteGo - Architecture diagrams and cost analysis. ↩

What Went Wrong: The Two Expensive Operations

The Prime Video team identified two primary cost drivers that made the distributed architecture unsustainable:

1. Orchestration Overhead (AWS Step Functions)

AWS Step Functions charges per state transition. The VQA service performed multiple state transitions for every second of every stream being monitored. At high scale — thousands of concurrent streams — this generated an enormous number of billable transitions. Worse, AWS imposes account-level thresholds on the number of state transitions, which became a hard scaling bottleneck. The team hit this limit at only ~5% of expected load.

2. Data Transfer Between Distributed Components

Because the media converter and defect detector ran as separate services, intermediate data (video frames, audio buffers) had to be stored in Amazon S3 so downstream services could retrieve it. This created two problems:

• High S3 request costs: Every write and read to the temporary S3 bucket was billed, and with thousands of frames per second across thousands of streams, these costs exploded.
• High latency: Writing to and reading from S3 added significant latency compared to keeping data in process memory.

Footnotes

1. Prime Video Microservices - System Design Newsletter - Neo Kim, detailed architecture breakdown. ↩ ↩²

The New Architecture: A Modular Monolith

The redesigned system preserved the same three logical components (media converter, defect detector, notifications) but deployed them within a single process. This is the key distinction: it is a modular monolith, not a "big ball of mud."

The critical design principle: deployment architecture changed, but logical architecture was preserved. The code was already organized into clean internal modules, so the team could reuse the vast majority of their code during migration.

Footnotes

1. Amazon Prime Video Monitoring Service - ByteByteGo - Architecture diagrams and cost analysis. ↩ ↩²

The Results: By the Numbers

The outcome of the migration was dramatic and well-documented in Amazon's own publication:

"Moving our service to a monolith reduced our infrastructure cost by over 90%. It also increased our scaling capabilities. Today, we're able to handle thousands of streams and we still have capacity to scale the service even further." — Amazon Prime Video Tech Blog

Footnotes

1. Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% - Amazon Prime Video Tech Blog, March 2023. ↩ ↩²

Why This Worked: The Deeper Analysis

The Prime Video case study isn't simply "microservices bad, monolith good." Understanding why the monolith succeeded here requires analyzing the specific characteristics of this workload:

Tightly Coupled Data Flow

The VQA pipeline is a linear, sequential data flow: media conversion → defect detection → notification. The output of one stage is the direct input to the next, with no branching, no independent scaling requirements, and no separate consumer patterns. Passing large binary data (video frames) over a network between microservices for this type of pipeline is particularly wasteful.

High-Throughput, High-Frequency Processing

The system processes data for every second of every stream — creating a constant, high-frequency hot path. Serverless pricing models (per-invocation, per-transition, per-request) are optimized for sporadic, event-driven workloads, not for continuous, high-volume streaming pipelines. The network tax of the distributed architecture was unsustainable.

Modularity Was Already Preserved

The team had organized their code into clean, well-separated logical components from the start. This made the migration relatively straightforward — they didn't need to untangle a messy codebase. They simply changed the deployment topology from separate services to a single process while keeping the internal module boundaries intact.

$$\text{Total Cost}_{\text{microservices}} = C_{\text{compute}} + C_{\text{orchestration}} + C_{\text{data transfer}} + C_{\text{serialization}} + C_{\text{operational overhead}}$$ $$\text{Total Cost}_{\text{monolith}} \approx C_{\text{compute}} + C_{\text{EC2 instance}}$$

The monolith eliminates the middle terms — orchestration, data transfer, and serialization costs — when the workload is a tightly-coupled pipeline running on a single machine.

Footnotes

1. Amazon Prime Video Monitoring Service - ByteByteGo - Architecture diagrams and cost analysis. ↩ ↩²

2. Even Amazon can't make sense of serverless or microservices - David Heinemeier Hansson (DHH), May 2023. ↩

Architecture Decision Framework

Rather than choosing an architecture based on hype, use a structured decision framework:

Key Decision Criteria