CloudFront distributes video that has already been packaged for HTTP delivery; it does not turn a raw source video into adaptive renditions. To configure it, prepare the media and origin first, then map manifest and segment requests to behaviours, choose caching and access controls for the workflow, and test the viewer URLs.
The right settings depend on whether you are serving stored VOD or a live feed, which packaging format you use, and how quickly content changes. The steps below give you a reusable path for either case, with AWS’s MediaPackage-specific live guidance kept separate from general CloudFront choices.
Choose the workflow: VOD or live
For video on demand, a viewer requests stored files: a manifest describes the presentation and the player then requests its media segments. The files may sit in an S3 bucket or another HTTP origin. CloudFront fetches objects from that origin when needed and can serve them from its edge cache when available; this describes the delivery arrangement, not a latency or playback guarantee.
For live delivery, an encoder sends an ongoing feed to a live packaging origin. AWS documents workflows involving MediaPackage or MediaStore as origins, with CloudFront in front to distribute manifests and segments. The manifest changes as the programme advances, so freshness and request parameters matter differently from a finished VOD package.
Decide which problem you are solving before creating a distribution. If you have a folder of finished files and want viewers to retrieve them, you are planning VOD. If a live encoder continuously publishes a changing playlist and segments, you are planning live. A channel that loops a fixed programme continuously is not automatically the same as a live-origin workflow: its delivery may instead be a live broadcast produced by a platform or encoder, or a hosted file presentation, depending on the service and player.
CloudFront is a distribution layer, not a media preparation step. The Amazon CloudFront Developer Guide says, “You must use an encoder to package video content before CloudFront can distribute the content.” AWS lists formats including HLS, MPEG-DASH, Smooth Streaming and CMAF. If you are deciding between a local continuous encoder and a hosted workflow for a YouTube channel, first separate that production question from the web delivery setup; the comparison of always-on YouTube operating models covers a different distribution target and should not be mistaken for CloudFront configuration.
Write down the target player, format, origin, access model and update cadence. A short note such as “HLS VOD, S3, private files, manifests stable after upload” is more useful than starting from a list of console defaults. For live, note whether the endpoint uses ordinary HLS, LL-HLS or DASH, because the exact paths and query strings are not interchangeable.
Prepare packaged media and an origin
Choose an encoder or packager that produces the format your target players accept. For VOD, AWS gives MediaConvert as one packaging example; the resulting manifests and segments can be stored on S3 or another server. For live, the encoder and live packaging service work together to create the changing output. CloudFront does not create the bitrate ladder, manifests or segment files for you.
Before configuring the distribution, inspect the output layout. Identify the manifest extension and location, segment extensions, any child playlists, and whether the player requests encryption keys or subtitles from additional paths. For example, an HLS presentation may have a top-level playlist, child playlists and transport stream segments; the actual names and directory structure are determined by your packager. Do not assume every .m3u8 or .ts file belongs to the same package just because the extensions look familiar.
For S3 VOD, place the full package in a predictable prefix and decide whether the bucket should be private. A private bucket with CloudFront Origin Access Control (OAC) lets the distribution retrieve protected objects without making the bucket publicly readable. AWS’s S3 and CloudFront video tutorial describes a route using a bucket and CloudFront; check the current AWS instructions for the console steps and bucket policy details, since labels and options can change.
An HTTP origin is another choice for stored files, and AWS live workflows use endpoint origins. Confirm that the origin serves the packaged paths and expected content types. If the same package plays directly at the origin but fails through the distribution, compare the requested object path, query string and response status rather than changing several cache settings at once.
Keep the package layout stable after publishing if you want cache behaviour to remain predictable. Replacing a segment or manifest at the same URL changes what a request should return, but a cached copy can remain until its freshness rules permit a new fetch. Versioned filenames or a deliberate invalidation strategy can help when you replace VOD assets; for live, use the origin workflow’s freshness needs rather than treating a playlist like a static download.
Create the distribution around the origin
In CloudFront, create a distribution and define an origin that points at the resource holding the package. For S3, select the bucket origin and configure OAC if the bucket is private. For a live endpoint or other HTTP server, use the origin host and any required origin protocol settings supplied by that service. AWS defines an origin as the resource from which CloudFront obtains objects; it is not necessarily the same thing as the viewer-facing domain.
A distribution can have more than one origin, but do not add complexity unless your paths actually need separate sources. A single VOD bucket is often simplest. If you later add a second package location, route only the relevant path patterns to it and verify that relative references inside manifests still resolve correctly. A manifest that points to a path outside the expected behaviour can fail even when the top-level manifest is reachable.
Set the viewer protocol policy deliberately. For public playback, HTTPS is ordinarily the viewer-facing choice; AWS’s documented MediaPackage setup also redirects viewer HTTP requests to HTTPS. If you use a custom domain, associate it with the distribution and use a certificate provisioned for that domain in the AWS Certificate Manager region required by CloudFront. Confirm the current AWS guidance before changing DNS or certificate settings.
At this stage, leave the distribution’s default path behaviour as a fallback, not as proof the video paths are right. The default behaviour may fetch any path from the origin, but it does not automatically provide the cache policy, query forwarding or viewer restrictions required by every manifest and segment. Once the distribution is deployed, use its CloudFront hostname for a first object request, then add the custom domain after you know the origin path works.
Map manifests and segments to behaviours
A cache behaviour matches a path pattern and applies settings to requests that match it. Map the manifest and segment paths to the intended origin and policies. You may use one behaviour for a straightforward VOD package, or separate behaviours where manifests and segments need different freshness, query forwarding or access settings. The pattern must match the real object paths, not a guessed extension.
For AWS’s documented MediaPackage live workflow, manifest and segment paths are commonly split into behaviours. Its examples use .m3u8 manifests with .ts segments for one HLS endpoint, and .mpd manifests with .mp4 segments for DASH. Treat those as examples for that workflow, not universal patterns: your endpoint and packaging format determine the actual URL shapes. AWS’s live streaming guidance gives the relevant path and behaviour details.
LL-HLS has additional request-shape requirements. In the documented MediaPackage case, the manifest behaviour forwards _HLS_msn and _HLS_part so blocking playlist requests work. The same guide specifies the m query string for manifest modification time. These are workflow-specific requirements; do not add them to an unrelated origin by habit. Check what the origin expects and forward only the values that are part of its request protocol.
Ordering matters when path patterns overlap. A broad segment pattern could catch files you intended to send through a more specific behaviour. Review the final behaviour order and test one manifest and one segment URL from each branch. If a player asks for a relative segment path, resolve it against the manifest URL and make sure the resulting CloudFront path lands on the expected origin.
A useful way to reason about routing is to write down representative URLs before touching the console: top-level manifest, child manifest, a segment, and any key or subtitle resource. Mark the path pattern that should match each URL. This simple route map is also useful when another person has to diagnose a midnight failure. For a local playlist workflow, the practical failure may be earlier in the chain: switching between pre-recorded OBS playlists is about producing the continuing broadcast, while CloudFront behaviours only route HTTP object requests.
Set cache rules for the update pattern
A cache policy determines selected values in the cache key, which identifies an object for CloudFront caching. Origin request settings determine what additional values CloudFront forwards to the origin. Query strings, headers and cookies can therefore affect both whether requests share a cached object and what the origin receives. AWS explains this distinction in its cache key documentation.
Start with the origin’s actual needs. If every query string is forwarded and included in the cache key, requests that could otherwise share an object may be treated separately, and the origin sees more variation. If a player or live origin relies on a particular parameter, omitting it can also break freshness or playback. Avoid forwarding all headers, cookies or query strings “just in case”; list the parameters that the package workflow requires, then configure them explicitly.
For VOD whose manifest and segments do not change after publication, longer-lived caching may be suitable, provided you have a way to update changed objects. A common operational choice is versioned object names for new packages, which avoids serving an old object at a reused URL. If you overwrite a stable path, plan for how the old cached response will age out or be invalidated. Do not assume a browser refresh clears CloudFront’s cache.
For live, the manifest changes more frequently than completed segments. Give the manifest behaviour a freshness policy suited to the publishing cadence and keep segment caching aligned with whether segments are immutable after creation. In AWS’s MediaPackage live instructions, use a minimum TTL of five seconds or less to help prevent stale content. That setting belongs to the documented MediaPackage workflow and is not a universal default for all live origins.
When tuning, change one dimension at a time and record the result: cache policy, origin request policy, or TTL. The useful question is not “is caching on?” but “which requests can safely share an object, for how long, and what must the origin see?” AWS’s cache behaviour reference is the place to verify the current console terminology and policy controls.
Configure HTTPS and restrict access where needed
Public VOD is simplest when the content itself is intended for anyone with the URL. If the S3 bucket must remain private, configure OAC and the corresponding bucket permissions so viewers fetch through CloudFront rather than bypassing it to read the bucket directly. Test both routes: a successful CloudFront response is not evidence that direct bucket access has been blocked.
For restricted viewer access, choose the mechanism based on the number and shape of requests. Signed URLs can suit an individual file or a client that cannot use cookies. Signed cookies are often more practical for a presentation made up of many restricted files, such as an HLS playlist and its segment set, because the viewer need not carry a separately signed URL for each object. AWS’s guide to choosing between signed URLs and cookies describes the trade-off.
You must configure the behaviour to require signed access and establish trusted signers or keys before issuing requests. A signed URL for the master manifest alone does not automatically make all child playlists and segments accessible if those requests are separately protected and do not carry valid authorisation. Test the whole playback path with the same client conditions your audience will use, including cookie support and expiry handling.
Live origins can also need protection from direct access. AWS recommends header-based MediaPackage CDN authorisation for the documented connection between MediaPackage and CloudFront. Confirm the current MediaPackage-side setup in its own guide before deployment, and distinguish origin protection from viewer authentication: protecting the origin does not decide who among your viewers may watch.
For a stream that is meant to be publicly embedded, do not add signed access merely because the option exists. Extra controls create failure points for players and can complicate testing. Conversely, a private event or paid presentation needs an explicit access design rather than a secret URL alone. Check the current official AWS documentation and your own content requirements before publishing.
Test the intended viewer URLs
Test through the URL your player will actually use: the CloudFront hostname or configured custom domain, not only the origin address. Fetch the top-level manifest and inspect its response, then test a child manifest and a segment. A manifest can return successfully while its relative references point to a wrong path, so test the chain rather than stopping at the first response.
Check that HTTPS works, that the expected behaviour handles each request, and that query parameters needed by the origin survive. For a private bucket, verify that an unauthorised direct S3 request fails while the CloudFront route behaves as intended. For signed playback, test with an authorised viewer and an unauthorised one, including what happens after a credential expires. These checks test configuration; they do not guarantee playback on every device, network or player.
For live, repeat the test while the presentation is changing. A stale manifest, missing query parameter or incorrect segment pattern may not appear when you test a static sample. If you use LL-HLS, test with the player and request pattern that relies on _HLS_msn and _HLS_part; a plain manifest fetch is not enough to validate blocking playlist behaviour.
Keep a small deployment record: origin name, distribution domain, path patterns, cache policy, forwarded query strings, access method and one tested URL per object type. This makes later changes safer, particularly if you replace an encoder, move the package prefix or add a custom domain. If your wider aim is a persistent YouTube channel rather than serving HLS or DASH objects to your own player, read about preparing a continuous devotional YouTube stream; the publishing and rights questions are different from CloudFront delivery.
| Decision | VOD starting point | Live starting point |
|---|---|---|
| Media preparation | Package a finished asset into the target format before upload | Encode and package a continuing feed at the live workflow stage |
| Origin | S3 or another HTTP server holding the package | A live endpoint such as MediaPackage or MediaStore in documented AWS workflows |
| Paths | Inspect actual manifest and segment names | Use endpoint-specific manifest and segment patterns |
| Freshness | Keep stable objects cacheable; plan for changed versions | Keep changing manifests fresh; treat completed segments according to origin behaviour |
| Access | Public, OAC-protected S3, or signed viewer requests | Protect the origin as needed and separately decide viewer access |
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 packaged HTTP media; a separate encoder or packager must produce the manifests and segments. AWS names formats such as HLS and DASH and states that video must be packaged before CloudFront can distribute it.
How do I stream video from S3 through CloudFront?
Package the media, store the resulting objects in S3, create a distribution with that bucket as the origin, and configure behaviours for the object paths. If the bucket is private, use OAC and confirm the bucket policy prevents direct public access; then test the manifest and segment URLs through CloudFront.
Should manifests and segments use separate cache behaviours?
Use separate behaviours when their paths need different routing, cache freshness, query forwarding or access rules. A simple package may not need separate settings, but live workflows often do; derive patterns from the actual endpoint rather than copying extensions from an example.
Is the MediaPackage live configuration right for every HLS origin?
No. The short minimum TTL and the m, _HLS_msn and _HLS_part query-string guidance apply to the documented MediaPackage workflow. Check the current guide for your origin and player before adopting those settings.