AWS Cloud Video Production: Architecture & Cost | Callaba
More live video workflow notes and product updates.
Cloud production architecture
Design the AWS live-video path around failure boundaries, not instance names
Start by deciding where contribution ends, where operators observe the signal, where media is transformed, and where viewers enter. Only then choose EC2 capacity, managed AWS media services, storage and CloudFront. This order keeps the design portable and prevents one overloaded machine from becoming ingest, mixer, recorder and origin by accident.
Each moving trace represents media crossing one boundary. The production should remain diagnosable when a downstream layer is removed. Motion stops for reduced-motion users.
Answer four questions before choosing compute
What must happen in real time?
Receiving and routing compressed feeds is a different workload from decoding many sources, compositing them, transcoding several outputs, or running NDI in a VPC. List simultaneous inputs, resolutions, codecs, frame rates and transforms.
What happens when the instance disappears?
Decide whether an event can restart on the same machine, needs a prepared second availability-zone path, or requires cross-region recovery. A backup that shares the same source, route and credentials is not independent.
Which data must survive compute?
Keep configuration, recordings and durable media outside disposable compute where appropriate. Define the copy, retention and restore procedure before a long event creates files faster than the team can move them.
Who pays for audience delivery?
Compute is only one cost. Model data transfer, CDN requests, storage operations, recordings and idle standby time. Use the current AWS calculator and pricing pages instead of copying a monthly figure from an article.
Match the AWS building block to the job
| Boundary | Typical choice | Acceptance evidence |
|---|---|---|
| Callaba control and compressed routing | General-purpose or compute-oriented EC2 sized from a representative Callaba workload. | Every planned input remains visible; routes and recording run without sustained CPU, memory, disk or network pressure. |
| Dense live transcoding | A compatible GPU, FPGA/media-accelerated or CPU profile selected for the exact codec matrix. | The full channel count, format changes and failover state run together. Do not extrapolate from one idle 1080p feed. |
| Managed AWS encode/package | MediaLive, MediaConnect or MediaPackage when their managed operating model fits the project. | Input, dual-pipeline behavior, output groups, alarms and downstream packaging are tested as one service chain. |
| Origin and archive | S3 or a purpose-built origin, with lifecycle and access controls matched to live and VOD media. | Segments, manifests and recordings can be read after compute is replaced; restore ownership is documented. |
| Viewer delivery | CloudFront in front of a valid HLS/CMAF origin when broad HTTP delivery is required. | Manifest freshness, segment availability, cache behavior and playback are checked from more than one region. |
Move an operating boundary to the cloud, not the whole facility
Moving live production to the cloud does not require a wholesale rebuild. A more useful first move is to choose one operating boundary the team can see, test and recover. For compressed contribution, that boundary can begin with SRT or RTMP ingest and continue through Multiview, transport checks, a configured recovery path, routing and recording.
Switching, graphics, venue audio, uncompressed production or an established playout chain can remain where they already work. Move another function only after the real event path—not a lab diagram—passes its acceptance test.
The centre boundary alternates between AWS and self-hosted placement. The two quiet route traces represent a primary interruption and a prepared alternate path; they do not claim hitless switching or a fixed recovery time.
1. See the signal
The intended feed is visible in Multiview, with decoded picture and audio—not only a connected socket.
2. Rehearse recovery
Interrupt the primary path and observe the configured alternate using the real encoder, destination, buffers and network. Keep the recovery contract explicit.
3. Prove the handoff
Confirm that the required recording and output survive the tested boundary before adding more sources or automation.
AWS and self-hosted deployment change who owns compute and network operations; they do not change the acceptance logic. Use the API only after the corresponding product workflow and state transition are understood. For an end-to-end rehearsal, follow the SRT, NDI, Multiview and recovery workflow.
Use availability zones deliberately
A second instance is useful only when it can receive a usable source and reach a usable destination during the failure you care about. AWS describes multi-AZ pipelines for stateful media services and publishes a separate cross-region live-streaming architecture. Use those patterns as design references, then test the smaller recovery boundary that your event actually needs.
- Prove the primary contribution and audience path.
- Prove the alternate source or receiver without the primary.
- Remove one dependency during a maintenance window.
- Observe recovery from the operator view and a clean audience client.
- Record recovery time and the manual action that was still required.
Keep NDI inside an explicit network boundary
Cloud NDI is not “the LAN, but farther away.” Discovery, source IPs, bandwidth, security groups and placement must be intentional. Keep related NDI applications in the required VPC and availability-zone design, and bridge unpredictable WAN contribution with an appropriate transport. AWS now documents MediaConnect workflows with NDI sources; Callaba also provides NDI discovery, adapters and UI-managed network configuration for its own production workflow.
Official AWS references worth keeping beside the runbook
- Guidance for Live Streaming on AWS for a managed ABR delivery reference.
- How MediaLive channels work for upstream, channel and output boundaries.
- CloudFront origin failover for supported HTTP failover behavior.
- EC2 VT1 when the deployed Callaba build and region support that accelerated profile.
Prove one Callaba workload before scaling the AWS design
Launch one real input, verify it in Multiview, route or record it, and collect the compute and network evidence. Use that trace to size the next event instead of starting with a generic architecture diagram.