If attendees need to speak and respond to one another on live audio and video, build the event around an Amazon IVS Real-Time stage. If most people will watch a presentation, an IVS Low-Latency channel is usually the simpler fit; you can combine the two when a small interactive group needs to appear before a larger viewing audience.
These are different delivery models, not audience-size settings on one shared room. Decide first who must exchange live media, then check the account’s regional quotas, network conditions, recording needs and slide design before you settle the implementation.
Start with the way people will take part
Write down what an attendee should be able to do during the event. If the answer is “watch and perhaps ask questions through a separate moderated channel”, the main programme is broadcast-led. If attendees must join with cameras or microphones and have a live conversation with hosts, those participants need a real-time environment.
That distinction matters more than the word “virtual”. A product launch with one presenter and a question period may be mostly a broadcast, while a remote workshop in which attendees take turns speaking is interactive. Trying to make every viewer a stage participant can make the experience harder to manage without improving the presentation.
Consider the number and role of active speakers separately from the number of people watching. A host, presenter and a few panellists might need to publish video; a much larger audience may only need playback. Do not describe the viewing audience as interactive simply because it can watch a stage feed. Chat, questions or polls can add participation, but they do not give viewers the same live audio-and-video exchange as stage participants.
Also decide whether the event is one session or a continuous channel. A scheduled presentation has a start, finish and replay plan. If you are adapting a recurring programme into an always-on YouTube channel, a guide to planning a 24/7 live TV channel covers a different operating pattern. For this event, keep the design tied to the participation the audience actually needs.
Choose a stage, a channel or both
Amazon IVS Real-Time Streaming provides stages: virtual spaces where participants exchange video in real time. AWS describes stage latency as under 300 milliseconds for stage participants. A Low-Latency channel is intended for one-to-many delivery; AWS describes its latency as under five seconds. Both figures are service descriptions, not guarantees of the delay every attendee will experience. Location, network conditions and the rest of the streaming path affect actual latency.
| Event need | IVS Real-Time stage | IVS Low-Latency channel |
|---|---|---|
| Main behaviour | Hosts and participants exchange live audio and video | Audience primarily watches a programme |
| AWS-described latency | Under 300 ms for stage participants | Under five seconds for channel viewers |
| Setup concept | Create a stage, issue participant tokens, integrate the Broadcast SDK, then publish and subscribe | Create a channel, send an encoder feed to its ingest endpoint, and share its playback URL |
| Capacity check | Regional stage publisher and subscriber quotas | Regional concurrent-view and simultaneous-stream quotas |
| Combined use | Stage participants can be broadcast to a channel | Channel viewers watch the resulting stage feed |
Choose a stage if the conversation itself is the product: a panel where speakers respond to each other, a small interactive class or a workshop with participant contributions. For a conventional keynote, product demonstration or devotional presentation, viewers may be better served by a channel while questions are taken through a separate mechanism. That keeps the programme coherent and reduces the number of people who need publishing access.
A stage participant needs to authenticate to join. In the usual implementation, you create the stage, distribute participant tokens and integrate the IVS Broadcast SDK into a web, Android or iOS application to publish and subscribe. For a channel, you configure an encoder or other contribution software with the channel’s ingest details and stream key; attendees use the playback URL. The AWS overview of IVS Real-Time and Low-Latency streaming explains the service models and their intended use.
Keep the channel stream key secret. Anyone who obtains it may be able to send a feed to the channel, so share it only with the people and systems that need to contribute. Treat participant tokens with similar care and provide them only to the intended stage participants.
Use a hybrid workflow only when it solves a real need
A hybrid stage-to-channel arrangement is useful when presenters need to interact with each other in real time, but most attendees only need to watch. Stage participants exchange media on the Real-Time stage; the stage output is then broadcast to a Low-Latency channel. The audience watches the channel feed rather than joining the stage. It is an option for separating a small speaking group from a larger viewing audience, not a requirement for every virtual event.
Plan the hand-offs before implementation. Identify who can join the stage, who controls the broadcast, what appears on the channel, and how the presenter knows whether the audience can see the current slide. Decide how you will handle a late speaker, a presenter who loses their connection, a pause between sessions and the end of the event. If viewers can send questions, decide where those questions arrive and who screens them before a host reads them aloud.
Do not promise that channel viewers get stage-level latency or interaction. AWS describes the stage and channel with different latency targets, and the channel remains a viewing path. If a question needs a spoken answer, a moderator can relay it to the speakers; the viewer still watches the channel output rather than joining the real-time exchange.
The hybrid design also adds work: you need both stage participation and channel contribution configured, and you must test the stage-to-channel path as a whole. If one presenter can deliver the entire programme and viewers do not need to speak, a channel alone avoids that extra layer. If everyone who matters is meant to talk with one another, a stage may be enough.
Check quotas and network conditions early
Capacity planning begins with the account and AWS Region you intend to use. AWS quota documentation lists default Real-Time limits per account and Region, including 12 stage publishers at once and 10,000 stage subscribers at once; the subscriber quota is adjustable. It also lists a maximum participant publish or subscribe duration of 24 hours and a regional concurrent-publisher quota across stages. Low-Latency documentation lists default regional quotas of 15,000 concurrent views and 100 simultaneous streams, both adjustable. These are quota values, not a promise that an individual account has been approved for a particular event size.
Check your account’s actual values in AWS Service Quotas and make any increase request well before the event. Do not infer that a broad product overview describing larger potential audiences means your account can support that count today. The Real-Time Streaming quotas page and Low-Latency Streaming quotas page are the places to verify current limits. Quotas can change, and configuration and account status matter.
For a stage, distinguish publishers, subscribers and the regional total across stages. The speaker count is not the audience count. For a channel, distinguish concurrent viewers from simultaneous channel streams. Estimate peak attendance rather than relying only on registrations, and leave room for speakers, operators and test devices where those consume relevant capacity. If the event includes multiple sessions or channels in the same Region, include them in the same planning conversation.
Network checks are as important as quota checks. IVS Real-Time uses WebRTC and WebSocket. AWS says media uses UDP by default; subscribers can fall back to TCP, but TCP fallback is not supported for publishing. A host on a managed corporate or venue network where UDP is blocked may therefore fail to publish even if viewers can otherwise reach the service.
Ask the organisation’s network team to confirm the required IVS destinations and ports for the client and role in question. Then test from the actual presenter locations and networks, not only from an organiser’s home connection. A clean test on one network cannot establish that a panellist behind a company firewall will be able to publish. Have a dial-in or alternate contribution plan only if you have verified it works with the chosen event design.
Make slides readable in the stream
A slide that looks crisp on the presenter’s monitor can be unreadable in a video window on a phone. Use short headings, large labels and clear contrast, and avoid putting a paragraph of notes into a small corner. Check a shared slide at the size attendees will actually watch, including a mobile-sized preview. If the presenter will switch between camera and slides, make sure the transition does not leave text hidden or cropped.
AWS’s guidance for text and slow-moving material such as presentations recommends layered encoding with simulcast or a lower frame rate. Its optimisation guidance also describes SDKs lowering bitrate, frame rate and resolution when network conditions are congested. Those are tools for adapting a feed; they do not establish one resolution as right for every room, device or presentation. See the IVS guide to optimising real-time video and test the actual content in the intended viewing layout.
For a presentation-led event, prioritise legibility and stable delivery over motion that the audience does not need. If a presenter is writing on a board, moving through a demonstration or showing detailed interface work, test that content separately from static slides. A frame-rate reduction that suits a mostly static deck may not suit a fast-moving demonstration. Ask a colleague on a different connection to report what they can read, rather than judging only from the production monitor.
Prepare a fallback for slides: a second copy of the deck accessible to the moderator, a clear way to advance or pause it, and a short note of what to do if screen sharing fails. The fallback should not depend on the same device or connection that has just failed. If your presentation is a prerecorded loop rather than a live event, guidance on streaming a folder of videos to YouTube with FFmpeg addresses that separate workflow.
Decide what you need to record
Recording is not automatic. Real-Time Streaming offers individual participant recording, which keeps separate publisher files, and composite recording, which produces a mixed programme view. Separate files can help an editor work with speakers independently or support moderation review; a composite is more convenient when you want a single ready-to-watch programme. Choose based on the post-event task, not simply on the idea that more recording is better.
For individual participant recording, enable it for the stage and configure a customer-owned S3 bucket. The stage, storage configuration and destination bucket need to be in the same AWS Region. AWS says individual participant recording has no additional IVS charge; standard S3 storage and request charges still apply. Composite recording has an hourly charge for the encoded video, as well as S3 costs. Prices and billing details change, so check the current AWS recording documentation and your account’s pricing before committing to a design.
Cloud recording should not be the only copy for an important event. AWS warns that problems between the source and AWS, or within AWS, can lead to recording data loss because live streaming takes priority. Plan a local recording backup where practical, assign someone to verify that it is running, and check that the file can actually be played after the event. Include enough time in the run sheet for the test; a configured destination alone does not prove that the expected recording is usable.
Set an operations plan alongside the technical one. Name a producer who can communicate with speakers, a moderator for questions and a person responsible for monitoring the programme feed. Agree a private channel for coordination so that production instructions do not leak into the presentation. Keep the stage participant list and the channel contribution credentials limited to the people who need them.
If the event will be watched after it finishes, decide who will publish the replay, how it will be labelled and who will confirm its audio and picture. Recording a session does not automatically create a polished replay. Cut dead time or private conversation if needed, check captions and slides, and make sure the replay is shared through the intended channel.
Rehearse the attendee journey
A useful rehearsal starts with the attendee link, not the control panel. Join as a viewer on a phone and a desktop, check that the playback URL opens, and confirm the audio is audible without headphones and with them. If there is a registration or waiting page, test that route too. A production preview that only the operator can access is not a substitute for the audience path.
For a stage, test the full join process with each kind of participant: token delivery, camera and microphone permissions, publish, subscribe and leaving or rejoining. For a hybrid event, verify that the stage reaches the channel and that the channel playback has the intended composition and sound. Test the speaker handover, question relay and fallback slide procedure rather than stopping once video appears.
Rehearse from the networks that presenters will use. Pay particular attention to corporate, campus and venue connections, where policies can differ from home broadband. Check that the intended browser or mobile application can access the camera and microphone and that the stream remains usable when one person temporarily loses connectivity. Avoid discovering on event day that a speaker’s network blocks publishing.
Give attendees simple instructions: which link to open, whether they need to sign in, how to adjust sound, and where to send a question. Do not imply that viewers can join the stage unless they have actually been invited and provisioned as participants. If the event is being delivered as a YouTube broadcast instead of an IVS channel, the practical concerns around keeping a stream running are different; this guide to monitoring an always-on YouTube stream remotely covers that operating context.
On the day, have a short run sheet with start time, speaker order, content cues, moderator prompts, recording checks and the person authorised to pause or end the feed. Keep a contact route for speakers that does not rely on the audience playback link. After the event, review the recording, note any audio or slide issues, and update the rehearsal checklist while the details are still fresh.
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
Should every attendee join an IVS Real-Time stage?
No. A stage is for people who need to exchange live audio and video, while a Low-Latency channel suits an audience that primarily watches. Choose based on the interaction required, not on the fact that the event is online.
Does a Low-Latency channel have the same delay as a Real-Time stage?
No. AWS describes stage latency as under 300 milliseconds and channel latency as under five seconds, but those are service descriptions rather than guarantees of each attendee’s experience. Actual delay depends on location, network and the streaming path.
Is a hybrid stage-to-channel setup necessary?
No. It is useful when a group of speakers needs real-time interaction while a broader audience watches the programme. For a one-presenter broadcast, a channel alone may be simpler; for a genuinely interactive group, a stage may be enough.
Can I assume the default quotas will cover my event?
No. The published figures are defaults or adjustable quota values, not confirmation of capacity for your account. Check the current Service Quotas in the intended Region and request any needed increase before event day.