Device communication protocols - AWS IoT Core

Device communication protocols

AWS IoT Core supports devices and clients that use the MQTT and the MQTT over WebSocket Secure (WSS) protocols to publish and subscribe to messages, and devices and clients that use the HTTPS protocol to publish messages. All protocols support IPv4 and IPv6. This section describes the different connection options for devices and clients.

TLS 1.2 and TLS 1.3

AWS IoT Core uses TLS version 1.2 and TLS version 1.3 to encrypt all communication. When connecting devices to AWS IoT Core, clients can send the Server Name Indication (SNI) extension, which is not required but highly recommended. To use features such as multi-account registration, custom domains, and VPC endpoints, you must use the SNI extension. For more information, see Transport Security in AWS IoT.

The AWS IoT Device SDKs support MQTT and MQTT over WSS and support the security requirements of client connections. We recommend using the AWS IoT Device SDKs to connect clients to AWS IoT.

Protocols, port mappings, and authentication

How a device or client connects to the message broker by using a device endpoint depends on the protocol it uses. The following table lists the protocols that the AWS IoT device endpoints support and the authentication methods and ports they use.

Protocols, authentication, and port mappings
Protocol Operations supported Authentication Port ALPN protocol name

MQTT over WebSocket

Publish, Subscribe Signature Version 4 443

N/A

MQTT over WebSocket

Publish, Subscribe Custom authentication 443

N/A

MQTT

Publish, Subscribe

X.509 client certificate

443

x-amzn-mqtt-ca

MQTT Publish, Subscribe X.509 client certificate 8883 N/A

MQTT

Publish, Subscribe

Custom authentication

443

mqtt

HTTPS

Publish only

Signature Version 4

443

N/A

HTTPS

Publish only

X.509 client certificate

443

x-amzn-http-ca

HTTPS Publish only X.509 client certificate 8443 N/A
HTTPS Publish only Custom authentication 443 N/A
Application Layer Protocol Negotiation (ALPN)

Clients that connect on port 443 with X.509 client certificate authentication must implement the Application Layer Protocol Negotiation (ALPN) TLS extension and use the ALPN protocol name listed in the ALPN ProtocolNameList sent by the client as part of the ClientHello message.

On port 443, the IoT:Data-ATS endpoint supports ALPN x-amzn-http-ca HTTP, but the IoT:Jobs endpoint does not.

On port 8443 HTTPS and port 443 MQTT with ALPN x-amzn-mqtt-ca, custom authentication can't be used.

Clients connect to their AWS account's device endpoints. See AWS IoT device data and service endpoints for information about how to find your account's device endpoints.

Note

AWS SDKs don't require the entire URL. They only require the endpoint hostname such as the pubsub.py sample for AWS IoT Device SDK for Python on GitHub. Passing the entire URL as provided in the following table can generate an error such as invalid hostname.

Connecting to AWS IoT Core

Protocol

Endpoint or URL

MQTT

iot-endpoint

MQTT over WSS

wss://iot-endpoint/mqtt

HTTPS

https://iot-endpoint/topics

Choosing a protocol for your device communication

For most IoT device communication through the device endpoints, you'll want to use the MQTT or MQTT over WSS protocols; however, the device endpoints also support HTTPS. The following table compares how AWS IoT Core uses the two protocols for device communication.

AWS IoT device protocols side-by-side

Feature

MQTT

HTTPS

Publish/Subscribe support

Publish and subscribe

Publish only

SDK support

AWS Device SDKs support MQTT and WSS protocols

No SDK support, but you can use language-specific methods to make HTTPS requests

Quality of Service support

MQTT QoS levels 0 and 1

QoS is supported by passing a query string parameter ?qos=qos where the value can be 0 or 1. You can add this query string to publish a message with the QoS value you want.
Can receive messages be missed while device was offline Yes No

clientId field support

Yes

No

Device disconnection detection

Yes

No

Secure communications

Yes. See Protocols, port mappings, and authentication

Yes. See Protocols, port mappings, and authentication

Topic definitions

Application defined

Application defined

Message data format

Application defined

Application defined

Protocol overhead Lower Higher
Power consumption Lower Higher

Connection duration limits

HTTPS connections aren't guaranteed to last any longer than the time it takes to receive and respond to requests.

MQTT connection duration depends on the authentication feature that you use. The following table lists the maximum connection duration under ideal conditions for each feature.

MQTT connection duration by authentication feature

Feature

Maximum duration *

X.509 client certificate

1–2 weeks

Custom authentication

1–2 weeks

Signature Version 4

Up to 24 hours

* Not guaranteed

With X.509 certificates and custom authentication, connection duration has no hard limit, but it can be as short as a few minutes. Connection interruptions can occur for various reasons. The following list contains some of the most common reasons.

  • Wi-Fi availability interruptions

  • Internet service provider (ISP) connection interruptions

  • Service patches

  • Service deployments

  • Service auto scaling

  • Unavailable service host

  • Load balancer issues and updates

  • Client-side errors

Your devices must implement strategies for detecting disconnections and reconnecting. For information about disconnect events and guidance on how to handle them, see Connect/Disconnect events in Lifecycle events.