A sane AWS video streaming architecture for 2026

Video architecture attracts over-engineering. Most subscription catalogues don’t need a multi-region DRM platform on day one. They need a private bucket, a reliable transcoder, a CDN, and playback that starts quickly on a ₹12,000 phone.

We’ve run this shape for Raykulam and Shaligram Healing: S3 + MediaConvert + CloudFront, with EC2 auto scaling behind the application and CloudWatch around it. It’s not exotic. It’s boring in the way infrastructure should be.

The job to be done

Strip away the vendor names and a video platform has five jobs: accept an upload, process it into playable formats, store the output, deliver it close to the viewer, and decide who is allowed to watch. Everything else — recommendations, analytics, downloads — sits on top of those five.

The five-piece pipeline

Why HLS, not a giant MP4

HLS splits video into short segments described by a manifest. The player picks a rendition that fits the current bandwidth. That means faster start, fewer stalls, and better mobile behaviour. It also lets the CDN cache segments instead of streaming a unique file per user.

For VOD, 4–6 second segments are a good default. Shorter segments improve latency but increase request overhead. For low-latency live, use a different design; don’t copy a VOD ladder into a live event and hope.

A bitrate ladder that doesn’t waste money

Don’t create twelve renditions because a guide says so. Start with four or five that cover real devices, then use quality-defined variable bitrate (QVBR) or per-title analysis where your pipeline supports it.

Audio at 96–128 kbps AAC is usually enough for speech. Captions are not optional if you care about accessibility, search, and corporate buyers. Animation and film grain need more bits than an interview.

Keep the bucket private

The source bucket should not be public. CloudFront should read it through Origin Access Control, and direct S3 URLs should be blocked. If a video URL works without a signature, assume it will end up in a WhatsApp group.

• Block public access at the account and bucket level.
• Use OAC, not a public bucket policy or a legacy origin access identity.
• Allow TLS only.
• Sign URLs or cookies with short expiry.
• Rotate CloudFront key pairs and store the private key on the server.
• Add WAF rules and rate limits for abuse-prone endpoints.
• Separate development, staging, and production buckets.

Authorisation belongs in your backend

The player shouldn’t decide who paid. Your API checks the subscription or purchase, then returns a short-lived signed URL or sets a signed cookie. Keep the CloudFront private key on the server.

For HLS, a signed cookie is often more practical than signing every segment URL, because the player requests a manifest and then dozens of parts. A wildcard signed URL policy can work too. Either way, the expiry should be shorter than a typical viewing session and the policy should cover only the content the viewer is entitled to.

// Server-side only. Never ship the CloudFront private key to the browser.
export async function getPlaybackUrl(userId: string, videoId: string) {
  const entitled = await hasActiveAccess(userId, videoId);
  if (!entitled) throw new Error("Not entitled");

  return signCloudFrontUrl({
    resource: `https://cdn.example.com/videos/${videoId}/*`,
    expires: Date.now() + 2 * 60 * 60 * 1000,
  });
}

The cost that surprises people

Egress usually dominates. A simple estimate: hours viewed × average bitrate ÷ 8 = gigabytes delivered. 1,000 hours at 2 Mbps is about 900 GB, before protocol overhead. Transcoding is spiky; delivery grows with success.

Put a CloudFront usage alarm and an AWS Budget alert on before launch. The first viral video shouldn’t be the first time you look at the bill.

Monitor the pipeline, not just the player

• MediaConvert job events through EventBridge, with retries and a dead-letter path.
• Duration and rendition checks after every transcode.
• CloudFront 4xx/5xx rates and cache hit ratio.
• Time to first frame and playback start failures by device.
• Upload failures and abandoned multipart uploads.
• Cost anomalies by distribution and content type.

Operations checklist

1. Block public access and verify with an unauthenticated request.
2. Confirm CloudFront can read the origin only through OAC.
3. Set lifecycle rules for masters, intermediates, and old outputs.
4. Add retries and alarms around MediaConvert jobs.
5. Test signed access with an expired URL.
6. Test playback on iOS Safari, Android Chrome, and a slow connection.
7. Add captions and test them on both players.
8. Set budget and usage alarms.
9. Document the reprocessing runbook.
10. Run a load test against the CDN, not the origin.

Where teams get it wrong

• A public S3 bucket “just for now”.
• Streaming MP4 files from the application server.
• CloudFront keys or AWS credentials in client-side JavaScript.
• No lifecycle policy, so storage grows forever.
• Transcoding the same video on every request.
• One 4K rendition for a catalogue that is mostly watched on phones.
• No retry or alert when a transcode fails.
• No cost alarm until the invoice arrives.
• Ignoring captions and accessibility.

None of this is glamorous. That’s the point. A good streaming platform is measured by how rarely anyone has to think about it.

Keep it boring

Start with the five-piece pipeline, keep the origin private, make access short-lived, and instrument the parts that cost money. You can add DRM, low-latency live, or multi-region later. You can’t easily undo a public bucket or a year of unbudgeted egress.