This original engineering analysis separates verified protocol behavior from hypothetical capacity and cost assumptions. Replace illustrative numbers with production measurements before selecting architecture or signing a hosting contract.

Why a successful video call can still cost too much

A realtime AI avatar product depends on connectivity through home routers, corporate firewalls and mobile carriers. A peer-to-peer media path is preferable when reachable, yet some networks require a relay. TURN is a standardized way to exchange packets through an intermediate server when direct NAT traversal fails. The IETF’s February 2020 RFC 8656 describes that role precisely. The financial danger is treating every connected minute as if it used the same amount of network capacity. A relayed high-resolution call can traverse additional infrastructure, while a direct session may avoid that extra hop. The service should separate connectivity rate, relay ratio, media bitrates, cloud egress and resilience overhead. None of these factors should be guessed from a single staging call behind office Wi-Fi. Capacity planning begins with a trace of how actual clients negotiate and recover connections.

Instrument ICE outcomes without spying on content

Record session identifiers, negotiated transport candidate type, selected relay region, retry count, time to first media, duration, bytes transmitted and terminal reason. Capture aggregate carrier and country data where permitted, but avoid recording private conversations merely to debug packet routes. Metrics must distinguish sessions that use a relay from sessions that attempted a relay and fell back, as well as sessions that failed entirely. The TURN protocol defines relay behavior; it does not itself supply a business monitoring dashboard. Add structured logs from the client and TURN service, join them using a temporary session key and create a short retention policy. At the operational level, the crucial metric is the percentage of completed minutes that were relayed, not the percentage of connection attempts that contacted a TURN server. This distinction changes both the cost estimate and the engineering backlog.

A worked traffic scenario with transparent arithmetic

Assume one thousand daily ten-minute calls, of which 20% actually use a relay. Suppose average outbound media through the relay is 1.5 megabits per second and hypothetical metered egress costs nine cents per gigabyte. Under decimal units, two hundred relayed ten-minute sessions transmit roughly 22.5 gigabytes outbound: 200 times 600 seconds times 1.5 million bits divided by eight billion. That implies approximately $2.03 of this narrow egress component per day. It excludes inbound transfer treatment, server hours, standby capacity, protocol overhead, regional price differences and any additional media streams. These inputs are illustrative, not AWS or another provider’s current tariff. A production spreadsheet should also test double the relay ratio, a codec change and peak-hour concurrency. Accurate bills require matching the vendor’s actual charge units rather than copying numbers from an example.

Capacity is driven by concurrency and failure spikes

Daily minutes alone do not tell an operator how many sockets or relays must be provisioned. A thousand calls spread evenly across twenty-four hours behave differently from a thousand calls during a television live event. Model concurrent allocations, peak aggregate bitrate, idle timeouts, authentication renewals and regional failover. If one provider or region is unreachable, a sudden surge of fallback traffic may overload the backup relay pool. Rate-limit retries and give clients an explicit alternate candidate list rather than starting repeated unconstrained negotiations. Keep one tested low-bandwidth path so a poor network does not automatically turn into a black screen. Stress tests should reproduce packet loss, restrictive NATs, expired credentials, handover between cellular and Wi-Fi, and transient DNS failures. A percentage of successful direct calls is not a resilience metric if relayed recovery remains untested.

Compare latency and completion rather than bandwidth alone

A relay in the wrong geography can add an extra round trip that makes a lip-synced avatar feel unnatural. Measure first-frame time, speech interruption recovery and end-to-end media latency alongside relay costs. AWS Internet Monitor provides measurements and recommendations about internet performance for client locations, while Network Flow Monitor addresses performance of network flows within AWS. These are different layers; neither substitutes for client-side session quality measurements. For example, moving a relay closer to Japanese users may reduce media delay while increasing unit bandwidth charges. Estimate the business value using completed conversations and reduced abandonment, not an isolated millisecond claim. Use the same devices and test scenarios across locations. A lower average can hide a worse ninety-fifth percentile for important mobile networks, so publish the distribution.

A rollout gate for engineering and finance

Set launch gates for completion percentage, p95 first-media time, fallback success and a relay cost ceiling per successful call minute. Require an observable recovery path when a TURN allocation expires and record why a session ends. Before buying bigger instances, optimize relay selection and media bitrate where evidence shows a real problem. Review provider invoices against byte counters monthly and reconcile their units. When tests meet the agreed reliability target at an acceptable all-in cost, increase the rollout share gradually. Otherwise keep the change behind a feature flag and preserve the previous routing configuration. The useful output of capacity planning is not a single bandwidth prediction, but a defensible operating range that both engineers and finance can validate after real traffic arrives.

Document experimental conditions, review changes with engineering owners, and monitor outcomes after release rather than relying on architecture diagrams alone.

Sources

  1. IETF RFC 8656 TURN, February 2020
  2. AWS CloudWatch Internet Monitor documentation, accessed 26 October 2026
  3. AWS CloudWatch Network Flow Monitor, accessed 26 October 2026