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 protocol versions

AWS IoT Core uses TLS version 1.2 and TLS version 1.3 to encrypt all communication. You can configure additional TLS policy versions for your endpoint by configuring TLS settings in domain configurations. When connecting devices to AWS IoT Core, clients can send the Server Name Indication (SNI) extension, which is required for features such as multi-account registration, configurable endpoints, custom domains, and VPC endpoints. 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 is configurable using an authentication type. By default or when no SNI extension is sent, authentication method is based on application protocol, port, and Application Layer Protocol Negotiation (ALPN) TLS extension that devices use. The following table lists the authentication expected based on port, port, and ALPN.

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.

Choosing an application protocol for your device communication

For most IoT device communication through the device endpoints, you'll want to use the Secure MQTT or MQTT over WebSocket Secure (WSS) protocols; however, the device endpoints also support HTTPS.

The following table compares how AWS IoT Core uses the two high-level protocols (MQTT and HTTPS) for device communication.

Choosing an authentication type for your device communication

You can configure authentication type for your IoT endpoint using configurable endpoints. Alternatively, use default configuration and determine how your devices authenticate with application protocol, port, and ALPN TLS extension combination. The authentication type you choose determines how your devices will authenticate when connecting when connecting to AWS IoT Core. There are five authentication types:

X.509 certificate

Authenticate devices using X.509 client certificates, which AWS IoT Core validates to authenticate the device. This authentication type works with Secure MQTT (MQTT over TLS) and HTTPS protocols.

X.509 certificate with custom authorizer

Authenticate devices using X.509 client certificates and perform additional authentication actions using a custom authorizer, which will receive X.509 client certificate information. This authentication type works with Secure MQTT (MQTT over TLS) and HTTPS protocols. This authentication type is only possible using configurable endpoints with X.509 custom authentication. There is no ALPN option.

AWS Signature Version 4 (SigV4)

Authenticate devices using Cognito or your backend service, supporting social and enterprise federation. This authentication type works with MQTT over WebSocket Secure (WSS) and HTTPS protocols.

Custom authorizer

Authenticate devices by configuring a Lambda function to process custom authentication information sent to AWS IoT Core. This authentication type works with Secure MQTT (MQTT over TLS) , HTTPS, and MQTT over WebSocket Secure (WSS) protocols.

Default

Authenticate devices based on the port and/or application layer protocol negotiation (ALPN) extension that devices use. Some additional authentication options are not supported. For more information, see Protocols, port mappings, and authentication.

The table below shows all the supported combinations of authentication types and application protocols.

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.

^* 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.

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.