AWS Blog

AWS IoT – Cloud Services for Connected Devices

by Jeff Barr | on | in Amazon Internet of Things, AWS re:Invent | | Comments

Have you heard about the Internet of Things (IoT)? Although critics sometimes dismiss it as nothing more than “put a chip in it,” I believe that the concept builds upon some long-term technology trends and that there’s something really interesting and valuable going on.

To me, the most relevant trends are the decreasing cost of mass-produced compute power, the widespread availability of IP connectivity, and the ease with which large amounts of information can be distilled into intelligence using any number of big data tools and techniques:

  • Mass-produced compute power means that it is possible to crank out powerful processors that consume modest amounts of power, occupy very little space, and cost very little. These attributes allow the processors to be unobtrusively embedded in devices of all shapes and sizes.
  • Widespread IP connectivity (wired or wireless) lets these processors talk to each other and  to the cloud. While this connectivity is fairly widespread, it is definitely not ubiquitous.
  • Big data allows us to make sense of the information measured, observed, or collected, by the processors running in these devices.

We could also add advances in battery & sensor technology to the list of enabling technologies for the Internet of Things. Before too long, factory floors, vehicles, health care systems, household appliances, and much more will become connected “things.” Two good introductory posts on the topic are 20 Real World Problems Solved by IoT and Smart IoT: IoT as a Human Agent, Human Extension, and Human Complement. My friend Sudha Jamthe has also written on the topic; her book IoT Disruptions focuses on new jobs and careers that will come about as IoT becomes more common.

Taking all of these trends as givens, it should not come as a surprise that we are working to make sure that AWS is well-equipped to support many different types of IoT devices and applications. Although I have described things as connected devices, they can also take the form of apps running on mobile devices.

Today we are launching AWS IoT (Beta).

This new managed cloud service provides the infrastructure that allows connected cars, factory floors, aircraft engines, sensor grids, and the like (AWS IoT refers to them as “things”) to easily and securely interact with cloud services and with other devices, all at world-scale. The connection to the cloud is fast and lightweight (MQTT or REST), making it a great fit for devices that have limited memory, processing power, or battery life.

Let’s take a look at the components that make up AWS IoT:

  • Things are devices of all types, shapes, and sizes including applications, connected devices, and physical objects. Things measure and/or control something of interest in their local environment. The AWS IoT model is driven by state and state changes. This allows things to work properly even when connectivity is intermittent; applications interact with things by way of cloud-based Thing Shadows. Things have names, attributes, and shadows.
  • Thing Shadows are virtual, cloud-based representations of things. They track the state of each connected device, and allow that state to be tracked even if the thing loses connectivity for an extended period of time.
  • The real-time Rules Engine transforms messages based on expressions that you define, and routes them to AWS endpoints (Amazon DynamoDB, Amazon Simple Storage Service (S3)AWS Lambda, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), Amazon Kinesis, and Amazon Kinesis Firehose) all expressed using a SQL-like syntax. Routing is driven by the contents of individual messages and by context. For example, routine readings from a temperature sensor could be tracked in a DynamoDB table; an aberrant reading that exceeds a value stored in the thing shadow can trigger a Lambda function .
  • The Message Broker speaks MQTT (and also HTTP 1.1) so your devices can take advantage of alternative protocols even if your cloud backend does not speak them. The Message Broker can scale to accommodate billions of responsive long-lived connections between things and your cloud applications. Things use a topic-based pub/sub model to communicate with the broker, and can also publish via HTTP request/response. They can publish their state and can also subscribe to incoming messages. The pub/sub model allows a single device to easily and efficiently share its status with any number of other devices (thousands or even millions).
  • Device SDKs are client libraries that are specific to individual types of devices. The functions in the SDK allow code running on the device to communicate with the AWS IoT Message Broker over encrypted connections. The devices identify themselves using X.509 certificates or Amazon Cognito identities. The SDK also supports direct interaction with Thing Shadows.
  • The Thing Registry assigns a unique identity to each thing. It also tracks descriptive metadata such as the attributes and capabilities for each thing.

All of these components can be created, configured, and inspected using the AWS Management Console, the AWS Command Line Interface (CLI), or through the IoT API.

AWS IoT lets billions of things keep responsive connections to the cloud, and lets cloud applications interact with things (works in device shadows, rules engine, and the real-time functionality). It receives messages from  things and filters, records, transforms, augments, or routes them to other parts of AWS or to your own code.

Getting Started with AWS IoT
We have been working with a large group of IoT Partners to create AWS-powered starter kits:

Once you have obtained a kit and connected it to something interesting, you are ready to start building your first IoT application using AWS IoT. You will make use of several different SDKs during this process:

The AWS IoT Console will help you get started. With a few clicks you can create your first thing, and then download the SDK, security credentials, and sample code you will need to connect a device to AWS IoT.

You can also build AWS IoT applications that communicate with an Amazon Echo via the Alexa Skills Kit. AWS IoT can trigger an Alexa Skill via a Lambda function and Alexa Skills can interact with thing shadows. Alexa Skills can also take advantage of AWS IoT’s bidirectional messaging capability (which traverses NAT and firewalls found in home networks) to wake devices with commands from the cloud. Manufacturers can use thing shadows to store responses to application-specific messages.

AWS IoT in the Console
The Console includes an AWS IoT tutorial to get you started:

It also provides complete details on each thing, including the thing’s API endpoint, MQTT topic, and the contents of its shadow:

AWS IoT Topics, Messages, and Rules
All of the infrasructure that I described can be seen as a support system for the message and rule system that forms the heart of AWS IoT. Things disclose their state by publishing messages to named topics.  Publishing a message to a topic will create the topic if necessary; you don’t have to create it in advance. The topic namespace is hierarchical (“myfactories/seattle/sensors/door”)

Rules use a SQL-like SELECT statement to filter messages. In the IoT Rules Engine, the FROM clause references an MQTT topic and the WHERE clause references JSON properties in the message. When a rule matches a message, it can invoke one or more of the following actions:

The SELECT statement can use all (*) or specifically chosen fields of the message in the invocation.

The endpoints above can be used to reach the rest of AWS. For example, you can reach Amazon Redshift via Kinesis, and external endpoints via Lambda, SNS, or Kinesis.

Thing Shadows also participate in the message system. Shadows respond to HTTP GET requests with JSON documents (the documents are also accessible via MQTT for environments that don’t support HTTP). Each document contains the thing state, its metadata,  and a version number for the state.  Each piece of state information is stored in both “reported” (what the device last said), and “desired” (what the application wants it to be). Each shadow accepts changes to the desired state (HTTP) post, and publishes “delta” and “accepted” messages to topics associated with the thing shadow. The device listens on these topics and changes its state accordingly.

IoT at re:Invent
If you are at re:Invent, be sure to check out our Mobile Developer & IoT track. Here are some of the sessions we have in store:

  • MBL203 – From Drones to Cars: Connecting the Devices in Motion to the Cloud.
  • MBL204 -Connecting the Unconnected – State of the Union – Internet of Things Powered by AWS.
  • MBL303 -Build Mobile Apps for IoT Devices and IoT Apps for Mobile Devices.
  • MBL305 – You Have Date from the Devices, Now What? Getting Value of the IoT.
  • WRK202 – Build a Scalable Mobile App on Serverless, Event-Triggered, Back-End Logic.

More to Come
There’s a lot more to talk about and I have barely scratched the surface with this introductory blog post. Once I recover from AWS re:Invent, I will retire to my home lab and cook up a thing or two of my own and share the project with you. Stay tuned!


PS – Check out the AWS IoT Mega Contest!