AWS Media Services is an umbrella term, not a single destination you can select in OBS. First identify whether you are publishing to an Amazon IVS low-latency channel, an IVS real-time stage, or an AWS Elemental MediaLive RTMP VPC push input; each has its own setup and connection details.
Once the AWS resource exists, configure OBS for that specific workflow and use the endpoint and credentials AWS generated for it. Do not copy an endpoint or stream key from an example, or assume that instructions for one of these products will work with another.
Choose the AWS ingest product
Start with the job you need the AWS service to do. An IVS low-latency channel is a broadcast destination: OBS sends a programme to a channel, which can then be viewed through its playback path. An IVS real-time stage is designed for real-time participation; a publisher sends media to a stage using an ingest configuration associated with that stage. MediaLive is a separate video-processing service, and the path covered here is an RTMP push input configured for a VPC.
| Destination | Typical publishing task | What OBS needs | Important distinction |
|---|---|---|---|
| IVS low-latency channel | Send a broadcast to an IVS channel | The channel's ingest details and stream key, using a supported channel protocol | Use the channel's own settings; AWS documents RTMPS and an SRT workflow |
| IVS real-time stage | Publish a participant's media to a stage | A stage-associated ingest configuration, its RTMP(S) endpoint and its stream key | This is a stage publishing workflow, not a low-latency channel setup |
| MediaLive RTMP VPC push input | Push an RTMP feed into a MediaLive input configured for a VPC | The input's own setup, networking and credentials | It is not interchangeable with IVS endpoint and key instructions |
If you are building a continuous public channel, check first that a broadcast channel is the product you intend to operate. If your application needs people to publish into a shared real-time session, examine the stage workflow instead. If MediaLive is already part of a video-processing design, follow its input-specific network and access requirements rather than starting with an IVS tutorial.
For a YouTube-only 24/7 loop, an AWS ingest destination may add a step you do not need: you still need a path from the resulting programme to YouTube. A useful comparison is whether you need a live production encoder or simply want a prepared file to keep broadcasting. For the latter, our guide to running a YouTube loop on a low-cost VPS explains a different operating model. Choose according to the output you need, not just the fact that OBS can connect to an ingest endpoint.
Prepare OBS Studio
Install OBS Studio and make sure the programme you want to send is visible in its preview. Sources such as a webcam, capture card, browser element or display capture build the scene; they are not prerequisites for connecting OBS to AWS. If you are sending a finished video, add it as a media source and confirm its audio and video before configuring the destination. The OBS Studio overview describes the basic role of scenes, sources and streaming settings.
Next, set the encoder to a format accepted by the selected AWS service. Do not treat one service's limits as a general AWS rule. The specific restrictions documented for IVS real-time RTMP, for example, are not automatically the restrictions for an IVS low-latency channel or a MediaLive input. Start from the destination's current documentation, then choose a resolution, frame rate, bitrate and keyframe interval OBS can sustain on your connection.
Before going live, check that your upload connection is stable enough for the configured video and audio. A local preview can look correct while the outgoing bitrate fluctuates or the source has no audio. Use OBS's statistics and a short test broadcast to catch dropped frames, unexpected scaling, or silent audio before viewers depend on the stream. For long-running channels, decisions about file size and programme rotation are separate from ingest; see our guide to storage for a 24/7 YouTube stream in India.
Keep the AWS stream key private. Treat it like a password for publishing: do not put it in a public screenshot, share it in a support forum, or commit it to a public script. If you believe it has been exposed, use the relevant AWS console or service procedure to replace or rotate the credential, then update OBS.
Connect OBS to an IVS low-latency channel
Create or select the IVS low-latency channel in AWS before configuring OBS. The channel's ingest endpoint and stream key belong to that channel; obtain the actual values from its AWS details rather than copying a sample. AWS's getting-started guide for streaming with OBS presents an OBS workflow using RTMPS. Its documented quick start uses OBS Studio v30.2 or later and recommends a two-second keyframe interval; check the current guide and your channel settings when following it.
In OBS, select the Amazon IVS service option where available, then enter the channel's stream key in the stream key field. Use the channel-specific endpoint and settings supplied by AWS. Do not put a real key into an article, shared checklist or image. The selected service integration is for the channel workflow; it does not convert OBS into a generic AWS sender for stages or MediaLive.
AWS's IVS low-latency setup guide also documents an SRT route. For that documented configuration, choose Custom in OBS and construct the server value from the channel's SRT endpoint, port, stream ID and applicable passphrase as supplied by AWS. Leave OBS's separate stream-key field empty for this SRT setup. These fields differ from the RTMPS channel setup, so do not move the stream key into the SRT URL or reuse an RTMPS address as an SRT server.
Use RTMPS where the selected workflow supports it. It uses TLS for the connection, but that does not change the need to protect the credential itself. Protocol names and endpoint formats matter: choose a protocol the resource supports and use the corresponding values AWS provides for that resource. If the endpoint, key or protocol is unclear, return to the channel's AWS details rather than guessing.
Use the IVS real-time stage workflow when applicable
A real-time stage needs a stage-associated ingest configuration before OBS can publish to it. Create that configuration through the IVS workflow and record the endpoint and stream key it returns. The IVS RTMP publishing documentation describes publishing to a stage, including the configuration OBS needs.
In OBS, open Settings > Stream, select Custom, and set Server to the stage ingest configuration's RTMP or RTMPS endpoint. Put that configuration's stream key in Stream Key. AWS recommends RTMPS. The ingest configuration's insecureIngest setting defaults to false, so plain RTMP is not accepted unless you deliberately enable it. Do not use a low-latency channel's service option, endpoint or key here: the stage has its own ingest configuration.
The real-time RTMP workflow has constraints that should shape your OBS output. AWS documents H.264 video, no B-frames, input resolution up to 720p and video bitrate up to 8.5 Mbps. It recommends a one- or two-second keyframe interval, and settings such as veryfast and zerolatency are relevant to this real-time mode. These are stage RTMP details, not a universal preset for every AWS service.
A bitrate target at the service ceiling leaves little room for encoder variation. AWS notes that an encoder can briefly exceed its target; its example advises setting a maximum below the ceiling, such as 6 Mbps. Choose settings based on the stage documentation and your actual content, then verify the outgoing stream rather than assuming a configured target is an absolute cap. If your programme is a lecture playlist, the source and rotation plan still matter; our guide to looping an exam-prep lecture playlist on YouTube Live covers that separate content workflow.
Understand the MediaLive RTMP VPC push path
MediaLive is not another name for IVS. The path in scope is an RTMP VPC push input: a source pushes into a MediaLive input associated with VPC networking. AWS's RTMP VPC input setup guide describes the AWS-side work, including VPC configuration and a role for MediaLive to assume.
That AWS-side setup is essential. OBS cannot create the MediaLive input, establish the necessary VPC configuration, or arrange the role on your behalf merely because you press Start Streaming. Before configuring OBS, complete the input setup and check the input's own endpoint and credentials in AWS. Ensure the machine running OBS can reach the destination as required by the chosen VPC design; if networking is not already in place, resolve that with the person responsible for the AWS environment.
Do not paste an IVS channel URL or stage ingest key into a MediaLive input. Likewise, do not use a MediaLive input endpoint in the IVS service selection. The commonality is only that OBS can send a stream; resource creation, network reachability, protocol details and credentials come from the selected product's setup. If you only need to broadcast a prepared file continuously to YouTube, a VPC push input may be more operational complexity than your use case requires.
Configure the product-specific endpoint and stream key
Keep a small record of which AWS resource you are configuring and where its connection values came from. A channel endpoint is not a stage endpoint, and a MediaLive input's RTMP credentials do not become valid for IVS. Use the resource's current console or CLI output and avoid relying on values copied from a tutorial, even one showing the same product.
| OBS field or choice | IVS low-latency channel | IVS real-time stage | MediaLive RTMP VPC push |
|---|---|---|---|
| Service choice | Amazon IVS integration where supported; use the documented SRT custom path for SRT | Custom | Configure from the MediaLive input's own setup |
| Server or endpoint | Channel-specific endpoint for the selected protocol | Ingest configuration's RTMP(S) endpoint | Input-specific RTMP details from MediaLive |
| Stream Key field | Channel key for the documented RTMPS path; empty for the documented SRT method | Ingest configuration's key | Use the credentials specified by the input workflow |
| Protocol note | AWS documents RTMPS and SRT setup paths | Prefer RTMPS; insecure RTMP is off by default | Follow the RTMP VPC input documentation |
The table is a way to keep workflows distinct, not a source of endpoint values. It intentionally does not provide a sample host or key: AWS assigns values to the resource you create, and substituting a plausible-looking example can send you down the wrong path. If OBS asks for fields that do not match the selected service's documentation, stop and check the product and protocol before proceeding.
When credentials change, update the matching OBS profile and remove old copies from notes or shared systems. If you maintain several channels, label profiles with the service and resource name rather than a vague label such as “AWS live”. That small habit reduces the risk of sending a programme to the wrong destination during a late-night restart.
Verify the selected workflow before going live
Test the AWS side and the OBS side together. Confirm that the intended channel, stage or MediaLive input is active and that the endpoint details correspond to it. In OBS, inspect the preview, audio meters and stream settings, then start a short test and check the selected AWS destination for an incoming feed. A successful connection to one AWS resource says nothing about a different resource's configuration.
If no feed appears, work through the path in order. Recheck that the OBS service and protocol match the AWS product; verify the endpoint and key were copied from the same resource; confirm that the stage ingest configuration exists, or that MediaLive's VPC and role prerequisites are satisfied. Then inspect encoder settings against that product's documentation. For stage RTMP, check the H.264, B-frame, resolution, bitrate and keyframe requirements. For IVS channel SRT, confirm the server components and passphrase, with the key field left empty in the documented workflow.
Once the short test works, watch for stable audio and video and check the AWS-side status before relying on the feed. A successful start in OBS is not proof that viewers can access the downstream playback or application. For YouTube-specific discovery, scheduling and viewer access, AWS ingest is only one part of a larger chain; our guide to helping viewers find YouTube live streams covers the audience-facing side.
For a 24/7 channel, also decide who or what will notice if the local encoder or network drops. OBS running on a desktop depends on that machine, its power and its connection. If your particular problem is that a computer must stay on to keep a file-based YouTube broadcast running, StreamNeo removes that specific burden by letting you upload the video and provide the YouTube stream key so the broadcast can continue without your computer running; it is YouTube-only, not an AWS ingest destination. If OBS remains the right choice, plan for monitoring and a tested restart procedure rather than assuming the stream will recover by itself.
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 I choose “AWS” as a universal OBS destination?
No. AWS Media Services includes products with different ingest workflows. Choose an IVS low-latency channel, IVS real-time stage or MediaLive input first, then use that resource's own instructions and connection details.
Should I use RTMP or RTMPS?
Use the secure protocol supported by your selected resource; AWS recommends RTMPS for IVS real-time RTMP publishing. A real-time stage's insecureIngest defaults to false, so plain RTMP requires an intentional setting change. Do not assume another AWS product has the same protocol options.
Does the 720p limit apply to every IVS stream?
No. The 720p maximum, 8.5 Mbps video ceiling and no-B-frames requirement described here apply to IVS real-time RTMP publishing. Check the current documentation for the exact channel or input you are using before selecting OBS encoder settings.
Can I use an IVS stream key for MediaLive?
No. MediaLive RTMP VPC push uses its own input setup, networking and credentials. Create and configure the MediaLive input first, then follow its documentation rather than reusing an IVS endpoint or key.