To estimate AWS Elemental MediaPackage charges for a 24/7 YouTube stream, calculate ingest from the total input bitrate and stream count, then calculate origin and packaging from audience traffic that misses the CDN cache. Keep encoding, CDN delivery and any applicable data transfer on separate bill lines; MediaPackage is not the whole streaming bill.
The useful starting point is a workload, not a headline hourly price. Gather your region, incoming renditions, average audience and cache behaviour, then substitute those values into current AWS rates or the AWS Pricing Calculator.
Gather the stream and traffic inputs
Write down the parts of the design that determine volume before opening a calculator. For MediaPackage, the main inputs are the AWS Region, the MediaPackage version and workflow, number of input streams, and aggregate bitrate received on each stream. For a continuous channel, also state the modeled billable hours rather than assuming every month has an identical number of hours.
For the audience side, estimate average concurrent viewers across the day and the average bitrate they actually watch. A peak concurrent figure is useful for capacity planning, but it does not describe a full-day traffic bill. Finally, determine the CDN cache-hit ratio, or equivalently the fraction of audience video volume that reaches MediaPackage as an origin request.
| Input | What to record | Why it matters |
|---|---|---|
| Region and workflow | Region, MediaPackage version and architecture | Rates and service path depend on the deployment. |
| Incoming video | Streams and bitrate ladder for each | Aggregate received bitrate drives ingest volume. |
| Active hours | Modeled hours in the billing period | Volume and charges scale with activity. |
| Audience | Average viewers and watched bitrate | These determine potential delivered video volume. |
| Cache behaviour | CDN hit ratio or origin fraction | Cache misses determine MediaPackage origin volume. |
| Other services | Encoder, CDN and transfer path | These are separate charges, not MediaPackage charges. |
Use the sum of the bitrate ladder, not just the top rendition. If a channel sends several quality levels to MediaPackage, each contributes to received volume. If it sends two redundant inputs, count both inputs for ingest even though they represent the same programme. That redundancy may be useful for resilience, but it is not free in the ingest calculation.
A plain spreadsheet is enough to make assumptions visible. One row per incoming stream and one row for audience volume makes it easier to find whether a surprisingly large estimate comes from redundancy, a high bitrate, or a low cache-hit assumption. This kind of distinction is also useful when comparing a VPS and other always-on streaming approaches, because the comparison should use the same programme quality and operating hours rather than mixing unlike totals.
Estimate MediaPackage ingest volume and cost
AWS prices MediaPackage live ingest by the data received. Convert the aggregate input bitrate to volume per hour, multiply by the number of incoming streams, then multiply by active hours and the current regional ingest rate. The pricing example on AWS Elemental MediaPackage pricing uses a stated conversion of 9.5 Mbps to 4.175 GB per hour for one input stream.
The worksheet is:
- Ingest GB per hour = aggregate bitrate converted to GB per hour × input stream count.
- Ingest volume = ingest GB per hour × modeled active hours.
- Ingest cost = ingest volume × current regional price per GB.
The meaning of “aggregate bitrate” needs care. Suppose your encoder sends multiple renditions, such as a high, medium and low quality version. Add their bitrates to get the stream’s total received rate. If the same ladder is sent through two redundant input streams, multiply its converted volume by two. Do not count only the rendition a typical viewer might watch: ingest charges follow what MediaPackage receives, not what a particular viewer selects.
AWS’s published example gives an illustrative ingest calculation: one 9.5 Mbps input stream is 4.175 GB per hour using AWS’s conversion; two such streams therefore total 8.35 GB per hour. At the example rate of $0.030 per GB in US East (N. Virginia), the two-stream ingest amount works out to $0.2505 per hour. These figures are AWS’s example inputs and rates, not a current quote for your Region or a general estimate. Check the present rate before using the calculation in a budget.
Model time explicitly. A seven-day continuous week is 24 hours multiplied by seven; for a month, use the billable hours you intend to model rather than treating all months as equal. If a channel is occasionally stopped for maintenance, estimate the hours it is actually active, but do not assume a short interruption will materially change a rounded monthly bill without calculating it.
For a channel made from prerecorded material, the operating method does not change the arithmetic once the MediaPackage input is defined. The upstream component still has to supply the expected input streams. If you are deciding between a local encoder and a hosted workflow, this comparison of streaming services with OBS can help frame the operational trade-off, but it does not replace a service-by-service AWS estimate.
Estimate origin and packaging from viewer traffic
Origin and packaging volume is tied to requests MediaPackage serves, not simply the number of viewers watching YouTube. A CDN such as CloudFront can satisfy repeated requests from cache; requests that miss the cache reach MediaPackage and contribute to origin volume. AWS recommends a CDN such as CloudFront because cache hits reduce the amount MediaPackage originates and packages. The CDN’s own delivery charge remains a separate line.
First estimate audience video volume over the modeled period:
- Viewer GB = average watched bitrate × average concurrent viewers × hours, converted to GB.
- MediaPackage origin GB = viewer GB × (1 − cache-hit ratio).
- Origin and packaging cost = MediaPackage origin GB × current regional origin/packaging rate per GB.
Use consistent units throughout. If bitrate is in Mbps, convert that rate across the number of viewers and hours before applying the volume conversion. AWS’s pricing example uses its stated conversion: 1,000 average viewers watching at 2 Mbps produces 878.91 GB per hour. At the example cache-hit ratio of 97.5%, 2.5% of that audience volume reaches MediaPackage, or 21.97 GB per hour. At the example $0.050 per GB origin/packaging rate, that is $1.10 per hour.
These are not universal audience assumptions. A devotional channel with a modest, steady audience and a news loop with a sharp evening peak may have very different averages and cache behaviour. If you only know peak viewers, do not silently substitute that number for the daily average. Make a low, central and high scenario instead, with assumptions stated for each.
The cache ratio deserves particular attention. A hit ratio close to 100% leaves relatively little viewer volume for MediaPackage to originate; a lower ratio puts more traffic on the origin line. The exact ratio depends on how the CDN is configured and how requests are distributed. If you do not have observed cache data yet, mark your assumption as uncertain and use the calculator to test more than one plausible origin fraction. A rough assumption is more useful when labelled than when presented as a measurement.
It is possible for a channel to have small ingest and large origin/packaging charges, or the reverse. A fixed input ladder can be moderate while a large audience repeatedly requests video, with the origin amount then shaped by cache misses. Conversely, a channel may pay meaningful ingest for redundant inputs while serving few viewers. This is why multiplying a single hourly figure by a month is not a reliable shortcut.
If you want to understand the audience-data side separately, this guide to data use for a 24/7 YouTube live loop concerns viewer delivery consumption, not a direct MediaPackage invoice. Keep that distinction in mind: the audience’s total viewing volume and the fraction reaching an origin are related, but they are not the same charge.
Keep encoding and delivery on separate bill lines
A defensible estimate should show a MediaPackage subtotal and then other architecture costs separately. AWS’s live streaming deployment guidance separates MediaLive encoding, MediaPackage ingest, MediaPackage packaging and origination, and CloudFront distribution. A full design may also incur storage, transfer or other service costs depending on its actual path and configuration.
| Bill line | What drives it | Include in MediaPackage subtotal? |
|---|---|---|
| MediaPackage ingest | Input GB, stream count, active hours and regional rate | Yes |
| MediaPackage origin/packaging | Origin GB after cache behaviour and regional rate | Yes |
| Encoding service | Encoder service, settings and time used | No |
| CDN delivery | Data delivered to viewers and CDN pricing dimensions | No |
| Data transfer | Applicable transfer path, destination and service rules | No |
| Other architecture services | Storage or components used by the design | No |
Do not interpret “to YouTube” as proof that MediaPackage itself is a YouTube encoder or publisher. YouTube’s guidance says creators configure an encoder with a YouTube stream URL and key for RTMP(S), and YouTube also documents HLS ingest requirements. Confirm the actual protocol and the component that publishes or converts the feed before pricing an end-to-end design. The reviewed documentation does not establish a direct MediaPackage-to-YouTube path for every architecture.
AWS notes that data transfer can apply when output goes over the internet or through a CDN other than CloudFront. Whether a transfer line applies depends on the actual service path, so check the current AWS rules for the design rather than adding an unsupported flat charge. The AWS deployment planning guide is useful for identifying separate components, but sample architecture costs there are workload-specific and can age.
The same separation matters if you are comparing AWS with a service that uploads a file and runs a continuous broadcast for you. Do not compare a MediaPackage-only subtotal with another service’s all-in operating cost unless the scope really matches. An always-on loop also has a publishing component, monitoring and restart considerations, not only packaging charges. The point is not that one architecture is automatically cheaper; it is that each line should have a clear service boundary.
Read AWS’s 24/7 example as an example
AWS’s pricing-page example for a 24/7 live linear channel in US East (N. Virginia) reports $1.3505 per hour for MediaPackage ingest plus origin and packaging, under its stated assumptions. Its arithmetic is $0.2505 per hour for ingest and $1.10 per hour for origin and packaging. It is not a general quote for a 24/7 channel, and it is not a complete cost for delivering a stream to YouTube.
The example assumes two input streams, each with a 9.5 Mbps total bitrate, and uses the displayed example ingest rate of $0.030 per GB. On the audience side it assumes 1,000 average viewers at 2 Mbps each, a 97.5% CDN cache-hit ratio, and the displayed example origin/packaging rate of $0.050 per GB. Change the stream count, ladder, average audience, watched bitrate, cache performance, region or current rate and the result changes.
In particular, the $1.10 audience-side portion does not mean that AWS charges that amount per channel hour regardless of viewership. It follows from the assumed 878.91 GB per hour of viewer traffic and the 2.5% that misses cache. A channel with few average viewers, a different watched bitrate or a different cache ratio will have another originated volume. Similarly, a one-input design does not have the same ingest volume as the example’s two-input redundancy.
The example also does not establish encoding or CDN delivery cost. Those belong to other services and rate cards. Nor should the cited figure be presented as a bill estimate for a YouTube channel unless the actual design includes the same service roles and the assumptions have been checked. Treat it as a worked illustration of the calculation method, not as a budget promise.
Substitute your values into current rates
Build a small sheet with separate rows for input volume and origin volume. Keep the assumptions beside the formula, especially the unit conversion and the period being modelled. AWS’s pricing page uses 1024 in its bitrate-to-volume conversion; do not mix that conversion with a decimal one halfway through the worksheet. Round only after calculating the volume and cost so that intermediate rounding does not distort the result.
For each scenario, record the Region and the rate source/date you checked. Rates can vary by Region and can change, so the example rates above should not be carried forward as current values. Use the AWS Pricing Calculator or the current MediaPackage pricing page to enter the relevant service and Region values. If you have an AWS agreement, credits or discounts, account for those separately rather than assuming public list rates reflect your actual bill.
A practical scenario worksheet might look like this:
| Scenario field | Lower case | Working case | Higher case |
|---|---|---|---|
| Input stream count and aggregate bitrate | Your assumption | Your assumption | Your assumption |
| Active hours | Your modeled period | Your modeled period | Your modeled period |
| Average viewers and watched bitrate | Your assumption | Your assumption | Your assumption |
| Cache-hit ratio | Your assumption | Your assumption | Your assumption |
| Ingest GB and cost | Formula result | Formula result | Formula result |
| Origin GB and cost | Formula result | Formula result | Formula result |
| Encoding, CDN and transfer | Separate estimates | Separate estimates | Separate estimates |
For a first estimate, a few scenarios are usually more honest than a single precise-looking total. If cache-hit ratio is unknown, vary that input while holding audience and watched bitrate steady. If viewership is uncertain, vary the average audience but avoid combining every worst-case assumption without explanation; state what each scenario represents, such as ordinary viewing or a sustained high-audience period.
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
How much does a 24/7 live linear channel cost on MediaPackage?
There is no single hourly amount that applies to every channel. Calculate ingest from aggregate input bitrate and input count, then calculate origin and packaging from audience traffic that reaches MediaPackage after cache misses. Use current regional rates and keep encoding, CDN delivery and any applicable transfer separate.
Is AWS’s $1.3505 per hour a quote for my YouTube stream?
No. It is AWS’s example result for MediaPackage ingest and origin/packaging in US East (N. Virginia), using two 9.5 Mbps inputs, 1,000 average viewers at 2 Mbps and a 97.5% cache-hit ratio, along with the example rates shown. It is assumption-bound and excludes other service lines such as encoding and CDN delivery.
Does a higher CDN cache-hit ratio reduce all streaming costs?
It can reduce the amount of viewer traffic that MediaPackage originates and packages, because fewer requests reach the origin. It does not erase CDN delivery charges, and the full bill depends on the CDN and any applicable transfer charges in the architecture. Check each service’s current pricing separately.
Can MediaPackage send a live stream directly to YouTube?
Do not assume that it can serve as the complete YouTube encoder and publisher. Check YouTube’s current encoder setup guidance and the protocol requirements for your intended workflow, then confirm what component supplies the YouTube ingest feed. Pricing an unverified path can leave important services out of the estimate.