ARR-OTA All articles
Engineering Deep Dive

Egress, Data Caps, and a Million Devices: The Real Price Tag of Pushing Firmware

ARR-OTA
Egress, Data Caps, and a Million Devices: The Real Price Tag of Pushing Firmware

Photo: Columbus Metropolitan Library, No restrictions, via Wikimedia Commons

Every engineering team budgeting for an OTA program accounts for the obvious line items: build servers, signing infrastructure, a fleet management dashboard. Very few account for the bill that shows up later, often in finance's inbox rather than engineering's: the cost of moving bytes to devices.

That cost is easy to ignore at a thousand devices. At a million, it becomes a line item worth engineering against. Here's where the money actually goes, and what you can do about it.

The Three Places Your Update Budget Leaks

CDN egress. Most OTA systems serve update artifacts through a CDN or cloud object storage. Object storage itself is cheap — pennies per gigabyte. Egress is not. Depending on provider and region, moving a 40MB firmware image out to the public internet can cost more than storing it for a year. Multiply by download retries, partial downloads restarted from scratch, and devices that poll for availability without downloading, and your "free" update starts looking like a bandwidth contract.

Cellular connectivity. For fleets on LTE-M, NB-IoT, or consumer cellular plans, the cost model inverts entirely. You're not paying per gigabyte to a cloud provider — you're paying per device, per megabyte, to a carrier. A connected vehicle telematics unit or a smart meter on a managed data plan has a hard ceiling, and a carelessly sized update can blow through a month's allocation in one download. In the US, where many IoT deployments ride on pooled data plans, one fleet segment downloading eagerly can starve another.

Redundant traffic. The sneakiest cost is the one that shouldn't exist: devices re-downloading artifacts they already have, metadata polled too aggressively, or manifests fetched in full when a conditional request would have returned a 304.

Delta Patching: The Single Biggest Lever

If your update payloads are full images, you're paying to ship the 98% of the firmware that didn't change. Binary diffing — generating a patch containing only the changed regions between two versions — routinely reduces payloads by 90–99% for typical firmware iteration.

The economics compound quickly. Consider a 40MB image with a 400KB patch:

On cellular fleets, the difference isn't just dollars — it's feasibility. A 400KB patch fits inside a metered data plan; a 40MB image doesn't. Delta updates turn "we update quarterly because of connectivity costs" into "we update weekly."

The engineering caveats are real: patch generation requires keeping base images for every version still in the field, patch application must be atomic and power-fail safe, and A/B partition schemes make the math cleaner at the cost of storage. But none of these are unsolved problems. Treat them as table stakes.

Compression and Container Hygiene

Beyond delta patching, audit what's actually inside your artifact. Embedded build systems accumulate dead weight: debug symbols shipped to production, duplicate static libraries, uncompressed assets that a dictionary compressor would destroy. Running your firmware image through bloaty or a size-reporting CI check is a one-afternoon exercise that pays for itself on every subsequent rollout.

For payloads that are already compressed, verify you're not double-compressing at the transport layer — it wastes CDN CPU and, occasionally, actually inflates the payload.

Scheduling: Smooth the Spike, Keep the Velocity

Delivery cost isn't just about payload size; it's about concurrency. A million devices told "update is available" simultaneously will hammer your origin, trigger rate limiting, and maximize peak egress billing in some contracts.

Instead:

None of this slows your ability to ship quickly when it matters. An emergency security patch should still be able to propagate aggressively; the point is that default behavior should be economical, with velocity available as an explicit override.

Put a Price on Each Rollout

The teams that manage OTA economics well do one simple thing: they instrument cost per update the way they instrument crash-free rate. Bytes served, bytes per device, cost per successful update, broken down by network type. When those numbers are visible on a dashboard next to deployment metrics, trade-offs become obvious. A 15% artifact size reduction stops being an abstract optimization and becomes a quantified saving on every future rollout.

Firmware delivery is one of the few engineering domains where the physics of the problem — bytes over wires — maps directly onto the finance of the problem. Engineers who understand egress pricing and carriers who understand firmware constraints are both rare. The teams that bridge the gap ship more often, for less, and with fewer surprises at the end of the month.

All Articles

Related Articles

Your Fleet Is a Lab: Running Controlled Experiments on Devices With OTA Channels as Cohorts

Your Fleet Is a Lab: Running Controlled Experiments on Devices With OTA Channels as Cohorts

The 1% Fleet: Engineering Progressive Deployment for Devices That Can't Run Kubernetes

The 1% Fleet: Engineering Progressive Deployment for Devices That Can't Run Kubernetes

The 40KB Firmware Update: How Binary Diffing Slashes OTA Costs at Fleet Scale

The 40KB Firmware Update: How Binary Diffing Slashes OTA Costs at Fleet Scale