CloudFront can deliver video to viewers, but it does not turn a raw video file or camera feed into a stream. First choose a VOD or live workflow, then encode and package the video, select an origin, and configure CloudFront to serve the resulting manifests and media segments.
The right settings depend on the output format, origin, latency needs and whether playback is public or restricted. This guide follows those decisions in order; use the current AWS documentation for the exact console labels and service behaviour before implementing a production workflow.
Choose a VOD or live workflow
VOD and live streaming may both use CloudFront, but the content reaches it differently. With video on demand, you prepare a complete asset in advance. With live video, an encoder processes a continuing input and publishes a changing set of outputs while the event or channel runs.
For VOD, an encoder and packager such as AWS Elemental MediaConvert can create the playback files. Those files commonly include a manifest and media segments. You can store the output in Amazon S3 or another suitable origin, then configure CloudFront to retrieve and distribute those objects as viewers request them. AWS describes this general pattern in its CloudFront overview for VOD and live streaming.
For live, a typical AWS workflow uses MediaLive to encode the real-time input. The output can be delivered through a service such as MediaStore, or packaged by MediaPackage when you need delivery formats such as HLS, DASH or CMAF. CloudFront sits downstream and delivers the prepared output. It is not the component that accepts an unprocessed feed and creates those formats.
Before choosing services, write down what the player must receive. Note whether the content is VOD or live, the packaging format, expected manifest and segment paths, whether low-latency HLS is required, and whether playback is public. If you need several delivery formats, the packaging workflow will differ from a single-format channel. If this is a YouTube broadcast rather than a website player receiving HLS or DASH, CloudFront may not be the relevant delivery path: compare the production model with a 24/7 YouTube stream from a VPS.
| Decision | VOD example | Live example | What it changes |
|---|---|---|---|
| Preparation | Encode and package a finished asset | Encode and package a real-time feed | Which upstream services produce the media |
| Origin | S3 bucket or another HTTP origin | MediaPackage or MediaStore endpoint | The origin hostname, path and authorisation |
| Manifest behaviour | Usually stable object names | Manifest contents and availability change | Cache policy and query-string handling |
| Format requirement | One or more packaged outputs | One or more live output formats | Manifest and segment path patterns |
Do not pick a service solely because it appears in an example architecture. Geography, viewer demand, bitrate, retention, latency and access requirements all affect the design and cost. AWS documentation explains the available patterns, but it cannot determine the best combination for a workload whose details are unknown.
Understand CloudFront’s role
Think of CloudFront as the distribution layer between an origin and viewers. The origin holds or generates packaged media. A player requests a manifest, reads the segment references in it, and then requests those segments. CloudFront can serve objects from cache or fetch them from the configured origin when necessary.
The manifest matters because it tells the player what to request and in what sequence. Common formats AWS lists include MPEG-DASH, Apple HLS, Microsoft Smooth Streaming and CMAF. They are not interchangeable file extensions: the distribution’s behaviours and the player must correspond to the actual packaging output. A .m3u8 HLS manifest and its segments, for example, need routes that lead to the correct origin objects.
This boundary helps diagnose setup problems. If the encoder has not created a playable package, adding CloudFront cannot fix that. If the manifest works but segments return errors, investigate the segment path, origin permissions, behaviour selection and cache settings rather than assuming the distribution encodes the missing media.
CloudFront is useful when you need an HTTP delivery layer for prepared video, including a website or player that retrieves packaged files. It does not replace a production tool that reads a camera or playlist, nor does it itself publish a YouTube live broadcast. For a continuing playlist, the distinction between generating a feed and distributing packaged web video is particularly important; see this guide to rotating relaxation videos in a continuous YouTube live stream.
Prepare an origin and packaged video
Start by producing and testing the media package independently of CloudFront. For VOD, identify the encoder or packager, select the output format, and create the manifest and all referenced segments. Store the outputs in a location the origin can serve. AWS’s S3 and CloudFront VOD tutorial is a primary reference for a stored-content path using S3.
For live, confirm that the live encoding and packaging stages are publishing the expected output before configuring the CDN. AWS documents patterns using MediaLive and MediaPackage or MediaStore; the precise endpoint and paths depend on the selected output configuration. MediaPackage is worth considering when one live source needs multiple delivery formats, but that adds an additional packaging and configuration step.
Record the origin hostname and any path prefix exactly. Also list a sample manifest URL and the relative paths of the segments it references. If a manifest contains a query string, note its parameters. These details become the basis for origin settings, path-pattern behaviours, cache policies and later tests.
For S3, decide whether viewers should reach the bucket directly or only through CloudFront. Review origin access control and bucket permissions so the intended delivery path is also the authorised path. Avoid making an origin broadly public merely to get a first test to work; test the access configuration deliberately.
For a live origin, check the endpoint’s own authorisation requirements. CloudFront-to-origin authorization is separate from viewer authorization: securing requests from the CDN to an origin does not automatically restrict who can watch, and signed viewer links do not configure the origin. AWS discusses ways to use CloudFront, including signed URLs and cookies for controlling viewer access.
Create a CloudFront distribution
Create a distribution with the origin type and address that match the prepared output. For S3, select the bucket or its supported origin configuration and review origin access control. For a MediaPackage or MediaStore workflow, use the endpoint AWS identifies for that workflow and configure any required origin authorization. Do not substitute a console example’s hostname or path for your own endpoint.
Set an origin path only if your package is actually below a shared path prefix. Then compare the URL a player will request with the origin URL CloudFront should request. A common source of failures is adding a prefix in the distribution and leaving the same prefix in the player URL, resulting in a doubled path. Another is pointing the distribution at a parent directory when the endpoint expects a specific path.
The default cache behaviour handles requests that do not match a more specific behaviour. Video distributions often need explicit behaviours for manifests and segments, so plan those routes before relying on the default. AWS’s MediaPackage guidance describes a wildcard route pattern and notes that unmatched requests may need a separate route; its examples use a dummy origin so unmatched requests are not sent to the actual MediaPackage endpoint. Follow the current AWS procedure if you adopt that design, and verify every behaviour’s origin association.
CloudFront distributions take time to deploy. Wait for the distribution to finish deploying before treating a test failure as a playback issue. Keep a record of the distribution domain, origin mapping, path patterns and policy choices. Those notes make it easier to identify whether a later failure follows a changed behaviour, origin or packaging output.
Configure manifest and segment behaviours
Create behaviours that match the paths your package actually uses. A manifest and a segment can have different extensions and different cache requirements. In AWS’s MediaPackage examples, HLS commonly separates *.m3u8 manifests from *.ts segments; CMAF uses *.m3u8 and *.mp4; DASH uses *.mpd and *.mp4. These patterns are examples, not universal rules: match them to the endpoint and output you have configured.
Some VOD paths include a packaging-configuration identifier. Do not copy a pattern from a live example without checking your VOD URL structure. Likewise, a .mp4 extension alone does not prove that a request is a segment; it may refer to a different object in your application. Test how CloudFront resolves each real path and confirm that the selected behaviour points to the intended origin.
For each behaviour, review allowed HTTP methods, viewer protocol policy, cache policy, origin request policy and any response-header policy your player requires. Keep the configuration narrow enough to make the intended request handling clear. If you use multiple output formats or origins, separate behaviours only where their path patterns make the routing unambiguous.
A useful setup worksheet has one row per request type: manifest, segment, subtitle or key if applicable. For each, write the example viewer URL, the expected origin path, query parameters that matter, and the behaviour that should match. This can expose a mismatch before you start testing through a player. It also helps when a manifest plays but a subset of its segment requests fail.
Set HTTPS, caching and access controls
Use HTTPS for viewer requests, especially when the player page itself is served securely. AWS’s MediaPackage setup procedure uses a viewer policy that redirects HTTP requests to HTTPS. If you use a custom domain, configure its DNS and certificate through the relevant AWS services, following the current S3, CloudFront and Route 53 tutorial. Confirm that the certificate covers the hostname viewers will use.
Caching requires different care for stored VOD and changing live manifests. VOD segments are often stable objects once published, while a live manifest may change as new segments become available. If a live manifest remains cached too long, a player can receive an older view of the programme. AWS’s MediaPackage guidance describes a minimum TTL of five seconds or less to help prevent stale live content; treat that as guidance for the documented workflow, not a universal value for every origin or player.
Cache keys must include the query strings that change the response. For live MediaPackage manifests, AWS documents forwarding m; for LL-HLS blocking playlist requests, _HLS_msn and _HLS_part are also relevant. If those parameters are omitted from the cache key or request handling, distinct playlist requests can be treated alike. VOD manifest filtering may require forwarding aws.manifestfilter. Check the behavior against the exact packaging feature you use rather than forwarding every possible parameter by default.
Viewer and origin access controls solve different problems. CloudFront signed URLs or signed cookies can restrict viewer access to private content. For S3 origins, configure origin access so a viewer cannot bypass the distribution and fetch the object directly when that is not intended. For MediaPackage, AWS recommends header-based CDN authorization between the origin service and CloudFront. These controls need to be tested as a complete chain; an authorised viewer request can still fail if the origin rejects CloudFront, and a working origin connection does not establish that viewers are restricted.
If access is public, document that choice and avoid adding signing complexity without a requirement. If content is private, decide who issues signed URLs or cookies, how long access should last, and how your player obtains them. Check current AWS documentation for supported policy options and service-specific requirements, because control names and implementation details can change.
Test playback and troubleshoot paths
Begin with one manifest URL through the CloudFront domain. Confirm that it returns the expected manifest, then inspect the paths it references and request representative segments through the same domain. A working origin URL alone does not prove CloudFront is routing correctly; similarly, a successful manifest request does not prove that all segment patterns match.
When a request fails, examine it in sequence: the player’s requested URL, the behaviour that should match, the origin path CloudFront constructs, and the origin’s response. Check for a missing or duplicated path prefix, an extension not covered by a behaviour, query parameters missing from the cache policy, or an origin permission that rejects the request. For live playback, also confirm that the encoder and packager are publishing current output.
A manifest that loads but points to unreachable segments often indicates that relative paths resolve differently than expected or that the segment behaviour is missing. A live player showing an old playlist can indicate inappropriate manifest caching or omitted query-string variation. A request that works over HTTP but fails over HTTPS calls for checking the viewer protocol policy and certificate hostname. Avoid changing several controls at once: make one targeted change and repeat the same request so you can identify what resolved the issue.
Test from the player and network locations that matter to your audience, but do not infer a general performance guarantee from a single successful playback. The result depends on the package, origin, viewer network and workload. If your actual goal is a 24/7 YouTube broadcast, CloudFront’s HTTP video delivery architecture is not a substitute for keeping a YouTube encoder feed running. The practical burden of maintaining a source machine and recovering after interruptions is discussed in this guide to resuming a cloud YouTube stream after an outage. StreamNeo removes the need to keep your own computer on for that specific YouTube-file workflow: you upload the video and provide your YouTube stream key, rather than configuring a CloudFront origin and packaged-media distribution.
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
Does CloudFront convert a video file into HLS or DASH?
No. CloudFront distributes media that has already been encoded and packaged. Use an encoder or packager to produce manifests and segments, then configure CloudFront to serve those objects.
Can I use the same CloudFront distribution for VOD and live?
The architecture can support different request paths and origins, but whether one distribution is suitable depends on the routing and policy requirements. Compare the behaviours, cache rules and access controls for each workflow, and follow current AWS documentation for the services involved.
Why does my manifest load while playback still fails?
The manifest may reference segments whose paths do not match a CloudFront behaviour, whose query parameters are handled incorrectly, or whose origin rejects the request. Test a referenced segment URL through CloudFront and trace its selected behaviour and origin response.
Is CloudFront a way to send a 24/7 stream to YouTube?
CloudFront is for delivering packaged HTTP video from an origin to a player; it is not a YouTube broadcast encoder. A YouTube live workflow needs a source that sends the live feed to YouTube, so choose tools designed for that output.