CloudFront delivers live-stream manifests and media segments to viewers; it does not encode or package the live input. To set it up, connect an upstream encoder and packaging or origin layer, configure CloudFront behaviours for the resulting paths, and test freshness, access and playback across the whole workflow.
A common AWS path uses MediaLive for encoding, MediaPackage for packaging and origin, and CloudFront for delivery. It is a useful reference, not a requirement: your origin, formats and cache settings should follow the player and freshness needs you actually have.
1. Map the path from input to player
Start by writing down each component’s role and the request path a viewer will use. A live input—such as a camera feed or a programme output—reaches an encoder. The encoder creates an adaptive-bitrate set of renditions; a packaging service prepares manifests and segments in formats that the player can request. CloudFront sits in front of the origin and delivers those HTTP objects to playback clients.
In the AWS reference pattern, two input feeds reach MediaLive, which creates adaptive-bitrate output. MediaPackage prepares endpoints for HLS, DASH and CMAF; CloudFront is configured with those endpoints as origins and distributes their content. AWS describes that design in its Live Streaming on AWS solution overview. Redundant input feeds and several output formats are design choices in that reference solution, not prerequisites for every channel.
Sketch the path with the exact endpoint hostname and path, the manifest suffix, the segment paths, and any player-facing URL. For example, a player may request an HLS playlist ending in .m3u8, then request media segments ending in .ts or .mp4. A DASH client typically requests an .mpd manifest followed by segments. The precise paths depend on the packager and endpoint configuration; an AWS sample path is not a substitute for checking your own endpoint.
This map is also useful when something fails. A missing or stale playlist points to a different layer than a player that cannot decode a segment. Before changing cache policy, confirm which URL the player requested, whether CloudFront received it, and whether the origin returned the expected object. Keep a record of the endpoint paths and formats so the people configuring CloudFront and the player are working from the same reference.
If the viewer destination is YouTube rather than a player on your own site, distinguish the workflow carefully: CloudFront’s live-delivery pattern describes serving media to clients, while YouTube ingest has its own requirements. For a practical checklist on that separate destination, see what to check before going live on YouTube. Do not assume that a CloudFront distribution is a replacement for an encoder’s YouTube output configuration.
2. Keep encoding and packaging upstream
CloudFront is the delivery layer. It can fetch video from HTTP origins, but it does not take a raw camera feed and turn it into a live HLS playlist, DASH manifest or set of media segments. That work must happen upstream, before CloudFront can cache or deliver the resulting objects. AWS documents CloudFront’s role alongside Media Services in its live streaming guidance.
Encoding determines the video and audio renditions made available to players. Packaging produces the manifests that describe those renditions and the segments a player fetches over time. A player chooses among renditions and follows the manifest’s current view of the live programme. If either upstream step produces paths or timing that differ from the CloudFront behaviour configuration, delivery can fail even when the distribution itself is available.
AWS’s documentation names HLS, MPEG DASH, Microsoft Smooth Streaming and CMAF among formats CloudFront can deliver. Format selection is not a universal preference question. Check the target players and devices, required packaging and DRM workflow, latency objective, and the capabilities of your chosen origin. AWS documents MediaStore as another origin path when encoded content is already in a form suited to the devices; that does not make MediaStore or MediaPackage universally better.
For each output, establish what the origin actually exposes: which manifest is the entry point, where it refers to segments, how frequently a live manifest changes, and whether requests need query parameters or authorisation. This information should come from your packager configuration and observed requests, not from assumptions based on an example deployment. If you encode outside AWS or already have a suitable HTTP origin, the same separation of roles still applies.
Upstream encoding settings can have delivery consequences, but changing them is not a CloudFront setting. A lower segment duration, for instance, affects how often a player can receive new media, while also changing the workload seen by the packager and player. Keep changes to encoding, packaging and CDN policy separate during tests so you can tell which change affected playback. For a different, YouTube-specific encoding workflow, the GStreamer settings guide for prerecorded live streams is a useful contrast, not a CloudFront configuration recipe.
3. Choose and configure the origin
Choose the origin based on what it needs to do, not simply because it appears in an AWS diagram. MediaPackage is a packaging and origin option in the documented AWS live workflow. MediaStore can serve as an origin in a path where the content is already encoded and packaged for its playback use. A general HTTP origin may also be appropriate where it serves the required live objects and fits your operational design.
Compare candidates against the same practical questions: can the origin produce the formats and manifest behaviour your clients require; does it support your packaging and DRM needs; how will you protect it from direct requests; and can your team inspect its responses during a live event? Consider the operational needs for failover and monitoring as well. The AWS CloudFront video streaming overview describes delivery from origins, while the live setup documentation covers the MediaPackage-oriented arrangement.
In CloudFront, add an origin for the endpoint that will supply the live objects. If you have distinct endpoints or formats, configure them deliberately rather than pointing every viewer path at one assumed location. Confirm the origin hostname, protocol, path conventions and any required headers against the origin’s own configuration. Then request a known manifest through the distribution and compare the response with a direct origin request, accounting for authorisation differences.
AWS’s documented MediaPackage live setup recommends a cache-policy minimum TTL of five seconds or less to help avoid stale content. Treat this as guidance for that described setup, not as a blanket rule for every live origin or playlist. The right observed freshness depends on the origin, the format, how often the playlist updates and what delay your viewers can tolerate. Validate the effect of the policy with repeated requests during an actual or representative live output.
Keep a written note of what is documented guidance and what you selected for your workload. The five-second-or-less minimum TTL and the LL-HLS forwarding requirements described below are AWS guidance for the MediaPackage scenario. Whether a given behaviour pattern, TTL, failover arrangement or format is suitable for your own channel needs testing against the endpoint and player you will run.
4. Separate manifest and segment behaviours
A manifest and a media segment have different jobs and different freshness requirements. The manifest tells the player what media is available and where to request it. In a live stream it changes as new content becomes available. A segment is a unit of media referenced by the manifest; once published, it is generally not updated in the same way as the live playlist. That difference is why AWS examples distinguish manifest requests from segment requests in CloudFront cache behaviours.
Create path patterns that match the actual endpoint and content paths. An HLS manifest might use .m3u8, with segments using .ts or .mp4; a DASH manifest might use .mpd, with segment paths that are specific to the packager. CMAF paths can vary too. Match the endpoint GUID or prefix and the relevant segment extensions you see in your configuration. Do not copy a sample pattern and assume it covers every rendition or object.
| Request class | Common path clue | What to verify in the behaviour |
|---|---|---|
| HLS manifest | .m3u8 |
Pattern matches the endpoint; freshness reflects playlist updates |
| HLS or CMAF media | .ts or .mp4 |
Pattern matches actual segment paths and extensions |
| DASH manifest | .mpd |
Pattern covers the endpoint and manifest path |
| DASH media | Packager-specific segment path | Verify the real path structure rather than infer it from .mpd |
This is a starting checklist, not a complete policy template. Behaviour order matters when patterns overlap, so check which behaviour handles each request. For a short live playlist, applying a segment-oriented cache policy to a manifest can make the player see an older view of the stream. Conversely, treating every media object as if it must be revalidated as frequently as the playlist can create avoidable origin requests. The right split depends on object paths and freshness needs.
Test with a manifest and one referenced segment from each relevant output. Inspect the status code and response content, and verify that the manifest’s referenced paths can be requested through CloudFront. Repeat the manifest request after the origin has advanced. If it does not reflect the new live window as expected, examine the matching behaviour and cache policy before changing unrelated encoding settings. If you are also building a YouTube workflow, the OBS and media-source comparison deals with a different replay method; it should not be used to infer CloudFront cache behaviour.
5. Forward LL-HLS query parameters when needed
Low-Latency HLS can use blocking playlist requests: a client asks for a playlist version associated with a media sequence number or part, and the origin can hold the request until the requested update is available. In AWS’s documented MediaPackage setup, the query parameters _HLS_msn and _HLS_part need to be forwarded on the manifest cache behaviour so the request reaches MediaPackage with the information it needs.
Configure this on the behaviour that matches LL-HLS manifests, not indiscriminately on every path. If CloudFront omits those values, the documented blocking playlist request feature will not work as intended, because the origin does not receive the client’s request details. Verify the actual query names in your player’s requests and the selected cache policy or origin request policy. The key is to preserve the required request information while avoiding accidental differences in how unrelated objects are cached.
A useful check is to capture a manifest request from the player, including its query string, and confirm the request reaches the origin with the required parameters. Then observe the response and player behaviour as new parts become available. Do not conclude that query forwarding alone makes a stream low latency: encoder cadence, packaging, distribution, player buffering and network conditions all contribute. If you are not using the documented LL-HLS blocking request path, do not add settings on the assumption that the parameter names improve ordinary HLS delivery.
6. Protect the origin, then design viewer access separately
An origin should not be unintentionally exposed as an easy bypass around the CloudFront distribution. AWS recommends header-based CDN authorisation between MediaPackage endpoints and CloudFront in its live setup guidance. In that arrangement, the origin expects a custom HTTP header identifying the authorised CDN request; the AWS reference solution stores its identifier in Secrets Manager. Follow the current AWS instructions for configuring and handling the value rather than copying a sample secret into a public document or client configuration.
This mechanism protects the connection from CloudFront to MediaPackage. It is not the same thing as deciding who is allowed to watch. If your stream needs viewer authentication, geographic or other access rules, or a private playback experience, those are separate design decisions. Decide whether the manifest and segments require viewer-level controls and test that a player can still make every request it needs after those controls are applied.
Validate origin protection in both directions. A request through the expected CloudFront path should reach the origin with the required authorisation and return the intended object. A direct unauthorised origin request should not disclose the live content if your design expects CloudFront-only access. Also test failure handling: expired or missing credentials should be observable in logs and alerts, not mistaken for a player or encoding fault. Do not treat a successful test once as proof that key handling and rotation are permanently correct.
7. Tune latency across the full workflow
Viewer latency is an end-to-end result. The source capture, encoder, packaging cadence, origin response, CloudFront delivery, player buffer and viewer’s network all contribute. A change in one layer may be hidden by delay in another. Measure from a known event at the source to its appearance in the player, using the same path and player settings you expect to operate; then repeat under the audience and network conditions that matter to you.
AWS’s MediaLive guidance for low-latency output to MediaPackage v2 identifies several settings that affect latency: connection retry interval, number of retries, file-cache duration, restart delay, segment length, minimum segment length, GOP size and closed GOP cadence. For that workflow, AWS recommends a one-second segment length for better latency. That is a specific upstream recommendation, not a CloudFront setting and not a promise of a particular glass-to-glass result. Consult the current MediaLive low-latency guidance before applying it.
A shorter segment duration may let a player obtain new media sooner, but it also changes how often requests are made and how the rest of the pipeline behaves. The trade-off depends on the packaging mode, player and audience network. Likewise, a player buffer that is deliberately conservative may improve continuity while increasing delay. Change one variable at a time and record the visible result, interruptions and origin request pattern; do not select a value solely because it is labelled low latency.
For reliability, decide what happens when an input or origin path fails, and exercise that scenario before an important event. The AWS reference design’s two ingest feeds and multiple packaged formats illustrate choices for a particular architecture, not a guarantee that failover will behave as your channel requires. Test the switchover, check whether manifests remain coherent, and verify what the player does when a request fails. A stream that recovers upstream can still leave a player stuck on an old playlist.
Operational checks should include the current manifest response, a playable segment, origin errors, distribution errors and player behaviour. Keep an event log with configuration changes and timestamps so that a night-time interruption can be traced across layers. If your actual need is to keep a YouTube channel live from a prerecorded file without leaving a computer running, a CloudFront build may be unnecessary; StreamNeo removes that local-machine burden by running the uploaded video as a YouTube live stream. For a computer-based setup, the guide to handling power cuts during a church YouTube stream addresses a different operational failure mode.
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 stream?
No. CloudFront delivers objects from an origin; encoding and packaging must happen upstream. Your encoder and packaging or origin layer need to create the manifests and segments before the distribution can serve them.
Which CloudFront behaviours do I need for HLS or DASH?
Use patterns that match your actual endpoint paths and distinguish live manifests from media segments where their freshness needs differ. Check the packaging configuration for the manifest suffixes and segment paths; example extensions are clues, not a complete template.
What must be forwarded for LL-HLS blocking playlist requests?
For the documented MediaPackage workflow, forward _HLS_msn and _HLS_part on the manifest behaviour. Confirm the player sends them and that the origin receives them; this configuration does not by itself establish a particular end-to-end latency.
Does the one-second segment recommendation guarantee low viewer latency?
No. AWS recommends that segment length for better latency in its specified MediaLive-to-MediaPackage v2 workflow. Capture, encoding, packaging, delivery, player buffering and network conditions still shape the result, so measure your complete path.