CLOUD ARCHITECTURE & CASE STUDY#12 • Amazon Prime Video VQA

Why Amazon Changed the Architecture of Prime Video's VQA Service.

Amazon moved a video monitoring service from a distributed serverless setup to a single-process architecture, reducing infrastructure costs by over 90%. Prime Video itself did not switch from microservices to a monolith. Here is a breakdown of what changed in the Video Quality Analysis (VQA) service and why.

By Shyam KumarJul 20, 20268 min read
#AWS#Microservices#PrimeVideo#CloudCost
01 / CLARIFICATION

Did Amazon Abandon Microservices?

When the Prime Video Engineering team published their article, it led to headlines like: “Amazon ditches microservices!” or “Microservices are dead, Prime Video moved to a monolith!”

What Actually Happened (Source: Prime Video Engineering)

Important: Amazon did not convert all of Prime Video to a monolith. Prime Video's main streaming platform, user accounts, catalog, and billing still run on microservices.

The change was made to only one component: the Video Quality Analysis (VQA) service.

Here is how the Video Quality Analysis service worked, its original architecture, and why it ran into issues at scale.

02 / THE WORKLOAD

What the Video Quality Analysis (VQA) Service Did

Prime Video used an internal service called Video Quality Analysis (VQA) to monitor live and on-demand video streams:

What the VQA Tool Did:

  • •Analyze video stream frames and audio in real time.
  • •Detect audio and video defects such as blockiness, frozen frames, sync issues, or audio drops.
  • •Alert operators immediately if an issue affected customer streams.

Because Prime Video streams thousands of live feeds and titles, this service had to process a large volume of video frames continuously.

03 / DISTRIBUTED SERVERLESS

The Old Architecture: Distributed and Serverless

The team initially built the service using AWS serverless components to build and deploy quickly:

┌── OLD ARCHITECTURE: SERVERLESS & DISTRIBUTED WORKFLOW ────────┐
[Video Stream Input]
│
▼
┌─────────────────────────────────────────────────────────────┐
│              AWS STEP FUNCTIONS (Orchestrator)                │
│           (Managing thousands of state transitions)                │
└──────────┬───────────────────────┬──────────────────────┬───┘
           │ (Trigger)             │ (Trigger)            │ (Trigger)
           ▼                       ▼                      ▼
┌──────────────────────┐┌──────────────────────┐┌──────────────────────┐
│  AWS Lambda (Converter)││ AWS Lambda (Detector 1)││ AWS Lambda (Detector 2)│
└──────────┬───────────┘└──────────┬───────────┘└──────────┬───────────┘
           │ (Upload Images)       │ (Read/Write Images)  │ (Read/Write Images)
           └───────────┬───────────┴───────────┬──────────┘
                       ▼                       ▼
┌─────────────────────────────────────────────────────────────┐
│                  AMAZON S3 BUCKET (Intermediate Storage)             │
│         (Massive amount of intermediate image reads & writes)       │
└─────────────────────────────────────────────────────────────┘
└─────────────────────────────────────────────────────────────────┘

In the original architecture:

  • AWS Step Functions: Coordinated the workflow and detection steps.
  • AWS Lambda: Ran individual defect detection algorithms (video decoding, blockiness detector, freeze detector) as separate serverless functions.
  • Amazon S3: Stored extracted video frames as temporary files so downstream Lambda functions could download and inspect them.
04 / THE PROBLEM

Too Much Communication and Intermediate Data Transfer

The issue was not that microservices or serverless were flawed. The issue was that this specific workload required heavy data transfer and constant communication between components.

1. S3 I/O and Network Overhead

Thousands of video frames were uploaded to S3 every second, and detector functions downloaded them back. This constant upload and download cycle added network latency and increased storage costs.

2. Step Functions Account Limits & Cost

AWS Step Functions charges per state transition. Running multiple transitions for every single video frame hit account limits and caused costs to rise quickly.

VideoDetectorLambda.java(Java)
// Old Architecture: Intermediate storage hops via S3
// Each detector ran in a separate AWS Lambda function

public class VideoDetectorLambda {
    private final AmazonS3 s3Client;

    public void handleRequest(S3Event event) {
        // Step 1: Download video frames from S3 (High Network I/O & latency)
        byte[] videoFrame = s3Client.getObject("vqa-frames-bucket", "stream-101/frame-45.jpg");

        // Step 2: Run quality analysis algorithm
        DefectResult result = analyzeDefect(videoFrame);

        // Step 3: Write intermediate results back to S3 for next Step Function stage
        s3Client.putObject("vqa-frames-bucket", "stream-101/defect-result.json", result.toJson());
    }
}
Core Problem: The components spent more time transferring data and coordinating than doing actual compute work.
05 / SIMPLIFICATION

The Change: Moving Components into a Single Process

The team simplified the architecture by moving the separate components into a single application process.

┌── NEW ARCHITECTURE: SINGLE-PROCESS ON AMAZON ECS ───────────────┐
[Video Stream Input]
│
▼ (Direct Stream into Container)
┌─────────────────────────────────────────────────────────────┐
│               AMAZON ECS CONTAINER (Single Process)              │
│  ┌───────────────────────────────────────────────────────┐  │
│  │             SHARED IN-MEMORY BUFFER (RAM)             │  │
│  │           (Video frames kept directly in memory)     │  │
│  └───────┬───────────────────────┬───────────────────────┬─┘  │
│          │ (Memory Pointer)      │ (Memory Pointer)     │    │
│          ▼                      ▼                      ▼    │
│  ┌───────────────┐     ┌───────────────┐     ┌───────────────┐  │
│  │ Video Decoder │     │ Detector A │     │ Detector B │  │
│  └───────────────┘     └───────────────┘     └───────────────┘  │
└─────────────────────────────────────────────────────────────┘
│ (Only final aggregated results saved)
▼
[Event Notifications & Alerts]
└─────────────────────────────────────────────────────────────────┘

Key Changes in the New Architecture:

  • ✓In-Memory Data Transfer: Video frames were no longer written to S3. They stayed in container memory, accessible directly via memory pointers by all detector routines.
  • ✓Step Functions Removed: Workflow orchestration moved inside the application code using standard method loops.
  • ✓Amazon ECS & EC2 Deployment: The application was packaged into a container, deployed to Amazon ECS (Elastic Container Service), and scaled horizontally on EC2 instances.
VideoQualityAnalysisService.java(Java)
// New Architecture: In-Memory Processing in a Single Process
// All detectors run together inside one container on Amazon ECS

public class VideoQualityAnalysisService {
    private final List<VideoDefectDetector> detectors;

    public void processStreamChunk(VideoChunk chunk) {
        // Frames stay in shared RAM memory (No S3 calls, zero network hops)
        byte[] frameBuffer = chunk.getRawBuffer();

        // Detectors process the buffer directly in-memory
        for (VideoDefectDetector detector : detectors) {
            detector.analyze(frameBuffer);
        }

        // Only final aggregated defect alerts are sent to storage/alerts
    }
}
06 / RESULT

Result: 90%+ Infrastructure Cost Reduction

According to figures shared by the Prime Video engineering team:

90%+
Infrastructure Cost Reduction

Removing intermediate S3 reads and writes and Step Functions transitions let the application process frames in memory, reducing costs by over 90%.

Other Benefits:

• Removed account scaling limits from Step Functions.
• Reduced processing latency by removing network calls.
• Simplified horizontal scaling across thousands of video streams.

07 / ENGINEERING LESSON

The Lesson: Match Architecture to the Workload

The takeaway here is not that monoliths are better than microservices or that serverless is bad.

“There is no single architecture that works best for every workload. The architecture should match the requirements of the workload.”

Microservices or Serverless Work Well When:

  • • Components need independent deployments and release schedules.
  • • Separate teams own distinct business domains.
  • • Services pass small payloads over the network.
  • • Traffic is bursty or event-driven (such as signup flows or payment webhooks).

A Single Process or Monolith Works Well When:

  • • Heavy data transfer (such as video frames) occurs between stages.
  • • Processing needs to happen directly in memory.
  • • Frequent network calls between services create performance bottlenecks.
  • • A closely related workload needs tight optimization.
08 / SUMMARY

Summary

The Prime Video team looked at the workload, found the main bottleneck, and moved the processing into a single process.

Sometimes a simpler architecture is the better architecture.

Did you find this breakdown helpful?

Share it with other developers discussing microservices, monoliths, and cloud architecture.

Like: If you found this breakdown useful
Share: With fellow backend and cloud engineers
Back to All Articles in The Tech Corner
Discuss Architecture? Contact Me