2 Cloud Computing Fundamentals for IoT
2.1 Start With a Shared Cloud Job
Imagine a building gateway that sends alarms, routine telemetry, dashboard updates, and firmware evidence to the same cloud account. The first architecture move is to separate what must respond immediately from what can be stored, queued, analyzed, or reviewed later.
Start simple: describe the job the cloud is doing for one device group before naming a provider or service. Once the job is clear, capacity, resilience, placement, and evidence boundaries become easier to judge. ## Shared Cloud Capacity for IoT {#overview-clouddepth-cloud-role .depth-l0}
Cloud computing lets an IoT system use shared remote compute, storage, networking, and application services through network APIs. It is valuable for ingestion, durable storage, fleet analytics, dashboards, device management, and long-running review evidence. It does not remove the need for edge processing: local control, filtering, buffering, and outage behavior still belong near devices when timing, safety, or connectivity require it.
NIST describes cloud computing through five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. For IoT, those characteristics are useful only when they are mapped to real workload boundaries and failure behavior.
Consider a cold-chain fleet with temperature probes, cellular gateways, and a cloud operations portal. The cloud side might use AWS IoT Core, Azure IoT Hub, Google Cloud Pub/Sub, Amazon S3, Cloud Storage, BigQuery, TimescaleDB, or Grafana-style dashboards to accept events, retain history, summarize exceptions, and show fleet status. Those products do not decide the architecture by themselves. The architecture decision is whether each workload benefits from shared capacity, central visibility, managed identity, durable storage, or elastic processing.
The same fleet still needs local behavior. A gateway may keep an MQTT or HTTPS queue while offline, reject malformed sensor records, preserve the last safe alarm threshold, and buffer readings until a mobile link returns. A site controller may keep refrigeration alarms independent from any cloud dashboard. Cloud fundamentals therefore start with a boundary: what is safe to centralize, what must remain local, and what evidence shows the boundary works during normal traffic, burst traffic, and outage recovery. Measured service then turns that boundary into quotas, cost signals, and capacity warnings.
On-Demand Self-Service
Teams can request and change resources through controlled automation instead of informal manual setup.
Broad Network Access
Gateways, applications, and operators reach services through standard network mechanisms with explicit identity and policy.
Resource Pooling
Shared infrastructure supports multiple workloads while isolation protects data, keys, environments, and ownership.
Rapid Elasticity
Capacity can expand and contract around bursts such as reconnect storms, firmware waves, alarms, and seasonal reporting.
Measured Service
Usage evidence supports capacity planning, retention review, accountability, abuse detection, and operations ownership.
Design question: use cloud when shared visibility, durable evidence, elastic capacity, or fleet coordination is worth the network, identity, data, and operations boundaries.
2.2 Workload Placement by Constraints
A practical cloud decision starts by tracing the IoT data flow. Devices sense and act. Gateways validate, translate, filter, buffer, and protect local continuity. Cloud services ingest, store, process, and share information. Operations teams review behavior and push approved changes back through controlled channels.
Write the path as a workload map before selecting a service. In a building-monitoring deployment, BACnet or Modbus devices may feed a site gateway, the gateway may publish normalized MQTT events, and the cloud may land them in a time-series store for dashboards and compliance reports. If a thermostat command, fire-damper signal, or freezer alarm cannot wait for an internet round trip, it stays local. If a monthly energy benchmark, remote certificate inventory, or model-training dataset needs fleet-wide comparison, it fits cloud-side processing.
2.2.1 Building Monitoring Example
A useful placement review asks for a concrete operating story. Suppose a university has twenty buildings, each with air-quality sensors, chilled-water meters, occupancy counters, and a gateway that can buffer several hours of records. The cloud path can compare CO2 trends across buildings, calculate weekday energy baselines, show Grafana or Looker dashboards to facilities staff, and retain audit trails for maintenance decisions. The site path should still enforce local ventilation fallback, handle gateway disk-full behavior, and keep certificate rotation, topic authorization, and failed-upload alerts visible to the operations team.
Cloud-Side
Fleet dashboards, hourly summaries, device inventory, certificate lifecycle records, trend analysis, and maintenance reports.
Site-Side
Ventilation fallback, local alarms, gateway filtering, short-term buffering, and protocol translation for building systems.
Hybrid
Approved summaries move to cloud while local gateways keep outage behavior and raw high-frequency signals under site control.
2.3 Cloud Evidence Boundaries
Under the hood, an IoT cloud design is a chain of service contracts. A device event becomes a gateway record, an ingestion decision, a storage item, an analytic result, an operator view, and sometimes a return-path change. Each step needs identity, data classification, failure behavior, observability, and ownership.
A cloud placement is weak if it relies on changing product names, pricing examples, or marketing claims. A stronger choice captures the workload intent, the cloud characteristic being used, the edge boundary, the data class, the timing class, the failure behavior, and the owner who can revisit the assumption when workload or risk changes.
One telemetry record shows why the boundary matters. A sensor measurement may include a device identity, firmware version, timestamp, sequence number, site id, unit, quality flag, and payload schema version. The gateway may validate it, add an idempotency key, write it to a local queue, and publish it through MQTT over TLS. The cloud ingress layer may authenticate the certificate, check topic authorization, reject unexpected fields, place the record on an event bus, and write different copies to short-retention raw storage and longer-retention aggregates.
That chain creates operational questions that cannot be answered by the word cloud alone. What happens when the MQTT broker throttles a reconnect storm? Which messages are safe to replay? Which raw records are deleted after seven days, and which hourly summaries remain for compliance? Which alert is raised when schema validation fails? Which operator can approve a configuration change that travels back through the cloud to the gateway? Durable evidence is the combination of logs, queue metrics, schema versions, access records, runbooks, and rollback paths that show those answers were designed rather than assumed.
Ingestion Contract
Define accepted event shape, identity, duplicate handling, malformed message behavior, queue limits, and retry expectations.
Storage Contract
Define raw versus summary records, retention, deletion, access roles, audit trails, and archive boundaries.
Analytics Contract
Define batch or streaming behavior, evidence freshness, model update approval, and how results are checked before action.
Return-Path Contract
Define who can change configuration, models, or firmware, plus rollout, monitoring, rollback, and local override conditions.
Failure mode: treating a successful online dashboard as proof that the architecture survives outage, burst load, unsafe return paths, data over-collection, or ownership drift.
2.4 Summary
Cloud computing gives IoT systems shared, automated, network-accessible, elastic, and measured resources. Those properties support ingestion, storage, analytics, dashboards, identity, updates, and fleet operations when the design also records local timing, data, connectivity, and ownership boundaries.
The architecture is strong only when cloud responsibilities are separated from edge responsibilities. Immediate safety, local fallback, raw-data minimization, and outage behavior need explicit placement evidence instead of a generic claim that cloud is scalable.
2.5 Key Takeaway
Use cloud for IoT when shared visibility, durable evidence, elastic capacity, or fleet coordination are needed. Approve the placement only with evidence for data class, timing, edge responsibility, failure behavior, observability, ownership, and future review conditions.
2.6 See Also
2.6.1 Cloud Service Models
Separate IaaS, PaaS, and SaaS responsibilities before choosing cloud runtime patterns.
2.6.2 Cloud Deployment Models
Compare public, private, community, hybrid, and edge-cloud placement boundaries.
2.6.3 Cloud Security for IoT
Review identity, data protection, monitoring, and shared-responsibility evidence.
2.6.4 Production Cloud Deployment
Plan quotas, back-pressure, rollout safety, observability, and recovery drills.