To create a live video channel with Amazon IVS, create a channel in the AWS console or with the AWS CLI, connect a compatible encoder using its ingest endpoint and stream key, then watch the result using its playback URL. The stream key authorises broadcasting and must be kept private; the playback URL is for viewers.
Choose the AWS region before creating the channel, and manage it from that region afterwards. Recording to S3 is an optional addition, not a requirement for a live stream. The route below starts with the console, then covers encoder choices, playback checks and common problems.
What an Amazon IVS channel provides
An IVS channel is a regional AWS resource that accepts a live contribution and makes the resulting stream available to viewers. Creating one gives you separate details for those two jobs: an ingest endpoint and stream key for the broadcaster, and a playback URL for the audience. Do not confuse them. The stream key is a secret credential that permits contribution; the playback URL is the address used to watch.
The channel does not create the video content or choose your camera, microphone or encoder settings. You supply a live source, such as a desktop encoder or a browser-based application, and configure it to match the channel type. If you have a recorded video that you want to show continuously rather than a live camera or programme feed, that is a different production question: first determine how you will provide the video as a live source, then confirm the method meets IVS input requirements.
IVS supports contribution over RTMPS, RTMP and SRT. AWS recommends RTMPS unless you have a specific, verified reason to use RTMP. This distinction matters when following generic encoder instructions: a service name alone is not enough; the protocol, endpoint and authentication fields need to match what the IVS channel provides.
For a one-off camera test, the console’s broadcast flow can be a direct way to check the channel. For a more controlled programme, OBS gives you familiar control over scenes, audio sources and output settings. If you are building a browser product, the IVS Web Broadcast SDK is the relevant integration path rather than a desktop encoder. The right choice depends on what is producing your show, not on which route sounds most advanced.
A live video channel also has costs and operational responsibilities. AWS’s setup guidance warns that live-video input is charged; the setup material does not establish a current dollar rate. Check the current official pricing and quota information for your intended region and use before relying on a budget. Keep a separate check of your YouTube publishing setup too: IVS makes its stream viewable, but it does not remove YouTube account or feature restrictions. Use the YouTube live streaming restriction check before planning a public launch.
Choose a region and create the channel
Begin with an AWS account and the IAM permissions needed to create and manage IVS resources. If you do not administer the account, ask the account owner to confirm access before you begin. Creating resources without the necessary permissions can turn a straightforward setup into a permissions investigation.
Select the AWS region in the console before choosing Create Channel. A channel belongs to the region in which it was created, and IVS resources in different regions are independent. Return to that region when you need to manage this channel later. The contribution source can be somewhere else, and viewers can watch from elsewhere; that does not make the channel itself regionless.
In the Amazon IVS console, open the channel area in your chosen region and select Create Channel. You can accept the default configuration or enter a name. Names do not have to be unique, so record the channel’s ARN if you need an unambiguous resource identifier for later administration. Console labels can change, so use AWS’s current getting started guide for IVS low-latency streaming if the steps on screen differ from these descriptions.
For an initial setup, the console is generally easier to follow than command-line creation: you can see the channel’s settings and output details together. The CLI is supported but is an advanced route. AWS’s basic example is aws ivs create-channel --name test-channel. The command’s response includes channel details and a stream key; handle the response as sensitive output, and do not paste it into a public terminal transcript or ticket.
Before creating anything, decide whether you need recording. You can leave it off and still broadcast and view a live stream. If you do want automatic recording, create or choose a recording configuration associated with an S3 bucket, then attach that configuration during channel creation. The recording choice can add setup and storage considerations, so it is worth making deliberately rather than selecting it simply because it appears in the channel workflow.
Find the ingest endpoint and protect the stream key
After creation, locate the channel’s ingest server and stream key, as well as its playback URL. The first two are broadcaster details. Enter them only into the encoder or application that is authorised to contribute. The playback URL is the audience-facing value you use to test viewing or share with viewers, subject to your intended distribution.
A stream key is not a viewing link and is not safe to publish. Someone who obtains it may be able to send a broadcast to your channel. Avoid including it in screenshots, public source code, shared documents, chat messages or logs. Store it where the people responsible for operating the stream can retrieve it, and limit access to those who need to configure or maintain the broadcast.
If you suspect that the key has been exposed, use the AWS console or supported API workflow to replace or rotate it, then update the encoder with the new value. Until the encoder is updated, it will not be able to authenticate using an old key. Treat this as a credential change, not as a change to the public playback address.
For SRT, expand the additional ingest options if needed and note the endpoint and passphrase values supplied for that protocol. The passphrase, like the stream key, is sensitive. Do not substitute the playback URL for an ingest endpoint, or use an RTMPS setting with SRT credentials. If a field’s purpose is unclear, check the channel details and the current AWS IVS streaming configuration documentation before entering secrets into an encoder.
A useful hand-off note for a small team can label values by purpose without reproducing secrets: “encoder endpoint”, “contribution credential”, and “viewer playback URL”. This reduces a common copy-and-paste mistake when one person creates the channel and another configures OBS. If you are maintaining several channels, include the AWS region and channel name in that note as well, but keep credentials in a private credential store rather than in the note itself.
Connect an encoder or browser broadcast SDK
Choose the broadcast method that matches your source. The IVS console camera-and-microphone flow is useful for a quick manual check, provided your browser has permission to use the selected devices. OBS is a practical desktop route when you need scenes, media sources or audio mixing. A web application should follow the IVS Web Broadcast SDK quickstart and initialise the client with the channel’s ingest endpoint and a broadcast preset.
For OBS, use a supported recent version; AWS’s guide specifies OBS Studio v30.2 or later. In the service selection, choose Amazon IVS, then enter the stream key from the channel. Confirm the protocol and endpoint in the channel’s ingest details, rather than assuming an endpoint copied from another service will work. AWS’s OBS setup instructions for IVS give the console-specific sequence.
Set resolution and bitrate within the limits for your channel type. Those limits are not interchangeable across every configuration, and exceeding an allowed input can disconnect the stream. Check the channel type and current AWS guidance before settling on output values. AWS recommends a two-second keyframe interval in its encoder guidance. Treat this as a setting to configure and verify, not a guarantee that a particular network or audience device will behave identically.
Use RTMPS by default where your encoder supports it. AWS describes RTMPS as using TLS 1.2 or later and recommends it unless a specific verified use case requires RTMP. SRT is another supported route; it uses port 9000 and requires the supplied endpoint and passphrase. If you have a legacy workflow that appears to require plain RTMP, check that need with the software documentation and AWS guidance rather than choosing the less protected protocol by habit.
For the browser SDK, make sure the broadcast preset matches the backend channel type. The client and channel configurations must align; a preset that does not fit the channel can fail even when the endpoint is correct. Follow the Web Broadcast SDK quickstart for the current initialisation flow, and avoid putting credentials into browser code that is publicly served. A browser application needs a secure way to obtain authorisation for an intended broadcaster; do not treat the stream key as an ordinary client-side setting.
Latency mode is another decision, not an encoder checkbox that solves every delay. The API describes LOW for near-real-time interaction and NORMAL for broadcast and delivery up to Full HD, with LOW as the default. Consider whether viewers need to react promptly, such as during a call-in session, or whether a broadcast-style delay is acceptable for a music or study stream. AWS describes low-latency delivery as capable of being under five seconds, but that is a service capability rather than a promise for every end-to-end route. AWS also says to use the Amazon IVS Player for the lowest-latency mode; third-party HLS players are not supported for that lowest-latency use.
Start the stream and view playback
Once the encoder is configured, check that the intended camera, scene or media source is selected and that the output settings match the channel. Start the broadcast from the encoder. Then open the channel’s playback tab in the IVS console or load the playback URL in a suitable player. This is the audience-side test; it is separate from whether the encoder has accepted the ingest credentials.
A stream may not appear at the exact instant you press Start. AWS’s console guide says playback typically becomes viewable after a brief delay, usually under 30 seconds. If the player remains blank beyond that initial wait, check whether the encoder reports an active connection, then inspect the channel status and the output log before changing several settings at once.
Keep the playback URL distinct from the stream key in any test instructions. You can use the playback address to share a viewing test with a colleague without giving them permission to broadcast. AWS advises against proxying the playback URL through a custom domain. If you want to embed playback on a site or deliver a YouTube stream using a separate workflow, check the relevant current product documentation rather than assuming that a URL can be rewritten freely.
For a channel intended to run continuously, a short successful test is only the first check. Confirm the picture, sound, overlays and transitions you expect viewers to see, and observe the stream long enough to notice obvious input or network instability. For a devotional music channel, for example, check that the audio source is present and not muted after a scene change. A practical OBS audio-monitoring setup for a 24/7 stream can help you hear problems locally while you verify the output.
If your operational plan is to send the same video to a YouTube live channel, remember that an IVS playback URL and a YouTube ingest key have different purposes. Confirm which service is receiving the encoder contribution and which player or platform your audience will use. Keep the publication workflow, title and audience access settings on the destination platform separate from IVS channel configuration.
Optional recording to S3
Recording is an optional branch for keeping a copy of the live output. It is not needed to make the IVS live stream viewable. If you want it, configure an S3 bucket and an IVS recording configuration, then associate that configuration with the channel. The console supports enabling automatic recording as part of setup; the CLI path requires creating the recording configuration and bucket before referencing it.
This choice affects more than a checkbox. Decide who should access the stored files, how they will be used, and how you will manage them in S3. Check the current AWS documentation for bucket permissions, supported configuration and storage charges before enabling recording. The setup research confirms live-video input charges but does not establish current dollar rates, so do not build a cost estimate from old figures or assumptions. Verify current AWS pricing for both the live channel and any storage or related services you plan to use.
If you only need to confirm a stream is live, playback is the direct check; recording does not make that check more valid. If you need a later copy for review or another workflow, recording may be useful, but test that the configuration produces the output you expect before relying on it. Keep access to the bucket and any recorded material aligned with your organisation’s audience and retention requirements.
Check channel status and common setup issues
When the stream does not appear, troubleshoot in a fixed order. First confirm that you are viewing the channel in the region where it was created. Next check whether the encoder is connected and whether it is sending a compatible protocol to the channel’s actual ingest endpoint. Then verify that the stream key or SRT passphrase is current and entered into the correct field. These checks catch basic region, endpoint and credential mismatches without repeatedly recreating the channel.
If the encoder connects but the stream fails or drops, compare its resolution and bitrate with the limits for the channel type. Confirm the keyframe interval and inspect the encoder’s own output status. Do not respond to every failure by raising bitrate: a setting outside the accepted channel limits can be the cause rather than the cure. If settings appear valid, consult the current AWS troubleshooting and quota guidance for the channel and account.
For a black or silent playback, separate contribution from presentation. Check the selected scene, media source, camera permissions and microphone input at the encoder. Confirm that the playback tab or player is using the channel’s playback URL, not its ingest endpoint. If the stream is being produced by a browser application, recheck that its broadcast preset matches the channel type and that its permission flow completed.
Before a scheduled launch, check service quotas and the account’s ability to create and operate the resources you need. AWS’s getting-started recommendations also include considering safeguards against undesired content and viewers. These are account and channel operating decisions; creating a channel alone does not resolve them. If your eventual audience is on YouTube, separately test the destination channel and stream workflow. A pre-launch test for an Indian music YouTube stream is a useful checklist for that separate destination-side work.
For a long-running stream, plan for what happens when the source or contribution connection stops. IVS channel setup gives you a broadcast path, but it does not remove the need to monitor your production source and respond to failures. If you are using an encoder you operate, decide who will check it and how it will be restarted; this guide to restarting an FFmpeg YouTube livestream automatically covers a different platform workflow, but highlights the separate operational question of recovery.
A final preflight is simple: region and channel identified, ingest details kept private, encoder output within channel limits, playback URL tested, and recording configured only if you need it. Keep the current AWS console and documentation close at hand, because service quotas, supported regions and console wording can change. Do not infer approval, cost or end-to-end performance from a successful test on one connection.
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
Where do I find my IVS stream key?
Open the channel details in the AWS region where you created it, then find its ingest information. The stream key is a private broadcaster credential, not the playback address; enter it only into the intended encoder or authorised application.
How do I stream OBS to Amazon IVS?
In OBS, select Amazon IVS as the service and enter the channel’s stream key, using the channel’s ingest details and a protocol supported by the configuration. Keep resolution and bitrate within the channel-type limits and use the recommended keyframe interval from AWS guidance.
How do viewers watch an IVS live stream?
Use the channel’s playback URL or the console’s Playback tab to verify viewing. Share that URL with viewers as appropriate, but never share the stream key as if it were a viewing link.
Do I need S3 recording for a live IVS channel?
No. Recording to S3 is optional and is separate from live playback. Add a recording configuration only if you have a reason to retain a copy, and check current AWS permissions and pricing before enabling it.