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 versionsAWS 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 authenticationHow 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.
Protocols, authentication, and port mappings Protocol Operations supported Authentication Port ALPN protocol nameMQTT over WebSocket
Publish, Subscribe Signature Version 4 443N/A
MQTT over WebSocket
Publish, Subscribe Custom authentication 443N/A
MQTT
Publish, SubscribeX.509 client certificate
443â
x-amzn-mqtt-ca
MQTT
Publish, SubscribeCustom authentication
443â
mqtt
HTTPS
Publish onlySignature Version 4
443
N/A
HTTPS
Publish onlyX.509 client certificate
443â
x-amzn-http-ca
â When using default endpoint configurations, 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.
Connecting to AWS IoT CoreProtocol
Endpoint or URL
MQTT
iot-endpoint
MQTT over WSS
wss://iot-endpoint/mqtt
HTTPS
https://iot-endpoint/topics
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.
AWS IoT device protocols (MQTT and HTTPS) side-by-sideFeature
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
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 Choosing an authentication type for your device communicationYou 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 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.
Supported combinations of authentication types and application protocols Authentication type Secure MQTT (MQTT over TLS) MQTT over WebSocket Secure (WSS) HTTPS Default X.509 certificate â â X.509 certificate with custom authorizer â â AWS Signature Version 4 (SigV4) â â Custom authorizer â â â Default â Connection duration limitsHTTPS 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 featureFeature
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4