Cloud infrastructure for a connected product is a recurring monthly cost that begins the day you ship and continues for as long as a single device is powered on in the field. Realistic ranges: a pilot fleet of a few dozen devices usually runs from nothing on a provider free tier to a few tens of dollars per month; a first commercial launch of a few hundred to a thousand devices typically lands in the low hundreds of dollars per month; a mature fleet of tens of thousands of telemetry devices commonly runs in the low thousands per month. Expressed per device, the number to aim for is a few cents to a few tens of cents per device per month. When it comes out far above that, it is almost always a design problem rather than a pricing problem.

What is actually on the bill

Connected-product infrastructure is not one service, it is a bundle, and each line is metered separately. Knowing the lines is how you find where the money burns:

  • Message ingest — the broker devices connect to. Priced by message count, message size tier, and concurrent connections.
  • Time-series storage — the database holding measurements. Priced by volume stored plus read and write operations.
  • Object storage for images, logs, firmware binaries, and exports.
  • Application compute — the API serving your app and dashboard, background processing, scheduled jobs, and reports. On real fleets this often becomes the largest single line, not messaging.
  • Identity and access — signup, login, password reset, multi-tenant organization management. Usually priced per monthly active user.
  • Egress — every byte leaving the cloud toward an app or a device is counted. On any product moving video or images, this dominates everything else.
  • Firmware distribution — hosting and pushing updates to the fleet, which is both storage and bandwidth. See OTA firmware updates.
  • Monitoring, logging, alerting, and backups — the easiest line to omit from a budget and the most painful one to be missing during an outage.

Platform choice shifts how these are packaged rather than eliminating any of them; the tradeoffs are compared in AWS IoT vs Azure IoT.

Where the cost actually comes from

Four parameters control nearly the entire bill, and all four are set during engineering specification, not later by a cloud engineer:

Reporting interval

A device reporting every five seconds costs roughly sixty times more to ingest and store than one reporting every five minutes. Most products do not need continuous streaming: report on a slow cadence, and send an immediate message only when a value crosses a threshold. This single decision moves the bill more than any other.

Payload size

A verbose JSON packet with long field names can be several times larger than a compact binary or short-key encoding. Both message-size pricing tiers and storage volume follow payload size directly. Protocol choice matters here too — see MQTT vs HTTP for IoT, where per-message overhead is a large part of the comparison.

Retention policy

Keeping raw samples forever is the most expensive habit in connected products. The workable pattern is short raw retention, then automatic rollup into hourly and daily aggregates, then archival to cheap cold storage or deletion. Decide the retention schedule before launch, because retrofitting it means writing a migration against a database that is already large.

Media

Any product uploading images or video changes the cost category entirely — storage plus egress plus any processing. Here the strongest lever is doing inference or filtering on the device so only relevant frames travel. That tradeoff is part of on-device AI in hardware products.

Cost you should not cut

Two lines are worth paying for from the first shipped unit: remote firmware update capability and proper security controls. Both are close to impossible to add credibly after a fleet is deployed, and the cost of not having them — a field recall for a bug that could have been patched, or a breach on customer data — is far larger than the infrastructure line. See IoT security for connected products. Also budget the dashboard: unbounded queries against a growing time-series database are one of the most common sources of a bill that quietly triples.

Build the estimate during specification

The estimate does not need sophistication, it needs to exist early. A simple sheet answers: messages per device per day, bytes per message, retention duration, number of dashboard users, and expected fleet size a couple of years out. Multiply, apply your provider's published rates, and you have a number good enough to make product decisions with. Do this while the requirements are still being written, alongside the hardware side of the budget in IoT product development cost.

From a technical number to a business decision

Once you know the monthly cost per unit, you can make the real decision: is the product sold once with cloud costs absorbed into margin, or does it carry a subscription that funds the service? If the cloud is where the value lives — remote monitoring, history, fleet management, predictive maintenance — a subscription is almost always the right structure, and the models are compared in hardware as a service. Either way, treat this as a genuine cost of goods sold line, exactly like a component, and remember it accrues on units that were sold years ago and are still online.

Get the number before you ship

Projects House designs the architecture for connected products and calculates the monthly infrastructure cost up front, so the business model is built on a real figure instead of a hope. If you are planning a connected product and want to know what its cloud will cost per unit per month, describe it through the contact form. More on the software layer of physical products in our software development guide.