If a virtual machine sends one continuous feed to YouTube, its outbound traffic is the stream feed, not a separate copy for every viewer. Amazon EC2 and Hetzner Cloud can both host that kind of workload, but neither is a universal cost or performance winner: the answer depends on where encoding happens, the chosen region and instance, transfer terms and how you recover from failures.
First decide whether you need an ingest sender or a viewer-delivery platform. For a simple file-based channel, YouTube’s own transcoding usually means you should compare the VM-to-YouTube feed, not multiply traffic by audience size. If your server also delivers video to viewers, that is a different architecture and a different cost calculation.
Start by drawing the traffic path
An ingest-only VM has one job: send a live feed to YouTube. A typical path is a video file or encoder, then the VM, then YouTube’s ingest endpoint. Viewers watch on YouTube, rather than connecting to the VM. Under that design, the VM’s outbound transfer is driven mainly by the continuous feed and its operating time.
A delivery architecture has more steps. An encoder sends a source feed to an origin or media service, which may package or transcode it, and a content delivery network distributes it to viewers. In this design, audience size and viewing time can drive substantial outbound delivery traffic. AWS’s live video architecture guide describes a broader pattern using MediaLive, storage or packaging, and CloudFront. It is not the same thing as renting EC2 to push one stream to YouTube.
The distinction matters if you are looking at a bill or trying to estimate one. For an ingest-only channel with no viewer-facing service on the VM, do not calculate VM egress by multiplying the feed by your YouTube audience. That audience watches YouTube’s delivery of the live stream. If your VM is also an origin, relay to other platforms, or serves playback directly, map those paths separately before estimating traffic.
Write down the path before comparing providers: where the file is read, where encoding happens, which endpoint receives the feed, and who serves playback. A devotional channel that loops a prepared video through YouTube is a different workload from a local news operation that also provides a separate web player. A clean diagram often settles the bandwidth question before you look at a pricing table.
YouTube handles viewer formats in an ingest-only setup
YouTube says it automatically transcodes a live stream into multiple output formats so people on different devices and networks can watch. In an ingest-only setup, you provide an incoming stream; YouTube creates the viewer-facing versions. You do not need to build an EC2 or Hetzner delivery network merely because your audience uses phones, televisions and slower connections.
That does not remove the need to choose sound encoder settings. YouTube recommends RTMPS for RTMP streaming and lists H.264, H.265/HEVC and AV1 as supported options in its encoder settings guidance. It recommends a two-second keyframe interval and says not to exceed four seconds. Follow the bitrate guidance for the selected resolution, frame rate and codec rather than assuming every channel should use the same setting.
For example, YouTube’s table recommends 12 Mbps for H.264 at 1080p and 60 fps, and 10 Mbps for H.264 at 1080p and 30 fps. Those figures are settings guidance for those specific rows, not a guarantee of quality and not a general traffic estimate for other codecs or resolutions. A higher feed bitrate means more data sent from the VM to YouTube, so it affects the sender’s monthly transfer calculation.
If the VM encodes the source, CPU capacity becomes part of the question. The workload depends on codec, resolution, frame rate and how many concurrent outputs you are creating. If you send an already encoded file or feed and only relay it, the compute needs may be different. The available research does not establish equivalent performance for particular EC2 and Hetzner sizes, so test the configuration you intend to run rather than infer it from a product name.
Compare the same job, not the provider names
A fair comparison puts like-for-like designs beside one another. Compare EC2 with a Hetzner Cloud server for the same role: encoding, relaying or both. Do not compare a single VM on one side with a full AWS media and delivery chain on the other unless you are intentionally comparing two different architectures.
| Decision point | Amazon EC2 | Hetzner Cloud | What to verify |
|---|---|---|---|
| Compute role | VM can encode or relay; AWS also offers separate media services | Cloud Server can host an encoder or relay | Whether encoding happens on the VM and which outputs are required |
| Region | Instance choices and prices vary by region | Available locations and terms depend on the selected product and location | Source location, route to YouTube ingest, and operational constraints |
| Transfer | Internet transfer out is separately relevant; AWS allowance and rates have terms | Product page advertises included traffic, subject to product terms | Included amount, excess rates, direction and applicable plan |
| Recovery | You design monitoring and restart behaviour for your workload | You design monitoring and restart behaviour for your workload | What detects a stalled stream, and who or what restarts it |
| Wider media stack | Can be composed with AWS media and delivery services | Compare the Cloud Server workload, not an assumed equivalent managed pipeline | Whether you actually need packaging or viewer delivery |
EC2 is worth examining if you already use AWS, want to compose the VM with AWS services, or have a reason to keep compute near other parts of an AWS design. That flexibility comes with choices to price and configure. EC2 alone is not the same product as AWS’s managed live-video architecture, and adding media or delivery services changes both the design and cost drivers.
Hetzner is worth examining if a Cloud Server with its advertised included traffic fits the workload and the available location suits your route. Its product information is not a matched quote for every region, size and transfer pattern. Check the terms for the exact server and location you would use, rather than treating a headline allowance as proof that a particular always-on stream will fit.
In either case, match the operating system, CPU and memory, storage, uptime and recovery design. If you are using Linux and FFmpeg, the practical choices resemble those in a VPS-based YouTube streaming setup. If you are using OBS to send a prerecorded feed, the OBS-to-YouTube setup guide can help you pin down the sender role before pricing the machine.
Pin down runtime, region and instance terms
A 24/7 channel runs for nearly the whole billing period, so use the runtime you actually intend to keep. A test machine that runs only while you configure it is not a useful price proxy for a continuously running sender. Check whether the chosen instance is billed by the hour or another unit, what happens when stopped, and whether attached storage or other services continue to incur charges. Do not assume compute is the only line item.
Instance choice depends on whether the VM encodes video. If the source is already encoded, a relay may need less compute than a software encoder working continuously at a demanding resolution and frame rate. Conversely, a small instance chosen only by memory can struggle if it must encode. The correct way to assess that difference is to run the intended codec and output settings under load, then watch for dropped frames, CPU saturation and thermal or memory pressure where applicable. Do not treat a successful short preview as evidence that a full-time process will behave identically overnight.
Region selection is not just a map exercise. Consider where your input file or source is, which route the stream will take to YouTube’s ingest service, whether a human operator needs access, and any data-location requirements you have. For an ingest-only channel, the viewers’ locations do not automatically dictate where the sender VM must sit, because YouTube serves the playback. For a separate delivery system, viewer geography becomes central to the delivery design.
AWS’s pricing depends on instance family and size, operating system, region and runtime, with internet transfer out priced separately. AWS describes 100 GB per month of internet transfer out as free in aggregate across eligible services and regions, subject to exclusions including China and GovCloud. The allowance is not a separate 100 GB for each EC2 instance. The Ohio pricing table in the research lists outbound internet transfer at $0.09 per GB for the first 10 TB per month, with lower tiers above that; verify the current rate and the applicable region on AWS’s data transfer pricing page.
Hetzner’s product page advertises included traffic, but the applicable volume and any excess terms depend on the product and location. Its Cloud and vServer agreement describes a 99.9% monthly availability effort measured for an individual Cloud Server, with defined terms and exclusions. That is not an end-to-end promise that a YouTube broadcast will remain live; the stream also depends on your encoder, the route and YouTube’s service. Read the Hetzner service agreement for its actual scope before relying on the figure.
Prices and product terms change, and no matched current quote has been established here for a particular EC2 and Hetzner configuration. At the point you decide, record the region, size, operating system, storage, expected runtime and transfer treatment for both providers. Price the same workload from each vendor’s current calculator or product pages; a generic headline instance price cannot settle the comparison.
Estimate transfer for the feed, not the audience
For an ingest-only VM, estimate outbound transfer from the selected stream bitrate and the time it runs. As a rough calculation, a continuous 12 Mbps feed sends about 5.4 GB per hour before audio and protocol overhead. That comes from converting megabits to megabytes and multiplying by an hour; it is an estimate, not a vendor quote. At 10 Mbps, the equivalent is about 4.5 GB per hour before overhead. Use the bitrate you have selected, not a viewer count.
To make a monthly estimate, multiply the hourly transfer estimate by the hours the channel runs, then allow for audio, transport overhead, reconnects and any other traffic the VM generates. A loop that is stopped for maintenance will send less than a truly continuous feed, while a higher bitrate sends more. Keep the assumptions visible in a worksheet so you can update them when the channel’s settings change.
Then compare the estimate against each provider’s current transfer terms. AWS’s free transfer amount is aggregated across eligible services and regions, so other outbound use in your account can consume part of it. The cited Ohio tier is an example from that region’s pricing table, not a global EC2 rate. Hetzner’s included traffic should be checked for the exact server location and plan, including what happens when the allowance is exceeded.
Do not reuse the same calculation if the server serves viewers. If a separate origin or CDN delivers playback, estimate viewer traffic from the number of viewers, watch duration, selected rendition and caching or packaging design. AWS’s live-streaming guide includes an illustrative one-hour, 1,000-viewer SD event where distribution is a large part of the stated cost. That is an example of a managed delivery architecture under its stated assumptions; it is not a cost estimate for sending an ingest feed from EC2 to YouTube.
Test the network path and stream health
A pricing comparison tells you little about whether the stream will survive an ordinary night. Before committing, run the actual file or encoder settings from the intended region and check YouTube Studio’s stream health. Look for dropped frames, bitrate instability, ingest interruptions and encoder warnings. A test from your office or home network does not prove that a cloud VM in another region will have the same path.
Check that the sender reconnects when the upstream connection is interrupted, and that the process starts again if it exits. Keep logs that show when the encoder stopped, why it stopped and whether it resumed. If you rely on a human to notice a frozen stream, decide who receives the alert and what they can do at the time it arrives. Monitoring a process is not the same as confirming that YouTube is receiving a healthy picture and sound.
Use a controlled test to see what viewers actually receive: video, audio, loop continuity and any intermission or file-end behaviour. You can review the stream later using YouTube’s DVR controls, but remember that DVR settings and viewer controls do not repair an interrupted ingest feed. If you use a playlist, confirm that transitions do not leave a blank interval or stop the broadcast.
Treat availability commitments as one input, not your recovery plan. Hetzner’s contractual availability language is scoped to its Cloud Server and has exclusions; it does not cover every link between a file, encoder, YouTube and the viewer. The research collected no directly comparable EC2 commitment for this article, so do not infer equivalence or superiority. For either provider, decide how you will detect a failure, restart the process and verify that the live event has resumed.
Choose only after the architecture and costs match
For a straightforward channel in which one VM sends one feed to YouTube, compare the cost of that VM, storage, and its feed transfer under the provider’s current terms. A useful decision sheet has a row for region, instance size, OS, disk, runtime, encoding mode, bitrate, estimated outbound transfer, recovery method and any other services. If a value is unknown, mark it unknown rather than filling it with a guess.
Choose EC2 if its regional instance choices and integration with services you actually need make the design fit, and the full set of charges is acceptable. Choose Hetzner if the available Cloud Server and its traffic terms fit your workload and operational constraints. Either can be a poor fit if the instance is underpowered for encoding, the chosen location makes operations awkward, or recovery is left to chance. There is no winner independent of the requirements.
If you need a playback origin and viewer delivery, price that architecture separately. AWS’s documented path using MediaLive, MediaStore or MediaPackage and CloudFront is a service composition, not a like-for-like substitute for an ingest VM. A separate CDN or managed media chain can be appropriate when you need to serve viewers yourself, but it introduces service configuration and cost drivers that are absent from YouTube-only playback.
If the source is a prepared file and the painful part is keeping a computer switched on and the broadcast process running, a managed route can remove that operational task. StreamNeo turns an uploaded video into a YouTube live stream, so you do not have to keep your own computer running for that file-based channel. It does not change YouTube’s ingest settings or make rights questions disappear; check YouTube’s current policies for your content and format.
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 YouTube charge the VM for each viewer?
Not in an ingest-only setup where the VM sends the feed to YouTube and does not distribute playback itself. YouTube says it transcodes the incoming stream into multiple formats for viewers. If your own origin or CDN serves viewers, estimate that separate delivery traffic on its own.
Is EC2 always more expensive than Hetzner Cloud?
There is no universal winner. EC2 cost depends on instance, operating system, region, runtime and transfer out, while Hetzner terms depend on the Cloud Server and its location. Compare current prices for the same workload and include the services and transfer your design actually uses.
Does Hetzner’s 99.9% figure mean my live channel is guaranteed to stay online?
No. The agreement defines a monthly Cloud Server availability effort for an individual server, with scope and exclusions. A live channel also relies on the sender process, network path and YouTube, so you need monitoring and a recovery plan.
Should I use EC2 for an encoder or a relay?
It depends on the work the VM must do. Encoding demands depend on codec, resolution and frame rate; relaying an already encoded feed is a different job. Test the exact settings on a suitable instance, then compare the resulting compute and transfer costs with the equivalent Hetzner setup.