Protecting a live video stream with Amazon CloudFront requires two controls: authorize viewers at CloudFront with signed access, and prevent them from bypassing CloudFront to reach the origin directly. Your application decides who is entitled to watch; CloudFront checks the signed request against its policy, but it does not make the entitlement decision for you.
For HLS, where a presentation uses a manifest and many segment files, signed cookies often suit an entitlement that covers the whole set. Signed URLs suit individual objects or clients that cannot use cookies. Neither mechanism alone makes an exposed origin private or supplies DRM.
Map the live delivery path
Think of the stream as a chain: an encoder or live input produces video, a packaging or storage layer makes media available, CloudFront distributes it, and a player requests a manifest and its segments. The viewer-facing control point is CloudFront. The origin is the service or bucket from which CloudFront obtains those files.
In an AWS-managed live workflow, MediaLive can encode a live input. MediaPackage can package video for device formats and optionally add DRM; MediaStore can serve content that is already encoded into suitable formats. CloudFront then distributes the resulting video. These services have different jobs, so begin by identifying what produces the files and what CloudFront is configured to fetch. AWS describes these roles in its live video workflow documentation.
A viewer commonly fetches a master manifest, a media playlist, and then a sequence of segments. Depending on the player and packaging, there may also be subtitles, encryption keys, audio tracks, or other resources. The exact request pattern matters: access that works for the first manifest may still fail when a later segment is requested under a different path or without the expected credentials.
Separate public resources from protected media deliberately. A landing page or player bootstrap script may be public, while the manifest and media paths require authorization. Put those paths into suitable CloudFront cache behaviours rather than assuming that one setting on a distribution describes every URL. This boundary is the foundation for both token scope and origin protection.
If you are comparing a file-based YouTube workflow rather than constructing an AWS delivery path, the guide to keeping a YouTube channel live with pre-recorded video covers that different operating pattern. CloudFront protection is about controlling access to media delivered through your own distribution; it is not a way to change YouTube's own viewing controls.
Decide how viewers are authorized
The application should perform the business decision. It might check that a viewer has signed in, has an active membership, or has otherwise been granted access. Once that check succeeds, the application issues signed access with a policy limited to the intended content and period. CloudFront validates the signature and policy when the protected request arrives.
This division avoids a common design mistake: treating a signed cookie or URL as proof that a payment or membership is valid by itself. The token represents an authorization decision already made by your application. Your application needs a process to stop issuing new credentials when entitlement ends, while your policy expiry bounds existing credentials. CloudFront enforces the cryptographic and policy conditions, not your account database or payment rules.
AWS recommends using trusted key groups for signed access. The public key is associated with the CloudFront configuration, while a trusted signer holds the corresponding private key and signs policies or URLs. AWS documents RSA 2048 and ECDSA 256 signing key types. Keep the private key in the application environment that needs to issue access, restrict who can read it, and plan a rotation procedure so a compromised or replaced key can be removed from trust.
A policy should describe the resource the viewer may fetch and when access is valid. A custom policy can include a start time, an expiry, and an optional IP range. Be cautious with IP binding for ordinary viewers: mobile networks and some internet connections can change a person's address during playback, which can turn a valid session into a failed request. Treat IP restrictions as a trade-off to test against your audience and threat model, not an automatic improvement.
There is no universal token lifetime for every live channel. A short window limits how long a copied credential remains useful, but a live player may continue asking for segments after the initial manifest request. Set expiry around the viewing session and decide how the application renews credentials. Test seeking, reconnecting, and long viewing sessions, not only the first seconds of playback.
Choose signed cookies or signed URLs
AWS says the two methods provide the same basic function: controlling who can access content. They differ in how credentials travel with requests and how naturally they cover a set of files. The key decision is whether a viewer needs one object or a group of related resources.
| Situation | Usually a better fit | What to check |
|---|---|---|
| One downloadable object or a single resource | Signed URL | Include all required query parameters before signing; changing the URL afterwards can invalidate it. |
| HLS manifest plus multiple restricted files | Signed cookies | Confirm the player sends cookies on manifest and segment requests, and scope the cookie to the intended paths. |
| Client cannot store or send cookies | Signed URLs | Ensure each requested protected object has a signed URL, including any child resources the player fetches. |
| Existing media URLs should remain unchanged | Signed cookies | Keep the cookie domain and path narrow enough to avoid granting access beyond the stream set. |
For an HLS presentation, cookies can cover multiple restricted files without rewriting each media URL. That can make a multi-file set easier to operate: the manifest can refer to its ordinary segment paths, and the browser sends the required credentials for matching requests. It is still necessary to check the actual player behaviour, particularly when media is fetched across origins or by a native application rather than a browser.
A signed URL carries its authorization in the URL. That is straightforward for a single file, a download link, or a client that has no cookie support. It can be less convenient when a player must request a large number of separately named segments, because each protected request needs an appropriately signed URL or a URL pattern and policy design that fits the implementation.
If both signed URLs and signed cookies are enabled for the same content, a request that includes a signed URL is evaluated on the basis of that URL. Avoid making the client send contradictory credentials and then guessing which one CloudFront will use. Choose a consistent mechanism for each protected path and test the exact URLs the player generates.
For related operational issues with a local encoder rather than CloudFront access, the OBS playlist restart guide explains how to keep a playlist cycling. That addresses continuity at the source; signed access addresses which requests are allowed to retrieve protected files.
Issue access tokens from the application
A typical sequence begins when a viewer opens the channel page. The page or player requests access from your application, the application checks the viewer's entitlement, and then it returns signed credentials in the form your player can use. If the check fails, the application does not issue them. Keep the authorization endpoint separate from the media origin so the media service is not being asked to make membership decisions.
For cookies, AWS's browser guidance uses three separate cookie name-value pairs for the policy, signature, and key-pair identifier. Set them as separate Set-Cookie headers rather than combining them into one value. Use Secure so the browser only sends them over HTTPS, an appropriate HttpOnly setting where client-side script does not need to read them, and a narrow cookie domain and path. Follow the current AWS instructions for the precise attributes and format.
Cross-origin playback needs deliberate browser configuration. A cookie will not be sent merely because it exists: the player request mode, cookie attributes, domain, and the distribution's CORS response must all permit it. Configure the player to make credentialed requests when appropriate, and allow only the origins that should use the stream. Do not use a permissive CORS response as a substitute for signed access; CORS controls browser access rules, while CloudFront signed access validates the request.
CloudFront does not require signed access for an OPTIONS preflight request. That request is part of a browser's CORS negotiation, not the media fetch itself. Ensure the origin's preflight response does not disclose protected media or otherwise return the stream content. Then test the subsequent GET request with missing and present credentials.
For signed URLs, generate the final URL only after deciding which query parameters the player needs. AWS notes that adding query parameters after signing can lead to an HTTP 403 response. Avoid logging full signed URLs in analytics, error reports, or support tickets: their query strings are credentials for the period when they remain valid.
Configure CloudFront validation
Create or select a trusted key group containing the public key used to validate signatures, then associate that trusted key group with each cache behaviour that serves protected stream paths. Require signed access on those behaviours. Keep any intentionally public player shell or static assets in a separate behaviour if they are not meant to require the same credentials.
The protected path needs to match the content model. If the HLS master playlist points to a media playlist in a subdirectory, and that playlist points to segments elsewhere, all those paths must be covered by the intended behaviour and policy. A policy that covers only the first manifest can make playback appear to start correctly and then fail at the next request. Review actual request paths from the player and compare them with the behaviour path patterns.
Set policy scope narrowly enough to match the entitlement. A custom policy can specify a resource pattern and temporal limits, with an optional IP range. A wildcard may be useful for a related set of HLS files, but it should not accidentally cover unrelated content that happens to share a directory. Where a stream has distinct paid and public variants, use separate resource scopes and test that credentials for one cannot retrieve the other.
Caching and authorization serve different purposes. CloudFront can cache an object and still validate whether a request has the necessary signed access. Do not infer that a cached object is public, or that making it private at the origin automatically enforces viewer entitlement at the edge. Configure and verify both the behaviour's validation requirements and the origin's access restrictions.
AWS's signed URL and signed cookie decision guide explains the selection trade-offs, and its private content overview sets out the division between trusted signers, policies, and CloudFront validation. Console labels and APIs can change, so check the current official instructions when implementing a distribution.
Restrict direct access to the origin
Signed access controls requests through CloudFront; it does not make a publicly reachable origin safe. If a viewer can obtain the origin URL and fetch the same manifest or segment directly, that request can bypass the CloudFront validation you configured. Protect the origin as a second, linked task.
For content in Amazon S3, use Origin Access Control (OAC) so the bucket allows retrieval through the intended CloudFront distribution rather than public direct reads. Review the bucket policy and remove public access paths that would defeat the restriction. AWS explains the available CloudFront origin access controls. Test with an origin URL directly, not only with the distribution hostname.
For a custom origin, choose controls that suit the service. You can restrict network access so only CloudFront can reach it, or configure a secret custom header that the origin checks on requests from the distribution. A header is only useful if the origin rejects requests that lack the expected value, and the value itself must be treated as a secret. Network restrictions need to account for how the origin accepts CloudFront traffic and how updates are maintained.
Do not assume that an obscure hostname is an access control. If the origin accepts public requests, knowing or discovering its address may be enough to bypass the edge policy. Similarly, using HTTPS from CloudFront to the origin protects that connection but does not by itself prevent an unrelated viewer from making a direct request to a public origin.
If you are running an encoder on an AWS virtual machine and need to keep its publishing process alive, the AWS VPS live-streaming guide covers a different part of the pipeline. It does not replace CloudFront's viewer access controls or origin restrictions. For teams whose actual need is simply to turn an uploaded file into a 24/7 YouTube broadcast without keeping a computer on, StreamNeo removes the recurring task of running and monitoring that local broadcast process; it is YouTube-only, not a CloudFront delivery layer.
Test access to manifests and segments
Test the complete viewer journey with the same player, browser, and network conditions your audience will use. Start with a valid entitlement and confirm that the master manifest, child playlist, segments, and any required tracks all load. Then test a missing signature, a malformed signature, and an expired policy. Protected requests should fail rather than falling through to a public origin route.
Test the origin separately. Try to retrieve a representative manifest and segment using the origin address, outside the CloudFront distribution. A successful direct response indicates that the origin restriction is not doing its job, even if a normal player session through CloudFront works. For S3, check both object URLs and bucket policy behaviour; for custom origins, verify the network or header condition rejects requests that do not come through the distribution.
Test renewal and duration at the boundaries. Let a session continue until near expiry, then observe whether the player requests another segment after credentials have expired. Exercise whatever renewal path your application provides, as well as reconnecting after a network interruption. This is especially important for live content, because playback depends on repeated requests rather than one initial download.
For browser playback, inspect the network panel for cookie sending, CORS responses, preflight behaviour, and the precise URL that receives an error. Test from a second domain if the player is hosted separately from the distribution. Do not treat a successful OPTIONS response as proof that the protected GET works, or vice versa.
A short checklist is more useful than a single green play button: authorized manifest, authorized segment, missing credentials, expired credentials, direct origin request, and browser preflight. Record which layer rejects each negative case. If the origin itself returns protected content on a direct request, fix that boundary before relying on CloudFront signatures.
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 decide whether a viewer has paid?
No. Your application checks identity or entitlement and issues signed access when its own rules allow it. CloudFront validates the signature and policy on protected requests; it does not know whether a payment, membership, or account status is valid.
Should an HLS stream use signed cookies or signed URLs?
Signed cookies are commonly a better fit when one entitlement should cover a manifest and many related restricted files, provided the player can send cookies. Signed URLs suit individual objects and clients without cookie support. Test the player’s actual requests before choosing.
Do signed cookies make a public origin private?
No. They control requests that pass through CloudFront, but an exposed origin can still provide a bypass. Restrict origin access separately, such as with OAC for S3 or suitable network or header controls for a custom origin.
Do signed URLs or cookies include DRM?
No. Signed access controls who can request content through CloudFront; it does not itself encrypt media or prevent screen recording or credential sharing. AWS describes DRM as an optional capability in packaging workflows such as MediaPackage, and you should check the current requirements for your player and audience.