Device connectivity in AWS IoT Core: Monitor, diagnose, and act at scale

Knowing whether your IoT devices are online, understanding why they disconnected, and monitoring fleet-wide connectivity trends are among the most fundamental challenges in any IoT deployment.

Connectivity visibility is what separates reactive troubleshooting from proactive operations. That holds true across every deployment scale and shape: a fleet of 100 smart-home hubs, millions of industrial sensors, thousands of autonomous mobile robots in a warehouse, or a distributed network of smart machines on a factory floor. It matters even more as Physical AI workloads (fleets of robots, autonomous vehicles, and intelligent machines that combine edge inference with cloud coordination) gain adoption.

Over the past year, AWS IoT Core has added data-plane connection APIs (GetConnection, ListSubscriptions, and DeleteConnection) that provide real-time introspection and control over individual client connections. Connectivity logging has also expanded with additional event types, including ping (keep-alive) activity and authentication failures. These join capabilities already in the service such as Fleet Indexing, the GetThingConnectivityData API, lifecycle events, and Fleet Metrics, so you can monitor, diagnose, and act on device connectivity without building and maintaining custom infrastructure.

In this post, we walk through these connectivity management capabilities, both the recent additions and the features that came before them. For each one, we explain what it does, when to reach for it, and how it works with the others. Our goal is to give you a practical map for matching the right tool to your connectivity use case, whether you’re checking a single device, troubleshooting a live connection, or tracking fleet health.

AWS IoT Core connectivity management capabilities at a glance

The following table summarizes each connectivity management capability, along with its primary use case, typical latency, and scope, so you can compare them briefly before the sections that follow go deeper on each.

1. The foundation: Fleet Indexing with connectivity data

Fleet indexing provides the foundation for fleet-wide connectivity search, aggregation, dynamic grouping, Fleet Metrics, and thing-name-based connectivity queries. By indexing device connectivity status alongside registry attributes, shadow data, and AWS IoT Device Defender violations, it turns your entire fleet into a searchable, aggregatable, and actionable dataset.

How it works

When you enable connectivity indexing, Fleet Indexing tracks connection and disconnection events for your registered things. Connectivity status updates are eventually consistent and typically appear in the index within seconds of the actual event, though propagation time can vary. This data is stored in the AWS_Things index alongside other device metadata, creating a unified view of your fleet.

Fleet Indexing adds a set of managed connectivity fields (connection status, disconnect reason, timestamps, client ID, keep-alive, session settings) to the AWS_Things index alongside your registry and shadow data. See Managed fields for the complete schema and data types.

The power of fleet indexing for connectivity

Beyond checking whether a single device is online, with Fleet Indexing you can search, aggregate, group, and set up metrics on devices by their connectivity status:

Search and query

Find devices based on their connectivity status combined with any other indexed attribute:

# Find all disconnected devices of a specific thing type
aws iot search-index \
    --index-name "AWS_Things" \
    --query-string "connectivity.connected:false AND thingTypeName:SmartThermostat"

# Find devices that disconnected due to keep-alive timeout
aws iot search-index \
    --index-name "AWS_Things" \
    --query-string "connectivity.disconnectReason:MQTT_KEEP_ALIVE_TIMEOUT"

# Combine connectivity with shadow data (for example, disconnected devices with low battery)
aws iot search-index \
    --index-name "AWS_Things" \
    --query-string "connectivity.connected:false AND shadow.reported.battery<20"

Aggregation queries

Compute fleet-wide connectivity statistics on demand using aggregation queries:

# Count how many devices are currently connected
aws iot get-statistics \
--index-name "AWS_Things" \
--query-string "connectivity.connected:true"

# Get the distribution of disconnect reasons across your fleet
aws iot get-buckets-aggregation \
--index-name "AWS_Things" \
--query-string "connectivity.connected:false" \
--aggregation-field "connectivity.disconnectReason" \
--buckets-aggregation-type '{"termsAggregation":{"maxBuckets":10}}'

Dynamic thing groups

Create dynamic thing groups that automatically update membership based on connectivity status, and use them as targets for AWS IoT Jobs:

# Create a dynamic group of all currently disconnected devices
aws iot create-dynamic-thing-group \
    --thing-group-name "DisconnectedDevices" \
    --query-string "connectivity.connected:false"
 
# Create a dynamic group of devices disconnected due to network issues
aws iot create-dynamic-thing-group \
    --thing-group-name "NetworkIssueDevices" \
    --query-string "connectivity.disconnectReason:CONNECTION_LOST OR connectivity.disconnectReason:MQTT_KEEP_ALIVE_TIMEOUT"

After you define them, you can use dynamic thing groups as job targets to remediate devices automatically. For example, you could target all devices in the NetworkIssueDevices group with a job that adjusts their keep-alive interval or reconnection backoff strategy.

Fleet metrics (CloudWatch dashboards)

Fleet metrics periodically executes aggregation queries and emits the results as Amazon CloudWatch metrics. You define queries that aggregate connectivity data across your fleet, then build CloudWatch dashboards, set alarms, and track trends over time:

# Emit a metric every 5 minutes: count of disconnected devices
aws iot create-fleet-metric \
    --metric-name "DisconnectedDevicesCount" \
    --query-string "connectivity.connected:false" \
    --aggregation-type name=Statistics,values=count \
    --period 300 \
    --index-name "AWS_Things"

# Emit a metric: count of devices disconnected due to throttling
aws iot create-fleet-metric \
    --metric-name "ThrottledDisconnections" \
    --query-string "connectivity.disconnectReason:THROTTLED" \
    --aggregation-type name=Statistics,values=count \
    --period 300 \
    --index-name "AWS_Things"

Use Fleet metrics dashboards for operations visibility, SLA monitoring, anomaly detection, and trend reporting. For example, a warehouse running a fleet of autonomous mobile robots can track DisconnectedDevicesCount to see in real time how many robots have dropped offline, surfacing safety-critical connectivity status before it disrupts order fulfillment.

In addition to custom Fleet Metrics, the AWS IoT Core console provides a prebuilt connectivity dashboard under the Dashboard section. This dashboard displays fleet-wide connectivity statistics out of the box, with no CloudWatch configuration required, giving you immediate visibility into connected/disconnected device counts and disconnect reason distribution.

When to use fleet indexing

Consider using fleet indexing in the following scenarios:

Enabling connectivity indexing

To enable connectivity indexing, use the following command:

aws iot update-indexing-configuration \
    --thing-indexing-configuration '{
        "thingIndexingMode": "REGISTRY_AND_SHADOW",
        "thingConnectivityIndexingMode": "STATUS",
        "filter": {
            "connectivity": {
                "includeSocketInformation": ["GET_THING_CONNECTIVITY_DATA"]
            }
        }
    }'

Note: update-indexing-configuration sets your account-level indexing configuration. Fields you omit can revert to defaults rather than merge, so retrieve your current settings with aws iot get-indexing-configuration first and include every field you want to keep (custom fields, named shadows, geolocation, and so on) in the update. GetThingConnectivityData returns socket-level details only when you enable the includeSocketInformation filter. Without it, passing --include-socket-information on the request has no effect.

After you enable it, all the capabilities described in this post (GetThingConnectivityData, Fleet Metrics, dynamic thing groups, and aggregation queries) become available.

2. Real-time connectivity status: GetThingConnectivityData API

The GetThingConnectivityData API provides a managed, persistent connectivity status store for your registered things. It’s designed to answer the question: “What is the connectivity status of my device?”, whether the device connected seconds ago or has been offline for days.

How it works

After you enable connectivity indexing in Fleet Indexing, the GetThingConnectivityData API gives you low-latency, near real-time access to the most recent connectivity status for any registered thing. Unlike querying the fleet index, it reflects status changes within seconds of AWS IoT Core determining a device’s connected or disconnected status, so per-device status reflects recent changes.

Why this matters

Before this API existed, tracking device connectivity meant building your own status database. The standard pattern was to route lifecycle events through an AWS IoT rule to an AWS Lambda function that writes to an Amazon DynamoDB table. This approach requires handling message ordering (connect and disconnect events can arrive out of sequence), managing idempotency, dealing with AWS Lambda concurrency, and scaling Amazon DynamoDB capacity. GetThingConnectivityData removes this undifferentiated heavy lifting. Instead of reconstructing connectivity from lifecycle events, applications query a managed latest-status record through a single API call. For customers who previously maintained this infrastructure, adopting GetThingConnectivityData means removing AWS Lambda functions, Amazon DynamoDB tables, and the associated operational burden, while getting a more reliable result.

Example

aws iot get-thing-connectivity-data --thing-name myThermostat --include-socket-information

{
  "connected": false,
  "disconnectReason": "MQTT_KEEP_ALIVE_TIMEOUT",
  "thingName": "myThermostat",
  "timestamp": "2026-05-28T14:30:00.000000-07:00",
  "keepAliveDuration": 300,
  "cleanSession": false,
  "clientId": "myThermostat",
  "sourceIp": "203.0.113.42",
  "sourcePort": 54321,
  "targetIp": "198.51.100.10",
  "targetPort": 8883
}

When to use it

Consider this capability in the following scenarios:

Key details

• Supports 350 transactions per second (TPS) by default (adjustable through a Service Quotas increase request)
• The latest connectivity record is retained while Connectivity Indexing remains enabled and the thing continues to exist. Historical connection events are not retained as a time series by this API.
• Requires the device’s clientId to match its thingName in the registry.
• For full details on response fields, permissions, and configuration, see the developer guide

Note: The GetConnection, ListSubscriptions, and DeleteConnection APIs referenced throughout this post require a recent AWS Command Line Interface (AWS CLI) v2 release that includes the corresponding API models. Verify support with aws iot-data help and upgrade the CLI if the commands are absent.

3. Connection introspection: GetConnection API

The GetConnection API reads the broker’s live session status directly, giving you the broker’s current view of a client’s connection status at that moment. Unlike GetThingConnectivityData (which reflects status changes near real-time and requires you to enable Fleet Indexing), GetConnection reflects the broker’s ground truth in real time.

Another key difference: GetConnection accepts any client ID. The client doesn’t need to be a registered thing. This means you can inspect connections from backend applications, mobile apps, or test clients that connect to your IoT endpoint without a corresponding thing in the Registry. In contrast, GetThingConnectivityData requires a registered thing name (with clientId matching thingName). The trade-off is retention: GetConnection data is available for approximately 30 minutes after disconnection, whereas GetThingConnectivityData retains indefinitely when connectivity indexing remains enabled.

Example

aws iot-data get-connection --client-id myThermostat-001 --include-socket-information

{
  "clientId": "myThermostat-001",
  "connected": true,
  "cleanSession": false,
  "connectedSince": 1748450000000,
  "thingName": "myThermostat",
  "sourceIp": "203.0.113.42",
  "sourcePort": 54321,
  "targetIp": "198.51.100.10",
  "targetPort": 8883,
  "keepAliveDuration": 300,
  "sessionExpiry": 3600
}

When to use it

Consider this capability in the following scenarios:

For full API parameters and AWS Identity and Access Management (IAM) requirements, see the GetConnection API reference.

Tip: Broker-side status confirms that a session exists, but not always that the device is genuinely reachable and acting on what it receives. For command-style interactions, the SendDirectMessage API adds delivery acknowledgement from the device itself (a PUBACK from the receiving client), not only the broker. Because the confirmation originates at the device, AWS IoT Core gains a stronger signal for observing connectivity health and surfacing delivery failures (such as a confirmation timeout), helping close the gap when a device looks connected but isn’t responding.

4. Subscription visibility: ListSubscriptions API

Understanding what topics a device is subscribed to is critical for diagnosing message delivery failures, especially the common scenario where a device connects successfully but fails to subscribe to the topics it needs. The ListSubscriptions API gives you visibility into what a client is actually subscribed to, so you can compare expected subscriptions against reality. It works for both connected clients and offline clients with persistent sessions.

Example

aws iot-data list-subscriptions --client-id myThermostat-001 --max-results 50

{
  "subscriptions": [
    {"topicFilter": "devices/myThermostat-001/commands/#", "qos": 1},
    {"topicFilter": "fleet/updates", "qos": 0},
    {"topicFilter": "$aws/things/myThermostat/shadow/update/delta", "qos": 1}
  ]
}

When to use it

The following scenarios show where checking a client’s active subscriptions can help.

Scenario: Verify device subscriptions match intended topic filters

This is one of the most common silent configuration issues in IoT deployments: a device connects successfully, lifecycle events confirm the connection, but it silently fails to subscribe to one or more topics because of policy mismatches or firmware misconfigurations. Perhaps you updated an IoT policy and the device lacks the iot:Subscribe permission on a new topic, or a firmware update changed the subscription logic. The device appears online, but stops receiving commands or shadow updates.

With ListSubscriptions, you can immediately verify whether the expected subscriptions are in place:

# Device is connected but not responding to commands. Check its subscriptions
aws iot-data list-subscriptions --client-id myThermostat-001
 
# Expected: "devices/myThermostat-001/commands/#" at QoS 1
# If missing → the device failed to subscribe (policy issue, firmware bug, or transient error)

This is especially useful when combined with DeleteConnection (covered next): after you identify that a device has missing subscriptions, you can force a disconnect to trigger a fresh reconnection with the corrected subscription logic.

Other use cases

Consider this capability in the following scenarios:

5. Active connection control: DeleteConnection API

Observability enables action. When you identify a device that is misbehaving, has a stale policy, or is missing critical subscriptions, you need the ability to take action. With the DeleteConnection API, you can programmatically disconnect an MQTT client, optionally clearing its session state and suppressing its Last Will and Testament (LWT) message.

How it works

When you call DeleteConnection, AWS IoT Core:

1. Sends an MQTT DISCONNECT packet to the client.
2. Closes the underlying TCP/TLS socket.
3. Publishes a disconnect lifecycle event with disconnect reason API_INITIATED_DISCONNECT.
4. Optionally clears the persistent session (subscriptions and queued messages).
5. Optionally suppresses the LWT message.

The client must then re-authenticate, re-authorize, and re-establish its session, which is exactly what you want when policies or configurations have changed.

Example

# Basic disconnect (preserves session, allows LWT)
aws iot-data delete-connection --client-id compromised-device-001
 
# Disconnect, clear the session, and suppress LWT (for planned maintenance)
aws iot-data delete-connection \
    --client-id faulty-sensor-042 \
    --clean-session \
    --prevent-will-message

When to use it

The following scenarios show where forcing a client offline can help.

Scenario 1: Disconnecting a malicious or compromised device

When you detect a compromised device (for example, through Device Defender or anomaly detection), the remediation workflow is:

1. Revoke or update the device’s IoT policy to remove unauthorized permissions.
2. Call DeleteConnection to force the device offline.
3. When the device attempts to reconnect, it re-authenticates against the updated policy, so its access reflects the new permissions.

# Step 1: Detach the permissive policy and attach a restricted one
aws iot detach-policy --policy-name "FullAccessPolicy" --target "arn:aws:iot:us-east-1: 111122223333:cert/abc123"
aws iot attach-policy --policy-name "QuarantinePolicy" --target "arn:aws:iot:us-east-1: 111122223333:cert/abc123"
 
# Step 2: Force disconnect. Device will re-auth with the quarantine policy
aws iot-data delete-connection --client-id compromised-device-001 --clean-session

Scenario 2: Forcing a reconnection to fix missing subscriptions

When ListSubscriptions reveals that a device is missing critical subscriptions (perhaps because of a transient error during connection setup), you can force a clean reconnection:

# Verified via ListSubscriptions that the device is missing the "commands" topic
# Force disconnect with clean session to start fresh
aws iot-data delete-connection --client-id myThermostat-001 --clean-session
# Device reconnects, re-subscribes to all required topics

Scenario 3: Client redirection during maintenance or multi-Region failover

When migrating devices to a different endpoint or Region, disconnect them programmatically and let them reconnect to the new endpoint through updated DNS:

# Disconnect all devices in a batch (respecting rate limits)
for client_id in $(cat devices-to-migrate.txt); do
    aws iot-data delete-connection --client-id "$client_id" --prevent-will-message
    sleep 0.1  # Respect rate limits
done

This same pattern is valuable for multi-Region resiliency and disaster recovery (DR). To fail devices over from one AWS Region to another, you can call DeleteConnection to disconnect clients in the primary Region and let them reconnect to the secondary Region through updated DNS or endpoint configuration. Previously, customers achieved this by rotating MQTT client IDs to force disconnects and reconnects, an approach that did not scale well across fleets of millions of devices. DeleteConnection provides a direct, purpose-built mechanism to trigger the disconnect, removing the need for client-ID rotation.

Scenario 4: Resolving stuck connections or session state issues

Persistent sessions that accumulate stale subscriptions or queued messages can cause unexpected behavior. Use DeleteConnection with --clean-session to reset:

aws iot-data delete-connection --client-id stuck-device-007 --clean-session

For full API parameters and behavior details, see the DeleteConnection API reference.

Important: DeleteConnection doesn't prevent reconnection on its own. To block a device, update or revoke its policy/certificate before calling DeleteConnection.

6. Event-driven notifications: Lifecycle connectivity events

For use cases that require reacting to connectivity changes in real time, such as notifying a backend system, triggering a workflow, or updating a customer-facing dashboard, Lifecycle Events are the right tool.

How they work

AWS IoT Core automatically publishes MQTT messages to reserved system topics whenever a client connects or disconnects:

• $aws/events/presence/connected/<clientId>
• $aws/events/presence/disconnected/<clientId>

These lifecycle events are available by default and can't be disabled.

AWS IoT Core also publishes lifecycle events for authorization failures on $aws/events/presence/connect_failed/<clientId> and for subscription changes on $aws/events/subscriptions/subscribed/<clientId> and $aws/events/subscriptions/unsubscribed/<clientId>. These follow the same reserved-topic pattern and you can consume them the same way for auditing failed connect attempts and tracking which topics devices subscribe to.

Event payload (Connect)

{
  "clientId": "myThermostat-001",
  "thingName": "myThermostat",
  "timestamp": 1748450000000,
  "eventType": "connected",
  "sessionIdentifier": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "principalIdentifier": "cert-id-hash",
  "ipAddress": "203.0.113.42",
  "versionNumber": 42
}

Event payload (Disconnect)

{
  "clientId": "myThermostat-001",
  "thingName": "myThermostat",
  "timestamp": 1748453600000,
  "eventType": "disconnected",
  "sessionIdentifier": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "principalIdentifier": "cert-id-hash",
  "clientInitiatedDisconnect": false,
  "disconnectReason": "CONNECTION_LOST",
  "versionNumber": 42
}

Note: The thingName field in lifecycle event payloads is only present when the device connects using the exclusive thing feature. If your devices do not use this feature, this field will be absent from lifecycle events.

Disconnect reasons

The disconnect payload includes a disconnectReason field that explains why the device disconnected, such as MQTT_KEEP_ALIVE_TIMEOUT, CLIENT_INITIATED_DISCONNECT, or DUPLICATE_CLIENTID. See the API reference for the complete enumeration.

When to use them

Consider this capability in the following scenarios:

Best practice

Because lifecycle messages might arrive out of order or be duplicated, implement a wait-state pattern: when a disconnect event arrives, delay (for example, by using Amazon SQS Delay Queues) and re-verify the device’s status using GetThingConnectivityData before taking action.

7. Connectivity history: Amazon CloudWatch Logs with dedicated log groups

For historical audit trails, troubleshooting past incidents, and compliance requirements, AWS IoT Core delivers connectivity events to Amazon CloudWatch Logs.

What’s new: Event-level log routing

With the V2 logging configuration, you can now configure per-event-type log levels and dedicated CloudWatch log groups. This means you can route connectivity events (Connect and Disconnect event types) to their own log group, separate from publish, subscribe, or rule engine events. This separation provides:

• Cost optimization: Set different retention policies per event type.
• Faster queries: Isolate connectivity logs for targeted Amazon CloudWatch Logs Insights queries.
• Compliance isolation: Retain connectivity history independently from message payloads.

Beyond Connect and Disconnect entries, the message broker now also emits Ping log entries (tracking MQTT PINGREQ/PINGRESP, with a successful entry including request timestamp, response timestamp, and measured latency) and Connection.AuthNError entries. Ping logging is opt-in and disabled by default. Failed Ping entries are emitted at the ERROR level, so any log level (ERROR, WARN, INFO, or DEBUG) surfaces them. Successful Ping entries are emitted at DEBUG, so only DEBUG-level logging surfaces them.

The Connection.AuthNError log type adds detail that lifecycle events alone don’t provide. When a device fails to connect because of an authentication or authorization issue (an expired certificate, a revoked policy, a misconfigured custom authorizer), AWS IoT Core already publishes a connect_failed lifecycle event to $aws/events/presence/connect_failed/<clientId>, signaling that the connection attempt was rejected. However, that lifecycle event alone doesn't provide the detailed root cause. The Connection.AuthNError log entry complements it by exposing the exact failure reason (for example, DEVICE_CERTIFICATE_NOT_REGISTERED, CERTIFICATE_REVOKED), the authentication type used (AWS_X509, custom authorizer), and network-level details like source IP and target endpoint. Because these logs are opt-in at the ERROR level and you activate them through resource-specific overrides, you can receive them selectively for specific clients, thing groups, or during targeted troubleshooting sessions. This gives you the diagnostic depth needed to identify and resolve authentication failures without generating noise across your entire fleet.

Configuration example

aws iot set-v2-logging-options \
    --role-arn arn:aws:iam::111122223333:role/IoTLoggingRole \
    --default-log-level WARN \
    --event-configurations '[
        {
            "eventType": "Connect",
            "logLevel": "INFO",
            "logDestination": "iot-connectivity-logs"
        },
        {
            "eventType": "Disconnect",
            "logLevel": "INFO",
            "logDestination": "iot-connectivity-logs"
        }
    ]'

Connect log entry structure

{
  "timestamp": "2026-05-28 15:37:23.476",
  "logLevel": "INFO",
  "traceId": "20b23f3f-d7f1-feae-169f-82263394fbdb",
  "accountId": "111122223333",
  "status": "Success",
  "eventType": "Connect",
  "protocol": "MQTT",
  "clientId": "myThermostat-001",
  "principalId": "certificate-or-principal-id",
  "sourceIp": "203.0.113.42",
  "sourcePort": 54321
}

When to use it

Consider this capability in the following scenarios:

Example CloudWatch Logs Insights query

fields @timestamp, clientId, status, eventType, sourceIp, disconnectReason
| filter eventType = "Connect" or eventType = "Disconnect"
| sort @timestamp desc
| limit 100

Putting it all together: Choosing the right tool

The connectivity management suite is designed so that each capability serves a specific tier of the observability and control stack:

Getting started

This section brings the individual capabilities together into a setup you can run end to end. It covers what you need before you start, then the commands to enable connectivity indexing, logging, metrics, and the APIs used throughout this post.

Prerequisites

Before you begin, make sure you have:

The Quick setup below then enables the two capabilities the rest depends on: Fleet Indexing with the connectivity data source, and V2 logging with event-level configuration for connectivity events.

Quick setup

The following commands enable the capabilities covered in this post. Step 2 assumes you have already created a CloudWatch Logs log group (iot-connectivity-logs in this example) and an IAM role (IoTLoggingRole) that grants AWS IoT Core permission to write to it. See Configure AWS IoT logging for those steps. The commands also assume your devices have a registered certificate and attached policy.

# 1. Enable fleet indexing with connectivity
# Note: update-indexing-configuration is account-level; omitted fields can revert to
# defaults. Merge with your existing configuration instead of replacing it. The
# connectivity filter below is required for GetThingConnectivityData to return socket info.
aws iot update-indexing-configuration \
    --thing-indexing-configuration '{
        "thingIndexingMode": "REGISTRY_AND_SHADOW",
        "thingConnectivityIndexingMode": "STATUS",
        "filter":{"connectivity":{"includeSocketInformation": ["GET_THING_CONNECTIVITY_DATA"]}}
    }'

# 2. Configure dedicated logging for connectivity events
aws iot set-v2-logging-options \
    --role-arn arn:aws:iam::123456789012:role/IoTLoggingRole \
    --default-log-level WARN \
    --event-configurations '[{"eventType":"Connect","logLevel":"INFO","logDestination":"iot-connectivity-logs"}]'

# 3. Create a fleet metric for disconnected device count
aws iot create-fleet-metric \
    --metric-name "DisconnectedDevices" \
    --query-string "connectivity.connected:false" \
    --aggregation-type name=Statistics,values=count \
    --period 300 \
    --index-name "AWS_Things"

# 4. Create a dynamic thing group for offline devices (job target)
aws iot create-dynamic-thing-group \
    --thing-group-name "OfflineDevices" \
    --query-string "connectivity.connected:false"

# 5. Query a specific device's connectivity status
aws iot get-thing-connectivity-data --thing-name myDevice

# 6. Get detailed connection information
aws iot-data get-connection --client-id myDevice

# 7. List device subscriptions
aws iot-data list-subscriptions --client-id myDevice

# 8. Force disconnect a misbehaving device (after policy update)
aws iot-data delete-connection --client-id myDevice --clean-session

Cleanup

If you created these resources only to follow along, remove them so they don’t continue to incur cost or clutter your account. Delete only the resources you created for this walkthrough. If Fleet Indexing or logging was already in use in your account, adjust the following commands to preserve your existing configuration.

# 1. Delete the fleet metric
aws iot delete-fleet-metric --metric-name "DisconnectedDevices"

# 2. Delete the dynamic thing group
aws iot delete-dynamic-thing-group --thing-group-name "OfflineDevices"

# 3. Disable connectivity indexing
# Reminder: update-indexing-configuration is account-level, and omitted fields can revert
# to defaults. Retrieve your current configuration first, then set
# thingConnectivityIndexingMode back to OFF while preserving every other setting you use.
aws iot update-indexing-configuration \
    --thing-indexing-configuration '{
        "thingIndexingMode": "REGISTRY_AND_SHADOW",
        "thingConnectivityIndexingMode": "OFF"
    }'

# 4. Disable connectivity event logging
# Set the default log level to DISABLED, or reapply your previous logging configuration.
aws iot set-v2-logging-options --default-log-level DISABLED

Conclusion

AWS IoT Core provides connectivity management capabilities that span fleet-wide orchestration and dynamic targeting, real-time status and connection introspection, active remediation, and historical analysis.

The suite is designed to be composable. Fleet Indexing acts as the foundation, enabling queries, aggregations, dynamic groups, and fleet metrics. The real-time APIs (GetThingConnectivityData, GetConnection, ListSubscriptions) give you per-device visibility. With the DeleteConnection API, you can act when you identify an issue. Lifecycle Events drive automated reactions. And CloudWatch Logs with dedicated log groups provide the historical record you need for compliance and post-mortem analysis.

Whether your challenge is real-time status visibility, connection diagnostics, subscription auditing, event-driven automation, fleet-wide orchestration, or active device remediation, the tools are available today to address it without building and maintaining custom connectivity tracking infrastructure.

To learn more

Use these resources to go deeper on the capabilities covered in this post and to start building.

Get hands-on

• AWS IoT Device Management learning path (basics): interactive Python scripts for device provisioning, dynamic thing groups, OTA jobs, IoT Commands, and bulk registration.
• AWS IoT Core learning path (basics): interactive scripts covering the registry, certificates and policies, MQTT, device shadows, and the Rules Engine.

Related posts

• Building Physical AI agents with MCP and MQTT on AWS IoT Core.
• Preventing machine breakdowns: how Physical AI predicts equipment problems.
• Seamless migration: Securely transitioning large IoT fleets to AWS.

Get started

Try these capabilities in the AWS IoT Core console, or learn more on the AWS IoT Core service page.

About the author