3 Cloud Service Models for IoT
3.1 Start With the Workload Duty
A cloud service model is a duty split. A team may own the application logic, the runtime, the operating system, the broker, or only the data contract, and each split changes what the team can fix during an IoT incident.
Start simple: pick one workload, such as alarm routing or firmware distribution, and ask who patches it, scales it, observes it, and recovers it. The right model is the one whose duty split matches that evidence. ## Service Models Move Duties {#overview-cloudsvcdepth-boundaries .depth-l0}
Cloud service models are responsibility boundaries. They describe which layers the IoT team operates directly and which layers a service provider operates under a contract. A model is not automatically mature, secure, cheap, or scalable. It becomes useful only when the team can name the device, data, runtime, access, recovery, and support responsibilities that remain on each side of the boundary.
IaaS gives the team more control over infrastructure and runtime choices. PaaS delegates more platform operation while the team still owns device behavior, application logic, data rules, and access policy. SaaS delivers a finished application surface, but the team still owns configuration, onboarding quality, user roles, integration contracts, export tests, and exit planning.
For a cold-chain monitoring product, IaaS might mean running Mosquitto, PostgreSQL, and dashboard workers on virtual machines that the team patches, backs up, monitors, and restores. PaaS might mean using AWS IoT Core or Azure IoT Hub for device identity, MQTT ingestion, routing rules, and managed queues while the team still owns topic design, payload validation, alert policy, data retention, and application release behavior. SaaS might mean using a finished fleet dashboard or work-order surface, but the team still owns device enrollment quality, role assignment, export rehearsals, integration tests, and the exit path if the workflow no longer fits.
The model is therefore a statement about accountable work. It should say who rotates gateway certificates, who reviews broker topic permissions, who restores historical telemetry, who changes alert thresholds, who answers operator tickets, and who proves that a site can keep alarming during provider or network degradation. Those responsibilities remain visible even when the provider operates more of the stack.
IaaS
The team gets flexible infrastructure and usually owns operating systems, runtime hardening, broker deployment, patching, scaling, backup, monitoring, and recovery drills.
PaaS
The provider manages more runtime capability, while the team owns application behavior, device model, data classification, policy, integration, observability, and release proof.
SaaS
The provider supplies the application surface, while the team owns configuration, user access, data quality, device onboarding, integration fit, exports, and exit evidence.
Design rule: select the model that best fits workload behavior and operating capacity. Do not choose a model because its label sounds modern or because another project used it.
3.2 Match Models to Workloads
Start with the IoT workload, not the cloud label. A telemetry archive, an alarm route, a command channel, a firmware workflow, and an operator dashboard can have different service-model choices inside the same product. The selection is strongest when it documents what the workload must do, which team can operate each layer, what the provider is expected to do, and which change signal will reopen the choice.
Use the same worksheet for every boundary. A managed device registry may reduce certificate-service maintenance, but it does not decide whether a failed revocation blocks command delivery. A SaaS dashboard may reduce frontend work, but it does not prove raw export completeness, role separation, or support handoff. A self-managed broker may support unusual bridge behavior, but it also creates patch, capacity, backup, and on-call duties that need named owners.
Use IaaS When Control Is The Reason
Choose it when custom network isolation, broker behavior, runtime versions, protocol gateways, or deployment constraints are real requirements and the team can operate them.
Use PaaS When Managed Capability Fits
Choose it when managed identity, ingestion, queueing, data stores, functions, or streams meet the workload needs without hiding ownership of application and data behavior.
Use SaaS When Workflow Fit Is Strong
Choose it when a finished dashboard, alerting, work-order, or fleet-management surface fits the process and export, role, data, and integration boundaries are acceptable.
Common failure: treating “managed” as “no operations.” Managed services still require configuration review, quotas, identity policy, monitoring, incident response, data lifecycle checks, and migration planning.
3.3 Runtime Shape and Review Records
The service model and the compute pattern are separate decisions. A PaaS-oriented architecture can still use containers, functions, managed jobs, stream processors, or local gateway control. An IaaS architecture can still delegate some capabilities to managed services. The important detail is whether each runtime shape fits the state, timing, retry, observability, and ownership behavior of the workload.
A short enrichment step can run well as AWS Lambda, Azure Functions, or a managed job when it is idempotent, observable, and safe to retry. A protocol bridge that holds MQTT sessions, translates payloads, and handles back-pressure may fit a container service such as Cloud Run, Azure Container Apps, ECS, or Kubernetes because it needs a controlled runtime and release path. A local alarm loop should stay in gateway firmware or an edge service when the WAN link cannot be part of the safety deadline. Those runtime choices can sit under IaaS, PaaS, or hybrid boundaries; the service model says who operates the layers, while the compute pattern says how the workload behaves.
The review record should tie both choices together. It should name the workload, service model, runtime shape, state owner, retry rule, identity boundary, telemetry store, recovery path, quota risk, release owner, and change signal. For example, a “PaaS ingestion” note is not enough for a freezer alert stream. The record needs the MQTT topic contract, certificate rotation owner, queue retention, late-message handling, dashboard freshness rule, export rehearsal, and gateway behavior when cloud acknowledgements stop.
This is also where teams catch mismatched promises: a serverless retry policy cannot fix a non-idempotent command, and a managed broker cannot prove local alarm behavior during a WAN outage.
Event Functions
Fit short independent reactions, enrichment, notification, and scheduled checks. Validate cold start, retry, idempotency, concurrency, and observability.
Containers And Workers
Fit sustained processing, custom runtimes, protocol bridges, stream consumers, and workloads that need controlled release and capacity behavior.
Long-Running Services
Fit persistent connections, stateful coordination, custom brokers, and low-latency loops. Keep restart, failover, and back-pressure evidence.
Local Gateway Control
Fit safety or availability paths that must continue during cloud outage. Define replay, duplicate detection, and reconciliation behavior.
Every service-model choice should leave a record. The record names the workload, the selected model, owned layers, delegated layers, compute pattern, data obligations, operations proof, portability assumptions, residual risks, owner, and change signal. Without that record, the architecture can drift into hidden obligations: unpatched virtual machines, unmonitored queues, unclear exports, brittle adapters, or a SaaS dependency with no exit path.
3.4 Summary
Cloud service models for IoT are ownership boundaries. IaaS gives more infrastructure control and more operating responsibility. PaaS can reduce platform work while leaving device, data, application, access, and operations decisions with the team. SaaS can accelerate dashboards, alerts, workflow, and fleet-management surfaces when configuration, data quality, integration, role design, export, and exit boundaries are acceptable. The right model is the one supported by workload behavior, operating capacity, security needs, data obligations, recovery evidence, and a clear review record.
3.5 Key Takeaway
Service-model choice is not just an implementation shortcut. It is an ownership decision that must name who operates each IoT layer, how the workload runs, what proof exists, and when the decision should be revisited.