Scalable Video Processing and Streaming Pipeline with AWS

When I was building my video-based cohort review platform, I faced a big challenge:

How do I let students upload large video reviews, process them into multiple resolutions for smooth playback, and make them available to users quickly without overloading my backend server?

The solution:

An event-driven, serverless video processing pipeline powered by AWS S3, ECS, Lambda, and ffmpeg.

The Problem

If you try to handle video uploads and processing inside your main backend server, you’ll quickly run into trouble:

• Large uploads will consume your backend bandwidth and slow down other requests.

• Processing videos in real time will block your app and lead to timeouts.

• Serving raw video files isn’t streaming and browser-friendly, so users will face buffering issues.

And the above methods are not scalable at all.

I needed a way to:

• Offload uploads from backend.

• Process videos asynchronously after upload.

• Output streaming ready formats with multiple quality operations.

The Solution

Lets understand the architecture.

1. Direct upload to S3 bucket with signed URLs

   Instead of uploading videos to my backend, the frontend:

   1. Requests a signed URL from the backend.

   2. Uploads the raw video directly to a temporary S3 bucket.

Why?

No backend bandwidth bottleneck.

Faster uploads for users.

2. S3 Event → SQS Queue

   When a new video is uploaded, S3 sends an event notification to SQS.

   Why SQS is great here:

   1. Reliability: If processing is delayed, messages will wait in the queue.

   2. Scalability: Can handle spikes in uploads without overwhelming the video processing service.

   3. Retry support: Failed processing attempts can be retried automatically.

3. SQS → Lambda → ECS

   After receiving a message from the S3 bucket on upload, the SQS queue triggers a Lambda function. The Lambda function reads the message from SQS (a message like the object key). After reading the message, the Lambda function starts the ECS with the proper configurations and environment variables.

   

4. Video Processing Inside ECS

   Inside ECS:

   Download the raw video from the temporary bucket using the object key.

   Use FFMPEG to transcode it into multiple resolutions (1080p, 720p, 480p).

   Split it into chunks for adaptive bitrate streaming (HLS).

   Upload the processed files to the final S3 bucket with the following structure:

   You can find a sample FFMPEG usage here.

   

5. Final Bucket → DB Update

   The final S3 bucket is configured with another event notification. This triggers a Lambda function that updates the database with appropriate URLs so that the frontend can display the processed videos.

   

Secure and Fast Video Streaming

After video processing, it's crucial to ensure that the videos can be viewed from your platform. Simply hosting videos in Amazon S3 and serving them directly can leave them vulnerable to unauthorized sharing. Additionally, serving videos from S3 is not efficient from a performance perspective.

To tackle these problems, we will use a Content Delivery Network (CDN) which serves videos from edge servers spread around the world. AWS CloudFront provides a CDN service that allows smooth and secure video streaming.

Videos Serving Architecture

In AWS CloudFront, we create a distribution that points to the S3 bucket from which we want to serve the content. For security, we must block all public access to the bucket and remove all CORS configurations so that only CloudFront can access resources from the S3 bucket.

Before understanding video streaming, let's understand signed URLs and signed cookies.

Signed URLs: A signed URL is a normal CloudFront URL with a signature, expiration time, and policy information embedded in it. The user must use that exact URL to access the resources. It is suitable when we want to serve a single file.

Signed Cookies: A signed cookie provides authentication details (signature, policy, expiration) in cookies rather than in signed URLs. Once set, all requests from the browser automatically include the cookies. When using signed cookies, the URL structure of the resource remains clean and unchanged. Any request that matches the cookie policy is allowed.

In our use case, where we serve multiple files (a playlist of video chunks), signed URLs would be inefficient because signing every URL is not feasible, so we will use signed cookies.

Generating signed cookies:

Refer to the official AWS documentation to generate signed cookies using AWS SDK.

Note: to generate public and private keys to generate signed cookies, ensure that your node js version is <20.

When accessing assets through cloudfront, then signed cookies are being sent in request headers on every file request. If cookies are not present in header or policy is not matching, then content will not be served.

When cloudfront server receives a request, then it checks its cache, if cache is available then cloudfront serves the content else it fetches the content from S3 bucket once.

With this approach, we can serve content securely as well as fast because there are hundreds of CDN servers scattered around the world.

Conclusion

By combining AWS's event-driven services with ffmpeg, I have created a video pipeline that is scalable, reliable, and streaming-friendly.

• Uploads are offloaded directly to S3, avoiding bottlenecks.

• Processing is handled asynchronously in ECS with ffmpeg, producing multiple resolutions for adaptive streaming.

• Delivery is secured and accelerated using CloudFront with signed cookies, ensuring smooth playback across devices and locations.

This approach keeps the system modular and cost-efficient: each component (upload, processing, delivery) can scale independently based on demand.

If you are building a video-based platform, this architecture gives you a production-ready blueprint to handle video at scale.