Why device management emerged as its own layer on top of IoT Core, and how it has grown since.

AWS IoT Core launched in 2015 with the core connectivity primitives — a device gateway, a message broker, and a rules engine — but it deliberately did not solve fleet-scale operational problems on day one. Early adopters quickly ran into the same wall: connecting a thousand devices was solved, but knowing which thousand devices existed, what firmware version each was running, and how to push an update to only the ones still on an old version was not. AWS IoT Device Management arrived in 2017 specifically to close that gap, adding a structured registry, a jobs execution framework, and fleet indexing on top of the existing connectivity layer.

The feature set has kept expanding along the same theme — reducing manual, per-device operations into fleet-wide, queryable actions. Fleet provisioning arrived to remove manual certificate installation during manufacturing. Secure tunneling arrived to give support engineers remote shell access to a device behind a NAT without opening inbound firewall ports. Fleet Hub arrived as a low-code dashboard for support teams who should not need to write code to check on a device’s health. Most recently, a Commands capability was introduced to handle short-lived, synchronous remote actions distinct from the longer-running Jobs framework, reflecting a growing recognition that not every remote interaction with a device fits the multi-stage rollout model Jobs was originally designed around.

Understanding this progression matters because, much like AppSync’s resolver history, a production IoT account can contain a mix of eras: devices still relying on a manually installed certificate from before fleet provisioning existed, sitting in the same registry as devices that self-provisioned last week through a JITP template. Recognizing which mechanism a given device went through explains a lot about why its registry entry looks the way it does, and it also explains why migration projects — moving a legacy manually provisioned fleet onto fleet-indexing-driven dynamic groups, for instance — tend to take longer than expected: the older devices often lack the consistent attribute data the newer provisioning path fills in automatically, requiring a deliberate backfill effort before they behave the same way in queries as devices provisioned through the current process.

What operational pain shows up the moment a fleet grows past a handful of devices.

A single connected device is easy to reason about — you can SSH into it, check its logs, and push an update by hand. That approach falls apart at scale for reasons that are more organizational than technical: nobody can manually track firmware versions across ten thousand devices in a spreadsheet reliably, nobody wants to push an update to the entire fleet simultaneously and risk bricking every unit at once if the update is bad, and nobody wants a new device sitting in a warehouse waiting for someone to manually generate and install its security certificate before it can ship.

Device Management exists to convert every one of those into a fleet-wide, queryable, and auditable operation rather than a per-device manual chore, without asking the device itself to become smarter than it needs to be — the intelligence lives in the managed service layer, not duplicated across thousands of constrained embedded devices.

The intermediate vocabulary — the pieces that matter once you’re past “a Thing is a device record” and into how fleets are actually operated.

It is also worth being precise about what a Job actually targets. A Job’s target is always a Thing or a Thing Group, never an individual shadow field or a raw MQTT topic directly — the Jobs service resolves the target group into a concrete list of devices at rollout time, and if that target is a dynamic group, the list of devices a Job reaches can genuinely change mid-rollout as devices enter or leave the group based on their evolving reported state, a subtlety that surprises engineers who assume a Job’s target list is frozen the moment the Job is created.

Custom registry fields deserve a closer look because they are frequently the bridge between a device’s technical identity and an organization’s operational reality. A Thing Type defines the schema every device of that model shares, but a business often needs to track things that have nothing to do with the device’s technical capabilities — which customer account it’s associated with, when its warranty expires, which distributor sold it. Custom fields let that operational metadata live directly on the registry entry, queryable through the same fleet-indexing mechanism as technical attributes, so a support query like “every device under warranty in this region reporting firmware below version 3” can combine business and technical attributes in a single search rather than requiring a join against some external system.

How the device management layer sits on top of, and alongside, core IoT connectivity.

Device Management is best understood as a set of services that all read from and write to the same underlying Device Registry, rather than as one monolithic service. The registry is the hub; Shadows, Jobs, Fleet Indexing, Secure Tunneling, and Fleet Provisioning are spokes, each solving one facet of fleet operations while staying anchored to the same Thing identity.

graph TD
  A[IoT Device] -->|MQTT over TLS| B[IoT Core Device Gateway]
  B --> C[Device Registry - Thing, Thing Type, Thing Group]
  B --> D[Device Shadow Service]
  B --> E[Rules Engine]
  E --> F[AWS Lambda]
  E --> G[Amazon S3]
  E --> H[Amazon DynamoDB]
  C --> I[Fleet Indexing Service]
  I --> J[Fleet Hub Dashboard]
  B --> K[Jobs Service]
  K --> L[OTA Update Execution on Device]
  B --> M[Secure Tunneling Service]
  M --> N[Remote Support Client]
  C --> O[Device Defender]
        

Notice that the Rules Engine sits beside Device Management rather than inside it — it is IoT Core’s general-purpose routing mechanism, and Device Management features frequently use it as plumbing. A Job status change, for instance, can trigger a rule that writes an audit record to DynamoDB or invokes a Lambda function to notify an operations team, without the Jobs service itself needing to know anything about DynamoDB or Lambda directly.

It also helps to notice what does not appear as a separate box in this diagram: device authentication and authorization. Every one of these services — Shadows, Jobs, Fleet Indexing, Secure Tunneling — sits behind the same device gateway and the same per-device X.509 certificate and IoT policy, meaning a device’s ability to interact with its own shadow or receive a job notification is governed by the exact same security boundary as its ability to publish a telemetry message, not a separate permission model layered on top.

The choice to anchor every one of these services around the Thing identity rather than around a raw device connection is deliberate and worth calling out explicitly. A device can disconnect and reconnect, change IP addresses, or even swap the physical hardware behind a given certificate during a repair, and every piece of Device Management state — its shadow, its group memberships, its job history — stays attached to the stable Thing record in the registry rather than to any particular live connection. This is what makes it possible to query “show me this device’s job history” meaningfully even while the device itself is offline.

What actually happens inside the shadow service and the jobs service when state changes.

The Device Shadow service works on a simple but easy-to-misunderstand principle: it never talks to the device directly to “ask” for its state. Instead, the device publishes its own state to a reserved shadow topic whenever it changes, and any application wanting to change the device’s target state publishes a desired-state update to a different reserved topic. The shadow service’s job is purely to store both documents, compute the difference between them, and publish that difference — the “delta” — to a topic the device is subscribed to. The device then decides, on its own schedule and its own logic, whether and how to act on that delta and report a new reported state once it has.

The Jobs service works differently, and understanding the distinction matters. Where a shadow is fundamentally about state, a Job is fundamentally about an action with a lifecycle — QUEUED, IN_PROGRESS, SUCCEEDED, FAILED, TIMED_OUT, CANCELED, or REJECTED, tracked individually per targeted device. When a Job is created, the service resolves its target Thing Group into a concrete device list, then publishes a job-available notification to each targeted device over a reserved MQTT topic. Each device independently requests the full job document — which contains whatever instructions the operator defined, commonly an S3 URL pointing to a firmware image plus a checksum — executes the described action locally, and reports its own execution status back. The Jobs service aggregates all of those individual statuses into the fleet-wide rollout view an operator sees on a dashboard.

Job execution status carries more nuance than a simple success/failure flag once you look closely at its terminal states. REJECTED means the device explicitly declined the job — for example, because it determined the referenced firmware version was already older than what it’s running. FAILED means the device attempted the job and its own logic reported an error during execution. TIMED_OUT means the device never reported a terminal status within the configured window at all, which is a meaningfully different signal from an explicit failure and usually points toward a connectivity or firmware-hang issue rather than an update that was actively rejected or broke something.

Tracing a Job from creation to fleet-wide completion, and a shadow update from device to application.

sequenceDiagram
  participant Op as Operator/Console
  participant Jobs as Jobs Service
  participant Reg as Device Registry
  participant Dev as Target Device
  Op->>Jobs: Create job with job document and target thing group
  Jobs->>Reg: Resolve target group into device list
  Jobs->>Dev: Publish job-available notification
  Dev->>Jobs: Request full job document
  Jobs-->>Dev: Return job document with update reference
  Dev->>Dev: Download, verify and apply update locally
  Dev->>Jobs: Publish job execution status update
  Jobs-->>Op: Aggregate status across the whole rollout
        

Rollout configuration is where the lifecycle gets operationally interesting. A Job can be configured with a rollout rate — for instance, starting at ten devices per minute and increasing gradually — rather than notifying the entire target group simultaneously, specifically to contain the blast radius of a bad update. Paired with this, an abort configuration can automatically halt the rollout if the failure rate among devices that have already attempted the job crosses a defined threshold, stopping a bad firmware push after a small, recoverable batch of devices rather than after the entire fleet has already attempted it.

graph TD
  A[Device Publishes Reported State] --> B[Shadow Document]
  C[Application Publishes Desired State] --> B
  B -->|Computed Delta| A
  B -->|Get Shadow Request| C
        

It is worth explicitly noting that a Job’s lifecycle and a Shadow’s lifecycle are independent of each other by default. A firmware update Job completing successfully does not automatically update a device’s shadow to reflect the new firmware version — if an operator wants that reflected in shadow state (so it becomes queryable through fleet indexing), the device’s own application logic, once it finishes applying the update, needs to explicitly report that new version as part of its reported state. This is a frequent point of confusion for teams new to the service, who sometimes assume Jobs and Shadows are more tightly coupled than they actually are.

There is also a subtlety in how a device discovers work at all when it reconnects after being offline for an extended period. Rather than relying solely on a live MQTT notification that it may have missed entirely while disconnected, a device can query for any pending job executions immediately after establishing its connection, using a dedicated get-pending-jobs request. This request-driven fallback is what actually guarantees a device eventually receives every job targeted at it, regardless of how long it stayed offline or how many notifications it missed while disconnected — the live notification is a convenience for immediacy, not the sole delivery mechanism.

What a managed fleet layer buys you, and where it still asks something of your device firmware.

The trade-off worth sitting with the longest is where responsibility actually lives. AWS owns the orchestration, tracking, and scale problem; the device’s own firmware still owns correctness — verifying a firmware signature before applying it, handling a failed download gracefully, and reporting truthful state. A device fleet built on Device Management with weak on-device update logic is still a fragile fleet, just one with a much better dashboard for watching it fail.

There is a secondary trade-off around indexing costs that is easy to overlook while designing a schema on paper. Every attribute and shadow field marked as indexed contributes to the fleet-indexing document size and the cost of maintaining that index across the entire fleet, not just the cost of running a query against it. Teams migrating from a smaller pilot fleet to full production sometimes discover, only once volume scales, that an indexing decision made casually during the prototype phase is now a meaningful and recurring line item — a reason to revisit indexed field choices deliberately before a full rollout rather than carrying forward whatever was convenient during early development.

The levers that keep a fleet’s rollout and query performance predictable as device count grows.

The main scalability lever operators actually reach for is Job rollout rate control, described earlier — deliberately trading rollout speed for blast-radius containment. A second, less obvious lever is choosing between classic and named shadows correctly: a single bloated classic shadow document updated at high frequency for many unrelated concerns (connectivity diagnostics, sensor calibration, user preferences) becomes a contention point, since every update to any part of the document re-triggers delta computation and delivery for the whole thing. Splitting unrelated state into separate named shadows lets each concern update independently without triggering unrelated delta notifications.

Fleet indexing scalability is mostly a query-design concern rather than a capacity concern, since AWS operates the index itself. The practical guidance is to index only the attributes and shadow fields actually used in dynamic group queries or Fleet Hub searches, since every additional indexed field adds to both cost and query complexity without necessarily adding operational value. Teams that index everything “just in case” tend to end up with sprawling, slow-to-reason-about queries later.

What the managed layer guarantees, and what still depends on your device’s own resilience.

The registry, shadow, and jobs services run across multiple Availability Zones as part of the managed IoT Core platform, so the control plane itself is not a single point of failure. Reliability concerns at the intermediate level mostly live at the edges — what happens when a device is offline during a rollout, and what happens when a device only connects intermittently.

That last point is worth dwelling on, because it is the most common reliability gap in real deployments. Device Management stops a bad rollout from spreading further; it does not automatically fix devices that already received the bad update. Firmware designed with an A/B partition scheme — keeping the previous known-good firmware image available and falling back to it automatically if the new image fails a post-update health check — is what actually closes that gap, and it lives entirely in device-side design, independent of anything AWS IoT Device Management provides.

Connectivity itself deserves a reliability note of its own, since devices in the field rarely enjoy the stable connections engineers test against in a lab. Intermittent connectivity — a device that connects for a few minutes, drops, and reconnects repeatedly over the course of a day, common on cellular-connected devices in poor signal areas — interacts with every mechanism described in this article simultaneously: shadow deltas queue and deliver on reconnect, job notifications may be missed and require the get-pending-jobs fallback, and fleet-indexing connectivity status flickers between connected and disconnected in a way that can make a perfectly healthy device look unstable in a dashboard unless the monitoring built on top accounts for that pattern explicitly.

How device identity, provisioning, and remote access stay locked down at fleet scale.

Fleet provisioning deserves particular attention because it is where security design decisions during manufacturing have long-lasting consequences. In Just-in-Time Provisioning (JITP), a device ships with a claim certificate that is deliberately restricted to only being able to trigger the provisioning flow — nothing else. On first connection, the device presents that claim certificate, the provisioning template runs (optionally invoking a Lambda function for custom validation, such as checking a serial number against a manufacturing database), and only if that validation passes does the device receive its permanent, individually scoped certificate and IoT policy. A poorly scoped claim certificate — one that accidentally grants broader permissions than “initiate provisioning only” — undermines the entire security model, since every device shipped with that claim certificate shares the same bootstrap identity until it individually provisions.

It is also worth distinguishing Just-in-Time Provisioning from Just-in-Time Registration, since both are commonly grouped under “fleet provisioning” but work differently underneath. JITR assumes a device already carries a unique certificate signed by a trusted certificate authority at manufacturing time, and registration in the AWS IoT registry happens automatically the first time that certificate is used to connect. JITP, by contrast, has devices share a common claim certificate and only receive their unique, permanent certificate through the provisioning template flow described above. The right choice between the two depends largely on whether the manufacturing process can already produce unique per-device certificates cost-effectively, or whether it is simpler to issue one shared claim identity and let the cloud-side template generate uniqueness at first connection instead.

Secure Tunneling’s security model is worth understanding on its own terms too, since it is easy to mistake for a VPN. It does not open any inbound port on the device’s network at all — the device establishes an outbound connection to the tunneling service using a short-lived access token, and a support engineer’s client does the same from the other side, with the tunneling service relaying traffic between the two outbound connections. No firewall rule ever needs to allow inbound traffic to the device, which is precisely why it works for devices sitting behind a typical home router’s NAT without any port forwarding configuration.

Device Defender’s audit and detect functions round out the security picture by catching drift that certificates and policies alone can’t. An audit check might flag that a device certificate is approaching its expiration date across the whole fleet, or that a device’s attached IoT policy is broader than AWS considers a best practice. A detect security profile, by contrast, watches live behavior — message frequency, connection source, authorization failure rate — against a baseline, and can trigger an automatic mitigation action, such as revoking a device’s certificate, the moment behavior crosses a defined anomaly threshold, without waiting for a human to notice the audit finding first.

How operators actually see rollout health and fleet status after the fact.

AWS IoT Core and Device Management publish metrics to Amazon CloudWatch covering connection counts, message throughput, and — specific to Device Management — job execution counts broken down by status (queued, in progress, succeeded, failed, timed out, rejected). CloudWatch Logs, when enabled for IoT Core, capture detailed connection and message-level events useful for diagnosing why a specific device failed to receive a job notification or shadow update. Device Defender adds its own detect and audit findings as a separate signal, flagging devices whose behavior has drifted from an expected security baseline rather than reporting on job or shadow health specifically.

Fleet Hub is worth mentioning again specifically in a monitoring context, since it is built to be the first place a support engineer looks rather than a raw CloudWatch dashboard. It surfaces per-device connectivity status, shadow contents, and job history through a searchable interface built directly on fleet indexing, letting non-engineering support staff answer “is this specific customer’s device online and up to date” without needing CloudWatch access or query-writing skills at all.

Alarming on these signals follows the same discipline as any other production system: CloudWatch Alarms set against job failure-rate metrics during an active rollout give an operator an automated early warning independent of whether they happen to be watching a dashboard at that exact moment, which matters especially for rollouts that run over many hours or days as they gradually expand from an initial wave to the full fleet. Pairing an alarm with the job’s own abort-threshold configuration means the rollout can be stopped automatically while a human is simultaneously notified to investigate, rather than relying on either mechanism alone. Retaining these logs and metrics for a meaningful retention window also matters beyond day-to-day operations — when a firmware issue only surfaces weeks after a rollout completed, having historical job execution and connectivity data available is often the only way to reconstruct which devices were affected and when, without needing every device to still be reachable and queryable in real time.

How registry structure, provisioning templates, and job definitions actually get shipped and versioned.

Provisioning templates, Thing Types, and IoT policies are almost always defined as infrastructure-as-code — through CloudFormation, CDK, or Terraform — rather than created ad hoc through the console, precisely because they define the security boundary every device in the fleet operates within. A change to a policy attached to thousands of already-provisioned devices needs the same review and rollout discipline as any other production security change, not a quick console edit.

Automated testing for this layer typically happens against a small, dedicated test fleet of physical or simulated devices connected to a non-production IoT endpoint, exercising the exact same provisioning template, job document format, and shadow schema that production devices will use, precisely because so much of Device Management’s correctness depends on the interaction between cloud-side configuration and device-side firmware behavior — something that is very hard to validate through cloud-side unit tests alone.

Certificate rotation strategy is another deployment-time decision worth planning deliberately rather than reactively. Device certificates typically carry an expiration date, and a fleet-wide rotation needs to be coordinated so a device’s old certificate is not deactivated before its replacement is successfully installed and verified — a process that itself often runs through the Jobs framework, treating certificate rotation as just another fleet-wide action with the same staged-rollout discipline as a firmware update, rather than a one-off manual operation performed outside the normal deployment tooling.

Recurring shapes that hold up at fleet scale, and recurring shapes that quietly cause pain later.

PATTERN-02 · Job-Driven Certificate Rotation Recommended

Context

Device certificates across a large fleet are approaching expiration and need coordinated replacement without any device losing connectivity during the transition.

Pattern

Treat certificate rotation as a staged Job like any firmware update: the device receives a job document instructing it to request, install, and verify a new certificate before the old one is deactivated, with the same rollout rate and abort-threshold discipline applied.

Consequence

Rotation becomes observable and reversible in the same way firmware rollouts are, avoiding a fleet-wide connectivity outage from a poorly coordinated manual rotation.

You may likeAWS Savings Plans→

The short list of habits that separate a resilient fleet operation from a fragile one.

Where these mechanisms show up in fleets people actually operate.