Cargando...
Cargando...
Fully managed MQTT broker and device gateway that connects billions of IoT devices to AWS services without managing infrastructure
AWS IoT Core is a fully managed cloud service that lets connected devices securely interact with cloud applications and other devices using MQTT, HTTPS, and WebSockets protocols. It provides a scalable message broker, a rules engine to route device data to AWS services, and a device shadow service to maintain persistent device state. IoT Core handles authentication, authorization, and message routing — eliminating the need to provision or manage servers.
Securely ingest, route, and act on data from millions of IoT devices without managing infrastructure, using certificate-based mutual TLS authentication and a powerful rules engine
Use When
Avoid When
MQTT Message Broker
Supports QoS 0 and QoS 1 only (QoS 2 NOT supported)
Device Shadow (Classic and Named)
Persists desired/reported/delta state; survives device disconnection
Rules Engine with SQL-like syntax
Routes messages to 20+ AWS service targets including Lambda, S3, DynamoDB, Kinesis, SNS, SQS
X.509 Certificate-based mutual TLS authentication
Primary and recommended authentication method for devices
Custom Authorizers (Lambda-based)
Enables token-based or OAuth authentication for devices that cannot use certificates
IAM-based authentication (for AWS services/users)
Used for AWS services calling IoT Core APIs, NOT recommended for devices
Amazon Cognito Identity authentication
Suitable for mobile/web apps acting as IoT clients
IoT Policies (resource-based, not IAM policies)
Attached to certificates or Cognito identities; control CONNECT, PUBLISH, SUBSCRIBE, RECEIVE actions
Fleet Provisioning
Automates device registration at scale using provisioning templates and claim certificates
Just-in-Time Provisioning (JITP)
Automatically registers devices on first connection using CA-signed certificates
Just-in-Time Registration (JITR)
Similar to JITP but requires a Lambda function to complete registration
Fleet Indexing and Search
Query device registry, shadow state, and connectivity status across entire fleet
Retained Messages (MQTT)
One retained message per topic; new subscribers receive it immediately
Last Will and Testament (LWT)
Broker publishes a configured message when a device disconnects unexpectedly
MQTT 5 Support
Includes shared subscriptions, message expiry, and reason codes
Shared Subscriptions (MQTT 5)
Distributes messages across a group of subscribers for load balancing
VPC Endpoints (PrivateLink)
Allows IoT Core API calls from within VPC without internet gateway
CloudWatch Metrics and Logs
Monitor connection counts, message rates, rule execution errors
CloudTrail Integration
Logs all IoT Core API calls for auditing and compliance
AWS IoT Defender (Audit and Detect)
Continuously audits IoT configurations and detects anomalous device behavior
QoS 2 (exactly-once delivery)
NOT supported — only QoS 0 and QoS 1 are available
Cloud-to-Edge Extension
high freqIoT Core handles cloud-side messaging and device registry; Greengrass extends IoT Core capabilities to edge devices for local processing, ML inference, and offline operation. Greengrass devices appear as things in IoT Core registry and use the same X.509 certificate authentication.
Serverless Device Event Processing
high freqIoT Rules Engine triggers Lambda functions based on SQL-filtered MQTT messages. Lambda processes device data, enriches it, and writes to databases or triggers downstream workflows. Most common pattern for real-time device event handling.
Device Telemetry Time-Series Storage
high freqRules Engine DynamoDB action writes filtered device telemetry directly to DynamoDB tables without Lambda. Supports DynamoDBv2 action for writing entire message payload as a single item.
High-Throughput Telemetry Ingestion
high freqRules Engine routes high-volume device messages to Kinesis Data Streams for real-time analytics with Kinesis Data Analytics or batch processing with EMR/Glue. Best for millions of messages per second.
Device Data Lake Ingestion
high freqRules Engine S3 action stores device messages as objects for long-term storage, compliance, and batch analytics with Athena or Glue. Often combined with Kinesis Firehose for batching and compression.
Service-Level Authorization
high freqIAM policies control who can call IoT Core management APIs (create things, manage certificates, create rules). IoT Policies (separate from IAM) control what authenticated devices can do on the message broker. These are two distinct authorization layers.
IoT API Audit Trail
high freqCloudTrail logs all IoT Core control plane API calls (CreateThing, AttachPolicy, CreateCertificate) for security auditing and compliance. Data plane (MQTT publish/subscribe) is logged via CloudWatch Logs, not CloudTrail.
Device Fleet Observability
high freqIoT Core publishes metrics (connected devices, messages in/out, rule executions, throttled requests) to CloudWatch. CloudWatch Logs captures broker logs and rules engine execution logs for debugging. Alarms can trigger SNS notifications or Lambda remediation.
Simple Device Action Triggering
medium freqIoT 1-Click manages simple single-purpose devices (enterprise buttons like Dash Button) and integrates with IoT Core to trigger Lambda functions or send SNS notifications on button press. Abstracts away certificate management for simple devices.
Device Alert Fan-Out
medium freqRules Engine SNS action publishes device alerts to SNS topics for fan-out to multiple subscribers (email, SMS, SQS queues, Lambda). Used for threshold-based alerting when device telemetry exceeds limits.
ML-Powered Device Anomaly Detection
medium freqDevice telemetry flows through IoT Core Rules Engine to Kinesis or S3, then to SageMaker for model training and batch inference. Real-time inference can use Lambda triggered by IoT rules calling SageMaker endpoints.
X.509 certificates with mutual TLS (port 8883) is the ONLY correct authentication method for IoT devices in exam scenarios — never IAM user access keys, never root account credentials, never username/password alone
IoT Policies are SEPARATE from IAM policies — IoT Policies are attached to X.509 certificates or Cognito identities and control MQTT broker actions (CONNECT, PUBLISH, SUBSCRIBE, RECEIVE). IAM policies control IoT Core API calls. Confusing these two is the #1 authorization trap.
IoT Core does NOT support QoS 2 (exactly-once delivery) — only QoS 0 (at-most-once, fire-and-forget) and QoS 1 (at-least-once, with ACK). If an exam question asks about guaranteed exactly-once delivery, the answer involves application-level deduplication, not QoS 2.
AWS IoT Greengrass ≠ AWS IoT Core — Greengrass runs at the EDGE (on local hardware) and enables local processing, Lambda execution, and ML inference without cloud connectivity. IoT Core is cloud-only. Exam questions about 'processing data locally when internet is unavailable' always point to Greengrass.
IoT devices authenticate with X.509 certificates (mutual TLS) — NEVER IAM user access keys, NEVER root account credentials. Certificates are the ONLY correct answer for device authentication.
IoT Core (cloud) ≠ IoT Greengrass (edge). 'Local processing', 'offline capability', 'edge ML inference' = Greengrass. 'Cloud connectivity', 'routing to S3/DynamoDB', 'device registry' = IoT Core.
There are TWO separate authorization systems: IoT Policies (attached to certificates, control MQTT broker actions) and IAM Policies (control IoT Core API/management calls). Both must permit the action for it to succeed.
Device Shadow is for lightweight state synchronization (desired vs. reported state), NOT for storing large amounts of data. The 8 KB limit means it holds configuration and status, not telemetry history. Large data goes to DynamoDB or S3.
Message billing uses 5 KB increments — a 128 KB payload costs 26 message units (ceil(128/5) = 26). This dramatically affects cost calculations for large payloads and is why chunking or using S3 pre-signed URLs for large data is architecturally preferred.
The Rules Engine uses SQL-like syntax (SELECT, FROM, WHERE) on MQTT topics — it can filter, transform, and route messages to 20+ AWS services without any Lambda code. Knowing this eliminates unnecessary Lambda in architecture questions.
VPC does NOT provide IoT device management or IoT Core functionality — IoT Core is a fully managed service outside your VPC. VPC Endpoints (PrivateLink) allow private API access, but device connections still go through IoT Core endpoints. Never select 'deploy IoT Core in VPC' as an answer.
CloudTrail captures IoT Core CONTROL PLANE API calls (management operations). CloudWatch Logs captures DATA PLANE activity (broker logs, rule engine logs). If an exam asks about auditing 'who created a certificate' use CloudTrail; if debugging 'why did my rule fail' use CloudWatch Logs.
Just-in-Time Provisioning (JITP) vs Fleet Provisioning: JITP auto-registers devices using CA-registered certificates on first connection. Fleet Provisioning uses claim certificates and provisioning templates for large-scale manufacturing scenarios. Both eliminate manual certificate management.
Last Will and Testament (LWT) is the mechanism to detect unexpected device disconnections — the broker publishes the LWT message to a configured topic when a device drops without a proper DISCONNECT. Use this to trigger alerts or state updates for offline devices.
Common Mistake
IoT devices should authenticate to AWS IoT Core using IAM user access keys (Access Key ID + Secret Access Key) for programmatic access
Correct
IoT devices MUST use X.509 certificates with mutual TLS authentication. IAM access keys are for human users and AWS services — they are not appropriate for embedded devices, are difficult to rotate at scale, and are explicitly against AWS security best practices for IoT
This is the #1 exam trap. The question will describe a device needing to 'securely connect' and offer IAM access keys as an option. Remember: Devices get certificates, humans get IAM. Certificates can be issued per-device, rotated via IoT Core, and revoked instantly without changing code.
Common Mistake
AWS IoT Core and AWS IoT Greengrass are the same service or Greengrass is just a feature of IoT Core
Correct
They are separate services with distinct roles. IoT Core is a cloud-based managed MQTT broker and rules engine. Greengrass is edge software that runs ON your devices/gateways, enabling local compute, ML inference, and offline operation. Greengrass devices DO register with IoT Core, but the processing happens locally.
Exam questions about 'offline processing', 'low latency local decisions', or 'running Lambda at the edge' always want Greengrass. Questions about 'cloud-scale device connectivity' or 'routing device data to S3' want IoT Core. The trigger phrase is 'local' or 'without internet'.
Common Mistake
VPC (Virtual Private Cloud) provides IoT device management capabilities and IoT Core should be deployed inside a VPC
Correct
IoT Core is a fully managed AWS service that exists outside customer VPCs — you cannot deploy it inside a VPC. VPC Endpoints (AWS PrivateLink) allow your VPC resources to call IoT Core APIs privately, but IoT Core itself is not VPC-hosted. Device management is handled by AWS IoT Device Management, not VPC.
Candidates confuse 'private connectivity to a service' with 'deploying a service in a VPC'. IoT Core manages its own infrastructure. If you see 'deploy IoT Core in VPC' as an answer, it is always wrong.
Common Mistake
IoT Core supports QoS 2 (exactly-once delivery) like standard MQTT brokers
Correct
IoT Core only supports QoS 0 (at-most-once) and QoS 1 (at-least-once). QoS 2 is NOT supported. For exactly-once semantics, you must implement application-level deduplication using message IDs stored in DynamoDB or similar.
This catches candidates who know MQTT well. Standard MQTT 3.1.1 supports QoS 0, 1, and 2 — but IoT Core deliberately omits QoS 2 for scalability reasons. Any exam answer mentioning QoS 2 as an IoT Core feature is a distractor.
Common Mistake
Device Shadow is a database that stores all historical device telemetry and can handle large data payloads
Correct
Device Shadow is a lightweight JSON document (max 8 KB) that stores ONLY the current desired and reported state of a device. It is not a time-series database or telemetry store. Historical telemetry should go to DynamoDB, S3, or Timestream via the Rules Engine.
The word 'shadow' implies a full mirror of device data, but it is really just a small configuration/status sync mechanism. If you see a question about storing sensor readings over time or large payloads, the answer is never 'Device Shadow'.
Common Mistake
Using the AWS root user account for IoT device programmatic access is acceptable for testing or development
Correct
The root user should NEVER be used for programmatic access under any circumstances — including IoT scenarios. Devices should use X.509 certificates. AWS services interacting with IoT Core programmatically should use IAM roles with least-privilege policies.
Root account misuse appears as a distractor in security-focused exam questions. Any answer suggesting root account credentials for device or service access is always wrong, regardless of context.
CERT not KEY: Devices get Certificates, Employees get Keys (IAM). Never mix them.
QoS 0-1-STOP: IoT Core stops at QoS 1. QoS 2 is a trap — implement dedup yourself.
SHADOW = Small (8 KB): Shadow stores State, not Streams. Streams go to Kinesis/S3.
CORE = Cloud, GREEN = Ground: IoT Core lives in the cloud; Greengrass grows on-device at ground level.
RULES route, LAMBDA executes: Rules Engine can route to 20+ services directly — Lambda is optional, not mandatory.
TWO POLICY LAYERS: IoT Policy (broker actions: CONNECT/PUB/SUB) + IAM Policy (API calls: CreateThing/AttachCert). Both must allow the action.
CertAI Tutor · CLF-C02, SAP-C02 · 2026-02-21
In the Same Category
Comparisons