Ubiquiti pays the relay POP egress out of their AWS bill - and they keep it survivable by silently capping every off-LAN stream to the substream, not by capping you in writing.
The relay infrastructure is Ubiquiti-operated. cloudaccess.svc.ubnt.com resolves to around 2,970 IPs on Amazon CloudFront, UDM Pro debug logs put the control plane in AWS us-west-2 on AWS IoT topics, and the data plane is whatever CloudFront POP is closest to the viewer. CloudFront egress lists at roughly USD $80-$120 per TB at retail tiers. Naively, "10 sites x 8 cameras x 4 Mbps x 24/7" works out to around 10 TB per day of relay egress per customer, which would run a low-five-figures USD monthly AWS bill per heavy user. That is not what's happening - and there are three reasons why.
1. STUN-brokered P2P first, relay only as a fallback. The NVR holds an outbound socket to AWS; when a viewer opens a camera, AWS introduces the two endpoints and the media flows peer-to-peer over a UDP hole-punch. Ubiquiti pays the signalling cost (cheap) but not the media bytes (expensive). Users posting their firewall logs on r/Ubiquiti regularly see the NVR start uploading to a residential IP the instant they open the Protect app - that's the hole-punch in action. The relay only carries the media bytes when symmetric NAT or strict outbound firewalls defeat STUN, which is most enterprise networks but very few homes.
2. The substream cap is the bandwidth ceiling. When the path does fall back to the relay, Ubiquiti forces the off-LAN viewer onto the camera's H.264 "preview" substream rather than the main archive bitstream. The in-product banner says it in plain English: "A local connection helps reduce latency and maximize resolution during your viewing sessions." A substream is typically 480p-720p at 500 Kbps - 1 Mbps; the archive stream is 4-8 Mbps. So the "10 sites x 24/7" workload is closer to 10 x 8 x 0.5 Mbps = around 40 Mbps of relay throughput, not the headline 320 Mbps. At sub-$1 per camera per month in CloudFront egress, that's economically sustainable. Ubiquiti never has to publish a byte quota because the codec choice does the rationing for them.
3. The ToS catch-all backstops the maths. Ubiquiti's May 2024 Terms of Service reserve the right to "terminate or suspend your access to or right to use all or part of the services without notice... if Ubiquiti determines, in its sole and absolute discretion, that you... have engaged in any conduct otherwise harmful to the interests of Ubiquiti." There is no published "fair use" byte ceiling, no MB/GB language, no per-account quota - just a unilateral kill option for any account whose relay traffic becomes unprofitable. No public IPVM, Reddit, or community.ui.com thread surfaces a confirmed throttling or cut-off event, which suggests the substream cap is effective enough that few consumers ever hit the wall.
4. Client-side caps further bound the relay. Vantage Point (the only first-party multi-NVR SOC tool) caps at 5 NVRs per workspace. Multi-view caps at 16 streams in the iOS app and 26 streams on web/Android. So even a 7,000-site bank with 100 SOC operators is structurally limited to 100 x around 20 active streams x around 500 Kbps = around 1 Gbps of relay throughput, not the headline 7,000 x 24/7 number. And that customer would not be on Cloud Access anyway - the named integrator population running Protect at >1,000-camera control-room scale has publicly moved to a different VMS for exactly this workload - u/corsalove, a Ubiquiti installer himself, says outright on r/UnifiProtect that Protect is not the correct software for a 1,000+ camera control room and his team runs a different VMS for the monitoring layer.
Where this leaves the SOC / multi-site buyer. The "no fees, ever" claim is technically true: Ubiquiti is not invoicing the customer for the relay. But the off-LAN viewing experience that comes with it is fundamentally a low-bitrate preview, not the recording; the only documented multi-NVR SOC tool caps at 5 NVRs; and the service is governed by a unilateral kill clause rather than a contracted bandwidth commitment. There is zero published IPVM coverage of a named Protect SOC deployment and zero Ubiquiti case study of a named ARC customer - the absence is itself the answer. Verkada, Rhombus and Eagle Eye take the opposite shape: camera or bridge uploads continuously to the vendor cloud, cloud is the canonical source for every viewer, multi-viewer fan-out is paid for once on the site-to-cloud upload, archive-quality is the only quality, and the bandwidth cost is explicit on the camera licence. TetherX sits in between: a TetherBox at the site brokers, and the customer chooses per camera which streams stay LAN-only (zero ongoing cost), which become cloud-resident at archive quality (priced explicitly per camera), and which use the cloud only as failover. No silent quality cap, no client-side keep-alive cliff, no sole-discretion suspension. Choosing the architecture is the point.
