This chapter provides a comprehensive overview of AWS IoT services, covering the core components, key use cases, and how they integrate with other AWS services. Understanding IoT services is essential for the CLF-C02 exam, as it tests foundational knowledge of how AWS enables Internet of Things solutions at scale. This objective (3.5) falls under the 'Cloud Technology Services' domain, which comprises approximately 30% of the exam; specific IoT questions may appear in 2-4% of the total questions.
Jump to a section
Imagine a car factory assembly line where each part—engine, wheels, windshield—is a different type of 'thing' that needs to be tracked. In the old way, you'd have separate, incompatible systems for each part: one for engines, one for wheels, etc. Each system speaks its own language, and you spend most of your time building translators. AWS IoT Core is like installing a universal communication hub in the middle of the factory floor. Each part (device) gets a small, standardized tag (device certificate) that identifies it securely. When an engine arrives, it sends a message in a simple, agreed-upon format (MQTT topic) to the hub. The hub then routes that message to the right departments (other AWS services) without anyone writing custom code. If a wheel supplier uses a different protocol, you don't replace your hub; you just add a small adapter (AWS IoT Greengrass or a protocol gateway) that translates. The hub also keeps a registry of all parts, so you can query 'how many engines are on line 3?' without walking the floor. And if a part starts sending gibberish (malformed data), the hub can automatically quarantine it (device shadow with desired state). This mirrors AWS IoT Core's device gateway, message broker, device registry, and device shadow—each component has a specific job, and together they let you manage millions of diverse devices without building custom infrastructure.
What AWS IoT Services Are and the Problem They Solve
Internet of Things (IoT) refers to a network of physical devices—sensors, actuators, appliances, vehicles—that collect and exchange data over the internet. These devices are often resource-constrained (limited CPU, memory, battery) and use varied communication protocols (MQTT, HTTP, LoRaWAN). The core challenge is securely connecting, managing, and processing data from potentially millions of such devices without building custom server infrastructure. AWS IoT services provide a managed cloud platform that handles device authentication, message routing, rule-based actions, and fleet management.
How AWS IoT Core Works – The Mechanism
AWS IoT Core is the central serverless service for IoT. It consists of several key components:
Device Gateway: A highly available, elastic endpoint that devices connect to using MQTT (port 8883 for TLS), MQTT over WebSocket (port 443), or HTTPS (port 443). The gateway can handle millions of concurrent connections. When a device connects, it presents a X.509 certificate for mutual TLS authentication.
Message Broker: Pub/sub messaging system based on MQTT. Devices publish messages to topics (e.g., factory/line1/temperature). The broker filters and delivers messages to subscribers—other devices or AWS services via rules. Topics are hierarchical and support wildcards (+ for single level, # for multi-level).
Device Registry: A database of devices. Each device has a unique thing name and optional attributes (e.g., firmware version, location). The registry helps organize and query devices.
Device Shadow: A JSON document that stores the last reported state and desired state of a device. Applications can read the shadow to know the device state even if the device is offline. When the device reconnects, it synchronizes with the shadow. This enables commands to be sent to devices that are not always connected.
Rules Engine: Evaluates incoming messages and routes them to other AWS services (Lambda, DynamoDB, Kinesis, S3, SNS, SQS) based on SQL-like rules. For example, a rule could insert temperature readings into DynamoDB if the value exceeds a threshold.
Key Tiers, Configurations, and Pricing Models
AWS IoT Core pricing is based on the number of messages published to the broker (each message up to 5 KB). There is no upfront cost; you pay per million messages. The free tier includes 2,500 messages per month for 12 months. Additional costs apply for Device Shadow updates, rules executions, and data transfer out.
AWS IoT also offers optional services: - AWS IoT Greengrass: Extends AWS to edge devices, allowing local processing, ML inference, and device sync even when disconnected from the cloud. - AWS IoT Device Management: Helps onboard, organize, monitor, and remotely manage IoT devices at scale. - AWS IoT Analytics: A managed service to run analytics on IoT data. - AWS IoT Events: Detects and responds to events from IoT sensors and applications. - AWS IoT SiteWise: Collects, stores, and organizes industrial equipment data. - AWS IoT FleetWise: For automotive fleets.
Comparison to On-Premises or Competing Approaches
Traditionally, organizations built custom IoT backends using servers, databases, and message queues (e.g., RabbitMQ, Mosquitto). This required managing authentication, scaling, and high availability. AWS IoT Core eliminates these operational burdens. Compared to other cloud IoT platforms (Azure IoT Hub, Google Cloud IoT Core), AWS offers the broadest integration with other AWS services and the most mature device management features. However, AWS IoT Core is more complex to configure correctly due to its many components.
When to Use AWS IoT vs Alternatives
Use AWS IoT Core when you need to connect millions of devices with varying protocols, require managed device shadows, or want to integrate with AWS analytics/ML services.
Use AWS IoT Greengrass when devices need to process data locally (e.g., for low-latency decisions) or operate offline temporarily.
Use AWS IoT Device Management when you need to manage device fleets (updating firmware, monitoring health).
Avoid AWS IoT Core if you only need simple pub/sub messaging for a handful of devices; consider Amazon MQ (managed RabbitMQ/ActiveMQ) or a lightweight MQTT broker.
Security and Authentication
Devices must authenticate using X.509 certificates (recommended) or AWS IoT custom authentication (e.g., token-based). AWS IoT Core supports mutual TLS: the device verifies the server certificate, and the server verifies the device certificate. Certificates can be activated, deactivated, or revoked. For fleet provisioning, AWS IoT Core can automatically issue certificates using a just-in-time provisioning (JITP) flow.
Limits and Defaults
Maximum message size: 128 KB (but pricing is per 5 KB block)
Maximum topic depth: 7 levels
Maximum number of subscriptions per device: 50 (default, can be increased)
Device Shadow document size: 8 KB
Rules: up to 100 per account (soft limit, can be increased)
Example: Connecting a Temperature Sensor
Create a thing in the device registry.
Generate and download a certificate, private key, and root CA.
Attach a policy to the certificate that allows publish/subscribe on specific topics.
Configure the device to connect to the endpoint (e.g., a1234567890abc.iot.us-east-1.amazonaws.com) using MQTT with TLS.
Device publishes {"temp": 22.5} to topic sensor/temp.
A rule triggers: SELECT * FROM 'sensor/temp' WHERE temp > 30 writes to DynamoDB.
A Lambda function is invoked to send an email alert via SNS.
CLI Example: Creating a Thing
aws iot create-thing --thing-name "TemperatureSensor1"
aws iot create-keys-and-certificate --set-as-active --certificate-pem-outfile cert.pem --public-key-outfile public.pem --private-key-outfile private.pem
aws iot attach-policy --policy-name "SensorPolicy" --target "arn:aws:iot:us-east-1:123456789012:cert/abc123..."
aws iot attach-thing-principal --thing-name "TemperatureSensor1" --principal "arn:aws:iot:us-east-1:123456789012:cert/abc123..."Create an IoT Thing
In the AWS IoT Core console, navigate to 'Manage' > 'Things' and click 'Create'. Enter a unique name for your thing (e.g., 'FactorySensor1'). You can optionally add attributes like 'firmwareVersion' or 'location'. Behind the scenes, this creates an entry in the Device Registry. The registry does not store actual device data; it's just metadata. You can create up to 1 million things per account by default. This step is the foundation: without a registered thing, the device cannot be authenticated or managed.
Generate and Attach a Certificate
While creating the thing, you can generate a new X.509 certificate. AWS IoT Core provides one-click certificate creation. Download the certificate, private key, and root CA for AWS IoT. The certificate must be activated (set as active). Then attach a policy to the certificate that defines permissions. For example, a policy might allow `iot:Publish` on topic `factory/sensor1/data`. The device will present this certificate when connecting. If you lose the private key, you must generate a new certificate. This step ensures secure mutual TLS authentication.
Configure Device to Connect
On the physical device (or a simulator), install the downloaded certificate, private key, and root CA. Use an MQTT client library (e.g., AWS IoT Device SDK) to connect to the device endpoint. The endpoint is specific to your account and region, e.g., `a3xyz.iot.us-east-1.amazonaws.com`. The connection uses TLS on port 8883. The device must specify the client ID (usually the thing name). If the certificate is valid and the policy allows, the connection succeeds. Behind the scenes, the Device Gateway authenticates the certificate and establishes a persistent MQTT connection.
Publish a Message
Once connected, the device publishes a JSON message to a topic. For example, it sends `{"temperature": 25.0, "humidity": 60}` to topic `factory/sensor1/data`. The message size is limited to 128 KB, but pricing is per 5 KB block. The Message Broker receives the message and delivers it to all subscribers of that topic. Subscribers can be other devices or the Rules Engine. If no subscribers exist, the message is still accepted but discarded. The broker acknowledges the publish with a PUBACK packet (if QoS=1).
Create a Rule to Process the Message
In the AWS IoT Core console, go to 'Act' > 'Rules' and create a new rule. Write an SQL statement like `SELECT temperature, humidity FROM 'factory/+/data' WHERE temperature > 30`. Set an action, e.g., 'Insert a message into DynamoDB table'. The rule's IAM role must have write access to the table. When a message matches, the Rules Engine executes the action. Behind the scenes, the rule subscribes to the topic pattern and processes each message in near real-time. This step enables serverless data processing without polling.
Monitor and Manage with Device Shadow
Optionally, use Device Shadow to synchronize state. In the console, under 'Manage' > 'Things', select your thing and view its 'Shadow'. The shadow is a JSON document with `reported` and `desired` sections. The device can update its reported state (e.g., `{"temperature": 25}`). An application can write to the desired state (e.g., `{"targetTemperature": 22}`) to command the device. When the device reconnects, it reads the desired state and acts. Shadows are stored in AWS IoT Core and have a maximum size of 8 KB. They are useful for devices that are not always online.
Scenario 1: Smart Building Energy Management
A commercial real estate company wants to reduce energy costs by monitoring HVAC systems across 500 buildings. Each building has thousands of sensors (temperature, occupancy, CO2). The team uses AWS IoT Core to connect all sensors via MQTT. Each sensor publishes data every 5 minutes. Rules route high-temperature alerts to an SNS topic that notifies facility managers. Device Shadow stores the last known state of each sensor, so the central dashboard always shows current data even if a sensor is offline. Cost: At 10 million messages per month, the message cost is ~$10 (at $1 per million). However, they also use AWS IoT Device Management for firmware updates, adding $0.05 per device per month. Misconfiguration: One team forgot to attach a policy that allowed publishing, causing all sensors to fail authentication. They fixed it by attaching the correct policy to the certificate. Without proper IAM roles for rules, the DynamoDB insert failed silently, leading to data loss. They learned to use CloudWatch Logs for rule execution errors.
Scenario 2: Industrial Predictive Maintenance
A factory uses AWS IoT Greengrass on a local edge gateway to collect vibration data from machinery. The gateway runs a Lambda function that analyzes data locally and only sends anomalies to the cloud. This reduces cloud data transfer by 90%. The gateway also maintains a local Device Shadow so that the machine's state is preserved during internet outages. When the gateway reconnects, it syncs the shadow with AWS IoT Core. Cost: Greengrass has no additional charge beyond the core AWS IoT Core message costs and the EC2 or hardware costs for the gateway. What goes wrong: If the Greengrass group's IAM role is misconfigured, the gateway cannot sync shadows. Also, if the local Lambda function fails, the gateway stops processing until restarted.
Scenario 3: Connected Vehicle Fleet
A logistics company uses AWS IoT FleetWise to collect telemetry from 10,000 trucks. Each truck sends engine diagnostics, GPS, and fuel data. FleetWise standardizes the data model and uses AWS IoT Core for connectivity. The data is processed in near real-time to optimize routes and predict maintenance. Cost: FleetWise charges per vehicle per month (~$1 per vehicle). Misconfiguration: If the data collection campaign is not properly defined, unnecessary data is collected, increasing costs. Also, if the vehicle's certificate expires, the truck cannot connect until a new certificate is issued.
What CLF-C02 Tests on This Objective
The exam objective 3.5 (Cloud Technology Services) asks you to identify the purposes of IoT services. You will not be asked to configure IoT Core deeply, but you must know:
The core components: Device Gateway, Message Broker, Device Registry, Device Shadow, Rules Engine.
The primary protocol: MQTT (and optionally HTTP).
The security mechanism: X.509 certificates for mutual TLS.
The integration targets: Lambda, DynamoDB, Kinesis, S3, SNS, SQS.
The difference between IoT Core and Greengrass (edge vs cloud).
Common Wrong Answers and Why Candidates Choose Them
'AWS IoT Core uses HTTP for all communication.' Wrong: It primarily uses MQTT, a lightweight pub/sub protocol. HTTP is only supported via WebSocket or REST API. Candidates confuse IoT Core with a general web server.
'Device Shadow stores the entire history of device data.' Wrong: Shadow stores only the last reported and desired state (a single JSON document). Historical data is stored using Rules Engine to DynamoDB or S3. Candidates think 'shadow' implies a log.
'IoT Core can process data without any other AWS service.' Wrong: IoT Core only routes messages; processing requires Rules Engine actions (e.g., Lambda, DynamoDB). Candidates see 'Core' and assume it does everything.
'Greengrass is a replacement for IoT Core.' Wrong: Greengrass extends IoT Core to the edge; it still requires IoT Core for cloud connectivity and management. Candidates think they are alternatives.
Specific Terms That Appear Verbatim
'MQTT' (Message Queuing Telemetry Transport)
'Device Shadow' (also called 'thing shadow')
'X.509 certificate'
'Rules Engine'
'Device Gateway'
'Greengrass'
'Thing' (a device representation)
Tricky Distinctions
IoT Core vs. IoT Device Management: IoT Core is for connectivity; Device Management is for fleet management (organizing, monitoring, updating).
IoT Core vs. IoT Analytics: Core routes data; Analytics processes and analyzes historical data.
IoT Core vs. Amazon MQ: IoT Core is for IoT devices with MQTT; Amazon MQ is for existing message brokers (RabbitMQ, ActiveMQ) for enterprise messaging.
Decision Rule for Multiple Choice
If the question asks about 'connecting millions of devices with different protocols' → IoT Core. If it mentions 'processing data locally even when disconnected' → Greengrass. If it asks about 'storing the last known state' → Device Shadow. If it asks about 'sending alerts based on sensor data' → Rules Engine + SNS.
AWS IoT Core provides a managed MQTT message broker, device gateway, device registry, and device shadow for connecting IoT devices to the cloud.
Device authentication uses X.509 certificates with mutual TLS; policies control publish/subscribe permissions.
Device Shadow stores the last reported and desired state (max 8 KB), enabling offline device synchronization.
Rules Engine processes incoming messages using SQL-like syntax and can route data to Lambda, DynamoDB, S3, Kinesis, SNS, SQS, and more.
AWS IoT Greengrass extends AWS to edge devices for local processing and offline operation, syncing with IoT Core when connected.
IoT Core pricing is per million messages (up to 5 KB per message); free tier includes 2,500 messages/month for 12 months.
The primary protocol is MQTT; HTTPS and MQTT over WebSocket are also supported.
Common exam traps: confusing Device Shadow with historical storage, thinking Greengrass replaces IoT Core, or assuming IoT Core only uses HTTP.
These come up on the exam all the time. Here's how to tell them apart.
AWS IoT Core
Cloud-based message broker and device gateway
Requires constant internet connectivity for real-time processing
Manages device authentication and shadows centrally
Pricing per million messages
Best for devices that can always connect to the cloud
AWS IoT Greengrass
Edge computing runtime that extends AWS to local devices
Can process data locally even when offline
Maintains local device shadow and syncs with cloud when connected
No additional charge beyond IoT Core messages and compute resources
Best for devices that need low-latency responses or intermittent connectivity
AWS IoT Core
Designed for IoT devices with MQTT protocol
Supports millions of concurrent device connections
Built-in device authentication via X.509 certificates
Serverless, no broker management
Integrates with IoT-specific services (Device Shadow, Rules Engine)
Amazon MQ
Managed message broker for RabbitMQ or ActiveMQ
Supports JMS, AMQP, STOMP, MQTT, and WebSocket
Authentication via standard broker mechanisms (username/password, TLS)
You manage broker instances (size, multi-AZ)
Best for migrating existing enterprise messaging systems
Mistake
AWS IoT Core only supports the MQTT protocol.
Correct
IoT Core supports MQTT (port 8883), MQTT over WebSocket (port 443), and HTTPS (port 443). It also supports LoRaWAN via AWS IoT Core for LoRaWAN, but not directly.
Mistake
Device Shadow stores all historical data from a device.
Correct
Device Shadow only stores the most recent reported and desired state (a single JSON document). For historical data, you must use Rules Engine to write to a database like DynamoDB or S3.
Mistake
You cannot use AWS IoT Core without using MQTT.
Correct
You can use HTTPS to publish and subscribe, but MQTT is recommended for low-bandwidth, high-latency, or unreliable networks. HTTPS is suitable for occasional updates.
Mistake
AWS IoT Greengrass is a standalone service that does not require IoT Core.
Correct
Greengrass extends AWS IoT Core to edge devices. It requires an IoT Core account and uses IoT Core for cloud connectivity and device management. Greengrass devices sync shadows and certificates with IoT Core.
Mistake
IoT Core automatically encrypts all data at rest.
Correct
IoT Core encrypts data in transit using TLS, but it does not store data persistently (except Device Shadow). For data at rest, you must use other services like S3 (server-side encryption) or DynamoDB (encryption at rest).
AWS IoT Core is a cloud-based message broker and device gateway that connects IoT devices to the cloud. AWS IoT Greengrass is an edge runtime that extends AWS to local devices, allowing them to process data locally, run Lambda functions, and sync with IoT Core when connected. Greengrass is not a replacement for IoT Core; it complements it by enabling offline and low-latency processing.
No, AWS IoT Core does not permanently store device messages. It only temporarily holds messages in the message broker until they are delivered to subscribers. For persistent storage, you must use the Rules Engine to route messages to a database like DynamoDB, S3, or Timestream. Device Shadow stores only the last reported and desired state, not historical data.
AWS IoT Core supports MQTT (port 8883 for TLS), MQTT over WebSocket (port 443), and HTTPS (port 443). MQTT is the recommended protocol for IoT due to its lightweight nature and support for pub/sub messaging. HTTPS is suitable for devices that only need to publish data occasionally.
Devices authenticate using X.509 certificates (mutual TLS). Each device presents its certificate when connecting, and AWS IoT Core verifies it against a registered certificate. Policies attached to the certificate define which topics the device can publish or subscribe to. Alternatively, custom authentication using token-based methods is possible but less common.
The maximum message size is 128 KB. However, pricing is based on 5 KB increments. For example, a 6 KB message counts as two messages (two 5 KB blocks). If your messages are larger, you should compress or split them.
Yes, you can use HTTPS to publish messages to IoT Core. However, HTTPS is request-response, not pub/sub, so you cannot subscribe to topics via HTTPS. For full pub/sub functionality, MQTT is required. IoT Core also supports MQTT over WebSocket for browser-based applications.
A Device Shadow is a JSON document that stores the last reported state of a device and a desired state set by applications. It allows applications to read the device state even when the device is offline, and it enables commands to be sent to devices that may not be continuously connected. For example, you can set a desired temperature in the shadow, and when the thermostat reconnects, it reads the shadow and adjusts accordingly.
You've just covered AWS IoT Services Overview — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?