AWS Elemental Link is a physical contribution device that can send a production feed to AWS Elemental MediaLive. It is not a complete streaming platform: you still need to configure encoding and choose how the stream will be packaged, delivered to viewers and played back.
To build an end-to-end system, decide what viewers should receive first, then work backwards through delivery, encoding and input. If you are asking, “How do I use AWS Elemental Link with MediaLive?”, the practical answer is to treat Link as one possible source in a larger workflow, not as the destination.
What Elemental Link does in the workflow
Elemental Link provides a physical path from production equipment into MediaLive. A camera or production setup supplies video and audio to the device; the configured Link input then makes that feed available to a MediaLive workflow over an AWS-managed secure connection. MediaLive is the service that ingests and transcodes the feed according to the channel configuration.
That distinction matters when you plan equipment and responsibilities. Link does not create the viewer-facing stream, publish a player, or distribute video to an audience by itself. It solves a contribution problem: getting a source from a venue or studio into the AWS processing stage. You must still decide what MediaLive should produce and where that output goes next.
Link is also not a mandatory input for every AWS streaming design. AWS reference material describes network input paths such as RTP, RTMP and HLS as well as Link. A network input may fit better if your source already produces a supported stream and a physical contribution device does not suit the venue. Check the current AWS documentation for supported devices, input types and service conditions before you order or design around a particular model.
It can help to picture a local news room with a camera and audio mixer. The camera and mixer create the programme; Link carries the contribution feed into MediaLive; MediaLive creates the configured output; and downstream services make that output available to viewers. If one of those later parts is missing, the camera can still be reaching AWS correctly while the audience has nothing usable to watch.
Map the full pipeline before creating a channel
Start with the viewer-facing result. Is the audience watching an event in a website player, receiving a stream through an app, or opening a playback endpoint in a supported client? What formats and resolutions must that experience support? Those decisions help determine whether you need an origin or packager, a content delivery network (CDN), and a player or playback device.
AWS recommends planning the systems before building the MediaLive channel, including upstream inputs and downstream destinations. In practice, sketch the path in this order: playback experience, delivery endpoint, packaging or origin, MediaLive outputs, then source. This is easier than creating a channel around the first available input and discovering later that its output does not suit your playback design. Review AWS’s MediaLive channel workflow guidance alongside its channel-planning workflow.
A simple diagram might read:
Camera and audio → Elemental Link → MediaLive → packager or storage origin → CDN → player
That is a planning model, not a requirement to use every component in precisely that arrangement. In an AWS reference architecture, MediaPackage can package adaptive-bitrate output for HLS, DASH and CMAF endpoints. Another reference design uses MediaLive to create adaptive-bitrate HLS segments, stores them in S3 and distributes them with CloudFront. These are examples of distinct downstream choices, not evidence that Link performs packaging or delivery.
Write down each hand-off, the team or service responsible for it, and what you will test at that point. For example, confirm that the source signal reaches MediaLive, that the channel produces the expected output, that the origin or packager exposes a playable endpoint, and that a viewer outside your production network can load it. A successful input test does not prove that the full audience path works.
Connect and prepare the source
Before configuring Link, identify the exact source you intend to contribute. Note the camera or switcher output, audio source, any captions, and the connections available at the venue. Check that the production equipment’s signal matches the Link device and workflow requirements described in AWS’s Elemental Link setup documentation. Do not assume that a device supports every format or connection simply because it is part of an AWS workflow.
Plan the physical installation as well as the software steps. Decide where the device will sit, how it will receive power, how the production feed will reach it, and how it will connect to the network. A permanent studio and a temporary event venue have different risks: a fixed installation can be labelled and checked before each broadcast, while a temporary setup needs a repeatable connection and signal check after transport. The source, Link device and network all need to be ready before you troubleshoot MediaLive.
Network planning is part of contribution planning. Check that the venue’s connection is suitable for sending the chosen feed, and establish who can investigate if connectivity changes during a broadcast. If the venue network is shared, confirm that another user’s large transfer or a routine network change will not unexpectedly disrupt the production path. Avoid assuming that a device’s secure connection eliminates the need to test the local network between source and AWS.
Link UHD may also be used with MediaConnect in workflows where that fits the design. That is a separate architectural choice to verify against current AWS guidance; do not treat it as an automatic substitute for the MediaLive input arrangement. If your source is already a network stream, compare the available input methods against the venue’s output and the workflow you want to operate. The appropriate source path depends on what your production equipment can reliably deliver.
Keep a source checklist near the equipment: confirm the intended video and audio feed, check that the source is active, verify device and network status, and record which input you expect to select in the AWS workflow. For a YouTube-focused creator used to software scenes, the guide to fixing an OBS scene that goes black covers a different part of the chain: checking the programme before it leaves the production setup. That sort of source-side check is useful whether the contribution path is hardware or software.
Configure MediaLive to ingest the feed
Once the source path is prepared, create the MediaLive input and channel to match the actual feed and the downstream plan. The input represents where MediaLive receives the contribution; the channel brings that input together with the processing and output configuration. Follow the current AWS guidance for configuring a Link device and using it with MediaLive, rather than relying on settings copied from a different production.
Before choosing encoding settings, write down the characteristics that matter to the output: video dimensions and frame rate, audio layout, captions if required, and the codecs and containers accepted by the next service. A small devotional channel sending a fixed-camera programme may have different requirements from a multi-camera event with captions and multiple playback formats. The channel should reflect the programme and intended delivery, not just the highest setting available in a console.
Plan for what happens when the contribution feed is interrupted. Decide who will notice, what they will check first, and whether the production has another source or recovery procedure. A resilient design may use redundant input feeds; AWS’s Live Streaming reference architecture is one example that uses two feeds. That does not mean every small channel needs the same arrangement. Redundancy has operational and cost consequences, so match it to the value of the event and the time you can spend monitoring it.
When you first test the channel, verify more than a green status indicator. Confirm that the expected video and audio are present, that the output looks and sounds right, and that downstream services receive it. A channel can process a technically valid signal that still contains the wrong camera, muted audio, or an unwanted overlay. Check with a real viewer path before treating the configuration as ready.
Plan encoding and downstream output
MediaLive transcodes the incoming feed into the outputs you configure. Decide which profiles you need based on audience devices and network conditions, then check that the next part of the workflow accepts those outputs. Adaptive-bitrate (ABR) output offers multiple renditions so a compatible playback path can select a suitable rendition; it also means more output streams and more downstream handling than a single rendition.
AWS’s reference designs illustrate two useful patterns. The Live Streaming solution uses MediaLive ABR HLS output with MediaPackage, which can expose HLS, DASH and CMAF endpoints. The Live Streaming with Amazon S3 design uses MediaLive for ABR HLS, puts the encoded segments in S3 and distributes them with CloudFront. The latter design lists several possible input paths, including Link, which is another reminder that the hardware is optional rather than the platform itself.
| Planning choice | MediaPackage pattern | S3 and CloudFront pattern |
|---|---|---|
| Downstream role | Packages output into supported streaming endpoints | Stores HLS segments and distributes them through a CDN |
| Formats described in the reference | HLS, DASH and CMAF | HLS segments |
| Useful question | Do you need the packaging options and endpoints this design provides? | Does an S3-hosted HLS path fit the playback requirements? |
| What to validate | Endpoint configuration, player compatibility and service availability | Segment delivery, S3 and CloudFront configuration, and player compatibility |
The table is a comparison of AWS reference patterns, not a universal ranking. Select an architecture by tracing a viewer’s playback request back to the output that must serve it. If you need formats or behaviours that a chosen path does not provide, change the design before you commit to a channel configuration.
Encoding profiles also affect both the viewing experience and the bill. Higher-resolution output requires more processing and can increase the amount of data delivered; multiple renditions create additional encoding and delivery work. AWS’s deployment guide offers HD-1080p, HD-720p and SD-540p profile choices in its CloudFormation-based solution. Treat these as choices in that solution, not a promise that every channel should use them or that they are the only valid profiles.
Add origin, CDN and playback
MediaLive’s output needs a destination that serves the playback design. An origin or packager accepts output and presents it in a form a player can request; a CDN distributes the content closer to viewers; and the playback device or website presents it. Depending on the architecture, some roles can be combined or handled by different services, but they do not disappear because Link is connected.
For the MediaPackage route, configure the intended output and endpoints, then connect a compatible player or playback experience to the endpoint. For the S3 route, ensure the segment and playlist objects are placed and served as intended, then configure distribution and playback to use the correct path. Do not assume that a MediaLive channel automatically creates a polished website or embeds a player. The viewer-facing experience is a separate part of the build.
Test the full route from outside the production environment. Use a device and network similar to those your audience is likely to have. Check that playback starts, audio and video remain in sync, and the player can continue requesting segments. Also inspect the end of the path after changes: a healthy source and channel do not tell you whether an endpoint, CDN configuration or player was changed incorrectly.
A continuous channel needs an operating plan as well as a technical diagram. Decide who receives alerts, how they distinguish a source problem from a delivery problem, and how the stream is restored after an interruption. Maintain a short runbook with the source checks, MediaLive input and channel details, downstream endpoints and escalation contacts. Test the recovery steps while the stakes are low rather than waiting for an overnight fault.
If your actual requirement is a fixed video loop on YouTube rather than a camera contribution workflow, this AWS pipeline may be more than you need. A folder-of-videos YouTube Live workflow addresses that different source pattern. For a channel that switches clips on a schedule, see the practical considerations in automatically switching videos in a 24/7 stream. Match the system to the programme: a hardware contribution chain is not inherently better when the content is a prepared playlist.
Region, operating effort and cost
A useful plan compares input fit, output requirements, reliability and service availability before comparing a headline cost. Check that the required services and solution are available in your chosen AWS Region. AWS’s solution guidance also notes Region considerations for deployments that use MediaConnect flows; verify the current requirements for the exact architecture you intend to launch.
Cost depends on configuration and audience, including encoding profile, broadcast duration, packaging choices and viewer delivery. AWS’s guide gives an illustrative estimate of approximately $69.74 for a one-hour SD-540p event with roughly 1,000 viewers in US East (N. Virginia), including about $67.24 for CloudFront distribution. The publication year was not stated in the retrieved guide, so this is a guide-specific example, not a current quote or a forecast for your channel. Distribution is a substantial part of that example, which is why the audience path and viewing volume belong in your estimate alongside MediaLive settings.
Build your own estimate using current regional prices, expected hours, output bitrates and audience traffic. If viewers are spread across regions or watch for different durations, model that pattern rather than assuming every event resembles the example. Recheck any AWS price and deployment assumptions immediately before committing; services, device conditions, templates and regional availability can change.
AWS’s CloudFormation solution guide estimates about 20 minutes for deployment, but that is a template estimate rather than a project duration. It does not include every decision, integration, test or approval that a real production may need. Read the current template prerequisites and test in the intended Region before planning a launch date around the estimate.
The operating choice should include who maintains the pipeline. A self-managed AWS build offers control over the components and configuration, but your team must understand and maintain the input, channel, delivery path and playback experience. A managed tool aimed at a simpler fixed-file YouTube channel may reduce the work of keeping a computer running, but it will not replace a camera-to-MediaLive production architecture. StreamNeo addresses the specific burden of keeping an uploaded file on air on YouTube without leaving your computer switched on; it is not a substitute for the AWS contribution and delivery design described here.
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 Elemental Link create a complete live-streaming platform on its own?
No. Link is a contribution input device for getting a production feed into an AWS workflow. MediaLive ingests and transcodes the feed, and you must also plan the output, packaging or origin, distribution and playback needed by viewers.
Do I have to use Link with MediaLive?
No. AWS reference designs include RTP, RTMP and HLS input paths as well as Link, so select an input that matches the signal your production can reliably provide. Check current AWS documentation for device compatibility, supported inputs and any workflow-specific conditions.
Should I use MediaPackage or S3 and CloudFront?
They are different reference patterns, not interchangeable answers for every project. MediaPackage can package output as HLS, DASH and CMAF in the documented architecture, while the S3 design stores HLS segments and uses CloudFront for distribution. Start with player and endpoint requirements, then confirm the chosen services are available in your Region.
Is AWS’s published event estimate what my stream will cost?
No. The approximately $69.74 example is tied to a particular one-hour SD-540p event, audience assumption and Region, and the guide does not state a publication year. Use current AWS prices and your own configuration, duration and audience traffic to estimate the actual workflow.