A MediaPackage limit for a 24/7 YouTube channel depends first on whether you use MediaPackage v1 or v2, and on the quota in the AWS Region where the channel runs. Neither live quota table sets a maximum continuous channel runtime of 24 hours: its manifest and time-shift limits describe different things.
Before relying on a published ceiling, check your account’s actual quota and confirm the path from your source through packaging or encoding to YouTube ingest. A MediaPackage playback endpoint is not automatically a YouTube ingest destination.
Identify whether the channel uses v1 or v2
Start with the resource type and the documentation that matches it. MediaPackage v1 and v2 have different resource hierarchies, and their published live manifest limits are not interchangeable. A plan based on v1’s five-minute figure can be wrong for a v2 workflow, just as applying v2’s channel-group layout to a v1 account can lead to the wrong capacity calculation.
In v1, a channel is the entry point for an upstream stream and can have endpoints that expose packaged output. The published default is 30 channels per account and Region, with up to 10 endpoints per channel. In v2, the hierarchy includes channel groups: the published defaults include three channel groups per account and 10 channels per group, with up to 10 endpoints per channel. AWS also lists a hard limit of 20 channels per channel group, so the adjustable default and the hard ceiling are not the same statement.
Check the AWS console and your deployment definitions to establish which generation your resources belong to. If a team has inherited a workflow, inspect the channel and endpoint resources rather than assuming the generation from the age of the original design. Keep the generation in tickets, runbooks and quota requests so a five-minute v1 manifest is not accidentally applied to a v2 service.
This distinction is useful even if the channel only distributes one continuous programme. The resource count and output arrangement still determine which quota table applies. The guide to keeping a YouTube playlist running with FFmpeg covers a different layer of continuity: a playlist process stopping at its end is not solved by changing MediaPackage quotas.
Check the quota for the running AWS Region
A published quota is a reference, not proof that your account has that amount available. AWS says adjustable quotas have published defaults, while an account can have a lower value. Confirm the value for the account and Region that actually host the channel; checking another Region or a development account does not validate production capacity.
Use AWS Service Quotas where the service quota is exposed there, and inspect the MediaPackage quota documentation for the resource being planned. For an adjustable quota, request an increase before you need it and allow time for AWS review. A quota request does not turn a hard limit into an adjustable one. Keep a record of the approved value and the relevant Region in your operations notes.
AWS documents quotas as regional/account limits, so multi-Region assumptions need care. If a failover design moves the channel to another Region, that Region’s account values and resource layout also need checking. A regional quota is not a pooled allowance that you can presume is shared across Regions.
Published request rates also need to be interpreted against the actual path. Ingest requests arrive at the channel; output requests go through an endpoint and can be affected by CDN behaviour. A configuration that sends many unique query strings or headers may behave differently from typical CDN caching. AWS describes some endpoint request rates as indicative under typical CDN use and notes that abnormal request patterns can reduce them. AWS quota pages and limits can change, so check the MediaPackage v1 quotas and MediaPackage v2 quotas when you design or revisit the channel. Amazon Web Services’ online quota documentation, accessed 2026, is the source for the figures below; the pages do not state a publication year.
Compare the generation-specific live quotas
The following figures are published defaults or hard limits, not a sizing recommendation. “Adjustable” means a quota may be requested for change; it is not a promise that a request will be approved. “Hard” means you should design within the limit rather than plan on increasing it.
| Limit | MediaPackage v1 | MediaPackage v2 |
|---|---|---|
| Channel structure | 30 channels per account and Region, adjustable default | 3 channel groups per account and 10 channels per group, adjustable defaults; 20 channels per group hard limit |
| Endpoints | 10 per channel, adjustable | 10 per channel, adjustable default |
| Maximum live manifest length | 5 minutes, adjustable | 15 minutes, adjustable default |
| Harvest jobs | 10 concurrent, adjustable | 10 active per channel group, adjustable default |
| Manifests per origin endpoint | Not listed in this v1 quota set | 25, adjustable default |
| Ingest streams | 20 per channel, hard | 20 per channel, hard |
| Tracks per ingest stream | 10, hard | 10, hard |
| Input requests | 50 per second per channel, hard | 200 per second per channel, hard |
| Time-shift manifest length | 24 hours, hard | 24 hours, hard |
| Maximum time-shift content age | 336 hours (14 days), hard | 336 hours (14 days), hard |
| Endpoint segment output requests | 300 per second, hard and indicative under typical CDN use | 500 per second, hard and indicative under typical CDN use |
| Endpoint manifest output requests | 5,000 per second, hard and indicative under typical CDN use | 10,000 per second, hard and indicative under typical CDN use |
| REST API request rate | 5 per second steady state; 50 per second burst, hard | 5 per second steady state; 50 per second burst, hard |
The table separates structure from throughput. For example, v1’s 30-channel account/Region default is not equivalent to v2’s group-based structure. Nor does v2’s higher listed input-request rate establish that it is the right generation for a particular workflow. Count the resources you need, then compare each count with the correct generation’s quota and the value actually granted to your account.
The egress rows deserve particular attention when viewers are served through endpoints. A viewer-facing workload can produce manifest and segment requests in patterns that differ from the count of channels or ingest streams. Consider how caching works, whether clients send varying headers or query strings, and whether an origin request is repeated or shared by a CDN. AWS’s stated rates are not a guarantee that every request pattern will work at those numbers.
For operational reliability, also distinguish service quotas from recovery behaviour. A stream that fits under every quota can still fail because an encoder stops, a source becomes unavailable, or a bridge to YouTube misbehaves. If your existing workstation and encoder are the fragile part, the automatic OBS restart guide addresses process recovery rather than MediaPackage capacity.
Distinguish manifest length from channel runtime
The maximum live manifest length is a rolling-playlist setting, not a timer for how long the channel may broadcast. AWS’s published adjustable maximum is five minutes for v1 and 15 minutes for v2. Those values refer to the live manifest delivered by an endpoint. They do not say that a channel must stop after five or 15 minutes, and they do not define a maximum continuous session of 24 hours.
A manifest is a description of media segments available to a playback client. A rolling live manifest presents a window of recent segments, and that window can advance as new content arrives. The channel’s operation is the ongoing ingest and packaging process. Confusing the window with runtime is like treating the length of a page in a programme guide as the duration of the broadcast itself.
For a 24/7 design, ask whether the upstream source continues sending media, whether MediaPackage receives it, and whether downstream systems can fetch the current output. The live manifest limit is relevant when configuring the playback window, but continuity depends on the whole chain. If the goal is to replay a file continuously rather than produce a live source, the continuous playlist options for YouTube discuss the loop question at the source/workflow level.
Treat adjustable values as account-specific until confirmed. The fact that a documentation table shows a maximum does not establish your effective setting or validate a particular combination of channels, endpoints, clients and request rates. Use the table to identify what to check, not to certify an architecture.
Interpret time-shift manifest and content-age limits
Both generations list a maximum time-shifted manifest length of 24 hours and a maximum time-shift content age of 336 hours, or 14 days. These are limits on the time-shift viewing feature: the amount of manifest history and the age of content available for that use. They are not a rule that a live channel must stop after one day.
The two limits answer related but separate questions. Manifest length concerns how much time-shifted material a manifest can describe. Content age concerns how far back the requested material can be. A short time-shift manifest can still refer to content within the permitted age window; neither setting says that the live ingest itself is limited to that duration.
Do not plan retention beyond the documented age limit, and do not assume that the 24-hour time-shift manifest is an archive strategy. If viewers need older programmes, plan a separate recording and publishing workflow with its own storage, rights and availability decisions. If time-shift viewing is not needed, the limits may not shape the live channel design, but they still should not be misread as runtime ceilings.
In v1, the quota set also lists a 24-hour maximum live-to-VOD manifest length. That is another manifest limit, not a statement about the duration of the live service. Keep it distinct from the time-shift manifest and from the continuously operating channel when documenting requirements.
Check the YouTube integration path
MediaPackage is a packaging and origin service. AWS describes a channel as receiving streams from upstream encoders, then packaging the content for delivery through origin endpoints. An endpoint provides output for players or downstream content delivery, such as a CDN. That role does not make the endpoint a YouTube ingest destination.
YouTube expects an encoder ingest workflow. Its encoder guidance recommends RTMPS for the common workflow. YouTube also documents HLS ingestion, but that is a specific encoder output mode with constraints: MPEG-TS segments, segment durations between one and four seconds, HTTPS POST/PUT requests, and a rolling playlist with no more than five outstanding segments. YouTube notes that HLS has higher latency than RTMP because video is sent in segments.
Therefore, do not paste a MediaPackage HLS playback URL into YouTube Studio and assume it will be accepted as a live feed. Confirm which component reads the MediaPackage output, whether it can encode or relay it in a format YouTube accepts, and whether it satisfies YouTube’s protocol and playlist behaviour. For HLS in particular, establish that the bridge can produce the required segments and playlist rather than merely fetch and replay a playback manifest.
Write the path down as source → encoder or processing stage → packaging/origin where needed → YouTube ingest. The exact order depends on the design; the important point is that every arrow represents a compatible hand-off. AWS identifies MediaLive as an example of an upstream encoder and CloudFront as a downstream CDN, but naming those components does not establish that they send to YouTube. Verify the output settings in the official YouTube Live streaming documentation and in the documentation for the actual encoder or bridge you use.
If your main difficulty is a computer that must stay awake to keep feeding YouTube, StreamNeo removes that specific dependence by letting you upload a file and run the YouTube broadcast with your computer switched off. It is for YouTube, not a replacement for a MediaPackage architecture when you need a custom packaging and distribution workflow.
Plan against published quotas, not assumed capacity
Make a short capacity worksheet before building. Record the AWS account and Region, MediaPackage generation, number of channels or channel groups, endpoints per channel, ingest streams and tracks, expected source request rate, and endpoint request pattern. Mark each item as adjustable or hard. Add the value currently shown for your account beside the published figure so that a default is never mistaken for the live setting.
Then test the path with realistic clients and CDN behaviour. Estimate how often clients request manifests and segments, and check whether cache keys or unique request headers cause otherwise shareable requests to reach the origin separately. For an always-on broadcast, observe what happens when the upstream encoder drops, when a manifest becomes stale, and when the downstream bridge reconnects. Testing should validate recovery as well as nominal traffic, without treating one successful run as a guarantee of future capacity.
Keep quota actions separate from compatibility actions. A Service Quotas request can address an adjustable MediaPackage limit; it cannot make a playback endpoint speak YouTube’s ingest protocol or remove a hard limit. A bridge or encoder decision addresses that integration boundary; it does not increase a channel’s request quota. This separation avoids spending time raising the wrong limit.
AWS’s published figures are starting points for planning, not assurances that a design will support a particular audience or traffic profile. Check current regional values, request changes where appropriate, and revisit them when the architecture or viewer behaviour changes. For an always-on channel, document who checks these values and who responds if a quota request is needed, rather than relying on a remembered number from an old design note.
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
What are the AWS Elemental MediaPackage limits for a 24/7 YouTube channel?
There is no single limit set until you identify v1 or v2 and check your account’s quota in its running Region. The published tables include resource, manifest and request-rate limits, but do not set a maximum continuous runtime for a live channel. Treat the figures as planning references, not capacity assurances.
Can MediaPackage run continuously for 24 hours a day?
The live quota tables do not specify a 24-hour maximum runtime. A channel’s continuity depends on the source, ingest, packaging, delivery and any connection to YouTube. The 24-hour time-shift manifest limit describes time-shift viewing, not a daily stop timer.
What is the maximum live manifest length in MediaPackage?
The published adjustable maximum is five minutes for MediaPackage v1 and 15 minutes for v2. Check the actual quota and the generation in your account. These are rolling live-manifest limits, not limits on how long a channel can remain on air.
Can I send a MediaPackage HLS endpoint directly to YouTube Live?
Do not assume so. A MediaPackage endpoint is for packaged playback output, while YouTube expects an encoder ingest workflow with supported protocol and formatting behaviour. Verify a compatible encoder or bridge against YouTube’s current RTMPS or HLS requirements before treating the path as ready.