Choose the cloud setup only after you have fixed the feed's resolution, frame rate and bitrate. For a simple prerecorded or lightweight live stream, a small Mumbai virtual machine may be suitable, but the lowest advertised bundle is not automatically the lowest complete cost or a reliable encoder.
The main calculation is bitrate multiplied by time. Compare the instance cost, regional transfer allowance, CPU behaviour, reconnects and archive handling together, then test the exact workload on the actual machine before leaving it unattended.
Define the feed before choosing a VM
Start with the source rather than the provider. A devotional loop made from a finished video has different requirements from a live camera scene, a local news playlist or a channel that overlays changing text. A prerecorded file can often be decoded and sent with modest processing. A live composition with scaling, subtitles, multiple audio tracks or filters may need substantially more CPU.
YouTube's H.264 guidance lists 4 Mbps for 480p at 30 frames per second, 8 Mbps for 720p30 and 10 Mbps for 1080p30. These are starting points from YouTube's encoder settings guidance, not a promise that every source will look good at the same rate.
For a first cloud test, write down these values:
| Feed decision | Example to record | Why it matters |
|---|---|---|
| Source | One finished MP4 loop | Determines decoding and storage needs |
| Output | 720p30 H.264 | Sets the target encoder workload |
| Video bitrate | 8 Mbps | Drives transfer use and YouTube ingest requirements |
| Audio | A fixed AAC track | Adds a small amount of transfer and processing |
| Keyframes | Every two seconds | Matches YouTube's usual recommendation |
| Protocol | RTMPS | Encrypts the contribution feed to YouTube |
YouTube recommends constant bitrate for the documented RTMP and RTMPS workflow, a two-second keyframe interval, and no interval longer than four seconds. If your source is already encoded in a compatible format, avoid unnecessary scaling or re-encoding where your workflow allows it. If the source needs conversion, prepare a test file first and measure the complete process rather than assuming that a plan's vCPU label tells you enough.
The source also affects whether a small instance is sensible. A static image with background music is a lighter test than a 1080p live camera feed with motion, denoising and graphics. If you are preparing a video for a loop, the HandBrake conversion guide can help you make the input more predictable before you rent the VM.
Compare the full monthly cost and allowance
The advertised compute charge is only one part of the decision. For a continuous stream, compare the regional included transfer, any charge for traffic above the allowance, storage, public IP or related services, taxes, and the amount of operational work required. A cheaper VM with too little regional transfer can cost more once the stream is running.
AWS lists a general Lightsail Linux bundle at $7 USD per month with 1 GB memory, 2 vCPUs, 40 GB SSD and 2 TB transfer, and another at $12 USD per month with 2 GB memory, 2 vCPUs, 60 GB SSD and 3 TB transfer, as listed on AWS's site in September 2026. AWS says the Mumbai Lightsail allowances are half the amounts shown in the general bundle table, so the corresponding examples are 1 TB and 1.5 TB, subject to the current billing terms.
Those figures are useful examples, not proof that Lightsail is the cheapest provider. The comparison must be made at the region and workload you intend to use.
| Candidate | India region check | Compute cost | Included transfer to compare | What remains to verify |
|---|---|---|---|---|
| Lightsail Mumbai | Mumbai | $7 or $12 examples, as listed on AWS's site in September 2026 | 1 TB or 1.5 TB for the examples above | CPU encoding, taxes, overage terms and all traffic |
| Google Compute Engine | Mumbai and Delhi are listed regions | Region-sensitive; no single equivalent price | Internet egress is separately priced | Machine type, egress rate, disk and monthly total |
| Oracle Cloud | Check the current India availability and price list | Compute and outbound transfer are listed separately | Check the selected service and region | Eligibility, capacity, egress, storage and total invoice |
Google documents Mumbai and Delhi among its Compute Engine regions and explains that pricing varies by machine type and region. Its general-purpose Compute Engine pricing is a useful place to build an equivalent calculation. Oracle's cloud price list provides another official reference for checking India compute and outbound data-transfer entries. Neither page, by itself, establishes a complete like-for-like monthly bill for this use case.
A fair comparison therefore has five rows in your own worksheet: the monthly compute charge, the storage charge, the regional transfer allowance, the expected charge for traffic beyond that allowance, and any service needed for monitoring or recovery. Record whether the displayed prices include tax. Recheck the figures immediately before deployment because cloud prices, regional availability and terms can change.
Treat Mumbai Lightsail as one clear candidate
Mumbai Lightsail is worth testing because the bundle presents memory, vCPUs, SSD and transfer in one straightforward entry. That makes the first calculation easier than assembling several separate charges. It is a candidate for a lightweight prerecorded feed, not a confirmed lowest-cost answer and not a guarantee that the smallest instance can encode every workload.
The regional allowance is the important correction. Do not take the 2 TB or 3 TB general-table figures and apply them unchanged to Mumbai. AWS's transfer documentation says that inbound and outbound data both count towards the allowance. Read the Lightsail pricing page alongside AWS's transfer allowance documentation before relying on the bundle.
The 1 GB example may be enough to run a very light process, but memory and CPU capability must be measured with your source. The 2 GB example gives more memory and transfer in the published bundle, while still listing two vCPUs. That does not tell you whether your encoder will sustain the chosen resolution, codec and frame rate. The only dependable answer for your content comes from testing.
Region can affect more than price. A Mumbai location may reduce the network distance from an Indian operator, but the encoder's route to YouTube ingest and the behaviour of the selected data centre still need checking. Latency is not the same as stream quality. A feed can have reasonable latency and still fail because of CPU saturation, process failure, packet loss or an incorrect restart policy.
If a different Indian region gives a better total calculation for your workload, use it. The aim is not to select a particular brand or location in advance. The aim is to find the smallest tested setup whose complete cost and operating effort remain acceptable for the channel.
Check whether the instance can sustain encoding
A VM specification is not an encoding benchmark. Two vCPUs do not guarantee that a particular H.264 preset will run in real time, especially when the source is high resolution or the command applies scaling, filters and audio processing.
Use a short copy of the real programme for the first test. Include the same logo, text overlays, frame rate, audio and loop behaviour that the unattended channel will use. Test the selected output rather than a lower-resolution substitute. A 480p test does not prove that 1080p30 will remain stable.
For a simple FFmpeg arrangement, watch CPU use while the encoder is decoding, processing and sending. Look for sustained load rather than a brief average. Also watch memory, process restarts, disk reads and network activity. If CPU remains close to saturation, the process may fall behind when the content changes or when the system performs another task.
You have several practical choices if the test fails:
- Reduce the output resolution or bitrate to match the source and the channel's viewing needs.
- Use a faster encoder preset if the resulting picture remains acceptable.
- Remove unnecessary scaling, filters or overlays.
- Choose a larger instance and recalculate the complete monthly cost.
- Prepare the file in advance so the cloud process does less work at stream time.
Do not use the fact that a file plays smoothly on your desktop as evidence that it will encode smoothly on a cloud VM. Desktop hardware may have a different CPU generation, hardware acceleration or codec support. Conversely, the VM may be adequate for a pre-encoded file but not for a live software-encoding workflow.
For channels that need a fixed file and do not want to maintain a cloud encoder themselves, StreamNeo removes the need to keep your own VM process running: you upload the file once, add the YouTube stream key, and the cloud stream can continue while your computer is switched off, with monitoring and restart handling included in that workflow. It is YouTube-only, so it does not replace a general-purpose VM when you need custom software or a different destination.
Connect the encoder to YouTube Live
Create or schedule the broadcast in YouTube Live Control Room, then copy the server URL and stream key into the encoder. YouTube's stream creation and management guidance explains the channel-side steps. Keep the stream key private, just as you would keep a password private, and rotate it if you believe it has been exposed.
Prefer the RTMPS server URL where it is supported by your encoder. Set H.264 video, constant bitrate, the chosen output resolution and frame rate, and a two-second keyframe interval. Start with YouTube's bitrate guidance, then adjust only after checking picture quality, transfer use and the encoder's measured load.
The cloud machine needs enough upload capacity for the feed with headroom. YouTube's streaming tips recommend planning for the primary bitrate plus a backup bitrate plus 20 percent. That recommendation is about capacity planning, not a guarantee that a particular network path will remain available. Read the YouTube streaming tips and test the actual path from your selected region.
Before starting a long broadcast, confirm that the encoder is sending the intended channel, the preview shows the correct content and the stream health indicator is stable. Check the audio separately. A video feed can appear healthy while the audio is silent, distorted or delayed.
Set the process to restart after an ordinary encoder exit, and arrange an alert when it stops. Do not treat a restart command as failover. A process supervisor can start the same process again, but it cannot repair a revoked stream key, exhausted transfer allowance, unavailable VM, bad input file or failed network route without a separate response.
Test load, stream health and reconnects
Run an extended test on the exact instance before calling the setup ready. The test should cover normal playback, a loop boundary, a temporary encoder stop and a deliberate network interruption where you can safely create one. Record what happened rather than relying on the fact that the YouTube preview looked fine for a few minutes.
Monitor four areas:
- Encoder health: CPU, memory, process state, frame rate and whether the output remains close to real time.
- YouTube health: dropped frames, stream warnings, video quality and audio continuity in Live Control Room.
- Network behaviour: outgoing rate, connection errors and the time needed to reconnect.
- Recovery: whether the supervisor restarts the encoder, whether it uses the same stream key and whether the broadcast resumes without manual intervention.
A reconnect test should include a clean process stop and an interrupted connection. These produce different failure modes. A clean stop may be handled by a supervisor immediately, while a stalled connection may leave the process alive but unable to deliver useful data. Configure and test timeouts and retries rather than assuming that FFmpeg or the VM will recover in the desired way.
You can also use the more detailed automatic FFmpeg reconnect guidance as a checklist for the failure cases, and the YouTube dropped-frames troubleshooting guide when the process is running but the ingest is unhealthy.
The result you want is evidence such as: the selected source remained in real time, CPU did not stay at an unsafe level, the stream health warnings were understood, and a controlled interruption produced the expected recovery. If you cannot explain what happens after a failure, the setup is not ready for an unattended night.
Plan transfer use and archive handling
At a constant 3 Mbps for 30 days, the payload calculation is 3,000,000 bits per second multiplied by 2,592,000 seconds, divided by eight. That is about 972 GB in decimal units before protocol overhead. At 8 Mbps, the same calculation is about 2.592 TB before overhead.
These are planning calculations, not a provider invoice. Audio, protocol overhead, reconnects, health checks, updates and other traffic require margin. Because the Lightsail allowance includes inbound as well as outbound bytes, do not spend the whole displayed allowance on the YouTube feed. Confirm how the provider defines the displayed TB and how excess traffic is billed.
This is why the $7 general Lightsail example, with 1 TB for Mumbai after applying AWS's stated regional adjustment, is marginal for a continuous 3 Mbps stream. It is not enough for YouTube's recommended 8 Mbps 720p30 H.264 rate when that rate is sent continuously for the full period, even before overhead. The $12 example's 1.5 TB Mumbai allowance also requires calculation against the chosen bitrate rather than being accepted automatically.
Lowering bitrate reduces transfer directly, but it can reduce picture quality. Lowering resolution may be more sensible when the source and audience do not require a larger frame. If you run a simple devotional or ambience channel, test whether a smaller output still gives clean text and acceptable motion. If the channel carries fast-moving local news graphics, measure those scenes rather than judging only a static frame.
Archive behaviour needs its own test. YouTube says streams under 12 hours are automatically archived. That documented condition does not prove that one uninterrupted 24-hour broadcast will appear as one complete archive. Investigate the current behaviour for your channel, and decide whether scheduled segments, separate recordings or another archive workflow is more suitable.
Keep local copies of important programme files and any records you need for editing or verification. A cloud VM's attached disk is not automatically a complete backup plan. If the source is stored only on the instance, a deletion, disk problem or operator error can remove the material needed to restart the channel.
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 Mumbai Lightsail the cheapest option for a 24/7 stream?
The available evidence does not establish a universally cheapest provider. Mumbai Lightsail is a clear fixed-bundle candidate, but you must compare the full regional transfer allowance, compute requirement, storage, taxes and any excess-traffic charge with current alternatives.
Can the smallest Lightsail instance encode my stream?
It may suit a lightweight prerecorded feed, but the published plan specifications do not prove real-time performance for every codec, preset, resolution or filter chain. Test the actual source on the selected instance and monitor CPU, memory and whether the encoder keeps up.
How much transfer does an 8 Mbps stream use?
At 8 Mbps continuously for 30 days, the payload calculation is about 2.592 TB in decimal units before protocol overhead and other traffic. Treat that as a planning figure, then compare it with the selected region's allowance and retain margin for inbound bytes, reconnects and operational traffic.
Will YouTube make one archive from a 24-hour stream?
YouTube documents automatic archiving for streams under 12 hours, but that does not guarantee one complete archive for a continuous 24-hour broadcast. Check the current channel behaviour and test your intended segmentation or recording workflow before relying on the archive.