An Internet of Things (IoT) platform is the technological and managerial foundation through which connected devices are registered, authenticated, monitored, controlled and integrated with business applications. It normally combines device connectivity, messaging, digital identities, rules or event processing, data storage, analytics, security controls and operational management.

For an organisation, platform selection is not simply a question of choosing the most technically sophisticated cloud service. It is a decision about operating model, ecosystem dependence, data governance, integration capability, skills, cost, resilience and long-term strategic flexibility. This chapter evaluates AWS IoT, Azure IoT Hub, Node-RED, and Google Cloud’s former IoT Core offering together with current Google Cloud partner-based alternatives.

Learning Objectives

1. The Architecture of an IoT Platform

Plane	Main responsibility	Typical capabilities
Device and identity	Establish trusted device participation	Registration, certificates, keys, policies, device metadata
Connectivity and messaging	Transport telemetry and commands	MQTT, HTTPS, AMQP, publish/subscribe, queues
Device management	Maintain devices throughout their life cycle	Provisioning, configuration, health monitoring, firmware updates
Event and rule processing	Convert events into actions	Filtering, transformation, routing, alerts and workflows
Data and application integration	Make information useful to the organisation	Databases, data lakes, analytics, ERP, CRM and APIs
Operations and governance	Control risk and performance	Logging, monitoring, access control, audit and cost management

The device layer produces observations such as temperature, location or vibration. The platform authenticates the source, receives the message, applies policies and routes the event. An application may then store the observation, display it on a dashboard, create a maintenance ticket or issue a command back to the device.

Device identity and management

Device identity answers the question, “Which device is communicating?” Authentication answers, “Can it prove that identity?” Authorisation answers, “What may it do?” Mature platforms separate these questions. A device may be permitted to publish temperature data to its own topic but prohibited from reading another customer’s data or changing its firmware policy.

Device management extends beyond initial registration. It includes provisioning, inventory, metadata, configuration, health status, software versions, certificate rotation, decommissioning and, where supported, over-the-air updates. These functions are particularly important when devices are geographically distributed and physical access is expensive.

Messaging models

MQTT is widely used in IoT because it is lightweight and supports publish/subscribe communication. A device publishes a message to a topic, while authorised consumers subscribe to that topic. This reduces direct coupling between devices and applications. HTTPS is also common, particularly for simple integrations and devices that already support web protocols. Azure additionally supports AMQP in relevant scenarios.

Messaging must be evaluated through delivery semantics, not merely protocol labels. “At most once” delivery may lose messages but avoids duplicates; “at least once” delivery may produce duplicates and therefore requires idempotent processing; “exactly once” semantics are difficult to guarantee across distributed systems and should not be assumed merely because a service uses a particular protocol.

Rules and integration

A rule engine examines incoming messages and performs actions. For example, a rule may route an excessive vibration reading to a stream processor, store it in a time-series database and send an alert. Rules reduce the need to build a separate bespoke integration service for every event type.

Integration capability is a major business concern. IoT data may need to reach object storage, relational databases, event buses, serverless functions, enterprise resource planning systems, maintenance applications and analytical models. An attractive platform with weak integration can create an isolated data silo.

2. AWS IoT

AWS IoT is a collection of managed services rather than one undifferentiated product. The central service for device connectivity and control is AWS IoT Core. Related services support device provisioning and management, fleet monitoring, device shadows, rules, security and edge execution.

Core capabilities

Identity and security. AWS IoT Core uses a registry for device identities and supports X.509 certificates, policies and authentication mechanisms. Policies determine which devices or applications may connect, publish, subscribe or receive messages. A sound implementation gives each device an individual identity, uses least privilege and protects private keys in secure hardware where feasible.

Messaging. AWS IoT Core supports MQTT, MQTT over WebSockets and HTTPS. The message broker receives telemetry and commands and uses topics to organise communication. Device shadows maintain a virtual representation of device state. A shadow can contain reported state, desired state and, operationally, the difference between them. This is useful when a device is intermittently connected: an application can set a desired configuration, and the device can reconcile it when it reconnects.

Rules engine. AWS IoT rules can filter and transform messages using SQL-like expressions and route results to services such as Lambda, Amazon Kinesis, Amazon S3, Amazon DynamoDB, Amazon OpenSearch Service and Amazon Simple Notification Service. This enables event-driven architectures. For example, a rule can detect a pressure reading above a threshold, invoke a function and publish an alert without requiring a continuously running application server.

Device management. Fleet Provisioning supports scalable onboarding. Jobs can distribute commands or software updates to groups of devices. Device Defender assists with auditing and monitoring security behaviour. Greengrass extends selected cloud capabilities to edge environments, where local processing, intermittent connectivity or low latency is required.

Business strengths and limitations

AWS IoT is strong when an organisation already uses AWS services and wants deep integration with serverless computing, analytics and storage. Its breadth supports complex industrial and consumer deployments. However, breadth also increases architectural complexity. Teams must understand interactions among IoT policies, IAM, certificates, topic structures, regional services, logging and cost dimensions. A poorly governed implementation can become difficult to operate and expensive to change.

AWS IoT should therefore be assessed as an operating ecosystem. The relevant question is not merely whether it can ingest messages, but whether the organisation can manage identity, observability, deployment, data retention and incident response at fleet scale.

3. Azure IoT Hub

Azure IoT Hub is a managed service for reliable, secure communication between an IoT solution and its devices. It provides a device identity registry, device-to-cloud telemetry, cloud-to-device communication, device twins, direct methods and integration with Azure services.

Device management and twins

The identity registry records devices and their authentication status. Device twins are JSON documents maintained by the service that describe device metadata, desired properties and reported properties. Desired properties express what the cloud wants; reported properties express the device’s current state. This provides a structured mechanism for configuration reconciliation.

Direct methods support command-and-response interactions, such as asking a machine to restart or perform a diagnostic action. Device-to-cloud messages are more appropriate for telemetry, while cloud-to-device messages and twin updates support control and configuration. Separating these interaction patterns improves clarity and operational governance.

Messaging, routing and scale

IoT Hub supports MQTT, HTTPS and AMQP-based communication patterns. Message routing can direct telemetry to endpoints such as Event Hubs, Service Bus, Storage and other Azure services. Azure Stream Analytics can process events, while Functions, Logic Apps and Power BI support automation and reporting.

Azure IoT Hub uses service tiers and quotas, so architecture must account for message size, throughput units, retention and regional availability. A design that works in a pilot may require partitioning, multiple hubs or downstream event-stream capacity when the fleet grows. Azure IoT Hub is therefore not identical to a general-purpose message broker: its value lies in combining messaging with device identity and management.

Managerial assessment

Azure IoT Hub is particularly attractive to organisations standardised on Microsoft identity, Azure analytics, Microsoft business applications and enterprise integration tools. Its device-twin model is valuable for operational state management. The main risks include quota planning, dependence on Azure-specific services and the possibility that business users confuse telemetry transport with complete device lifecycle management.

4. Node-RED: A Development and Integration Tool

Node-RED is a flow-based programming tool, originally associated with IBM, that allows developers to connect devices, protocols, APIs and services through visual flows. A flow consists of nodes connected by wires. Input nodes receive events, processing nodes transform or evaluate them, and output nodes call devices, databases, dashboards or cloud services.

Node-RED is not, by itself, equivalent to AWS IoT or Azure IoT Hub. It generally does not provide a complete managed global control plane, fleet identity service or cloud-scale device registry. Instead, it is a rapid application-development and integration layer that can run on a gateway, local server, virtual machine, container or cloud environment.

Uses and strengths

Node-RED is useful for proof-of-concept work, edge gateways, protocol translation and operational dashboards. A flow might read Modbus values from factory equipment, normalise them, publish MQTT messages and write selected records to a database. Its visual representation makes event logic accessible to multidisciplinary teams and accelerates experimentation.

Running Node-RED at the edge can reduce latency and bandwidth consumption. Local rules may continue operating during cloud disconnection. However, such benefits require disciplined deployment, backup, access control, secret management, version control and monitoring.

Limitations and governance

Node-RED flows can become difficult to test and maintain when they grow into large, undocumented systems. Community nodes vary in quality and may introduce security or maintenance risks. Node-RED should therefore complement, rather than replace, managed device platforms when an organisation needs large-scale identity, fleet updates, compliance evidence and globally managed availability.

A sound pattern is to use Node-RED as an edge orchestration tool while delegating authoritative identity, long-term storage and central fleet governance to AWS IoT, Azure IoT Hub or another managed service.

5. Google Cloud IoT Core and Current Alternatives

Google Cloud IoT Core was a managed service for device connectivity and management. It supported device registries, public-key authentication, MQTT and HTTP bridges, configuration and state data, and integration with Google Cloud services such as Pub/Sub. Google announced its retirement, and IoT Core was discontinued on 16 August 2023. It should therefore be treated as a legacy offering, not as a current platform choice.

What IoT Core provided

IoT Core separated device registration from message ingestion. Devices connected through MQTT or HTTP, while telemetry could be forwarded to Pub/Sub for downstream processing. Device configuration and state supported basic cloud-to-device coordination. This architecture reflected an important principle: a specialised device gateway can provide protocol and identity functions while a general event service provides scalable distribution and analytics.

The post-IoT-Core model

Google Cloud’s current approach is partner-based and composable rather than centred on a first-party, end-to-end IoT Core replacement. Organisations may select an IoT device-management and connectivity partner, connect that partner’s platform to Google Cloud through Pub/Sub or other integration mechanisms, and use Google services such as Dataflow, BigQuery, Cloud Storage, Cloud Run, Vertex AI and Looker for processing, storage, applications and analytics. Google Cloud documentation identifies partner solutions and integration patterns; the exact capabilities, pricing and support responsibilities depend on the selected partner.

This model offers flexibility and access to Google’s data and AI ecosystem, but it changes accountability. The buyer must examine the partner’s device identity model, certificate handling, OTA capability, protocol support, service-level commitments, data residency, export mechanisms and exit strategy. A partner-based architecture can be powerful, but it introduces an additional contractual and operational relationship.

6. Comparative Evaluation

Criterion	AWS IoT	Azure IoT Hub	Node-RED	Google approach today
Device identity	Strong registry, certificates and policies	Strong registry and authentication options	Usually delegated to nodes or connected platform	Depends on partner solution
Messaging	MQTT, MQTT over WebSockets, HTTPS	MQTT, HTTPS and AMQP patterns	Protocol nodes; commonly MQTT, HTTP and industrial protocols	Partner gateway plus Pub/Sub or other services
Device state	Device shadows	Device twins	Custom flow state or external service	Partner-specific; Google services provide downstream storage
Rules/integration	IoT Rules and broad AWS targets	Routing plus Azure event and workflow services	Visual flow logic and custom integrations	Composed through partner, Pub/Sub, Dataflow, Cloud Run and others
Fleet management	Provisioning, Jobs, Defender and edge options	Device identities, twins and Azure management ecosystem	Limited natively	Partner-dependent
Scalability model	Managed regional cloud services and quotas	Managed tiers, quotas and downstream capacity	Depends on deployment and operations	Partner scale plus Google service scale
Main advantage	Deep AWS ecosystem and mature IoT building blocks	Strong enterprise integration and device twins	Rapid development and edge flexibility	Strong data/AI ecosystem with partner choice
Main risk	Complexity and vendor lock-in	Quotas and Azure dependence	Operational and security burden	Partner fragmentation and accountability boundaries

Platform selection should use weighted criteria rather than brand preference. For a criterion j, a simple decision model is:

Here, Sᵢ is the total score for platform i, wⱼ is the weight assigned to criterion j, and rᵢⱼ is the platform’s rating on that criterion. Weights should sum to 1, and ratings must use a consistent scale. The model is only a decision aid: it does not remove uncertainty, migration risk or non-compensatory requirements such as regulatory compliance.

For example, if security is weighted 0.35, integration 0.25, scalability 0.25 and cost 0.15, ratings from 1 to 5 can produce a transparent preliminary ranking. A platform scoring poorly on mandatory security requirements should be rejected even if its weighted total is high; mandatory criteria are constraints, not merely low-weight preferences.

7. Applied Case: Connected Cold-Chain Logistics

Background. An illustrative pharmaceutical distributor operates 8,000 refrigerated containers. Each container reports temperature, battery status and location. Connectivity is intermittent during transport, and an excursion can create regulatory, financial and patient-safety consequences.

Problem. The distributor’s prototype uses Node-RED on gateways and sends data directly to a dashboard. It has no consistent certificate rotation, device inventory, offline command strategy or auditable firmware process.

Analysis. Node-RED is useful at the gateway for protocol conversion, local buffering and immediate alarms. It is insufficient as the sole fleet-management control plane. The distributor needs individual device identities, tamper-evident logs, configurable retention, alert escalation and controlled updates.

Approach. The organisation evaluates AWS IoT and Azure IoT Hub. It selects a managed cloud IoT service according to existing enterprise skills and regulatory integration. Node-RED remains at the edge. The gateway stores readings during disconnection, applies a local safety threshold, and forwards buffered events when connectivity returns. Cloud rules route telemetry to durable storage and an event-processing service. Device state records the desired sampling interval and reported configuration. Access is divided among logistics operations, security administrators and application developers.

Outcome. The architecture separates edge responsiveness from central governance. Operations can identify the affected container, security can revoke credentials, and compliance staff can audit configuration changes. Before production, the organisation conducts a failure exercise covering lost connectivity, compromised credentials, duplicate messages, incorrect time settings and a failed firmware update.

Learning points. First, a visual integration tool and a managed IoT platform serve different purposes. Second, device identity and lifecycle controls are business-risk controls, not merely technical details. Third, the design must specify what happens when the cloud is unavailable. Finally, procurement should require data export and migration provisions.

8. Security, Governance and Strategic Issues

IoT platforms expand the attack surface because devices may be physically accessible, resource-constrained and deployed for many years. Best practice includes unique credentials, secure boot where feasible, encrypted transport, least-privilege policies, certificate rotation, signed updates, vulnerability management, network segmentation and continuous monitoring.

Governance must address who owns device data, where it is stored, how long it is retained, and whether location or behavioural data creates privacy obligations. Data minimisation is important: collecting more data than the business purpose requires increases cost and exposure. Rules that trigger physical action require approval, testing, rate limits and safe failure modes.

Vendor concentration is another strategic issue. A platform can reduce development effort while increasing switching costs through proprietary topics, identity models, rule languages, data formats and monitoring tools. Portability does not mean avoiding all vendor-specific functionality; it means deliberately identifying what is proprietary, maintaining export paths and documenting interfaces. Open protocols such as MQTT may improve transport portability, but they do not automatically make device identities, fleet operations or analytics portable.

Artificial intelligence can add predictive maintenance, anomaly detection and intelligent routing, but model outputs must be governed. Training data may be biased toward normal operating conditions, false alarms can create operational fatigue, and automated commands require human accountability. AI should be integrated after reliable identity, telemetry quality and event lineage have been established.

Best-Practice Selection Process

Chapter Summary

IoT platforms combine trusted device identity, messaging, device lifecycle management, rules, integration, data services and operational governance. AWS IoT provides a broad managed ecosystem centred on IoT Core, certificates, policies, shadows, rules and fleet-management services. Azure IoT Hub combines secure device communication with device twins, routing and Microsoft integration. Node-RED is a flexible flow-based development and edge-integration tool, but it is not a complete substitute for a managed fleet platform. Google Cloud IoT Core is a discontinued legacy service; current Google Cloud designs generally use partner-based connectivity and management integrated with Pub/Sub, Dataflow, BigQuery, Cloud Run and Google’s data and AI services.

Effective selection depends on lifecycle management, security, integration, operational resilience, scalability, cost and exit strategy. The most robust architectures often combine tools: edge logic for local responsiveness, a managed platform for identity and fleet governance, and cloud analytics for enterprise value.

Key Terms

IoT platform: A coordinated set of services for connecting, managing, securing and using connected devices.

Device shadow: A cloud representation of desired and reported device state, commonly associated with AWS IoT.

Device twin: A digital record of device properties and state, prominently used by Azure IoT Hub.

Publish/subscribe: A communication model in which producers publish to topics and consumers subscribe to them.

Fleet provisioning: The scalable process of registering and configuring many devices.

AWS IoT Core: AWS’s managed connectivity, identity and messaging service for IoT solutions.

Azure IoT Hub: Microsoft Azure’s managed service for device communication, identity and device-state management.

Google Cloud IoT Core: A former Google Cloud managed IoT service discontinued in 2023.

Pub/Sub: Google Cloud’s managed event-messaging service used in many partner-based IoT architectures.

At-least-once delivery: A delivery guarantee that may produce duplicate messages.

Idempotence: The property that repeated processing produces the same effective result as one processing operation.

Vendor lock-in: Dependence on proprietary services that increases the cost or difficulty of switching providers.

Review Questions

5 Short Answer Questions

5 Long Answer Questions

3 Analytical / Application Questions

Multiple Choice Questions with Answers

Question 1

Which capability most directly supports a device reconnecting and receiving a previously requested configuration in AWS IoT?

Question 2

Question 3

Question 4

Question 5

Question 6

Question 7

Correct Answer: A. To provide local processing during intermittent connectivity

Question 8

In current Google Cloud partner-based IoT architectures, which service can provide scalable event messaging downstream of a partner platform?

Chapter 5 IoT Platforms, Cloud Services and Development Tools

IoT Platforms, Cloud Services and Development Tools

Introduction