Amazon IVS can carry the live video for an online auction, but the auction itself belongs in your application. Choose between a real-time stage and a low-latency channel based on how participants use video, then design bid acceptance around the delay your viewers actually experience.
That distinction matters: IVS does not provide an auction engine, validate or order bids, enforce auction rules, or guarantee a bidding latency. It supplies video capabilities; your product must decide which bids count and tell bidders what happened.
Choose the IVS mode around the room you want
Start with the participants, not a latency headline. Do bidders merely watch a presenter and submit offers through your application, or do hosts and other participants need to join the video experience as interactive publishers? The answer points towards either a low-latency channel or a real-time stage.
A low-latency channel is a fit for a conventional broadcast: one auctioneer appears on video, while viewers watch and submit bids through a separate web or mobile interface. AWS describes IVS Low-Latency Streaming as supporting delivery under five seconds, but that is a product capability, not a promise that every viewer sees every frame at the same moment. Geography, connection quality and the full media path affect what a particular bidder sees. See AWS's low-latency streaming overview.
A real-time stage is designed for participants to publish and subscribe to media through an application. It suits a product where, for example, an auctioneer and a remote specialist both need to appear, or where participant interaction is part of the experience. AWS identifies live video auctions as a real-time use case and documents latency under 300 milliseconds. That figure describes the service capability; it does not set the deadline or acceptance rule for a bid. Review AWS's real-time streaming overview.
| Consideration | Low-latency channel | Real-time stage |
|---|---|---|
| Typical video pattern | A host broadcasts to an audience | Participants join and exchange media through an application |
| Bid submission | Usually a separate application path | Still a separate application path, even if integrated into the same product |
| Main design question | How will viewers submit bids while watching? | Which people need to publish or subscribe, and how will the application manage participation? |
| Latency framing | AWS documents delivery under five seconds | AWS documents real-time latency under 300 milliseconds |
| Useful when | A straightforward host-led presentation is enough | Interactive participant media is central to the experience |
These options are not interchangeable settings for auction rules. A stage does not make bidding fair by itself, and a channel does not prevent you from building a responsive bid interface. Select the video mode that matches the media experience, then design a distinct, authoritative application path for bids.
A stage can be broadcast to a channel when you need an interactive production for participants and broader distribution to viewers. AWS documents this pattern as a way to deliver a stage broadcast to channel viewers. It adds another media path to understand and test, so use it for a real product need rather than simply because the stage has a lower stated latency.
Map the host's video path
For a simple single-host auction, map the journey from camera and microphone to the viewer's screen. The auctioneer captures a feed; an encoder or application sends it to IVS; viewers receive and play it; and your bid interface operates alongside that video. Keeping the video path and bid path separate on a diagram helps avoid assuming that a video event can determine whether a bid was accepted.
If you are building an integrated application, AWS provides IVS broadcast SDKs for publishing video. The web guide covers joining a stage, publishing and subscribing to media, and monitoring media and WebRTC statistics. An SDK-based host needs access to a camera and microphone, but the documentation does not require a particular webcam, microphone or lighting kit. Choose equipment according to the room and production needs, not on the assumption that hardware changes IVS latency. Start with the IVS Broadcast SDK web guide if a browser-based stage is part of your design.
If the auctioneer already works with encoder software, AWS documents RTMPS, RTMP and SRT ingest for channels, with setup instructions using OBS. RTMPS encrypts the connection from encoder to ingest. An encoder workflow can be simpler for a single presenter, but it means you must configure and monitor that software and the host's connection. Consult AWS's OBS streaming setup and its streaming configuration guidance before settling on encoder settings.
AWS's OBS walkthrough recommends a two-second keyframe interval. Its broader configuration guidance discusses one-second keyframes as an option for reducing startup latency, while noting possible adaptive-bitrate trade-offs such as resolution switching or buffering. Do not treat a smaller interval as an automatic improvement: set the encoder to match documented channel requirements, test at the intended resolution and bitrate, and watch playback on the connections your bidders use.
You can also compare the live presentation with a prepared video workflow in this guide to live versus pre-recorded video. An auction needs a live host and changing lot information, but prepared graphics, product clips or demonstrations can still be part of the production. Decide which content is live and which is prepared before choosing how the host's feed reaches IVS.
Treat latency as part of bid timing
Video latency is the time between an event in the room and its appearance on a viewer's screen. Bid latency is different: it includes the viewer's decision, their network round trip, your application processing and the time it takes to confirm the result. A low-delay video feed helps the experience, but it does not make those other steps disappear.
AWS says observed latency can vary with geography, network type and speed, and components in the streaming chain. That means a bidder in one location may see the auctioneer's gesture or hear the closing call later than another bidder. Do not put a countdown on screen and assume that everyone sees it at the same instant. Give the application a clearly defined deadline and make that deadline authoritative, with video used to communicate the event rather than to measure eligibility.
For example, your host might say that bidding on a lot closes at a stated time shown in the application. A bidder submits an offer, the application records its receipt time, and the interface returns a result. The auctioneer's words and gesture help viewers follow the action, but the product's published closing rule determines whether the offer arrived in time. Make the rule visible before bidding begins and repeat the closing status in the interface.
There is a trade-off between giving a bidder time to respond to what they see and keeping an auction moving. A short close window can feel abrupt to a viewer whose feed is delayed; extending it can keep the experience understandable but slow the event. Consider a defined extension when an eligible offer arrives near close, or a clear pause-and-resume process when the host needs to correct a lot detail. These are product rules for you to set, not behaviours supplied by IVS.
Test the whole experience from realistic bidder locations and networks. Measure the visible video against application events and observe the time from submitting an offer to receiving confirmation. Use those observations to choose your countdown, announcements and support guidance. Do not turn one test into a latency guarantee: conditions change, so explain how a bidder can recover if playback stalls or a confirmation is delayed.
Build lot and bid handling in the application
Treat each lot as a stateful object in your application. A useful design distinguishes a lot that is scheduled, open for bids, closing, closed, withdrawn or paused for correction. The exact states depend on the auction, but transitions should be deliberate: a host should not be able to close one lot while the interface still accepts offers against the next one by mistake.
When a bidder submits an offer, your application needs to check it against the current lot state and the rules you have published. Those checks might include whether bidding is open, whether the amount satisfies your increment rule, whether that bidder can participate, and whether the offer arrived before the application-defined deadline. Store the outcome and return a clear acknowledgement. IVS is carrying video; it is not performing these checks.
Plan the display around the outcome, not merely the button tap. Show whether an offer is pending, accepted or rejected, and identify the lot to which it applied. If the network interrupts a request, the client should not silently issue a duplicate offer on retry. An idempotency token or comparable request identifier can help your application recognise a repeated submission, while the interface asks the bidder to wait for the recorded result.
Keep a durable event record for the business process you need: lot opened, offer received, offer accepted or rejected, lot closed, and any correction or reopening. Include timestamps and identifiers sufficient to reconstruct what the application did. The record is an engineering and operations measure, not a statement that any particular record meets a legal evidentiary standard. Requirements for auction conduct, payments, bidder verification and record retention vary; seek advice appropriate to your jurisdiction and check current official requirements.
Your host tools and bidder view should agree about lot state. If a host pauses the event, the application should visibly stop accepting bids or clearly indicate the pause. If the stream drops but the bid service remains live, decide whether to pause, continue with a notice, or move to another communication route. Video continuity and bid validity are related operationally, but one does not automatically control the other.
Plan bidder identity and bid ordering
Identity is a product and business decision. You may need an account, a verified contact method or another eligibility check, depending on the auction and where you operate. IVS does not establish a bidder's identity or determine their eligibility. Design registration, sign-in recovery and any required verification as application functions, and explain what information you collect before asking someone to bid.
For simultaneous offers, define what your application means by an offer being first. A common approach is for a single authoritative service to assign a receipt time or sequence when it processes each valid request. The interface can then tell bidders that the application's recorded order controls, rather than implying that a device clock, video frame or screen animation establishes priority. This is a design choice, not a feature of IVS.
Also decide how you resolve requests that arrive close together. Your application could use a transaction or other serialised update so two accepted offers cannot both overwrite the displayed leading amount. Whichever approach you choose, record the decision and return consistent results to the bidder and host console. A test with concurrent submissions is more revealing than clicking the bid button from one browser at a time.
Tell bidders what they will see when an offer is leading, outbid, rejected, or under review. Avoid a green flash or sound effect that appears before the server-side result is known. If the host's video has fallen behind, the application can still show current lot status and a message that the video is delayed; if the bid application itself is impaired, stop accepting offers or clearly communicate the fallback rule.
Decide how to record the event
Recording can support later review, production reuse or moderation, but it is separate from the live bid record. AWS documents individual participant recording and composite recording to S3 for real-time stages. Individual recordings preserve participant tracks separately; a composite gives you a combined programme view. Choose based on whether your editing or review process needs separate sources or a finished combined picture.
Recording has practical costs and operational dependencies. AWS notes that S3 storage and requests are involved, and composite recording also incurs video encoding charges. Stage, storage configuration and bucket need to be in the same AWS Region for real-time recording to S3. Check current AWS pricing and requirements before planning a budget, since charges and limits can change.
Do not make the cloud recording the only copy if a missing section would matter to your operation. AWS warns that network problems can cause recording data loss and recommends local recording as redundancy. Decide who checks that recording has started, how the local copy is safeguarded, and how authorised staff can access it later. Whether a recording is legally sufficient for a dispute is not established by the streaming documentation; check current rules and take appropriate professional advice.
Test the auction, not only the stream
A successful preview confirms that video plays; it does not prove that the auction workflow is ready. Rehearse the full sequence with test lots and accounts: host opens a lot, a bidder submits an offer, another bidder submits at nearly the same time, the application returns outcomes, the host closes the lot, and the next lot becomes available. Check that the same result appears in the bidder view, host console and event record.
Include failure cases. Disconnect the host feed while a lot is open, delay a bidder's connection, refresh a page after submitting an offer, and retry a request whose response was lost. Confirm that a duplicate does not become a second bid, that a video interruption does not leave the rules ambiguous, and that staff know how to pause or resume the auction. Run these tests with the actual playback route and devices planned for the event.
For an encoder path, test keyframe interval, resolution, bitrate and frame rate on the intended channel and observe the viewer playback, not only the encoder's status panel. If a mobile broadcaster is part of your contingency plan, this troubleshooting guide for a Larix stream that keeps disconnecting can help frame the questions to ask about connection stability. It is not a substitute for an auction fallback rule or a test of your own setup.
For an SDK stage, verify camera and microphone permissions, participant join and leave behaviour, media statistics and any recording path. Test what the audience sees if a stage participant disconnects, and make sure the host can distinguish a video problem from a bid-system problem. Write down who can pause bidding, who can announce a correction and how bidders learn the authoritative status.
If an auction format includes demonstrations, music or other third-party material, check rights and platform rules separately from streaming configuration. This overview of YouTube copyright rules for live streams is useful for a YouTube production, but it does not address auction regulation. Confirm current official guidance for the platforms and jurisdictions involved.
The final rehearsal should include the people who will actually host, moderate and support bidders. Give them a short runbook with the lot-state controls, the pause procedure, the fallback communication channel and the person authorised to make a correction. For a YouTube delivery path, confirm that the YouTube event and viewer-facing details are prepared as well as the IVS feed; an IVS video path alone does not configure the receiving platform.
Once you have chosen the video mode, mapped the bid path and rehearsed failure handling, you can assess the operational workload.
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
Can Amazon IVS run the auction for me?
No. IVS carries video, while your application must implement lots, bidder identity, bid checks, ordering, deadlines and auction rules. Build and test those functions independently of the video service.
Should I choose real-time stages or a low-latency channel?
Choose a channel for a straightforward host broadcast when viewers can bid through a separate interface. Choose a stage when hosts or other participants need to publish and subscribe through an interactive application; decide based on the media experience, not the assumption that it determines bid validity.
Can I use OBS to send an auction feed to IVS?
AWS documents OBS setup for IVS channel streaming, along with supported ingest protocols and encoder guidance. Configure and test the channel settings against current AWS documentation, then rehearse viewer playback and the separate bid workflow.
Does low-latency video guarantee that every bidder sees the close at the same time?
No. AWS documents latency capabilities, while observed delay varies with geography, network conditions and the streaming chain. Define bid deadlines in your application and test how the interface communicates them to viewers.