CloudFront can deliver video files and packaged streams to viewers, but it does not turn a source video into streaming renditions. For a straightforward video-on-demand setup, prepare the video first, store the finished files in S3, then configure CloudFront to deliver them.
This guide follows that S3-backed VOD path. Live streaming uses a different encoding and packaging workflow, so it belongs in a separate section rather than being folded into the same set-up steps.
What CloudFront does, and what it does not
CloudFront is a content delivery network: it serves content from an origin such as an S3 bucket to viewers over HTTP or HTTPS. Amazon Web Services describes both VOD and live delivery in its CloudFront video streaming guide. The service distributes content; it is not the encoder that creates your streaming files.
For VOD, your files are available for viewers to request when they want to watch. You can deliver a single video file, such as an MP4, through CloudFront. That is different from adaptive streaming, where a player requests a manifest and then retrieves media segments at a suitable quality. AWS says you must use an encoder to package video content before CloudFront can distribute it as a streaming package.
The distinction matters when choosing what to set up. If you only need to deliver a finished MP4, the file itself can be the object CloudFront serves. If you need adaptive playback, prepare the manifest and segments first. CloudFront will not create multiple resolutions from your original file, nor will it create the manifest that tells a player which segments to request.
It also helps to separate delivery from playback. CloudFront provides URLs for your objects or packaged stream. A player on a website, app or device makes requests to those URLs and interprets the manifest and media. Check the formats supported by your intended players before selecting an encoding workflow; a format choice should follow the clients you need to serve, not a general claim that one format suits everyone.
Prepare the video as segments and manifests
Start by deciding whether you are delivering a single file or an adaptive stream. A single MP4 may be enough for a simple viewing page, but it does not on its own provide adaptive bitrate playback. For that, an encoder produces one or more versions of the video, divides the media into segments, and writes a manifest that describes the available stream to the player.
AWS lists MPEG-DASH, HLS, Smooth Streaming and CMAF among formats used for streaming video. The right choice depends on your workflow and the devices and players you intend to support. Test that choice with the actual player rather than assuming every television, browser, phone or embedded player behaves the same way.
For a VOD package, an encoding service such as AWS Elemental MediaConvert can produce the outputs. If you want playback to adjust to a viewer's connection, configure appropriate renditions at different resolutions or bitrates. The player can then select among the versions represented in the package. This takes more preparation and storage than publishing one file, but it gives compatible players alternatives when bandwidth or device capability differs.
Keep the output structure intact when you upload it. A manifest refers to media segments, and players request those referenced objects using paths. If you move, rename or omit a segment after packaging, the manifest may load while playback fails when the player requests missing media. Treat the encoder's output as a set: manifest files, segments and any supporting files should remain together in the expected paths.
Before moving on, note the package's entry-point manifest and the folder in which the output will live. You will need its path when testing through CloudFront. If you are preparing recorded material for a continuous YouTube broadcast rather than hosting VOD for on-demand viewers, the encoding and publishing goal is different; see this guide to choosing 720p settings for a pre-recorded YouTube live stream.
Create an S3 bucket and upload the content
Create an S3 bucket to hold the video source, or the completed streaming package, according to your workflow. In the AWS VOD tutorial, the bucket is the origin CloudFront will use. Choose a Region with your audience, cost and regulatory requirements in mind; do not treat the bucket location as a substitute for checking applicable obligations or current AWS charges.
For packaged VOD, upload the encoded output, not just the original source file, if the goal is adaptive playback through a manifest. Preserve the directory structure generated by the encoding process. For a single-file workflow, upload the finished file and record its object path. Keep unrelated files out of the published path so it is easier to reason about what a viewer can request.
Decide whether the objects should be public or restricted. For a CloudFront-backed site, a common arrangement is to prevent viewers from fetching objects directly from S3 and let CloudFront access the bucket as the origin. This avoids maintaining a second public route that bypasses the distribution. Do not make the bucket public merely to get playback working; that can mask an origin-permissions problem while leaving your objects directly accessible.
AWS's tutorial covers creating a bucket, uploading a video and connecting it to CloudFront in its S3-to-CloudFront VOD walkthrough. Follow the current console and documentation labels, which can change. If you later add a custom domain, AWS's tutorial uses Route 53, but domain registration, hosted-zone and DNS query charges may apply. The total depends on your choices and usage, so check current AWS pricing rather than relying on a generic estimate.
Create a CloudFront distribution
Create a CloudFront distribution and select the S3 bucket as its origin. The origin is where CloudFront retrieves an object when it needs to serve a request. Set the origin path only if your published files sit below the bucket root, and make sure it matches the paths you intend to use in viewer URLs.
Restrict access to the S3 origin so the distribution, rather than an open bucket URL, is the public delivery route. AWS recommends using Origin Access Control (OAC) for this pattern. Its setup documentation notes that OAC is required when the S3 bucket uses SSE-KMS encryption; the older Origin Access Identity (OAI) does not support that case. Do not copy an older OAI-only tutorial without checking the encryption and current access-control guidance.
During distribution setup, select viewer HTTPS behaviour appropriate to your site. A reader's link should use HTTPS, and an HTTP request can be redirected to HTTPS through a viewer protocol policy. Choose the default cache behaviour and allowed request methods for the kind of objects you serve. A basic read-only VOD delivery path normally has no reason to accept write requests from public viewers.
Use a cache behaviour that matches the paths of your video package. For a simple S3 package in one folder, the default behaviour may be enough; for separate paths or access rules, add behaviours deliberately. Manifest and segment cache patterns can be format- and path-specific. Do not import rules from a MediaPackage live example into an S3 VOD distribution unless the paths and requirements actually match.
After saving the distribution, wait until AWS reports it as deployed before relying on its domain name. The CloudFront domain is the host portion of your viewer URL; it is not the S3 bucket URL. Once it is available, a basic object URL follows the shape https://<distribution-domain>/<path-to-object>. For packaged playback, use the manifest object's path as the player entry point.
Configure access and delivery behaviour
There are two different access questions: can someone bypass CloudFront and fetch from S3, and is a viewer allowed to watch through CloudFront? OAC addresses the first question by restricting origin access. It does not decide whether a particular viewer is entitled to private content.
For public video, restrict the origin and leave the viewer path available according to your intended audience. For private video, use CloudFront signed URLs or signed cookies on the relevant behaviour. AWS explains signed URL and cookie options. Your application must still decide whether a viewer is entitled to watch and issue access accordingly; CloudFront verifies the signed request rather than making your business decision.
Signed URLs can be useful when you want to authorise a specific object request, while signed cookies can suit access to multiple files under a path. AWS supports canned policies for straightforward expiry rules and custom policies for conditions such as a start time or IP range. If your URLs include query parameters, account for them in the signed URL as AWS instructs; otherwise the request can be rejected.
Be careful when enabling trusted signers or key groups on an existing behaviour. Once the behaviour requires signed requests, viewers matching that path need valid signed URLs or cookies. If your site or application is not ready to create them, you can lock out ordinary playback. Test with the intended viewer flow before applying a private-access rule to every object.
Cache settings also need to fit the content. A packaged video consists of a manifest and segment objects, and the player requests them separately. If you update a package while reusing the same object paths, cached copies can remain in circulation until the cache policy or invalidation process allows new content through. A versioned folder or filenames can make a new upload easier to distinguish from the earlier package. Set TTLs with the expected update pattern in mind rather than assuming all VOD is immutable.
Test playback through CloudFront
Test from the distribution domain, not only from the S3 object URL. For a single MP4, open the corresponding CloudFront URL in a suitable player or browser and confirm that the object is returned and plays. For adaptive streaming, supply the manifest URL to a player that supports the selected format. The player should fetch the manifest and then request the referenced media segments.
A successful manifest response is only one part of the check. If playback stalls or fails, inspect the browser or player network requests and look for missing segments, incorrect paths, denied requests or an origin permission issue. Confirm that the case and spelling of every object key match exactly. A manifest can point to relative paths, so placing it at a different directory from the expected one can change where the player looks for segments.
Test the privacy path as well as the public path. If the content should be private, try an authorised request and an unauthorised one; a copied S3 URL should not become a back door. If signed URLs or cookies are required, test expiry and the actual application flow that issues access. These checks establish how your configuration behaves; they do not amount to a guarantee that every device or network will behave identically.
For a site aimed at viewers in India, test on the devices and connections your audience actually uses, including a mobile connection if that is a common viewing route. The point is not to infer a universal performance result from one test, but to find mismatched formats, paths or access rules before sharing the link widely. For YouTube live workflows, the concern is instead sustaining an outbound broadcast; this article on testing a YouTube stream key from an Ubuntu VPS in India covers a different publishing path.
If playback is denied, check the response and request path systematically. A 403 may point to an origin policy, a required signature, or a malformed signed request; it does not identify the cause by itself. A missing-object response usually sends you back to the bucket key, manifest reference or origin path. Make one change at a time, then retest the same CloudFront URL so you know which adjustment mattered.
Live streaming is a different architecture
A live stream is not simply a VOD file that happens to be watched at the same time by many people. A live workflow begins with a live input and an encoder that compresses and formats the output. AWS identifies MediaLive as an encoder example, with MediaStore or MediaPackage used as origin or packaging services before CloudFront delivers the stream. That is a different chain from uploading a finished VOD package to S3.
The live origin and packaging choice affects the paths and requests CloudFront must handle. For MediaPackage, AWS documents behaviours matching manifest and segment extensions, and its examples include HTTPS redirection and forwarding only query strings needed by endpoint features. Those details are specific to that MediaPackage workflow. For example, AWS names _HLS_msn and _HLS_part for LL-HLS manifest requests; do not add those parameters to a plain S3 VOD behaviour without a matching need.
Likewise, recommendations for authorising CloudFront to request content from a MediaPackage endpoint are not interchangeable with OAC for an S3 bucket. Keep origin protection tied to the origin service and its documentation. Viewer authorisation is still a separate decision from whether CloudFront itself may retrieve content from that origin.
If your actual goal is to keep a recorded programme looping as a YouTube live broadcast, CloudFront VOD delivery is not the same as sending an ongoing YouTube live signal. You would need a live publishing workflow, an encoder or managed streaming service, and YouTube's own ingest configuration. A 24/7 YouTube radio stream setup guide describes that kind of channel workflow; it should not be treated as instructions for an S3-backed CloudFront VOD distribution.
| Decision | S3-backed VOD | Live delivery |
|---|---|---|
| Input | A finished video or packaged output uploaded to S3 | A live input encoded as it is produced |
| Preparation | Encode and package before viewers request playback if using adaptive streaming | Encode live output and use an appropriate origin or packaging service |
| CloudFront origin | Commonly an S3 bucket | For example, MediaStore or MediaPackage in an AWS workflow |
| Viewer entry point | File URL or package manifest URL | Live manifest endpoint and its referenced segments |
| Main checks | Object paths, origin restriction, manifest and segment playback | Live encoder output, endpoint paths, cache behaviours and request parameters |
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Do I need to encode the video before using CloudFront?
For adaptive streaming, yes: use an encoder to create the manifest and segments before CloudFront distributes them. CloudFront does not make renditions from your source file. You can deliver a finished MP4 as a file, but that is not the same as adaptive bitrate playback.
Can I serve an MP4 directly through CloudFront?
Yes. The S3-backed VOD workflow can deliver a video file through CloudFront, and a basic viewer URL points to the object path. If you need the player to switch among quality levels, prepare a packaged stream with the necessary renditions, manifest and segments instead.
How do I stop viewers bypassing CloudFront to reach S3?
Restrict direct bucket access and configure the applicable CloudFront origin access mechanism. AWS describes OAC for S3 origins and notes that it is needed for an SSE-KMS-encrypted S3 origin, where OAI does not support the encryption arrangement. Check current AWS instructions when configuring bucket and key policies.
How do I make a video private?
Restrict the S3 origin separately from viewer access, then use signed URLs or cookies for the CloudFront behaviour that serves private content. Your application decides who is entitled to watch and issues the signed access. Test the authorised and unauthorised paths before requiring signatures for an existing audience.