A small general-purpose Google Compute Engine VM is a sensible starting hypothesis when it only relays an already encoded stream to YouTube. For that workload, benchmark an E2-standard-2 against your real feed, then increase the size only if measured CPU, memory, restart behaviour or outbound throughput leaves too little headroom.
There is no Google-certified VM size for every 24/7 YouTube channel. The right choice depends first on whether the VM forwards encoded video or processes it, and then on the codec, resolution, frame rate, bitrate, number of outputs and operating requirements.
Start by identifying the workload
A relay receives an encoded feed and sends it onwards to YouTube. It does not decode every frame, apply overlays, resize the picture or create a new video stream. The VM is mainly moving bytes and keeping the streaming process alive.
An encoder is different. It takes images from a camera, video file or scene, compresses them with a codec and sends the result to YouTube. A transcoder may decode one format and create another resolution, frame rate or bitrate. Compositing, subtitles, scene changes and multiple simultaneous outputs add more processing as well.
This distinction is more useful than beginning with a machine-family chart. A devotional channel that has already prepared an H.264 file and needs one continuous feed has a different workload from a local news channel that combines several sources, adds graphics and creates multiple outputs.
Before choosing a VM, write down these details:
- Is the source already encoded, or will the VM encode it?
- What codec, resolution and frame rate will be used?
- What is the target video and audio bitrate?
- Is there one YouTube output or more than one destination?
- Will the process loop a file, receive a camera feed or assemble several inputs?
- What should happen after a process exits or the input disappears?
For a prepared file, the simplest arrangement is often a relay or a process that reads the file and sends its existing encoded content. If you use FFmpeg, its reconnect and restart behaviour deserves its own test; the FFmpeg reconnect guide for an always-on YouTube stream covers that operational problem separately.
Keep the YouTube stream key private. YouTube describes it as the encoder's password and address, so store it as a secret and reset it if it is exposed. YouTube's official encoder guidance also recommends RTMPS for encrypted ingest where supported.
Use a small general-purpose VM as a starting hypothesis
For one already encoded feed, start by testing an E2-standard-2. This is not a certified answer, a guaranteed result or a claim that every E2-standard-2 will carry your stream. It is a workload-based starting hypothesis: a relay normally needs less CPU than software video encoding, while still needing enough memory and network capacity to run the operating system and streaming process reliably.
The important word is test. A machine label does not tell you how your particular input behaves overnight. A file may have a different bitrate from the sample you used during setup. A reconnect may briefly create extra work. A monitoring agent, disk operation or log-writing process may compete for resources. You want observations from the stream that will actually run, not a conclusion drawn from the VM name.
Google lists maximum egress values for E2 machine types, but those are ceilings rather than promises. Its Compute Engine network-bandwidth documentation says that maximum possible egress bandwidth is not a guarantee. Actual throughput can depend on the destination, packet size, number of flows, driver and congestion.
For a single ordinary YouTube feed, the stream bitrate is usually a more useful first calculation than the headline maximum. If the stream sends 10 Mbps, the VM's outbound requirement is related to that 10 Mbps feed, not to the number of people watching on YouTube. Viewers receive playback from YouTube; the VM sends the ingest stream to YouTube.
For multiple feeds or destinations, add the outbound bitrates together. A primary stream and a backup stream, for example, consume more outbound capacity than either stream alone. Include audio and protocol overhead in your planning, then retain practical headroom rather than operating at the edge of the available connection.
Benchmark E2-standard-2 with the real stream
Run the benchmark with the same source, settings and destination you intend to use in production. If the source is a pre-recorded loop, use the actual file or a representative section with the same codec, bitrate and frame rate. If it is a camera or live input, test the real capture path rather than a quiet substitute.
A useful test should include the ordinary events that cause weak setups to fail:
- Start the process and confirm that YouTube receives data.
- Preview the stream before making it public, following YouTube's testing guidance.
- Let the feed run long enough to observe ordinary CPU, memory and network behaviour.
- Interrupt the input or process and check whether your restart and reconnect plan works.
- Inspect the YouTube stream-health indicators while the VM is under its normal load.
- Record the measurements and any gaps, stalls or process exits.
The purpose is not to produce a laboratory score. It is to answer practical questions. Does CPU remain comfortably below saturation? Does memory remain stable rather than rising throughout the run? Does the process reconnect without manual intervention? Does outbound throughput stay steady when the file reaches a busier section? Does the operating system remain responsive enough for you to inspect it during a fault?
YouTube's streaming tips recommend keeping 20% upload bandwidth available beyond the total stream bitrate, including primary and backup streams. Treat that as planning guidance for the upload path, not as proof that a particular Compute Engine machine will deliver a given result.
A simple record is more valuable than a guess. Note the VM type, region, operating system, source file, encoder settings, measured bitrate, CPU, memory, restart count and observed interruptions. If you later change the region or software, repeat the test because the comparison is no longer like for like.
For channels built around playlists, the failure may be at the hand-off between files rather than in the VM itself. A guide to scheduling a 24/7 YouTube livestream with a VPS playlist can help you examine the playlist side separately from the machine-size question.
When to test E2-standard-4 or another VM type
Move to an E2-standard-4 when measurements show that the smaller test leaves insufficient headroom or when the workload changes. Do not move merely because a larger number sounds safer. A larger VM can increase recurring cost without fixing an unsuitable encoder, a poor reconnect design, an input problem or a network path issue.
Reasons to test a larger general-purpose VM include sustained high CPU, memory pressure, repeated process failures associated with resource exhaustion, slow recovery work or several concurrent relays. If you need more than one output, calculate the combined outbound bitrate and benchmark that combined workload rather than multiplying a single-stream assumption.
You may also need to test another machine type when the bottleneck is not simply more general-purpose capacity. A compute-optimised family may be more relevant for software encoding. A different design may be needed for specialised acceleration, but the correct choice depends on the codec, software and whether that software can use the available accelerator. Do not select a GPU or a machine size from resolution alone.
Network limits need careful interpretation. Google documents E2 maximum egress values that vary by machine configuration. It also explains that general per-instance egress is commonly related to vCPU count, with exceptions by family, and that traffic outside a VPC can face separate limits. Those figures help you identify a possible ceiling, but they do not establish the throughput your YouTube stream will achieve.
For a relay sending one modest feed, network capacity may not be the first constraint. For several high-bitrate feeds, primary and backup paths, or other outbound traffic, it becomes more important. Test the real destination and leave room for variation rather than designing around the published maximum.
Encoding and transcoding change the CPU question
Software encoding repeatedly analyses video frames and compresses them according to the chosen codec and quality settings. Resolution, frame rate, motion, codec, preset and the number of simultaneous outputs all affect the work. A static devotional image and a fast-moving 4K scene may occupy the same file duration but demand different processing from an encoder.
Transcoding adds another layer because the VM may decode an input, transform it and encode a new output. Creating several renditions means repeating or sharing parts of that workflow, depending on the software. A relay benchmark cannot answer an encoding question.
Google identifies media transcoding as a compute-bound workload for C2D. Its compute-optimised machine documentation lists C2D standard configurations across a broad vCPU range, but those published options are not a recommendation for your channel. If the VM will encode or transcode, benchmark a suitable C2D configuration with the actual codec, resolution, frame rate, software and target bitrate.
A proper encoding benchmark should measure completed output and stream health, not just whether the process starts. Check for dropped or late frames, CPU saturation, audio drift, thermal or resource-related instability, and what happens when the process is restarted. If a preset change reduces CPU but harms the picture, that is a quality trade-off rather than a successful capacity test.
GPU acceleration may suit some video workflows, but it is not automatically better. The software must support the chosen accelerator, and the output quality, cost and recovery behaviour still need testing. Without those details, an exact GPU or VM-size recommendation would be guesswork.
If you are deciding between local streaming software and a command-line process, compare the actual workload rather than the interface. The OBS versus FFmpeg comparison for a 24/7 study stream explains why the choice affects operation as well as setup.
Check the measures that matter overnight
CPU is only one signal. During and after the benchmark, check four areas.
| Measure | What to watch | What a warning may mean |
|---|---|---|
| CPU | Sustained use, peaks during transitions and encoder load | The VM may be too small for encoding or concurrent work |
| Memory | Stable usage and available headroom over time | A leak, oversized process or insufficient VM memory |
| Restarts | Process exits, reconnects and recovery time | Supervision or input handling needs attention |
| Throughput | Actual outbound rate, stalls and destination errors | A network path, egress limit or congestion problem |
Also inspect disk use, system logs, clock synchronisation and the health information shown in YouTube Studio. A stream can have acceptable average CPU and still fail when a process reaches the end of a file, changes scenes or loses its input.
Set up process supervision so an ordinary crash does not require someone to log in immediately. Add alerts for a stopped process, missing output, abnormal CPU or memory behaviour and a YouTube-side data problem. Test each alert. An alert that is never delivered is not part of the recovery plan.
YouTube recommends previewing and testing before going live, monitoring stream health and testing encoder failover. For an unattended channel, extend that thinking to the whole operation: document how to replace the stream key, restart the process, restore the input and switch to a backup path.
A separate backup encoder or path can improve resilience, but it also adds recurring resources and another configuration to maintain. Test failover before relying on it. Redundancy is an operational decision, not a reason to claim that any single VM will remain available indefinitely.
Include region, egress and the full cost
The VM type is only one part of the configuration. Google says Compute Engine pricing depends on machine type and region. Attached Persistent Disk or Hyperdisk storage is billed separately, and network transfer can affect the total. Check the current Compute Engine pricing documentation for the exact region, operating system and resources you plan to use.
Do not compare only the hourly machine line. Include the disk, snapshots if used, outbound transfer, monitoring, backup capacity and any duplicate resources for failover. A configuration that looks inexpensive as a single VM may have a different total once the channel needs a second path or stores large media files.
Region can also affect the practical result. It may change network distance, available machine options and pricing. Benchmark in the region you intend to operate, or record clearly that your test used another region and needs confirmation before production.
The same principle applies to bandwidth figures. An E2 listing may show a maximum egress value, but that value is not a guaranteed YouTube upload rate. Use the published ceiling to identify an obvious mismatch, then use an actual stream to learn whether your selected configuration has enough usable headroom.
Choose the operating path, not just the VM
If you already have an encoded file and want control over the operating system, an E2-standard-2 benchmark is a reasonable first experiment. Increase capacity only when the measurements identify a constraint. If the process must encode, transcode, composite or create multiple outputs, begin a separate benchmark with a compute-appropriate configuration rather than carrying over the relay assumption.
If managing restarts, monitoring, stream keys, updates and overnight recovery is the main burden, a managed workflow may remove that particular maintenance task. StreamNeo turns an uploaded video into a YouTube live stream: you upload once, provide the YouTube stream key, and the broadcast continues with your computer switched off, with automatic monitoring and restart if it drops. It is YouTube-only, so it does not replace a workflow or remove the need to check YouTube's current requirements.
Whichever path you choose, keep a written configuration record. Include the source, codec, resolution, frame rate, bitrate, VM or service settings, region, restart method and last successful test. That record makes a later fault diagnosable instead of turning the next overnight failure into a fresh experiment.
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 E2-standard-2 enough for a 24/7 YouTube stream?
It is a sensible starting hypothesis for benchmarking one already encoded feed, not a guaranteed answer. Test the real source and destination, then check CPU, memory, restarts and outbound throughput before treating it as suitable for your channel.
Does viewer count determine the VM's upload requirement?
Usually, the VM sends the ingest feed to YouTube rather than sending a separate copy to each viewer. Estimate outbound demand from the stream bitrate and add the bitrates of any additional feeds or destinations.
Should I use a C2D VM for every stream?
No. C2D is more relevant when the VM performs compute-heavy encoding or transcoding, and Google identifies media transcoding as a compute-bound workload. A relay and an encoder should be benchmarked as different workloads.
Does a published egress limit guarantee a stable stream?
No. Google states that maximum possible egress is not a guarantee, and actual throughput can depend on destination, packet size, flow count, drivers and congestion. Use the documented limit to spot an obvious capacity problem, then verify the real stream in the intended region.