AI, LLM and real-time · WebRTC · LiveKit
A WebRTC platform for mobile apps built on the LiveKit SFU: token-based access, UDP and TURN/TLS connectivity, server-side recording to S3, webhooks, ingress for streams and scaling across nodes and regions.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
The app resolves the regional LiveKit hostname. Latency-based records in Route 53 steer users to the nearest healthy cluster.
The user authenticates to your backend (Cognito or your IdP). The token service checks business rules, then mints a short-lived LiveKit access token (JWT) with grants for one room: join, publish, subscribe, and any recorder or admin rights.
The SDK connects with the token over WebSocket signalling and negotiates media. UDP is preferred. If networks block it, ICE falls back to TCP and to TURN over TLS on 443, which passes most corporate and mobile carrier firewalls.
The load balancer forwards to LiveKit nodes. Nodes are exposed with host networking and a public IP each, because media flows directly between client and node and does not benefit from a layer 7 proxy.
Nodes register in Redis so any node can find the node that owns a room, and so autoscaling can add capacity without downtime.
A recording request (room composite or per-track) starts Egress workers that join the room as a hidden participant and render video with headless Chrome or write tracks directly.
Egress uploads MP4, HLS or track files to S3, using a task role scoped to the recordings prefix.
LiveKit posts webhooks (room started, participant joined, egress ended) to a receiver that verifies the signature and publishes events to EventBridge for billing, notifications and post-processing.
Ingress accepts RTMP or WHIP streams from encoders and publishes them as participants, which is useful for broadcasts or hardware cameras.
| Component | What it does | Why this choice |
|---|---|---|
| LiveKit server (open-source SFU) | Selective forwarding of audio and video with simulcast, dynacast and data channels. | An SFU scales to many participants per room, unlike a mesh, and costs less than an MCU that mixes on the server. |
| Amazon EKS with managed node groups | Runs LiveKit, Egress and Ingress with the official Helm charts. | Rolling node upgrades and autoscaling. Use compute-optimised instances with good network throughput. |
| Network Load Balancer | TLS on 443 for TURN and signalling, UDP for STUN and TURN. | Layer 4 keeps latency low. Media typically uses node public IPs, with the NLB handling signalling and TURN. |
| Token service (Lambda, Cognito) | Authorises users and issues scoped JWTs with the LiveKit API key and secret. | The API secret never reaches the app. Tokens are short-lived and room-scoped. |
| ElastiCache for Redis | Shared state for multi-node routing, and for Egress and Ingress job queues. | Required when you run more than one node. |
| LiveKit Egress and Ingress | Recording, composite layouts, streaming out and RTMP or WHIP in. | Runs as separate scalable services so media forwarding is not slowed by encoding. |
| S3 with KMS | Recording storage with lifecycle to colder tiers and deletion for retention. | Durable and cheap, and recordings are personal information that need retention rules. |
| EventBridge and Lambda | Webhook fan-out for notifications, billing and analytics. | Decouples your business logic from the media plane. |
Self-host or LiveKit Cloud
Why. Cloud removes the hard parts: global edge, scaling and TURN operations.
Trade-off. Self-hosting makes you responsible for UDP networking, capacity planning and upgrades.
Media topology
Why. Each client uploads once and receives only the quality its bandwidth supports.
Trade-off. Higher server egress than peer-to-peer, but reliable for more than two participants.
Connectivity
Why. Mobile and corporate networks often block UDP.
Trade-off. TURN relays media through your servers and adds bandwidth cost for those users.
Node layout
Why. Avoids NAT and kube-proxy overhead on UDP and keeps CPU predictable.
Trade-off. Less bin-packing and higher idle cost than shared nodes.
Regions
Why. Latency is dominated by distance to the SFU.
Trade-off. Participants far from the room's region get worse latency. Check LiveKit's current cross-region options if you need them.
Short-lived room-scoped JWTs, DTLS-SRTP media encryption, secrets in Secrets Manager, security groups limited to required ports and private Redis.
Multiple nodes across AZs, health checks and graceful draining on deploy. Clients reconnect automatically and can resume.
Bandwidth, not CPU, is usually the first limit. Use simulcast, dynacast and appropriate instance network performance, and load test with the LiveKit load tester.
Data transfer out dominates. Recording, TURN relays and egress rendering add compute and transfer.
Helm and Terraform, Prometheus metrics from LiveKit, node-pool autoscaling on CPU and participants, and a rehearsed upgrade procedure.
Scale node pools down off-peak, record only when required and apply retention policies to recordings.
Public subnets for media nodes (each needs a reachable address), private subnets for Redis, Egress and Ingress. Open UDP for the configured media port range (or a single muxed port), TCP 7881 for ICE over TCP, and 443 and 3478 for TURN, with security groups restricting everything else. Check the current LiveKit deployment guide for exact ports.
Your IdP or Cognito authenticates the user. The token service authorises each room join. LiveKit API keys live only in the token service and the server. Egress writes to S3 with an IRSA role limited to one prefix.
Audio and video are personal information, and recordings can contain sensitive conversations. Notify participants and capture consent where recording, encrypt with KMS, set retention, and restrict access to the recordings bucket. Media is end-to-end encrypted hop by hop, not between participants, unless you enable LiveKit's end-to-end encryption.
| Control | How this design addresses it |
|---|---|
| Restrict administrative privileges | No static keys on nodes, IRSA roles and scoped token grants. Essential Eight. |
| Patch applications and operating systems | Managed node groups and a regular LiveKit upgrade cadence. Essential Eight. |
| Collection and consent | Recording notices and consent support APP 3 and APP 5. |
| Security of personal information | Encryption, retention and access logging support APP 11. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
| Failure mode | Mitigation |
|---|---|
| Node failure mid-call | Clients reconnect and rejoin. Design the app UI to show reconnecting state. |
| UDP blocked on the user's network | ICE fallback to TCP and TURN over TLS 443. |
| Capacity exhausted during a peak | Autoscale on CPU and participant count with headroom, and use node selection that avoids new rooms on hot nodes. |
| Recording job fails | Webhook on egress_ended with status, retry policy and alarms on failed egress. |
EC2 compute and network egress for media, TURN relayed traffic, Egress rendering and S3 storage.
WebRTC · Amazon Chime SDK
A managed real-time platform on AWS: a Meetings API backend, mobile and web clients, media regions close to users, SIP media applications for phone calls and media pipelines for recording, all driven by Lambda and EventBridge.
Google Cloud
A private, governed Gemini and Model Garden inference platform: Cloud Armor at the edge, Cloud Run for the application, Vertex AI over Private Service Connect, Pub/Sub for async jobs and BigQuery for audit and cost analytics.
Azure
A governed Azure OpenAI platform: Front Door and API Management as the AI gateway, private endpoints, Entra ID managed identities, AI Search for retrieval, Content Safety, Cosmos DB for conversation state and Monitor for cost and quality.
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.