AWS Cloud Digital Interface (CDI) is a software development kit and transport technology for moving live video between applications in AWS. It is designed for cloud production workflows that need uncompressed video and low latency; it is not a viewer-facing streaming service or a way to publish a channel directly to YouTube.
The practical choice is usually about where the video must travel, what compression is acceptable, and which endpoints need to exchange it. AWS CDI SDK transport, a MediaConnect CDI flow and ST 2110-22 with JPEG XS are related tools, but they are not interchangeable names for the same technology.
What AWS CDI means
AWS Cloud Digital Interface provides software components that let compatible applications exchange video in AWS. Think of a production chain with a video source application on one EC2 instance and a processing or switching application on another. CDI is the transport layer between those software endpoints, rather than the camera, codec, editing application or final streaming destination.
AWS describes the SDK as supporting uncompressed live video. That matters because uncompressed picture data can preserve the source signal without first reducing it with a video codec, but it also requires a suitable high-throughput path. Moving that signal between applications is a different problem from compressing a programme for delivery to viewers over the public internet.
The SDK belongs in a cloud production design: ingest, process, switch, or hand off media among systems that have been built to use it. AWS points developers to the CDI SDK user guide and related integration materials. An operator does not simply select “CDI” in an ordinary desktop streaming app and expect a public live channel to appear.
That distinction is useful if your actual goal is a continuous YouTube broadcast from a finished video. You may be comparing a cloud production transport with a channel playout method, when they solve different jobs. For a simpler loop, the practical questions are closer to those in this guide to streaming a podcast archive from a VPS or this walkthrough for looping worship videos on YouTube Live.
AWS says CDI can support latency as low as a single frame of video. Treat that as a capability statement for suitable deployments, not a guarantee that every path, application or buffer setting will achieve it. Frame buffering, instance selection, placement and the wider workflow all affect what the operator experiences.
How CDI moves live video in AWS
At a high level, one application produces media, the CDI SDK carries it across the AWS network, and another compatible application receives it. The applications must be part of an architecture designed for CDI: the SDK is not a universal bridge that makes arbitrary software endpoints compatible. Before planning around it, confirm how each source and destination implements the SDK and which formats and metadata it handles.
The network path matters as much as the application path. AWS documents CDI SDK transfers between EC2 instances in the same Availability Zone, with support for an uncompressed UHD rate up to 4K at 60 frames per second under the guide’s stated conditions. The instance types must support Elastic Fabric Adapter (EFA), and AWS recommends clustered placement groups for optimal performance. Those are scoped product details, not a claim that any two EC2 instances can pass any signal at that rate.
A useful design exercise is to sketch each stage before choosing a transport. Mark where the source enters AWS, which application processes it, where any audio or ancillary data travels, and where the signal leaves the cloud. Then write down the Availability Zone boundary and the external network links. A path that is smooth between two nearby cloud nodes may not meet the same requirements once it crosses a region, a facility connection or another service boundary.
This is why “uncompressed” alone does not settle the design. The useful question is whether the workflow has the network capacity, compatible endpoints and operational control to move the required media where it needs to go. If your concern is instead converting or preparing streams for distribution, see the explanation of cloud transcoding for live streaming; transcoding and CDI transport can appear in one workflow, but one does not replace the other.
EFA, SRD and the performance conditions
AWS describes CDI SDK transport as using Elastic Fabric Adapter (EFA) and Scalable Reliable Datagram (SRD). EFA is a network interface for supported EC2 instances, while SRD is the transport technology AWS uses to move data across that network. Their role is to support high-throughput, low-latency exchange between application nodes; they do not remove the need to choose suitable instances and topology.
EFA availability is limited to supported Nitro-based EC2 instance types. This makes instance compatibility an early design check, rather than an optimisation to leave until deployment. AWS’s guide also recommends clustered placement groups for performance, but notes that clustered placement is not suitable or possible for every interoperability scenario. A placement choice that helps one portion of a cloud workflow can constrain another, so validate the end-to-end layout rather than copying a diagram without its context.
The AWS guide describes 4K at 60 frames per second for transfers between EC2 instances in one Availability Zone, with the supported EFA configuration. It also describes latency as low as a single video frame. Neither statement means every deployment will operate at that level: distance between nodes, buffer requirements, processing stages and application behaviour can change the result. The guide states a performance goal of no more than one dropped frame in a 24-hour period, but that is an AWS SDK goal, not an independently measured promise for every customer topology.
In practice, test with the actual source and receiving application, representative media, and the placement you intend to keep. Watch not just for image delivery but also for audio alignment, application buffering and what happens when a node or network path is interrupted. If your production needs redundancy or a facility hand-off, test the recovery path too. A nominal data-rate capability does not by itself tell you how the whole service behaves during an overnight or live event.
Where MediaConnect CDI flows fit
MediaConnect is a managed AWS service for transporting live media flows. A MediaConnect CDI flow is related to the SDK transport, but it is a MediaConnect workflow feature with its own source and output configuration. AWS documentation says a CDI flow source must be in a VPC configured using Amazon VPC, and the flow can carry uncompressed or lightly compressed content. See AWS’s instructions for creating a flow with a CDI source when evaluating the service’s current requirements.
This distinction helps avoid treating “CDI” as a single product toggle. The SDK is for compatible applications exchanging media; a MediaConnect flow is a service-level way to move media through MediaConnect and connect cloud and broadcast workflows. You need to check whether the exact source interface, output protocol, VPC arrangement and destination fit your design. The word CDI alone is not enough to establish interoperability.
AWS describes a contribution use case that bridges on-premises SDI, 2022-6 or 2110 networks with VPC CDI using Direct Connect. That is a broadcast contribution path, not an ordinary home internet uplink. A facility may have a dedicated connection and an engineering team responsible for routing, monitoring and signal format. If you are sending a single pre-recorded file as a 24/7 channel, this architecture can add complexity without solving a problem you have.
Topology can impose hard boundaries. In the cited MediaConnect workflow, CDI outputs do not support transfer between Availability Zones. AWS points to ST 2110 JPEG XS outputs for delivery to a different Availability Zone. Confirm this limitation against the current MediaConnect documentation and the precise source and output configuration you plan to use; service capabilities and supported combinations can change.
A cloud service cost is also not the same thing as a protocol or SDK fee. AWS states that there are no CDI SDK fees, but an implemented architecture can involve EC2, MediaConnect, VPC connectivity and Direct Connect or other services. There is no single meaningful workflow price without the architecture and usage assumptions. Check each AWS service’s current pricing and model the actual path before committing; do not infer total cost from the SDK fee statement.
CDI versus ST 2110-22 with JPEG XS
SMPTE ST 2110 is a family of standards for professional media over managed IP networks. AWS distinguishes uncompressed ST 2110-20 video from ST 2110-22 video compressed using JPEG XS. MediaConnect can offer a CDI path and an ST 2110 JPEG XS path, but these are distinct protocol choices. CDI is not another name for ST 2110-22, and JPEG XS is not an uncompressed transport.
The central trade-off is media data rate versus compression. A CDI or ST 2110-20 path is appropriate when the design calls for uncompressed video and the network can carry it. JPEG XS reduces the amount of video data while aiming at low-latency, visually lossless compression for contribution workflows. AWS specifically describes JPEG XS as a means of reducing Direct Connect bandwidth in its contribution example. Check the source quality requirements and the actual supported profile rather than assuming any compression setting is invisible in every workflow.
| Choice | Video path | What to check | Often fits |
|---|---|---|---|
| CDI SDK | Uncompressed exchange between compatible applications in AWS | EFA-capable instances, same-AZ design, placement and buffering | Cloud production applications that need uncompressed transport |
| MediaConnect CDI | CDI flow into or out of a VPC, carrying uncompressed or lightly compressed media | VPC source, configured interfaces, supported flow topology and outputs | Contribution workflows connecting cloud and broadcast systems |
| ST 2110-20 | Uncompressed video in the ST 2110 family | Network design and the exact supported media profile | Broadcast IP workflows requiring uncompressed video streams |
| ST 2110-22 with JPEG XS | Lightly compressed video in a separate ST 2110 path | JPEG XS support, media stream handling and bandwidth trade-off | Contribution paths where reducing network load is useful |
The table is a workflow guide, not a complete standards catalogue. AWS product support is specific to the relevant service. For instance, AWS Elemental Live’s documented profile for uncompressed video and JPEG XS describes particular resolutions, scan modes, chroma sampling and bit depths; do not project that product table onto all ST 2110 implementations. MediaConnect also has a specific media-stream support table, including audio and ancillary data considerations. Read the MediaConnect media-stream documentation for the service-specific matrix.
A decision should include audio and ancillary data, not just the picture. In an ST 2110 workflow, video, audio and ancillary information can be separate media streams, and service support is not universal for every stream type. Make a list of the signals your production actually uses, then match each to the chosen source and output configuration. If a workflow must cross Availability Zones or reduce a dedicated connection’s bandwidth, the JPEG XS alternative may make more sense than an uncompressed CDI output, subject to compatibility checks.
Who CDI workflows are for
CDI is aimed at broadcasters, television professionals, video engineers and software vendors building cloud production workflows. It makes sense when you have compatible application endpoints in AWS, a requirement for high-quality uncompressed transport, and control over instance and network placement. It can be relevant to a virtual production chain, remote production system or cloud-based media processor where each stage must exchange live video with low delay.
It is less compelling when you need a finished programme to reach viewers on YouTube or another public platform. Viewer delivery typically involves an encoder, a streaming protocol accepted by the destination, and a platform ingest configuration. CDI is not a public streaming protocol or a replacement for the platform’s live setup. For a continuous channel built from a file, compare the operational approach in cheap VPS versus cloud streaming for a 24/7 YouTube channel, which addresses a different job from broadcast contribution.
A useful fit checklist is:
- Do both ends of the proposed connection support the required CDI SDK or MediaConnect configuration?
- Does the source need to stay uncompressed, or can a JPEG XS path meet the quality and latency need?
- Can you place supported EFA instances appropriately, and does the design stay within the relevant Availability Zone boundary?
- Does the flow need to connect to a facility, and is the VPC and dedicated connectivity plan already understood?
- Have you checked service-specific support for video, audio and ancillary data, plus the operational recovery plan?
If several answers are uncertain, start by drawing the signal path and asking the application vendors or AWS team to verify the exact interoperability combination. Then test a representative signal and a failure case before using the design for a live production. A diagram that labels a line “CDI” is not enough evidence that every endpoint, stream type and network boundary is supported.
For a simple prerecorded YouTube loop, the operational pain is often keeping a local computer and encoder running overnight, rather than moving uncompressed pictures between production applications. StreamNeo removes that specific always-on computer burden by turning an uploaded video into a YouTube live broadcast that runs with your computer off; it is not a CDI workflow and is YouTube-only.
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 AWS CDI a streaming platform?
No. AWS CDI is a transport technology and SDK for applications exchanging live video in AWS, while a streaming platform distributes a broadcast to viewers. A workflow may use other components after CDI to encode or deliver a programme, but CDI itself does not publish a YouTube channel.
Does AWS CDI always have one-frame latency?
No. AWS describes latency as low as a single frame under suitable conditions, and notes that a deployment may need additional buffering. Instance choice, node placement, application behaviour and the full signal path affect the result, so test the actual architecture.
Is MediaConnect CDI the same as the CDI SDK?
They are related but serve different parts of a workflow. The SDK lets compatible applications exchange media, while MediaConnect CDI is a flow configuration within AWS Elemental MediaConnect with its own VPC and source or output requirements. Check the current AWS documentation for the exact configuration you need.
Is ST 2110-22 with JPEG XS the same as CDI?
No. AWS identifies ST 2110-22 as a JPEG XS lightly compressed video path, distinct from CDI and from uncompressed ST 2110-20. Compare supported endpoints, network boundaries, bandwidth and media types before selecting either path.