If your Compute Engine VM only relays an already encoded video feed to YouTube, a small E2 general-purpose instance is a reasonable place to begin testing. If it continuously encodes or transcodes video, compare performance-oriented C-series machines and N2D instead; there is no single best machine type for every 24/7 stream.
That distinction matters more than the word “streaming” in the setup description. A relay passes encoded media onwards, while encoding asks the VM to do sustained video-processing work. Choose against the job your VM performs, then use measurements from your own stream to decide whether the starting size is sufficient.
Start with the work, not the machine name
A 24/7 YouTube stream describes an operating schedule, not a Compute Engine workload. The VM might send an encoded feed that another device produced, or it might create that feed by processing source video. Those jobs can put quite different demands on the CPU, memory and network connection.
For a devotional channel, for example, you might already have a finished video file encoded in a format suitable for your streaming workflow. If the VM simply reads that file and relays its encoded output, it is not doing the same work as a VM that decodes the file, resizes it, adds overlays and encodes a new output continuously. A lofi station that switches between pre-encoded clips could likewise have a different processing load from a pipeline that combines and transforms several inputs.
Google’s general-purpose machine guidance describes E2 as suited to lower-cost, modest workloads and lists media streaming and transcoding among the workloads for C-series machines. That is useful guidance for forming a shortlist, not a benchmark for a particular YouTube channel. It does not establish a minimum machine type, a guaranteed stream quality or a universal winner.
Treat the first machine choice as a testable hypothesis. Write down what enters the VM, what processing happens there, how many outputs it sends and what you observe while the channel is running. If your stream drops frames or buffers, do not assume immediately that the VM is too small: the source, encoding settings, network path and YouTube ingest connection may also need attention. The practical checks in this guide to troubleshooting buffering on Indian broadband can help separate connection symptoms from VM sizing questions.
Relay and encoding are different jobs
In a relay-only setup, an encoder has already produced the video and audio stream. The VM forwards that encoded feed to YouTube without changing its video content or encoding parameters. The VM still needs enough resources to run its relay software and maintain the connection, but you should not size it as if it must perform continuous video encoding unless it actually does so.
Encoding or transcoding changes the calculation. Encoding turns source video into a compressed stream; transcoding decodes and re-encodes or otherwise transforms an existing stream, such as creating another resolution or format. Filters, compositing, scaling and multiple output renditions may also add processing. Software encoding can make CPU use sustained rather than occasional, and a setup producing multiple outputs has more work to do than one producing a single unchanged feed.
A useful way to describe your workload is to trace one frame from source to YouTube. Ask whether the VM decodes it, alters it, encodes it, or merely forwards it. If you are not sure, inspect the streaming application’s configuration and its logs or status display. For an FFmpeg workflow, compare the command’s input, filters and output codec rather than relying on the fact that FFmpeg is running. If you use a hardware encoder, the relevant GPU and machine configuration will also matter; a CPU-family comparison on its own may not answer the sizing question. The NVENC settings checklist is a useful companion when the issue is a hardware-encoding configuration rather than relay capacity.
If the stream is mostly pre-recorded material, decide whether the VM needs to encode it at all. Re-encoding a file can be appropriate when its format, bitrate or output requirements call for it, but it adds work that a relay does not. On the other hand, a local news loop with graphics and frequent changes might need a processing pipeline even if its source clips are already encoded. The channel’s subject does not determine the machine family; the media path does.
Use a small E2 as a relay test, not a promise
For a relay-only workload, a small E2 general-purpose VM is a sensible starting hypothesis to test. Google positions E2 as a lower-cost series for modest use cases, and its comparison guidance suggests starting with general-purpose machines when the right family is unclear. Applying that guidance to a YouTube relay is an inference. Google’s documentation does not publish a YouTube relay benchmark or identify a smallest machine type that will work for every feed.
Begin with the smallest configuration that is plausible for your software and operating needs, then watch the actual stream under its normal conditions. Do not leave a test running only while the channel is quiet if the normal schedule includes other software, playlist changes or periods of higher activity. Observe CPU and memory over time, and check that the required outbound connection remains healthy. Keep a record of the configuration and the behaviour you see so a later resize has evidence behind it.
A channel that only forwards one encoded feed may have little reason to pay for substantial CPU capacity that sits unused. But reducing the VM until it is close to saturation can leave little room for bursts, maintenance tasks or an unexpected restart. Leave headroom based on what you observe rather than picking a generic percentage: the supplied Google guidance does not define a CPU threshold for this exact use case.
This is also where it helps to keep the streaming workflow simple. Avoid running an editor, desktop session or unrelated jobs on a relay VM unless you need them. A cloud desktop may be more suitable if you need a visual workspace to operate the stream; the trade-offs are different from a relay process that runs without a desktop. See how a cloud desktop can be used for a 24/7 stream before deciding that a headless relay and an interactive machine are interchangeable.
Compare C-series and N2D for sustained processing
When the VM continuously software-encodes or transcodes video, compare C-series performance-oriented options and N2D rather than assuming an E2 relay test answers the question. Google’s machine-family guide lists media streaming and transcoding among demanding C-series workloads. Google’s own N2D machine type article describes N2D as suitable for video streaming. These are vendor guidelines, not results for your resolution, codec or number of outputs.
The sources do not establish one winner between C-series and N2D for an unspecified stream. Make a comparison using the same source, codec, frame rate, filters and output count that you expect to run continuously. Compare the CPU behaviour and the resulting stream, and confirm that each candidate is available in your chosen region and supports the requirements of the software you will run. A machine family name alone cannot tell you whether a particular configuration will sustain your chosen settings.
If you have not yet decided whether the VM will encode, do not pay for a performance-oriented machine simply because the project is always on. First establish the pipeline. If encoding is essential but CPU remains heavily occupied and the stream cannot keep up, compare larger or different performance-oriented configurations. If CPU is not the constraint, increasing CPU capacity may not fix a problem caused by disk reads, insufficient network throughput, an unstable source or a misconfigured encoder.
For channels that produce several resolutions, one should also consider whether each rendition is generated on the VM or elsewhere. More simultaneous processing can change the amount of work substantially. There is no workload-independent CPU estimate in the cited material, so test with the intended number of outputs rather than extrapolating from a single-output run. If a different architecture or managed media product is better suited to your production needs, weigh its operational features and costs plainly against a VM; the choice is not automatically Compute Engine.
Measure CPU, memory and the connection
Measurement turns a shortlist into a decision. For each candidate, observe the machine while the actual stream runs, not just while it is idle or playing a short sample. Note CPU utilisation and whether it remains high, fluctuates around busy periods or leaves useful capacity available. Relate those observations to encoder status, dropped-frame messages and any playback symptoms viewers report.
Memory use matters too, particularly if the VM runs a desktop, playlist tooling, filters or multiple media processes. Compare used memory and signs of pressure while the full workflow is active. A relay process may be modest in its memory needs, but no source here establishes a universal memory requirement for a YouTube relay. Set a practical baseline from your software and the actual stream rather than copying a number from another channel.
Network use is a separate measure. Check the outbound throughput required by the feed and whether the machine configuration and region can support it. With multiple outputs or a higher-bitrate stream, outbound traffic and throughput deserve more attention. Google’s machine-family and pricing material notes that networking is separate from compute charges, and available throughput depends on the selected configuration. Do not infer a required bitrate or network capacity from the channel being live 24/7; those depend on the stream settings and workload.
Keep a small test record: candidate machine, region, stream settings, observed CPU and memory, network behaviour, and any interruptions or frame warnings. Change one factor at a time where practical. If you resize the VM and alter the encoder in the same test, it becomes harder to tell which change mattered. Revisit the size when the workflow changes, such as adding a new output, overlay or processing step.
A healthy-looking average can hide short periods of contention, while an occasional spike does not by itself prove a larger machine is necessary. Look at sustained behaviour across the normal operating pattern and check whether the channel’s actual output remains acceptable. Neither the cited official guidance nor the available research supplies a benchmark or reliability guarantee for this exact YouTube configuration, so your measured setup is the evidence that matters.
Include disk, network and region in the cost
Compute is only one part of a 24/7 VM’s cost. Google states that disk and network usage are charged separately from machine pricing. A continuously operating stream may also send data out of the cloud, so estimate expected egress from your output bitrate and operating pattern, then use Google’s current pricing information for the region and configuration you intend to use.
Google’s general-purpose pricing page lists machine prices by configuration and region in USD and identifies on-demand as the default consumption model. Prices can change, and the research does not support a total monthly dollar estimate without knowing your region, machine size, disk, egress, stream settings and discount eligibility. Price the complete workload rather than multiplying an hourly compute figure and treating that as the bill.
Also account for the disk that holds your media or operating system. The required capacity depends on whether you keep a single file, a rotating set of clips or other working data on the VM. Disk choice and usage are billed separately; do not assume the machine price includes every storage requirement. If your source media is stored elsewhere, include the way it reaches the VM and any associated data movement in your cost and operational plan.
Google’s sustained-use discount documentation describes discounts and an Always Free quota equivalent to the monthly hours of one e2-micro VM. Check the current terms and eligibility before including either in a budget; do not assume a particular stream workload or machine configuration qualifies for a specific discount. For a channel expected to run continuously, compare the ongoing cost under the billing option you can actually use, not a discount you have not verified.
Region matters for both availability and price, and the stream’s audience location does not by itself settle where the VM should run. Consider the region where the machine type is offered, the route to YouTube ingest, any latency needs in your workflow, and regional pricing. If viewers in India report buffering, investigate the end-to-end path rather than treating the Compute Engine region as the only cause; viewer broadband and YouTube playback are outside the VM’s control.
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
Is a small E2 enough for a 24/7 YouTube stream?
It may be a reasonable test for relaying an already encoded feed, but Google does not publish a minimum E2 size or benchmark for this exact workload. Measure the real stream’s CPU, memory and network use, then resize if the evidence shows a constraint.
Should I use C-series or N2D to encode video?
Compare both when the VM performs sustained software encoding or transcoding. Google lists media streaming and transcoding among C-series use cases and describes N2D as suitable for video streaming, but those statements do not identify a winner for your codec, resolution, frame rate or output count.
Does the machine’s hourly price cover a 24/7 stream?
No. Google bills disk and network usage separately from machine pricing, and network egress can matter for a continuous outbound feed. Check current prices for your region and configuration, and include storage, data transfer and any discount eligibility in the estimate.
How do I know whether the VM needs encoding capacity?
Trace the video from its source to YouTube and determine whether the VM changes or creates the encoded output. If it only forwards an already encoded feed, test it as a relay; if it decodes, filters, resizes or encodes continuously, measure that processing workload and compare performance-oriented machines.