Insights / Cloud & Connected Systems
How to Choose an IoT Platform: Types, Pricing Models and Lock-in
How to choose an IoT platform on durable grounds: what it must do, build vs buy, pricing against your usage, device management, lock-in and who owns the data.
The short answer
Choose an IoT platform by how well it fits your devices, your usage and your exit plan, not by the length of its feature list. Decide first how much you want to own: a managed message broker, a managed IoT platform, or an end-to-end application. Then price each option against a realistic usage profile, check device provisioning and over-the-air updates, and confirm you can export your data and move your devices if the vendor changes or retires a service. Cloud vendors do retire IoT services, so design for that.
Key takeaways
- Decide how much of the stack you want to own before comparing vendors.
- Price every option against the same usage profile: devices, messages, payload size and connection time.
- Provisioning and over-the-air updates matter more in year three than dashboards do in month one.
- Keep the device-facing contract (identity, protocol, topics) under your control so a platform can be replaced.
- Confirm every service in a proposal is current and available to new customers.
Why the platform choice outlives the first release
An IoT platform is the middleware between connected devices and the applications built on their data. It sets your operating cost model, how devices are identified and updated, and where data lives. Those choices are expensive to reverse once thousands of devices in the field depend on them.
Vendor catalogues also change. Products that appeared in earlier comparisons, including Google's Cloud IoT Core and several Azure IoT offerings, have since been retired or reorganised. Teams that built directly on a retired service had to migrate devices and back-end code on the vendor's timetable. The durable question is therefore not which vendor is best today, but which architecture lets you keep control when a service changes.
Where a platform sits in an IoT system
IoT systems are commonly described in five layers: devices that turn physical parameters into data; connectivity or gateways that carry it; edge computing that pre-processes data close to the source; the platform layer that collects, processes and stores data, monitors resources, updates device software and secures the system; and the application layer that people use. A platform can cover one of these layers or several.
For a fuller walk through each layer, see IoT solution anatomy.
| Capability group | What it covers | Why it matters |
|---|---|---|
| Application management | Development environments, modelling tools and digital twins for building IoT applications | Sets how fast you can build and change product features |
| Device management | Deploying, configuring and monitoring devices, and patching device firmware and edge software | Decides whether a fleet can be operated without site visits |
| Data management | Storage, analysis (including machine learning) and visualisation of device data | Decides what you can learn from the data and where it lives |
A small air-quality monitor shows the split in practice. The ESP32 reads four sensors and publishes over Wi-Fi; the managed platform receives the messages, routes readings to a database behind the frontend and sends alarms as notifications.
Types of IoT platforms
Platforms differ by which part of the system they cover. Each type brings a different kind of dependency.
| Type | What it covers | Good for | Dependency to watch |
|---|---|---|---|
| Hardware-specific | Software tuned to a manufacturer's boards, SoCs or modules | Fast start on that vendor's hardware | Growth is tied to one hardware supplier |
| Connectivity / M2M | Communication between devices and data centres over cellular, Wi-Fi, Bluetooth and protocols such as MQTT, AMQP, DDS or LoRaWAN | Moving data reliably across networks and regions | Little help with processing or device lifecycle |
| Analytics | Analysis and visualisation of collected data | Finding patterns and reporting on them | Your data model and history live in the vendor's store |
| Application development | Tools, templates and layouts for building end-user applications | Quick operator and customer interfaces | Applications may not move to another platform |
| End-to-end | Device management, data, applications and support across all layers | Teams that want one supplier for the whole stack | The deepest lock-in if any part no longer fits |
The large public clouds sit mostly in the end-to-end and connectivity categories, offering managed device connectivity alongside general compute, storage and analytics services. Their strength is integration with the rest of their cloud; their weakness, for a newcomer, is a large catalogue of overlapping services where choosing the wrong combination is costly to undo.
Build vs buy: how much of the stack to own
The most useful first decision is not which vendor, but which level of the stack you will run yourself.
| Option | You run | The provider runs | Fits when |
|---|---|---|---|
| Self-hosted open-source broker and services | Broker, device registry, update service, storage, scaling and security | Infrastructure only, if hosted in a cloud | Data must stay on premises, or cost at scale justifies an operations team |
| Managed message broker | Device registry, updates, rules and storage | Connectivity, scaling and availability of the broker | You want control of device management and data with less infrastructure work |
| Managed IoT platform | Your business logic and integrations | Connectivity, device registry, provisioning, twins or shadows, rules | Most connected products, where speed matters and usage is predictable |
| End-to-end IoT application (SaaS) | Configuration and users | Almost everything | Standard monitoring use cases and fast time to market |
For how these levels map to cloud service models and shared security responsibility, see SaaS, PaaS and IaaS for IoT.
IoT platform pricing models
IoT pricing takes several forms, and some platforms combine them, which adds flexibility but makes estimates harder.
| Model | You pay for | Rewards | Penalises |
|---|---|---|---|
| Traffic-based | Number and size of messages to and from devices; processing and storage usually billed separately | Devices that filter and batch at the edge | Chatty devices and large payloads |
| Connection time | Total duration of device connection sessions | Devices that connect briefly and sleep | Always-connected devices |
| Per device | Each unique connected device | Fleets of fewer, higher-value devices | Large fleets of cheap sensors |
| Combined | A mix of the above, often with tiers | Usage close to the tier design | Usage that crosses tier boundaries |
Device provisioning, updates and security
The platform must support the hardware you plan to use and let you manage, monitor, group and update devices remotely. Provisioning is where platforms differ most in practice. A well-designed flow registers devices at scale without a person configuring each one.
- EnrolThe manufacturer adds the device's identity to an enrolment list before shipping.
- First bootThe device contacts the provisioning service using an identity stored at manufacturing, such as an X.509 certificate or a TPM key.
- Verify identityThe service checks the identity against the enrolment list.
- AssignThe service registers the device with the right hub, region or customer tenant and records its desired state.
- ConnectThe device receives connection details and connects to its assigned endpoint.
- Sync stateThe device reads its desired configuration from its twin or shadow and starts reporting.
Re-provisioning reuses the same flow when a device changes owner, region or configuration.
- One identity per device: every device gets its own certificate or key. Never share one credential across a fleet.
- Least privilege: each device may publish and subscribe only to its own topics.
- Certificate lifecycle: track expiry and plan rotation before the first certificates in the field expire.
- Fleet audit: watch for unusual traffic volumes, unexpected endpoints and devices that change behaviour.
- Signed updates: over-the-air updates are signed and verified before install, with a way to recover from a failed update.
Lock-in, data ownership and the exit plan
Some lock-in is the price of moving fast. The aim is to choose it knowingly. Lock-in builds up in a few predictable places: proprietary device SDKs, platform-specific twin or shadow formats, rules engines, analytics stores, and hardware that only works with one cloud service.
- Own the device-facing contract. Use standard protocols such as MQTT, and define your own topic structure and payload schema rather than adopting a vendor's.
- Keep a firmware abstraction between application code and the vendor SDK, so the connectivity layer can be swapped.
- Make device identity portable. Prefer certificates from a CA you control, so devices can authenticate to a new endpoint.
- Export data continuously to storage you own, in an open format, not only through the platform's API.
- Plan endpoint migration. Devices need a secure way to receive a new endpoint and credentials over the air.
If your organisation already runs on one cloud, extending it is often sensible: identity, networking, billing and team skills already exist there. That is a good reason to choose a vendor, as long as the device-facing contract stays yours.
When the platform must work offline
Unreliable connectivity stops many deployments. The major clouds offer edge runtimes that deploy containerised modules or functions to gateways, so devices keep collecting, filtering and acting on data when the internet is down, then sync when it returns. Filtering locally also reduces traffic-based costs.
An edge runtime extends the platform's reach and its lock-in onto your hardware. Check which operating systems and processor architectures it supports, how modules are updated and rolled back, and what happens to local state during a long outage. See edge computing and IoT for how to decide which functions belong at the edge.
Engineering trade-offs
Managed IoT platform vs managed broker plus your own services
- You gain
- A managed platform gives provisioning, twins, rules and fleet tools on day one.
- You pay
- Its data model, pricing and service lifecycle become part of your product.
- Choose it when
- A managed platform when speed matters and usage is predictable; a broker plus your own services when device management or data must stay yours.
Your existing cloud vs the best-fit specialist platform
- You gain
- Staying on your cloud reuses identity, networking, billing and skills.
- You pay
- Its IoT services may fit your devices or pricing less well than a specialist's.
- Choose it when
- Stay on your cloud unless a specialist covers a hard requirement, such as protocol support or regional coverage, that your cloud does not.
Vendor device SDK vs standard protocol with your own client
- You gain
- The vendor SDK handles connection, retries and twins with less code.
- You pay
- Firmware becomes tied to that vendor's endpoint and features.
- Choose it when
- Use the SDK behind an abstraction layer; keep topics, payloads and identity in your own design.
Decision matrix: which level of platform fits
Start from fleet size, team and data constraints; the platform level follows.
| Device | Time to first devices | Control of device management | Cost behaviour at scale | Exit effort |
|---|---|---|---|---|
| End-to-end SaaS | Fastest | Low | Rises with devices or tiers | High |
| Managed IoT platform | Fast | Medium | Rises with traffic | Medium to high |
| Managed broker plus own services | Moderate | High | More predictable | Low to medium |
| Self-hosted open source | Slowest | Full | Infrastructure and team cost | Low |
Decision rule: Most connected products start on a managed IoT platform or managed broker, with the device-facing contract kept in their own design. Move down the table only when data control or cost at scale justifies the operations work.
How to test a shortlist
Run every option through the same scenario before committing:
- Write one end-to-end scenario, such as a device reporting status and an operator receiving an alert, and ask each option to walk through it.
- Estimate monthly usage: devices, messages per device per day, message size and connection time, at launch and at target scale.
- Price each option against that profile, including storage, processing and data transfer.
- Check support for your hardware, protocols and the network coverage you need in each region.
- Walk through provisioning, a failed update and certificate rotation for one device.
- Confirm on the vendor's own documentation that every service is current and available to new customers, and record the date of the check.
- Write down what leaving would take: data export, device endpoint change, firmware changes.
Common mistakes
Comparing feature lists instead of a scenario
Two attractive proposals turn out to solve different problems.
Instead: Keep one scenario constant across every option.
Pricing from the headline rate
Separately billed storage, processing and data transfer appear after launch.
Instead: Price a full usage profile at target scale.
Building on a vendor's device model directly
A retired or repriced service forces a firmware and back-end migration on the vendor's timetable.
Instead: Keep identity, topics and payloads in your own design behind an abstraction.
Shipping with tutorial security policies
Every device can act for every other one.
Instead: Use per-device credentials and per-topic permissions.
Hardware that only works with one service
Devices become obsolete if the service changes or is withdrawn.
Instead: Choose hardware and firmware that speak standard protocols.
Questions engineers ask
What pricing models do IoT platforms use?
Mainly traffic-based pricing (messages and payload size), connection-time pricing, per-device pricing, or a combination with tiers. Storage, processing and data transfer are often billed separately, so price a full usage profile rather than the headline rate.
What should you check when selecting an IIoT platform for asset monitoring?
Support for your hardware and industrial protocols, remote provisioning and updates, per-device security, behaviour during connectivity loss, integration with existing systems, pricing at your target fleet size, and what it would take to export data and move devices later.
Was this useful?
Where this shows up in our work
ExpertiseCloud engineering for the systems behind connected productsComparing platforms against a real usage profile, designing the device-facing contract and building the cloud services behind it is the cloud engineering work our teams own.Industrial fleets add long device lifetimes, existing OT systems and site constraints to the platform choice. See Engineering connected products for machines that keep running.
Apply this to your product