A 24/7 stream sent from an Amazon EC2 instance to YouTube is internet data transfer out from AWS. You can estimate its traffic volume from the configured bitrate, but you cannot turn that estimate into a reliable monthly bill without the source Region and your account’s aggregated transfer usage.
For a 30-day month, a continuously sustained 10 Mbps stream carries about 3.24 decimal TB before protocol overhead; at 12 Mbps, it carries about 3.888 decimal TB. Those are volume estimates, not AWS charges. The price depends on the applicable AWS schedule and how much of any account-wide allowance or tier your other services have already used.
The stream is outbound from EC2
For the stream in question, the important data path is the encoder on EC2 sending its video and audio feed to YouTube’s ingest endpoint. The bytes leave AWS for the public internet, so the relevant AWS pricing category is data transfer out (DTO) to the internet. The stream direction is determined by where the data originates, not by the fact that viewers eventually watch it online.
This distinction is useful when you read a bill or enter usage into a calculator. Select the outbound internet transfer flow for the EC2-originated feed, rather than treating it as a download to the instance. If EC2 only sends one feed to YouTube, the calculation starts with that single outgoing feed.
YouTube’s live encoder settings give recommended ingest bitrates by resolution, frame rate and codec. They are setup guidance, not a promise that your encoder emits exactly that amount of traffic every second. Your estimate should use the bitrate you actually configure and sustain.
Outbound transfer is not internet ingress
Internet ingress is traffic arriving at AWS from the public internet. AWS’s global infrastructure FAQs say AWS does not charge for inbound data transfer. That does not mean a stream uploaded from EC2 to YouTube is free: the outgoing direction is the one to investigate for this use case.
It is easy to mix the two directions up because the encoder is “uploading” to YouTube from the application’s point of view. From AWS’s point of view, however, the source is inside AWS and the destination is outside it. The relevant question for this part of the bill is therefore how much data leaves the AWS Region, not how much the YouTube account receives.
The traffic can be bidirectional at the network level: connections have acknowledgements and control messages. The main media payload still travels from EC2 to YouTube. A bitrate-based estimate is a practical starting point for that payload; a precise measured transfer total can differ because of transport overhead and other traffic.
Estimate traffic from bitrate and run time
A bitrate is a rate, while AWS meters transferred bytes. To estimate the volume, multiply the sustained bitrate by the number of seconds the stream runs, divide by eight to convert bits to bytes, and convert bytes to the unit you want. For a 30-day month, this simplifies to approximately bitrate in Mbps × 0.324 = decimal TB.
The simplified formula assumes the configured bitrate continues without interruption for the whole month. It uses decimal terabytes, where one TB is one trillion bytes. It does not include protocol overhead, and it is not a claim about AWS’s measurement or rounding. If you use binary units such as GiB or TiB, label them as such rather than treating them as identical to decimal units.
Use the encoder’s video setting as the starting point, but remember that an actual stream includes audio as well as video and the transport that carries them. Some encoders target a constant bitrate; others vary their output. The best input for a careful estimate is the sustained bitrate shown in your encoder or a measurement of the outgoing interface over a representative period.
If you are deciding between encoding approaches, the practical trade-offs around looping content and encoder control are covered in the guide to GStreamer versus OBS for prerecorded YouTube Live video. The choice of software does not alter the basic arithmetic: if one stream leaves EC2 at the same sustained bitrate for the same duration, its estimated payload volume is similar.
A 24/7 bitrate example
YouTube’s official recommendations include H.264 at 10 Mbps for 1080p30 and 12 Mbps for 1080p60. Applying the 30-day formula gives the following approximate traffic volumes. These are arithmetic from the bitrate and duration, not published AWS measurements or charges.
| Example configuration | Sustained bitrate used | Approximate volume in 30 days |
|---|---|---|
| 1080p30 H.264 recommendation | 10 Mbps | 3.24 decimal TB |
| 1080p60 H.264 recommendation | 12 Mbps | 3.888 decimal TB |
For instance, a channel that runs at the 10 Mbps scenario day and night should plan for roughly 3.24 decimal TB of stream payload in a 30-day period, before overhead. The 12 Mbps case sends about 20 per cent more data than the 10 Mbps case because the rate is higher by that proportion. Neither figure says what the bill will be.
The same reasoning applies to another bitrate: multiply its Mbps value by 0.324 for a 30-day decimal-TB estimate. If your stream runs for fewer than 30 days, use the actual operating seconds instead. YouTube recommends other rates for other resolution and frame-rate combinations, so check the table rather than assuming every channel should use one of these two examples. A bitrate guide for slow internet in India can help frame the trade-off between a rate your connection can sustain and the quality you want to send.
Do not multiply this EC2-to-YouTube figure by your audience size. YouTube says it transcodes an incoming live stream into output formats for viewers to watch across devices and networks. The EC2 encoder sends one ingest feed; YouTube’s viewer delivery is a separate leg and is not additional EC2 upload for every viewer.
Find the source Region and account-wide usage
AWS says data-transfer charges are based on the source Region. The Region where your EC2 instance sends the stream therefore matters when you price the outbound transfer. A universal monthly dollar estimate is unsound if the Region is unknown, because the applicable schedule can differ.
The account’s wider usage matters as well. AWS describes a monthly 100 GB free internet DTO allowance aggregated across AWS services and Regions, with exceptions for China and GovCloud. The allowance is not necessarily untouched just because this EC2 stream is the only workload you are thinking about: other AWS services or Regions may already have consumed some or all of it. AWS also aggregates DTO usage across multiple services for its applicable tiers.
Before estimating, note the EC2 source Region and check the account’s usage across AWS services and Regions for the billing period. Do not subtract the full allowance from the stream estimate unless you have verified that the allowance is available to this usage. Similarly, do not assume the stream alone determines which aggregated tier applies.
If you use a cloud host specifically to keep a recorded class available all day, the article on cloud services for 24/7 recorded classes offers a broader operating-options context. For this question, keep the AWS Region and aggregate DTO usage in view even when comparing hosting methods: a transfer estimate only becomes a cost estimate once it is matched to the correct account and pricing conditions.
Separate the traffic estimate from the AWS bill
The volume formula answers how much data the configured stream may send. The bill calculation is a separate step: take the estimated outbound volume, apply the current EC2 internet DTO pricing for the source Region, and account for any unused portion of the relevant aggregate allowance and applicable tier. The EC2 pricing page is the primary place to check the current schedule; the AWS Pricing Calculator lets you enter a Region and monthly usage by transfer flow.
A calculator result is only as useful as its assumptions. Enter the correct Region and outbound internet transfer, then represent the stream’s monthly usage and the rest of the account’s relevant DTO usage as accurately as you can. If you do not know the latter, treat the result as a scenario rather than a forecast. Review the bill after the first operating period and compare actual transfer with the estimate.
Do not take a cost example for a different AWS architecture and apply it to a single stream ingest. AWS’s live streaming on AWS planning guide describes a different kind of deployment that can include distribution to viewers. A system that serves video directly to viewers from AWS has additional transfer paths and potentially different services involved. Its costs are not a proxy for EC2 sending one feed to YouTube.
Likewise, a percentage difference between two bitrate scenarios translates into a corresponding difference in payload volume only under the stated assumptions. It does not guarantee the same percentage difference in the bill: allowances, pooled usage and tier boundaries can affect the marginal charge. For a reliable decision, keep the raw volume calculation and the Region-specific pricing calculation as two separate lines in your notes.
Account for variation and extra traffic
A configured bitrate is a useful baseline, not a meter reading. The actual amount transferred can differ because audio, transport protocol, connection behaviour and encoder output contribute bytes beyond a nominal video bitrate. If the encoder is set to constant bitrate, its output is closer to the scenario assumption than if it varies widely, but actual network totals still include overhead.
Allow for other traffic from the instance or account. Software updates, monitoring, file downloads, backups or a second stream can create additional traffic. Some data paths may be priced differently from internet DTO, so do not add every byte on an AWS network to this estimate without checking its flow and service. Focus first on the public-internet upload from the EC2 encoder to YouTube.
For a more grounded estimate, record the encoder’s configured rate, planned run hours, source Region, and measured outgoing bytes over a representative period. Then calculate a monthly scenario and compare it with the AWS bill after the stream has run. This is especially useful if you are changing resolution or frame rate: the OBS bitrate and preset guide for a 24/7 YouTube stream on a VPS can inform encoder choices, while AWS billing still depends on the actual Region and aggregate account usage.
If the stream pauses, the monthly total will be lower than a full 30-day continuous scenario, but do not simply assume that short interruptions materially change the bill without measuring. Conversely, restarting a stream or changing its quality does not remove the bytes already sent. Keep the observation period long enough to reflect normal operations, and use a buffer in your own estimate for overhead rather than presenting the formula as exact.
A stream that you run from your own computer has a different practical burden: the computer and connection need to remain available, and interruptions need attention. For a recorded programme, StreamNeo removes that particular need to keep your own computer running by taking an uploaded file and maintaining the YouTube broadcast for you. This does not change the AWS billing method for an EC2 stream, and it should not be read as covering EC2 data-transfer charges.
What to check before estimating
Use this checklist before treating a figure as a budget input:
| Check | Why it affects the estimate |
|---|---|
| Configured sustained bitrate | Sets the starting point for payload volume |
| Resolution, frame rate and codec | Determines the relevant YouTube ingest recommendation and chosen rate |
| Hours streamed in the billing period | A 30-day continuous run differs from a shorter schedule |
| EC2 source Region | Determines which regional DTO schedule to consult |
| Other account and service DTO | Affects available aggregated allowance and applicable tier |
| Other instance traffic | Can add bytes beyond the stream feed |
| AWS pricing calculator assumptions | Ensures the cost scenario uses the relevant flow and usage inputs |
Keep a note of when you checked the pricing information and the assumptions you entered. AWS pricing can change, and an estimate made with one month’s account usage may not apply to another. This is why an answer such as “a 24/7 YouTube stream costs a fixed amount per month” is not a sound general answer: it mixes a predictable traffic calculation with pricing inputs that are specific to the account and source Region.
When the operating choice is still open, compare the cost of the whole arrangement, not just the estimated transfer line. Instance compute, storage, monitoring, backups and any distribution beyond YouTube may be separate items. Keep those outside the EC2-to-YouTube DTO estimate unless you explicitly add them to a broader budget.
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 an EC2 stream to YouTube count as inbound or outbound data?
It is outbound internet data transfer from AWS because the EC2 instance originates the media feed and sends it to YouTube. Internet traffic entering AWS is a different direction and AWS says inbound transfer is not charged.
How much data does a 10 Mbps stream use in a month?
At a constant 10 Mbps for 30 days, the estimate is about 3.24 decimal TB, excluding protocol overhead. It is a traffic-volume calculation, not an exact measurement or an AWS bill.
Do more YouTube viewers increase EC2 transfer for this setup?
No, not for the single EC2-to-YouTube ingest feed described here. YouTube transcodes the incoming stream for viewers; a separate AWS distribution design would be a different cost calculation.
Why is there no fixed monthly dollar amount here?
The source Region affects the applicable DTO pricing, and AWS aggregates usage across services and Regions when applying the stated allowance and tiers. Without those account details and current pricing inputs, a universal monthly amount would be misleading.