Amazon CloudFront delivers prepared live-video files from an origin to viewers. It does not encode a live feed or package it into manifests and segments; those jobs belong upstream, so your first decision is which encoding and packaging path fits your stream and players.
A practical workflow is to prepare the stream with an encoder, make it available from an origin or packager, and then configure CloudFront to deliver the resulting format. The exact behaviours and cache settings depend on whether you are serving HLS, DASH, CMAF, or another supported output, and on features such as time-shifted playback.
What CloudFront does in a live-video workflow
Think of the workflow as three distinct jobs. An encoder turns a live source into video renditions and packages them into media segments and manifests. An origin or packager stores or prepares those outputs and responds to requests. CloudFront sits in front of that origin and delivers the requested files to viewers through its distribution URL.
A manifest tells the player which segments are available and in what order to request them. A player first obtains a manifest and then requests the media segments it describes. If the encoder or packager has not produced those files, CloudFront has nothing live to deliver. AWS makes this distinction in its CloudFront live streaming guide and explains the encoder's role in its video-on-demand guidance.
For an AWS-based workflow, MediaLive can encode a real-time feed. MediaPackage can package or transform outputs for the delivery formats and features your audience needs. MediaStore can serve as an origin when the upstream outputs are already in the required formats. CloudFront then delivers the files from the selected origin. These are choices, not steps you must all add to every setup.
This distinction matters when troubleshooting. If the manifest is missing or its segment references are wrong, check the encoder, packager, and origin path before adjusting CloudFront. If the files are available at the origin but viewers receive errors or stale segments through the distribution, inspect the distribution's origin, behaviours, cache settings, and request forwarding.
If you are running a YouTube channel rather than building your own viewer-facing player, CloudFront is not a substitute for sending a broadcast to YouTube. For that workflow, the useful concerns are a stable encoder and recovery when a broadcast disconnects; see this guide to recovering a 24/7 Indian music stream after YouTube disconnects. CloudFront is relevant when you are delivering prepared stream files from your own origin to viewers or an application.
Choose an encoder and prepare the stream
Start by documenting the source and the playback requirements. Identify what produces the live feed, which devices or player software need to play it, which output formats those players accept, and whether you need multiple quality levels. A phone, browser player, and television app may not all have identical requirements. Your encoder and packaging path must produce outputs the intended players can use.
In the AWS workflow described in its documentation, MediaLive performs real-time encoding. It can create adaptive-bitrate outputs, allowing a compatible player to select a rendition suited to the viewer's connection. The encoder also creates segments and manifests in a format such as HLS or DASH, depending on your configuration. CloudFront does not create those renditions or decide their playback order; it delivers the generated files.
Before building the distribution, verify what the encoder actually emits. Record the manifest filename and extension, segment extension, directory or endpoint structure, and any query parameters used in requests. Also establish whether the output is HLS, DASH, CMAF, or another format. Do not infer format solely from the file extension: confirm it against the encoder or packager configuration and the AWS guide for the specific path.
For a continuous channel, test the upstream workflow before adding CDN delivery. Confirm that the origin can return a current manifest and the segments named by it, and that new segments continue to appear as the live feed advances. A CloudFront distribution can make an origin's output reachable to viewers, but it cannot repair gaps created upstream. For a local-news loop or devotional channel, for example, check that the source switches or repeats as intended and that the manifest continues to describe playable media after the change.
If the feed originates in OBS or another local encoder, treat its output and ingest requirements as a separate part of the system. Do not assume that an encoder configured for a YouTube ingest endpoint automatically creates an AWS origin structure suitable for CloudFront. The production and destination have to be designed for the same workflow. For an OBS-specific presentation question, this guide to adding a waveform visualiser to an always-on stream covers an on-screen element, not an AWS delivery configuration.
Select a packaging or origin path
Choose the upstream path according to what the players need, not simply by adding every AWS media service. MediaPackage is useful when you need packaging into multiple delivery formats or its packaging-related features, such as DRM or manifest functions. If MediaLive already creates outputs that match the formats your viewers require, MediaStore is a documented alternative origin. Confirm the current service capabilities and setup steps in the AWS live streaming instructions, because endpoint details and feature support are specific to the chosen workflow.
| Workflow need | Path to consider | What to verify before CloudFront |
|---|---|---|
| Multiple delivery formats or packaging features | MediaLive with MediaPackage | Required formats, endpoint paths, and enabled features |
| Outputs already match player requirements | MediaLive with MediaStore as origin | Manifest and segment files are present in the expected structure |
| Simple test of a prepared stream | Existing compatible origin | The origin serves valid manifests and referenced segments |
The table is a selection aid, not a guarantee that every combination supports every feature. Check the current AWS documentation for your encoder, packaging configuration, and player. If you need time-shifted playback, manifest filtering, or low-latency playlist requests, make sure the selected packaging path and player support those behaviours before you add their related request parameters.
The origin endpoint must exist and work before CloudFront can be configured against it. AWS's live MediaPackage instructions assume that the channel and endpoint have already been created. Note the exact endpoint host and path, whether the origin expects a particular request header, and which formats that endpoint serves. Avoid copying an example endpoint path into your own distribution without checking your account's endpoint details.
Plan origin protection as part of this choice. AWS recommends header-based CDN authorisation between MediaPackage endpoints and CloudFront; its reference design uses a CDN Identifier custom HTTP header, with the identifier stored in Secrets Manager. Follow the current AWS instructions for the exact configuration. The goal is to avoid leaving the origin broadly accessible when requests should come through your distribution. Do not treat a custom header as a replacement for checking the origin's own access controls.
Create a CloudFront distribution
Once the origin responds with the expected stream files, create a CloudFront distribution and set that endpoint as its origin. Configure the origin domain and any required origin path from the endpoint details you recorded. If the origin requires a custom header for authorisation, configure it as described in the current AWS guide. Keep a record of the origin path and the public CloudFront hostname because they help distinguish an origin error from a delivery error later.
A distribution is not a universal live-stream preset. Its cache behaviours match request paths and determine how CloudFront handles those requests. The manifest and segment paths must be covered by the relevant behaviours. AWS's MediaPackage examples commonly use one behaviour for manifests and another for segments, but the exact patterns depend on the output format and endpoint. Use the examples as a starting point only after comparing them with the files your origin actually serves.
For a first test, keep the configuration narrow: use the required origin, the behaviours needed for the chosen format, and only the query-string settings required by enabled playback features. This makes it easier to tell whether a failure comes from the source, origin, path pattern, or cache policy. Add optional behaviours only when a concrete player request or feature requires them.
Do not confuse an origin that is reachable from your own network with a working distribution. CloudFront has to be able to request the origin, the behaviour has to match the requested object path, and the viewer must use the distribution URL rather than bypassing it. AWS documents the standard CloudFront URL format for applications requesting media files in its live streaming guide. Give the player that distribution URL, using the correct manifest path for your format.
Configure behaviours for manifests and segments
Create path patterns from the actual manifest and segment names or paths. In AWS's MediaPackage examples, HLS and CMAF use .m3u8 manifests, with .ts segments for HLS and .mp4 segments for CMAF. DASH uses .mpd manifests and .mp4 segments. Smooth Streaming uses a single manifest behaviour in the documented examples. These patterns are format-specific illustrations, not a claim that every origin uses identical paths. Check the endpoint and current AWS instructions before setting them.
Manifest requests and segment requests can need different cache treatment. Live manifests change as the stream advances, so serving a stale manifest can leave a player requesting segments that are no longer current. AWS's documented live MediaPackage policy uses a minimum TTL of five seconds or less to help prevent stale content. Treat that as a documented policy detail for that workflow, not a universal setting for all origins. Review the current cache policy guidance and verify the result with your stream's update cadence.
Query strings are part of the behaviour design. AWS's MediaPackage guidance includes the m modification-time query string, and describes additional parameters for particular features: start and end for time-shifted viewing, aws.manifestfilter for manifest filtering, and _HLS_msn plus _HLS_part for LL-HLS blocking playlist requests. Forward only parameters needed by features you have enabled. Blindly forwarding every query string can make requests behave differently from what you intended; omitting a required one can prevent a feature from working.
Test a manifest request with the same path and query-string shape that your player uses. Check that the response is a manifest rather than an error page, and that its segment references resolve through the expected CloudFront paths. Then test a segment request. If the manifest works but a segment does not, inspect the segment path pattern and origin path before changing the manifest cache settings.
Test playback and delivery
Test from the viewer's perspective, not only from the AWS console. Give a compatible player the CloudFront URL for the manifest, start playback, and confirm that it can continue as the live output advances. Use the same format and playback options your eventual viewers will use. A browser test that fetches a manifest is useful, but it does not establish that every target device can decode the content or follow the playlist correctly.
Test the distinct requests in order: manifest, first referenced segment, and later segments as the stream updates. Check HTTP responses and the requested paths. If the player reports a network error, compare the CloudFront request with a direct origin request where your access permissions allow that test. A failure at both points suggests an upstream or origin problem; a working origin response and failing CloudFront response point you towards distribution configuration, authorisation, caching, or path matching.
For HLS, inspect the .m3u8 manifest and confirm the referenced .ts or CMAF .mp4 segment paths match the behaviours you configured. For DASH, check the .mpd manifest and referenced .mp4 paths. These examples follow AWS's documented MediaPackage patterns; your origin's precise paths remain authoritative. If a player can begin but freezes later, determine whether the manifest stopped changing, the next segment is unavailable, or a cached response is older than the current live window.
Repeat the test after changing a behaviour or cache policy. A successful playback session before a change does not verify the new configuration. Test from outside the network used to configure the origin if possible, and include the devices or player implementations that matter to your audience. Keep a short record of the manifest URL, response, segment path, and player result so that a later failure can be compared with a known-good test.
Monitor, protect, and refine the setup
After playback works, observe both the delivery path and the upstream workflow. A viewer complaint that a stream is frozen can originate in the source feed, encoder, packager, origin, distribution, or player. Check whether the live manifest is advancing and whether its referenced segments are available before treating every interruption as a CDN problem. Monitoring only distribution requests will not tell you whether the encoder stopped producing new content.
Review cache behaviour against real player requests. If manifests appear stale, inspect their TTL and query-string treatment first. If segments are missing, confirm the origin has them and the request matches the appropriate behaviour. Change one relevant setting at a time and retest, rather than widening all path patterns or forwarding all query strings as a general remedy.
Protect the origin and manage changes carefully. For MediaPackage, use the current AWS procedure for CDN authorisation and the custom header. Restrict access to credentials and avoid placing sensitive identifiers in public documentation or player URLs. Keep distribution settings, endpoint paths, and required query parameters written down so another operator can distinguish an intentional setting from a workaround.
Consider resilience in proportion to the consequences of an interruption. AWS documents media quality-aware resiliency for MediaPackage v2 origins, using a MediaLive-generated Media Quality Confidence Score to select between origins. Its setup has specific prerequisites, including a secondary channel in another Region for a cross-Region deployment and a configured origin group. This is not a generic toggle for any origin. Read the current AWS media quality score documentation and assess whether the supported design fits your deployment.
AWS also describes a broader live-streaming reference architecture with parallel MediaLive feeds, packaging through MediaPackage, and CloudFront delivery. Redundancy adds configuration and operating work, so decide which failure modes you need to tolerate before implementing it. For a small channel, a documented recovery process may be more appropriate than adding an architecture whose components nobody can monitor. If your concern is a local YouTube broadcast that drops after power loss, see how to restart a church stream after a power cut; it addresses a different delivery path from CloudFront distribution.
Finally, model costs using your own region, viewer count, bitrate, viewing duration, cache behaviour, and service configuration. AWS's published event examples are estimates under stated assumptions, not quotes or stable benchmarks; delivery can be a substantial part of the model. Check the current AWS pricing pages and recalculate when your audience or output changes. Do not assume an example's cache-hit ratio or highest-bitrate consumption represents your viewers.
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 encode or package a live video stream?
No. An upstream encoder creates renditions, segments, and manifests, while an origin or packager provides those prepared files. CloudFront delivers requests for them; it does not turn a raw feed into a playable stream.
Should I use MediaPackage or MediaStore as the origin?
Consider MediaPackage when you need packaging into different delivery formats or its packaging features. MediaStore is an option when the encoder already produces outputs that meet the devices' format needs. Confirm the required features and endpoint path in the current AWS documentation before choosing.
Which CloudFront path patterns should I add?
They depend on the endpoint and format. AWS's MediaPackage examples distinguish manifest and segment behaviours for HLS, CMAF, and DASH, while Smooth Streaming uses a single manifest behaviour. Verify your actual paths and use the current AWS guide rather than copying patterns without checking them.
Why does a stream play at the origin but fail through CloudFront?
Check whether the CloudFront behaviour matches the manifest or segment path, whether the origin path and any authorisation header are correct, and whether required query strings are forwarded. Also inspect manifest freshness and test the exact URL the player requests. A working origin narrows the search, but does not establish that the distribution is configured correctly.