IoT Architecture Diagrams: Device, Edge, Gateway & Cloud Patterns (2026)

An IoT architecture diagram shows how physical devices — sensors, actuators, controllers, and gateways — connect to cloud services to send telemetry, receive commands, and stay up to date. Unlike a typical web or mobile architecture, IoT systems span a physical trust boundary: devices are often deployed in the field, unattended, on constrained networks, with limited power and no guarantee of a stable connection. That changes almost every architectural decision, from which protocol you use to how you handle firmware updates to where you draw the line between "trusted" and "untrusted" in your security model.

Diagramming an IoT system matters because the failure modes are different from a typical backend: a fleet of ten thousand devices at the edge can generate an order of magnitude more traffic than a typical API, devices can go offline for hours or days and need to reconcile state when they reconnect, and a single compromised device certificate can become a foothold into your entire fleet. IoT architecture reviews, security audits, and compliance documentation (HIPAA for connected medical devices, industrial safety standards for manufacturing) all depend on a diagram that clearly shows the device fleet, the connectivity path, the edge processing tier, and the cloud ingestion and storage layer.

The core components of an IoT architecture

Device and sensor layer

At the bottom of every IoT diagram sits the device layer: the physical sensors (temperature, humidity, vibration, GPS, occupancy), actuators (valves, motors, relays), and the microcontroller or system-on-chip that reads sensor data and executes commands. Devices vary enormously in capability — from battery-powered sensors with kilobytes of RAM that sleep most of the time, to industrial PLCs with real-time operating systems and persistent power. In your diagram, group devices by class (constrained sensor, powered controller, gateway-capable device) since each class has a different connectivity and security profile.

Connectivity protocols

The protocol a device uses to talk to the network is one of the most consequential architectural decisions in an IoT system, because it determines power consumption, range, and bandwidth trade-offs. MQTT is a lightweight publish/subscribe protocol over TCP, widely used when devices have a reasonably reliable network connection (Wi-Fi or Ethernet) and need low-latency, low-overhead messaging to a broker. CoAP is a lightweight, REST-like protocol built on UDP designed for highly constrained devices — it mirrors HTTP semantics (GET/POST/PUT) but with a much smaller header footprint, making it a good fit for sensors with very limited memory and processing power. LoRaWAN is a low-power, wide-area (LPWAN) protocol built for devices that need to transmit small payloads over long distances (kilometers) on battery power that must last months or years — common for agricultural sensors, utility meters, and remote environmental monitoring, at the cost of very low bandwidth. Zigbee is a low-power mesh protocol used mostly in short-range settings like smart-home and building automation, where many devices relay messages to each other to extend coverage without needing a cellular or Wi-Fi connection. Cellular connectivity (including NB-IoT and LTE-M) gives a device wide-area network access without needing a local gateway at all, at the cost of higher power consumption and per-device connectivity fees — a common choice for mobile assets like vehicles and shipping containers. Your diagram should label the protocol on every device-to-network connection, not just draw a generic line.

Edge gateway

Many IoT deployments place an edge gateway between constrained devices and the cloud. The gateway does protocol translation (converting Zigbee, LoRaWAN, or CoAP traffic from local devices into MQTT or HTTPS for the cloud), local buffering (queuing telemetry when the upstream network connection drops so no data is lost), and edge compute — filtering, aggregating, or running lightweight inference on data before it's sent upstream, which reduces bandwidth costs and lets the site keep operating during a connectivity outage. In your diagram, show the gateway as a distinct node with the local device protocols coming in on one side and the single upstream cloud protocol going out the other, plus the local storage buffer used during disconnection.

Device provisioning and identity

Every device needs a verifiable identity before the cloud will accept its data. The standard approach is an X.509 certificate provisioned onto the device at manufacturing time or during a secure first-boot enrollment process, used to authenticate the device's TLS connection to the cloud. Many managed IoT platforms also maintain a device twin (or device shadow) — a cloud-side JSON document that mirrors the device's last-known reported state and holds the desired state the cloud wants the device to reach. This lets applications read or set device configuration even while the device is offline; the device syncs the difference the next time it connects. Your diagram should show the certificate authority or provisioning service, the per-device certificate, and the device twin/shadow store as distinct components.

Cloud ingestion layer

Devices (or gateways) connect to a managed IoT message broker — services like AWS IoT Core, Azure IoT Hub, or Google Cloud IoT-style ingestion services are purpose-built for this: they terminate device TLS connections at scale, authenticate devices by certificate, and route incoming messages to downstream processing (rules engines, stream processors, or directly into storage). This layer is what lets a system accept telemetry from thousands or millions of devices without every device needing to know about downstream infrastructure. In your diagram, show the broker as the single entry point for all device traffic, with routing rules fanning out to storage, stream processing, and alerting.

Time-series data storage

Telemetry is fundamentally time-series data — a stream of timestamped readings per device per metric. Purpose-built time-series databases (or time-series-optimized tables in a general database) handle this more efficiently than a standard relational schema, supporting fast range queries, downsampling, and retention policies that automatically age out raw high-frequency data while keeping rolled-up aggregates. Show the ingestion path from the message broker into the time-series store, and annotate the retention/downsampling policy — this is often a compliance and cost requirement, not just a performance one.

Device management and OTA updates

A device management layer handles fleet-wide operations: monitoring device health and connectivity status, grouping devices for targeted rollouts, and delivering over-the-air (OTA) firmware updates. OTA updates need to be staged (a percentage of the fleet first), resumable (a device that loses connection mid-download should recover, not brick), and verifiable (signed firmware images so a device won't install an unauthorized update). Your diagram should show the OTA update service, the firmware artifact store, and the rollout strategy (canary percentage, rollback trigger) as explicit elements — this is one of the most common places IoT architectures fail in production.

Digital twin representation

Beyond the low-level device shadow used for state sync, many IoT systems build a higher-level digital twin: a virtual model of a physical asset (a machine, a building, a vehicle) that combines live telemetry with historical data and domain models to support simulation, predictive maintenance, and monitoring dashboards. A digital twin is a consumer of the time-series data and device metadata described above, not a replacement for them. In your diagram, show the digital twin as an application-layer component that reads from telemetry storage and device metadata, rather than conflating it with the device shadow used for connectivity state sync.

Common IoT architecture patterns

Pattern 1: Cloud-direct connectivity for simple sensors

Devices with sufficient power and network access (Wi-Fi or cellular) connect straight to the cloud message broker with no local gateway. Simplest pattern to diagram and operate — one hop from device to cloud. Best for: smart-home devices, connected appliances, and any deployment where devices have reliable network access and don't need to keep functioning during an internet outage.

Pattern 2: Edge-gateway aggregation for industrial sites

A single site (factory floor, warehouse, substation) has many constrained sensors talking to a local gateway over Zigbee, CoAP, or wired fieldbus protocols; the gateway aggregates, buffers, and forwards to the cloud over one MQTT or HTTPS connection. Best for: industrial IoT (IIoT), building automation, and any site where local devices vastly outnumber the available uplinks and need protocol translation.

Pattern 3: Hub-and-spoke fleet management

A central cloud platform manages device identity, configuration, and OTA updates for a geographically distributed fleet, with each device or site gateway as a spoke reporting back to the same hub. Best for: retail chains, fleets of vending machines or kiosks, and any deployment where consistent central management matters more than per-site autonomy.

Pattern 4: Hybrid edge-cloud with local inference and cloud aggregation

Edge gateways or on-device compute run lightweight inference or rule evaluation locally (for low-latency alerts or to reduce bandwidth), while raw or summarized data still flows to the cloud for long-term storage, cross-site analytics, and model retraining. Best for: predictive maintenance, video/vibration analysis at industrial sites, and any use case where local latency matters but a central view across sites is still required.

IoT protocol comparison

Prompt templates for IoT architecture diagrams

Smart-building sensor network with MQTT and an edge gateway

Industrial IoT predictive-maintenance pipeline

Fleet-tracking system using cellular connectivity

Consumer smart-home device with local hub and cloud app

What a good IoT architecture diagram must show

• Device trust boundary: Draw a clear line between physical devices (which can be lost, stolen, or tampered with) and the managed cloud environment. Devices should be treated as untrusted until authenticated by certificate, not implicitly trusted because they're on a private network.
• Connectivity protocol and constraints: Label every device and gateway connection with its protocol (MQTT, CoAP, LoRaWAN, Zigbee, cellular) and note power and bandwidth constraints — these determine how much telemetry the system can realistically move and how often.
• Offline / intermittent-connectivity handling: Show local buffering at the device or gateway level and how the system reconciles state once connectivity is restored. IoT architectures that assume a permanently connected device fail in production.
• OTA update path: Show the firmware artifact store, the update delivery service, and the rollout strategy (staged/canary, rollback trigger, signature verification). This is a frequent security and reliability gap.
• Data retention and aggregation tier: Show where raw telemetry lands, how it's aggregated or downsampled over time, and what the retention policy is — both for storage cost and for compliance requirements.
• Security: Show device identity (certificates, provisioning service) and where encryption in transit is applied (device-to-gateway and gateway-to-cloud legs may use different protocols and need separate verification).

Frequently asked questions about IoT architecture

What is an IoT architecture diagram?

An IoT architecture diagram is an architecture diagram that shows how physical devices — sensors, actuators, and gateways — connect to cloud infrastructure to send telemetry and receive commands. It typically depicts the device/sensor layer, the connectivity protocol used (MQTT, CoAP, LoRaWAN, Zigbee, or cellular), an optional edge gateway that aggregates and translates local device traffic, the cloud ingestion layer (a managed IoT message broker), time-series storage, and the device management and OTA update path. It is the standard documentation artifact for reviewing security, planning capacity, and onboarding engineers on a connected-device system.

What's the difference between an IoT gateway and a cloud IoT platform?

An IoT gateway is a physical or virtual component deployed close to the devices themselves — typically on-site — that handles protocol translation, local buffering, and sometimes edge compute before forwarding data upstream over a single connection. A cloud IoT platform (like AWS IoT Core or Azure IoT Hub) is a managed service that runs in the cloud, terminates device or gateway connections at scale, authenticates devices by certificate, and routes messages to downstream storage and processing. In short: the gateway sits between constrained local devices and the network; the cloud platform sits between the network and your application and storage layers. Many architectures use both — the gateway solves the local aggregation problem, the cloud platform solves the fleet-scale ingestion problem.

How do I diagram security for an IoT system?

Show the device identity mechanism first — typically a unique X.509 certificate provisioned per device — and the certificate authority or provisioning service that issues it. Draw the trust boundary between the physical device and the network explicitly, since devices in the field are the most likely component to be physically compromised. Annotate encryption in transit on every hop (device-to-gateway and gateway-to-cloud may use different protocols with different security properties, so don't assume one TLS annotation covers both). Finally, show the OTA update path with firmware signature verification — an unsigned or unverified update path is one of the most common ways an IoT fleet gets compromised at scale.

Related guides: edge AI architecture, streaming data architecture diagrams, mobile app architecture diagrams, and zero trust architecture diagrams.