Servers Without Servers, and the Real Question

Serverless means you write functions and event handlers, and the provider runs them on demand, bills per invocation and per gigabyte-second, and scales to zero when nothing is happening. For a connected product that promise is genuinely attractive: no instances to patch, no capacity to guess at, no monthly bill before the first customer.

The real question is not whether serverless works for IoT. It does, and large fleets run on it. The question is whether your traffic shape and your team make it the cheaper, simpler choice, because the same properties that make it excellent for a launching product make it awkward for a mature one.

What Serverless Actually Gives You

  • Zero idle cost. A backend serving three hundred beta units can run for $15 to $60 a month, versus a few hundred for an always-on cluster with managed databases and a load balancer.
  • Elasticity you did not have to plan. When ten thousand devices reconnect after a regional outage, the platform absorbs the spike. On a fixed fleet of instances that same spike is an incident.
  • Managed integrations. The MQTT broker, device registry, rules engine, authentication, and object storage come as services rather than as software you operate. A small team can stand up a credible connected-product backend in weeks.
  • Operational surface removed. No OS patching, no certificate renewal on your own load balancers, no cluster upgrades at midnight. For a two-person team that is real capacity returned to product work.
  • Natural event alignment. Device telemetry genuinely is an event stream, and rules-engine-to-function-to-datastore maps onto it cleanly.

Why It Fits a Product Early

Before product-market fit, you do not know your reporting interval, your payload size, your query patterns, or your fleet growth curve. Every one of those will change after real customers install real units. Serverless lets you be wrong cheaply. Change the reporting interval from 60 seconds to 10 and the bill moves; it does not require re-provisioning anything.

It also front-loads almost nothing. The upfront engineering to stand up ingest, storage, and an API is typically two to four weeks rather than the eight to twelve a self-managed stack takes, which matters when that time is competing with firmware and enclosure work in the budget laid out in IoT product development cost. And the managed device services on the major platforms, compared in AWS IoT vs Azure IoT, do the parts that are genuinely hard to build correctly: per-device identity, X.509 handling, shadow state, and fan-out.

Where It Starts to Hurt

Per-request pricing meets constant traffic. This is the decisive one. Serverless is priced for bursty, human-driven load. Device fleets produce steady load. A fleet of 10,000 units reporting every 30 seconds is 28.8 million invocations a day. At typical function pricing plus the messaging charges, that lands in the low thousands of dollars a month, where a pair of reserved instances handling the same rate might cost a few hundred. The crossover is real and arrives sooner than teams expect.

Cold starts. A function that has been idle takes 200 ms to over a second to respond, more with a heavy runtime or a VPC attachment. For telemetry ingest that is irrelevant. For an app command like unlocking a door or starting a motor, it is the difference between a product that feels instant and one that feels broken. Provisioned concurrency fixes it and reintroduces the idle cost you were avoiding.

Persistent connections. Functions are short-lived; device connections are long-lived. You end up on the provider's managed broker, which is fine, but it means the broker's quotas, message size limits, and pricing become your architecture. If your product needs a custom protocol or a non-standard keepalive, that abstraction stops fitting. The protocol economics behind this are in MQTT vs HTTP for IoT.

Database connections. Thousands of concurrent function instances each opening a connection will exhaust a relational database quickly. You need a connection proxy, or a serverless-native datastore, or the purpose-built store described in time-series databases for sensor data.

Debugging and long jobs. Distributed tracing across dozens of small functions is harder than a stack trace, and execution time limits, commonly fifteen minutes, rule out long batch processing. Local development also degrades: reproducing the cloud environment on a laptop is a permanent low-grade tax.

Portability. A backend built on one provider's rules engine, registry, and event bindings is not a weekend port. That is acceptable, but it should be a decision rather than a discovery.

Rules of Thumb

  • Fleet under a few thousand units, or highly variable traffic: serverless, almost without argument.
  • Steady high-volume telemetry above roughly ten thousand active devices: model the bill honestly against reserved compute before committing. The comparison belongs next to the numbers in IoT cloud infrastructure costs.
  • Hard latency requirements on control commands: keep the control path on always-warm compute or provisioned concurrency, whatever you do with telemetry.
  • Team of one to three engineers with no dedicated ops: serverless buys you people you do not have.
  • Regulated, on-premise, or air-gapped deployments: serverless usually cannot go there.
  • Best answer for most products: hybrid. Serverless for provisioning, OTA orchestration, alerts, scheduled jobs, and the customer-facing API; dedicated compute for the steady-state ingest pipeline. Splitting by traffic shape rather than by ideology gets you most of the elasticity and most of the cost efficiency.

The Decision Is Commercial as Much as Technical

Ask what your infrastructure cost per device per month can be. If you sell a $200 device with no subscription and expect a seven-year service life, you have a hard ceiling measured in cents per device per month, and that ceiling, not elegance, picks the architecture. If you charge $12 a month per device for a monitoring service, you have room and should optimize for speed of iteration instead.

Then ask what happens at ten times the fleet. If the answer is a bill that grows linearly with no path to bend it, plan the migration point now, while the migration is small. Whatever you choose, keep the device side flexible: an adjustable reporting interval and working OTA give you a cost lever that lives in firmware, and a dashboard built on precomputed rollups, as described in IoT device dashboards, keeps query cost from tracking fleet size.

Model It Before You Build It

Projects House sizes connected-product backends against real fleet projections, reporting intervals, and payload sizes, then builds the architecture the numbers actually support. Send us your device count, telemetry rate, and business model through our contact form and we will run the comparison with you.