How Much Does Live Streaming Cost on AWS?

Update

This blog post has been updated since it was first published on August 8, 2018.
Effective May 17th, 2019, AWS Elemental MediaPackage announced a significant reduction in pricing for live channel ingest, and origination and packaging. All of the costs below have been revised based on the updated pricing for MediaPackage and reflect the latest pricing with new, lower costs of running a live channel.

Introduction

The most common questions I get about setting up live streaming have little to do with the technical aspects of building a video workflow. Instead, they are about the cost of running a channel and when running one becomes cost effective. These are important questions. These are also questions that are difficult to answer with simple responses. This is not because the answers themselves are complex, but because you have to know the answers to other questions first. So, the answer to “how much will a live video stream cost?” or “when will a channel make money?” leads to more questions before any answers can be worked out.

What I hope to do with this blog post is to suggest some of those questions that need answering. Then, I’ll show how it is possible to get answers about costs and return on investment using some assumptions as examples.

First, I want to define the boundaries of what I will cover. I won’t address production costs directly, which need to be taken into account if you are planning to do any live streaming. A live stream can be an event, or a regular channel, or a 24×7 channel, and the production value can vary dramatically in quality, number of cameras, sound mixing, graphics, lighting, makeup, and more. The resulting video is sent to the cloud for processing and distribution. This can be done using a smartphone or free software on a computer, or it could be done using a professional, broadcast-grade contribution encoder. The main reason I want to avoid tackling all these variables here is the wide array of options and possible combinations, and the impact they can have on cost. Let’s just say there will be a cost, and that cost can match whatever budget you have to work with.

That covers the start of the live streaming workflow, beginning with content production. There are similar options at the end of the chain. A live stream has to be available to watch somewhere, from a social media page to a hosted website or a custom smartphone app. You may need custom player development, and for monetization, a platform that can run subscriptions or transactions, or a relationship with an ad decision server. Again, there are lots of options and a big range of costs depending on the options that are chosen. So again, let us just say, there will be a cost, and that cost can match whatever budget you give to it.

What I will cover is everything in between producing the content and the platform on which that the content will be watched. This includes the cost of running AWS services that process, package, and distribute a live video stream, namely AWS Elemental MediaLive, AWS Elemental MediaPackage, and Amazon CloudFront. I’ll also see what affects the cost, and the potential return on investment when the stream is monetized with AWS Elemental MediaTailor.

Now to the first round of questions that need answering.

The first set of questions fall into two categories: those that can be stated definitively, based on requirements, and those that are estimates, targets, or assumptions. The stated answers are decisions about the encoding parameters of the live stream, the level of redundancy required, and the range of target devices. Although these may change, they will have a fixed value for a fixed decision. The estimated answers are around audience size, average quality the audience will get when watching, and cache/hit ratio (or egress factor; I’ll explain these terms later) that CloudFront or another CDN will achieve. These all have variable values and although a certain combination of values will give a predicable result, is it almost impossible to predict all the values in advance.

Now we know the what needs answering, let’s build an example.

Of the stated answers that are required, for this example, we’ll assume the requirement is to target a range of devices, including smartphones, tablets, computers and connected TVs. The contribution video stream to AWS will be a 1080p HD feed encoded at a bitrate of 15 Mbps using the AVC codec. For ABR (Adaptive Bitrate) encoding, we will use the Apple-recommended TN2224 HLS parameters, which are available as a preset within AWS Elemental MediaLive. This produces the following outputs:

We will use MediaLive’s built-in regional redundancy for a Standard channel, and will not run any addition channels to increase that level of redundancy. With these decisions made, we can start to work out some costs.

The hourly cost for running a MediaLive standard channel with this configuration in the US East (N. Virginia) region is $4.872 per hour with On-Demand pricing.

This hourly cost is stable for this configuration. One option that can reduce the cost, if the channel is going to run 24×7, is to create reservations for the input and outputs. With a 12-month commitment, the hourly rates are discounted, and the total cost of running the channel drops to $1.1794 per hour. For a 30-day month, that is a reduction from $3,505.84 using On-Demand pricing to $849.17 for reserved. Another option, is to run a Single-pipeline channel, this reduces the the rates for both on-demand and reserved pricing, but means the live channel will only have a single input, encoding pipeline, and output, instead of the dual set-up of a Standard channel. The cost for this configuration as a Single-pipeline channel would be $2.923 per hour for on-demand, or $0.0716 per hour for reserved pricing ($515.59 for a 30-day month).

Next, we’ll look at packaging and origination for the live channel using AWS Elemental MediaPackage. The first half of this cost is easy to work out, as we already have the information we need from the decision about encoding parameters.

The total for data per hour for a one live channel output is 11.76 GB. MediaLive provides two sets of outputs per standard channel for redundancy, so the total output for the live channel doubles to 23.52 GB. The hourly cost for ingesting this live channel into MediaPackage in the US East (N. Virginia) region would be $0.9408 per hour (23.52GB * $0.04).

We now have the cost of encoding the live channel with MediaLive and ingesting it into MediaPackage as $5.813 per hour. If no one was watching the channel, we could stop here with our pricing. But that’s not practical, so now we have to move on to the areas that require estimations.

Adding in estimated costs for audience watching the stream

The cost of packaging, origination, and distribution are related to the volume of data being served, which is in turn related to the total audience for the live channel, and the quality (or bitrate) that they are viewing. To get to an answer that can be used to at least model and estimate cost, a target or prediction needs to be made. This can be informed by data from existing or past channels to see what the historic average audience size is, and the average bitrate that audience gets.

The prediction I’ll use is for one hour, with an average of 5,000 viewers watching at an average of 4 Mbps. This would mean a total egress of 8,789.06 GB per hour.

This means the cost for Amazon CloudFront distribution within the US would be $747.07 (8,789.07 * $0.085). (A small note here that other CDNs can be used to distribute live streams and will probably have a rate per GB similar to CloudFront. If another CDN is used, the cost of data transfer out of AWS would need to be added to the total calculation of cost.)

To predict packaging and origination costs we have to go to the previously mentioned cache/hit ratio or egress factor values. This will provide a way to estimate cost by working out expected data being sent from AWS Elemental MediaPackage, either as a percentage of total egress from CloudFront (cache/hit ratio) or a factor of the total ingest to MediaPackage (egress factor).

If CloudFront delivers 100GB in video content to end viewers, and MediaPackage packages and originates 5GB, the cache/hit ratio is 95% (5% of the total served).

If MediaPackage ingests a total of 1GB in an hour, and packages and originates 5GB, the egress factor is x5 (potentially 5 copies of everything that is ingested in a single packaged format, or 2 copies of 1 packaged format and 3 copies of another packaged format). This may be the hardest thing to predict. The volume of concurrent viewers, the rate they join, the variety of devices they use, the range of network conditions they are using to connect, and where in the world they are watching from (geographic location) — all these things affect the ratio/factor and have an impact on the resulting cost. For this example, I’ll show the calculation with an estimated cache/hit ratio of 99%, or an egress factor of x7.5.

The cost for MediaPackage for packaging and origination in the US East (N. Virginia) region would be:
Using a 99% cache/hit ratio, $4.3945 per hour. (1% of total egress 8,789.06GB = 87.89GB * $0.05 = $4.3945/hour)
With an egress factor of x7.5, the cost would be $4.4095 per hour.(Total ingest onto MediaPackage 11.76GB * 7.5 = 88.19GB * $0.05 = $4.4095/hour)

A short aside here to explain the how these values could vary: The values I chose represent a shortened event-based channel, expecting a high number of concurrent viewers and potentially more requests that need to be fulfilled by the origin. This means the egress factor increases as the origin has to work harder, but the cache/hit ratio remains high as the percentage of total egress is still low. For a 24×7 linear channel, the average audience size would be lower (distributed across a whole day). The average bitrate would likely be lower too, as would the cache/hit ratio. I’d suggest an average audience of 1,000, at an average bitrate of 3.3mbps and a cache/hit ratio of 98%. This scenario would work out closer to an egress factor of x2.5. This highlights the importance of trying to get some historical data and modeling predictions to match the type of stream and corresponding changes in the values for audience size, average bitrate and cache/hit ratio.

What we have worked out so far

We now have a more complete view of cost for a live channel with input of 15 Mbps 1080p AVC is encoded into the Apple-recommended TN2224 HLS parameters with AWS Elemental Media Live and ingested into AWS Elemental MediaPackage. MediaPackage formats and originates the video content, and Amazon CloudFront handles distribution, with a cache/hit ratio of 99%/x7.5 egress factor, to an average of 5,000 viewers watching at an average of 4 Mbps. The total cost in the US East (N. Virginia) region for this is $761.94 per hour.

It is clear that the largest part of the cost is based off estimates, which can be a challenge when trying to predict costs up-front, but the costs are directly linked to the popularity of the stream.

Another very important note here is that the Amazon CloudFront and MediaPackage costs are based on published on-demand pricing. Significant discounts are offered when you commit to a monthly usage level of 10 TB or higher for 12 month or longer. If you commit to higher levels of usage, you receive additional discounts. These discounted rates are not published like the MediaLive reserve rates, so you can contact us if you are interested.

Monetizing your channel

Next, I want to look at how you could monetize the channel, what the cost implications are, and what the revenue potential is. I’ll focus on advertising as a way to monetize content, but a transactional model (such as a pay-per-view platform for live events) or a subscription model (paying for access to a live channel) are also options. The good news with using an advertising model is that some of the estimates we made to predict the costs will also help predict potential revenue, and the revenue, like the cost, will be directly linked to how popular the stream is.

First, we need more concrete values for the number of ads that will be inserted per hour, and the CPM rate, which is the revenue that will be generated per 1,000 ad impressions reported. As I mentioned before, I will not cover the cost of maintaining a relationship with an advertising provider, something that has to be taken into account for the big picture. Here I’ll focus on the cost of AWS Elemental MediaTailor, which is used to insert targeted ads into live video when the appropriate ad markers are in the video stream, and the revenue generated from the ad impressions (which MediaTailor will report back to the ad provider). For this solution to work, the live stream needs to have markers embedded to signal when and how long the ad break should be.

I will assume a conservative 28 ads per hour (which equates to 14 minutes of ads if each is 30 seconds long). With more ads but in shorter duration (such as 15 seconds), the total ad duration per hour would drop, but total number of ads would remain the same. I’ll also assume a CPM of $10.00 ($10 per 1,000 ad impressions). This can vary greatly and will be based on the agreement with the ad decision server and the type of content; for example, premium sport content would merit higher rates. I will keep the estimate of an average of 5,000 viewers, which works out to a total of 140,000 ad insertions per hour.

MediaTailor prices are $0.75 per 1,000 ads inserted, so the cost per hour would be would be $105.00 (140,000/1,000 * $0.75).

The revenue for generated by the ads would be $1,400.00 (140,000/1,000 * $10.00).

So now we have an almost complete forecast for cost and revenue, bearing in mind the assumptions made about audience size, the average bitrate they will be watching, and the cache/hit ratio or egress factor between AWS Elemental MediaPackage and Amazon CloudFront. Here are the totals:

Conclusion

Overall, we can break the cost of this live streaming workflow into three parts: One is the fixed cost of encoding and ingesting the stream. Two, the cost of packaging and origination and distribution. And three, the cost of ad insertion. The highest proportion of this cost is distribution, with the assumption of an average of 5,000 viewers watching at an average of 4mbps. If this assumption is reduced, the cost will be reduced. For example, changing the assumption to 500 viewers at an average of 3mbps (with the same cache/hit ratio) reduces packaging and origination cost to $0.33 and distribution to just $56.03. Distribution is still the biggest portion of cost, but now much lower. Of course, this also affects potential revenue, as a smaller audience will reduce cost, but also reduce the number of ad impressions. So, that smaller audience will only generate $140 of gross revenue, or a net revenue of $67.33. Naturally, a successful stream, with advertising-based monetization, is a good thing.

Putting distribution costs aside, the value of the roles played in the workflow by AWS Elemental MediaLive and MediaPackage should not be underestimated. MediaLive provides redundant inputs, dual encoding pipelines and redundant outputs as standard. MediaPackage provides redundant ingest points with a scaleable egress, options for encryption and DVR-like features, and that’s only part of the feature set.
As I’ve said, the cost for MediaLive can also be significantly reduced if streams are required 24×7 by using reserved pricing so rates go down the more the service is used. Single-pipeline channels can be used to reduced costs event more.

I have explained where the costs are for this portion of the live streaming workflow using AWS, and how to estimate what actual cost might be. Next time, I want to dive deeper into what you are actually getting for your money, with a look at the benefits that the AWS Elemental Media Services provide to offer great value with broadcast-grade quality, reliability, and features.