Livestream From Your Phone to AWS with IVS (and What Every Setting Means) Livestream From Your Phone to AWS with IVS (and What Every Setting Means)

I wanted the simplest possible way to livestream from my phone to other devices, and it turns out AWS makes it genuinely easy with Amazon IVS (Interactive Video Service), no server to run, no app to build. You point a free broadcaster app at IVS and share a playback link. Done.

But the create-channel wizard throws a dozen settings at you (channel type, latency, ingest, container format), and it’s not obvious what any of them mean. So this is the full walkthrough and a plain-English explanation of every setting, ending with a real stream from my phone.

What Amazon IVS is

IVS is managed live streaming, built on the same technology behind Twitch. You give it video; it handles ingest, transcoding, and global delivery, and hands you a playback URL. It comes in two flavours: Low-latency streaming (broadcast to an audience, what we’re using) and Real-time streaming (WebRTC, sub-second, for interactive/two-way).

One design detail worth knowing: IVS is a global service with regional control. Delivery to viewers is worldwide, but you create and manage the channel in a specific region.

Getting started is a single button, AWS even estimates it at 1–2 minutes:

Latency, throughput, and scale

• Latency (Low-latency streaming): glass-to-glass latency is usually under 5 seconds, and can be under 3, fine for watch-live with light interaction (chat, reactions).
• Latency (Real-time streaming): if you need true two-way, IVS Real-time uses WebRTC for under ~300 milliseconds.
• Throughput / input: you can ingest up to 1080p video; keep your input within IVS’s recommended limits (around 8.5 Mbps max) with a 2-second keyframe interval for clean transcoding.
• Scale (output): delivery runs on a global CDN, so one channel fans out to very large concurrent audiences with nothing to provision, that’s the point of a managed service.

Where it’s available (regions)

IVS is a global service with a regional control plane: delivery to viewers is worldwide, but you create and manage channels in one of these regions:

• US East (N. Virginia) us-east-1
• US West (Oregon) us-west-2
• Europe (Ireland) eu-west-1
• Europe (Frankfurt) eu-central-1
• Asia Pacific (Tokyo) ap-northeast-1
• Asia Pacific (Seoul) ap-northeast-2
• Asia Pacific (Mumbai) ap-south-1

Creating the channel, what every setting means

This is the part that confused me the first time, so here’s each option decoded.

Default vs Custom configuration

• Default configuration — sensible defaults, optimized for live interactions. Pick this if you just want it to work.
• Custom configuration — lets you choose the channel type and latency yourself. I chose Custom so I could see (and explain) every knob.

Channel type, the one that drives quality and cost

What to care about: transcoding = adaptive bitrate, IVS makes several quality versions so a viewer on a weak connection auto-drops to a lower resolution. Standard gives the best experience; Basic is cheapest but everyone gets exactly the stream you send (no auto-downgrade). For a test, Basic saves money; for a real product with viewers on mixed networks, Standard is worth it.

Video latency, playback auth, ingest, container format

• Video latency — Low vs Normal. Low (a few seconds) is best when viewers interact with the broadcaster; Normal is higher delay but can be more reliable in some regions. For watch-live, choose Low.
• Playback authorization. Off = anyone with the playback URL can watch (what you want for a public/test stream). On = playback requires a signed token (private streams), more setup. I left it off.
• Insecure ingest (RTMP). Off means IVS only accepts RTMPS (encrypted). Keep it off and stream securely, every decent broadcaster (including Larix) supports RTMPS.
• Container format — MPEG-TS vs fMP4. Leave it on MPEG-TS. fMP4 is only needed for Multitrack Video Input (an advanced feature). Not relevant here.

Channel created

Click create and you get a success screen with a three-step “get started” (Broadcast → Playback → Monitor) and the channel’s ARN and type.

The three values you actually need

Scroll to Stream configuration and Playback configuration. Three things matter:

• Ingest server — an rtmps://... URL your phone pushes video to.
• Stream key — your secret credential (click Show to reveal). Anyone with this can stream to your channel, keep it private.
• Playback URL — an .m3u8 (HLS) link viewers open to watch.

Broadcasting from your phone (the gotcha step)

Install a broadcaster app that supports RTMPS. I used Larix Broadcaster, but any of these work the same way, you just point them at the IVS ingest URL + stream key:

• Larix Broadcaster — free, iOS/Android (what I used)
• Streamlabs — mobile + desktop, popular and beginner-friendly
• Prism Live Studio — free mobile broadcaster
• OBS Studio — free desktop, the most popular streaming software (great from a laptop + webcam)
• Wirecast / vMix — professional desktop production tools
• FFmpeg — command-line, for scripted or automated streams
• IVS Broadcast SDK — build broadcasting into your own iOS/Android/web app (and no watermark)

Add a new connection in whichever you pick. Here’s the part that trips everyone up:

IVS does not use username/password RTMP auth. The stream key is your credential, and it goes on the end of the URL.

• Name: anything (e.g. IVS)
• URL: the ingest server with the stream key appended after /app/:

  rtmps://<your-ingest>.global-contribute.live-video.net:443/app/YOUR_STREAM_KEY
  

• RTMP authorization: None — leave username and password blank.

Save, then tap the red button to go live.

It’s live

Back on the channel page, the built-in preview player shows the stream, State: LIVE, Health: Healthy, viewers counting, and audio coming through:

To watch on other devices, open the Playback URL:

• iPhone/Mac: paste it into Safari — it plays natively.
• Any device: VLC → Open Network Stream → paste the URL.

The gotchas I hit (so you don’t)

What it costs (and how to not overpay)

IVS bills two things, and only while there’s activity:

• Input — an hourly rate while you’re broadcasting, set by channel type, flat with no volume tiers. Standard is $2.00/hour — the same in every Region. Advanced HD is $0.85, Advanced SD and Multitrack Full HD are $0.50, and Basic is $0.20. This is per stream, not per viewer.
• Output — an hourly rate per viewer (the console preview tab counts too), varying by resolution (HD > SD > audio-only) and the region it’s delivered from. Unlike input, output is tiered by monthly volume. In North America, HD output runs $0.072/viewer-hour for the first 10,000 hours a month, then $0.066, $0.060, $0.056, and $0.048 above 500,000.

Rough worked example — a 1-hour Standard stream watched by 10 HD viewers in North America: $2.00 input + (10 × $0.072 output) = $2.00 + $0.72 = ~$2.72 for the hour.

Note the shape of that, because it is the thing worth internalising: input is flat per stream, output scales with your audience. Divide one by the other and the crossover is $2.00 ÷ $0.072 ≈ 28 concurrent HD viewers — below that the broadcast itself dominates your bill, above it the audience does. Which side of 28 you expect to live on decides whether channel type or output resolution is the lever worth pulling.

Keep it cheap:

1. Stop the broadcast when done (ends input cost).
2. Close the preview tab and viewer devices (ends per-viewer output cost).
3. Use Basic for testing; Advanced SD/HD or Multitrack to cut transcoding cost in production.

An idle channel that isn’t streaming or being watched costs nothing, but tidy up when finished.

Which IVS mode should you use?

• Broadcasting to an audience (one-to-many) → IVS Low-latency streaming (what we did).
• Interactive / two-way (guests joining, video calls, live shopping) → IVS Real-time streaming (WebRTC, sub-second).

IVS vs Kinesis Video Streams: which service?

IVS isn’t AWS’s only video service, and the one it’s most often confused with is Kinesis Video Streams (KVS). Picking wrong is a classic mistake. The simplest framing:

IVS = broadcast video to people. KVS = ingest video from devices for storage and machine learning.

Ask yourself (the senior version):

1. Who or what consumes the video — humans watching a broadcast (→ IVS), or software/ML processing it (→ KVS)?
2. Do I need to store it for hours, days, or years? → KVS (IVS is not a recorder).
3. Do I need computer vision on the stream? → KVS + Rekognition.
4. Do I need huge concurrent audiences at low latency? → IVS.
5. Is it a camera/sensor feeding video for later review (security, monitoring)? → KVS.

If you’re building “let users go live to an audience,” it’s IVS (this article). If you’re building “cameras that record and get analysed,” it’s KVS — a different pipeline, and a good topic for its own piece.

Wrapping up

From nothing to a live phone stream watched on other devices took about fifteen minutes and zero code: create an IVS channel, understand the handful of settings (Standard vs Basic is the one that matters for cost/quality; keep ingest secure, playback public for a test), append your stream key to the RTMPS URL in Larix, and watch via the playback URL in Safari or VLC. Managed streaming really is the easy path, the only hard parts are the two or three gotchas above, and now you have those too.

References and Further Reading

• Amazon Web Services. Amazon IVS Low-Latency Streaming User Guide.
• Amazon Web Services. IVS channel types.
• Amazon Web Services. Setting up for streaming (ingest).
• Amazon Web Services. Amazon IVS pricing.