Traditional adaptive streaming protocols, built around segmenting video into several-second chunks and buffering multiple segments client-side for smooth playback, inherently trade latency for resilience — the buffering that makes playback smooth on unreliable networks is the exact same mechanism that introduces the many-second delay standing between a live moment and the viewer seeing it. That trade-off is perfectly acceptable for passive viewing of a live sports broadcast, but it breaks down completely for use cases that depend on real-time interaction: a live shopping host can’t react to a viewer’s question if that question arrives fifteen seconds after it was asked, and a co-streaming gaming setup becomes unusable if participants are seeing each other several seconds out of sync. IVS exists to solve this specific latency problem at managed-service scale, without requiring teams to build and operate custom low-latency streaming infrastructure themselves.

Production example: live shopping platforms have adopted IVS specifically because host-to-viewer interaction — a viewer asking about sizing or availability and the host answering on-stream within seconds — is the core value proposition of the format, and that interaction simply doesn’t work if the underlying stream carries the many-second delay typical of standard adaptive streaming.

This section assumes you already know IVS “streams live video with low latency.” It focuses on the specific building blocks and vocabulary that matter once you’re actually architecting a broadcast or interactive experience with it.

You may likeAWS App Runner→

Channels: The Core Broadcast Construct

A Channel is the fundamental IVS resource representing a single live broadcast — it has an ingest endpoint that a broadcaster’s encoder streams to, and a playback URL that viewers’ players consume. Channels are configured with a latency mode (standard low-latency or ultra-low-latency) and a type that determines the maximum supported resolution and bitrate, and this configuration is set per channel rather than negotiated dynamically per stream, meaning the latency and quality profile for a given broadcast is a deliberate upfront architectural decision.

Low-Latency vs. Ultra-Low-Latency Modes

The two latency modes represent a genuine trade-off, not just two speed settings. Standard low-latency mode targets a glass-to-glass delay of a few seconds and offers broader compatibility with generic playback clients and slightly more resilience to network variability on the viewer side. Ultra-low-latency mode pushes delay down toward roughly a second by using a different underlying delivery mechanism tuned specifically for that target, but requires the IVS player SDK on the playback side to fully realize that latency reduction — playing an ultra-low-latency stream back through a generic HLS player won’t achieve the same result, because the latency advantage depends on client-side behavior matched to the server-side delivery mechanism.

Stages: Real-Time Multi-Participant Video

A Stage is a distinct construct from a Channel, built for real-time, bidirectional, multi-participant video — the kind of interaction needed when several people need to see and hear each other live with sub-second delay, such as co-hosts on a live show or a guest joining a broadcast. Participants publish and subscribe to each other’s audio and video directly through the Stage using real-time communication protocols, and a Stage’s output can optionally be composited and published onward to an IVS Channel for broader one-to-many broadcast distribution — meaning the “several people talking to each other live” problem and the “one broadcast reaching thousands of viewers” problem are handled by two different, purpose-built constructs that can be composed together.

Playback Restriction Policies and Recording

IVS supports playback restriction policies that control where and how a channel’s stream can be consumed — for example, restricting playback to specific signed URLs to prevent unauthorized redistribution of a paid live event. Channels can also be configured to automatically record their live output to S3 as the broadcast happens, producing a VOD asset immediately available once the live stream ends, without a separate manual recording or transcoding step.

A broadcaster’s encoder pushes an RTMPS stream to a channel’s ingest endpoint. IVS’s managed ingest and transcoding layer processes that incoming stream, and the managed distribution layer serves it to viewers through a global edge network tuned specifically for the latency characteristics of the channel’s configured mode. For interactive scenarios, participants connect to a Stage using real-time protocols distinct from the Channel’s ingest path, and a Stage’s composited output can feed into a Channel as its source, chaining the real-time interactive layer into the broader broadcast distribution layer.

graph TB
    subgraph Interactive["Real-Time Layer"]
        P1["Participant 1"]
        P2["Participant 2"]
        STAGE["IVS Stage"]
    end

    subgraph Broadcast["Broadcast Layer"]
        ENCODER["Broadcaster
Encoder (RTMPS)"]
        CHANNEL["IVS Channel"]
        EDGE["Low-Latency
Edge Network"]
    end

    subgraph Viewers["Viewers"]
        V1["Viewer 1"]
        V2["Viewer 2"]
        V3["Viewer N"]
    end

    P1 --> STAGE
    P2 --> STAGE
    STAGE -->|"Composited Output"| CHANNEL
    ENCODER --> CHANNEL
    CHANNEL --> EDGE
    EDGE --> V1
    EDGE --> V2
    EDGE --> V3
        

This two-tier architecture reflects a deliberate scaling decision: real-time, bidirectional, sub-second communication among many participants simultaneously is a fundamentally different (and much harder to scale) problem than one-to-many low-latency broadcast to a large audience, so IVS solves each with a purpose-built construct rather than trying to make one system do both equally well at any scale.

On the Channel side, once video arrives at the ingest endpoint, IVS’s managed transcoding layer processes it according to the channel’s configured type and latency mode, then hands it to a distribution layer built to minimize the buffering typically introduced by standard adaptive streaming delivery. In ultra-low-latency mode specifically, this involves delivering video to compatible player clients using a mechanism that avoids the multi-segment buffering window standard HLS players rely on for smoothness, trading some of that buffering-driven resilience for materially lower delay — which is exactly why full realization of that low latency depends on a compatible player rather than being purely a server-side property.

On the Stage side, participants establish real-time, bidirectional media connections that carry audio and video with the low latency real-time communication protocols are built for, fundamentally different from the one-directional segment-based delivery a Channel uses. When a Stage’s output feeds a Channel, IVS composites the individual participant streams into a single combined video layout server-side, then that composited feed becomes the Channel’s ingest source, effectively bridging the real-time interactive layer into the broadcast distribution layer’s ingest path.

Trace a live shopping broadcast with an interactive guest segment. A host begins streaming from their encoder to their Channel’s ingest endpoint at the start of the show, and viewers immediately begin watching through the low-latency edge distribution layer. Partway through, a guest joins via a Stage, publishing their audio and video alongside the host’s own Stage participation; IVS composites both participants into a combined layout, and that composited output is routed into the same Channel viewers are already watching, so the interactive segment appears seamlessly within the ongoing broadcast rather than requiring viewers to switch to a different stream.

Throughout the broadcast, the host injects timed metadata at key moments — say, whenever a featured product changes — which viewer-side application code can listen for and use to update an on-screen product card synchronized precisely to that moment in the video, not just approximately. If the channel is configured for automatic recording, the entire broadcast, including the interactive guest segment, is simultaneously being written to S3 as a VOD asset, so the moment the live show ends, that recording is immediately available for on-demand replay without any separate manual export or transcoding step.

On the broadcast (Channel) side, IVS’s distribution layer scales to large concurrent viewer audiences using the same fundamental principle as other CDN-backed video delivery — a managed edge network absorbs viewer fan-out so the ingest and transcoding layer only has to handle the single broadcaster’s incoming stream regardless of how many thousands of viewers are watching. This is what makes it practical for a single live shopping host or broadcaster to reach a large audience without their own infrastructure needing to scale proportionally to viewer count.

On the Stage side, real-time multi-participant interaction scales along a fundamentally different, more constrained axis — the number of simultaneous participants who can be actively publishing and subscribing to each other’s real-time streams within one Stage is architecturally bounded far more tightly than Channel viewer count, precisely because bidirectional real-time communication among many participants is a genuinely harder scaling problem than one-directional distribution to passive viewers. This is exactly why large-audience distribution is deliberately routed through a Channel rather than attempting to scale a Stage itself to broadcast-sized audiences.

You may likeAmazon Neptune→

As a managed AWS service, IVS’s ingest, transcoding, and distribution infrastructure operates with the standard multi-AZ resilience expected of AWS regional services, meaning the loss of a single underlying AZ doesn’t represent a complete service interruption. For the broadcaster’s own encoder — the piece of the architecture outside AWS’s direct control — reliability depends on the broadcaster’s own network connection to the ingest endpoint, which is why production broadcast setups commonly include encoder-side reconnection logic to handle transient network interruptions on the way up to IVS without requiring the broadcaster to manually restart their stream from scratch.

IAM policies control who can create, configure, or delete Channels and Stages, and separately, playback-level access control — signed playback URLs and authorization tokens — governs who can actually watch a given channel’s stream, letting an application enforce that only authenticated or paying users can view content regardless of who technically has the raw playback URL. Stream keys used by broadcasters to authenticate their encoder to a channel’s ingest endpoint are treated as sensitive credentials, since possession of a valid stream key alone is sufficient to publish to that channel.

Channels and Stages are commonly provisioned as infrastructure-as-code alongside the broader application stack that manages broadcaster onboarding, viewer authentication, and recorded-content handling, so that a new broadcaster’s channel — including its latency mode, recording configuration, and playback restriction policy — is created consistently through the same automated pipeline rather than manual, easily-inconsistent console configuration for every new broadcaster.

Live shopping platforms have used IVS’s low-latency delivery combined with timed metadata to synchronize product highlight cards precisely to what a host is showing on screen in real time, enabling viewers to purchase featured items within seconds of them being shown rather than experiencing a noticeable lag between the host’s presentation and the on-screen interactive elements. Social and gaming platforms have used IVS Stages to power co-streaming features, where multiple creators broadcast together with the sub-second latency needed for natural, unawkward real-time conversation, then composite that combined feed out to a Channel reaching their broader audience. Fitness and education platforms running live interactive classes have used IVS specifically so instructors can respond to viewer questions and reactions submitted through a chat interface within a genuinely conversational timeframe, rather than the delay typical of standard streaming making the interaction feel disjointed.