Industrial IoT (IIoT) with Amazon Web Services

The last two years have been an exciting time in the IoT market, with tech giants such as Intel, IBM, Google, Amazon, and Microsoft looking to expand their large, cloud-based services platforms to appeal to a wide range of customers. The recurring nature of annual service revenues is attractive for large organizations that face shrinking margins on traditional “sell-once” products. While the market for IT/enterprise services has seen tremendous growth over the past decade, it is still early days for IoT-specific products. Two of the largest IoT competitors, Amazon and Microsoft, have recently added IoT-specific services to their overarching cloud services portfolios. Amazon launched AWS IoT in October 2015, and Microsoft followed suit with the Azure IoT Hub the following month. In this view, we will explore both in detail, outlining the key differences in protocol selection, security, marketing, and pricing.

Amazon Web Services

In October 2015, Amazon announced the launch of its AWS IoT platform at its re:invent developer conference. Prior to this announcement, AWS did not have a specific service aimed at addressing the needs of IoT-focused organizations with large networks of deployed, low-power nodes. Amazon’s acquisition of IoT cloud platform startup 2lemetry in early 2015 foreshadowed its launch of AWS IoT six months later.

AWS IoT Architecture

The AWS IoT architecture is best described as a pub/sub (publication/subscription) service that allows customers to selectively send and receive messages from disparate devices. To this end, Amazon IoT supports the legacy MQTT (MQ telemetry transport) protocol for both publishing and subscribing, and the HTTP REST interface for publishing messages. It also supports MQTT over Websocket in order to enable browser-based and remote application communication. AWS IoT’s close tie to the lightweight MQTT protocol for resource/battery/bandwidth-constrained devices and networks will benefit large industrial automation customers.


Exhibit 2 outlines the AWS IoT security architecture. Users must assign a unique identity to each device and manage permissions for different groups of users and devices. AWS IoT supports three types of identity principle architectures that match up to their respective messaging protocols:

  • X.509 certificates: MQTT
  • IAM 2 users, groups, and roles: HTTP
  • Amazon Cognito identities: HTTP

The benefit of using X.509 certificates is the amount of control it gives the client over the private keys used to authenticate new things. Rather than relying on AWS to both issue and authenticate keys, a client can embed the device’s private key directly into secure storage on the device for unique and permanent identification. All traffic to and from AWS IoT is encrypted using Transportation Layer Security (TLS). The service uses the TLS protocol’s client authentication mode to check the device’s certificate against a registry of known certificates, then it challenges the device for proof of the private key that matches up to the public key that is contained in the certificate.

Pricing: AWS IoT is free for the first twelve months for accounts that use under 250,000 messages per month. Additionally, there is no charge for message delivery to AWS’s Lambda, DynamoDB, S3, Kinesis, SNS, and SQS. Users will still incur regular costs for processing on these “free-to-push” AWS services.

AWS IoT displays its pricing per million messages, with a message defined as each 512-byte block of data that AWS IoT processes when (1) a device publishes a message to AWS IoT, (2) AWS IoT publishes a message to a device, or (3) AWS IoT delivers a message to an external database. While Amazon displays price per million messages, it actually charges by the individual message – if a US East customer consumes 1.5M messages, Amazon will charge $7.50 rather than $10.

Throttling: AWS IoT API throttle limits for actions (such as certificate/thing create, list, get, and delete) vary from 10-15 transactions per second. Ingress and egress throughput to the AWS message broker is limited to 512 KB/s per connection. The message broker also limits each client session to up to 50 subscriptions at a time, which can be kept alive for anywhere from 5 seconds to 30 minutes of inactivity. The broker allows up to 100 in-flight inbound unacknowledged messages at which point it will stop accepting new messages, as well as 100 in-flight outbound messages at which point no new messages will be sent to the client until the client acknowledges the previous batch.

Leave a Reply