An Introduction to AWS IoT Core

Guest post by Christine Samson, Startup Solutions Architect, and Zoran Nakev, Senior Startup Solutions Architect, AWS 

Internet of Things (IoT) refers to any device or physical object that connects and exchanges data with other devices and systems over the internet. These devices or objects are embedded with sensors, software, and other technologies. As you control different appliances in your homes (i.e. fans, thermostats, and refrigerators), or go on a jog and track your exercise activity using a smart watch, then you know that IoT touches our daily lives. Other day-to-day use cases for IoT include using vacuuming robots to help with cleaning houses, or using devices to monitor and secure homes, businesses, or packages.

When building an IoT architecture, businesses, such as startups, often encounter roadblocks or challenges. They ask questions similar to the following:

1. How does IoT even work?
2. How do you keep track of different IoT devices?
3. How do you stream data into the cloud from IoT devices?
4. What are ways to analyze and organize this data?
5. How do you scale IoT devices?
6. How do we keep IoT devices secure?
7. How is IoT different in the cloud and do I build all of it myself?

Startups are often bootstrapped and many concerns we hear as Solutions Architects stem from not having enough developers or cash to build out an IoT architecture that is well-architected and follows best practices on AWS. Startups are often busy and on a fast timeline, which doesn’t enable them to explore architectural and platform options as freely as they would like to. Often, bootstrapping a solution that works for them regardless of where it is hosted is the path they usually take. However, there is an AWS service that will help solve those questions. AWS IoT Core will help with the undifferentiated heavy lifting of provisioning or managing servers while allowing businesses to connect IoT devices to the AWS Cloud.

AWS IoT Core has many features that tackle different challenges IoT customers often have. It can be overwhelming at times to read about them in different places and figure out what exactly to use them for. In this blog post, we go into the different components of AWS IoT Core and walk you through an example of how a fictional startup will use the different components of AWS IoT Core to their benefit.

Example Scenario

You are the CTO for a fictional startup. This startup wants to create products that will help people live healthier lifestyles. Their flagship product is a bracelet that tracks user activity (steps, heart rate, blood pressure), which will connect with an application on their mobile phones.

You lead a team of five engineers. You and the team have no experience in the realm of IoT and are starting from scratch. In time, you’d like to expand your startup to sell other products like bikes and weights to your customer base. In the sections below, we will walk you through how you can take advantage of AWS IoT Core to build and scale your business and show you the value proposition of buying AWS IoT Core vs. building one on your own.

While we take a fictional startup in the industry vertical of fitness as an example, this information can be applied to any company that is new to IoT on AWS. A number of customers in different industry verticals—smart devices, technology, industrial, automotive, oil and gas, security, etc.– use AWS IoT Core in a number of ways. See our IoT use cases page for more information about how customers have achieved success with IoT on AWS. AWS has a number of IoT-related offerings beyond just AWS IoT Core, but we will only cover the basics in this post.

Architecture Overview

Understanding the concepts outlined in this post requires no previous AWS IoT Core experience. The architecture diagram below depicts the example of the different components of AWS that we will go through. In the following sections, we will highlight the knowledge one needs to get started with AWS IoT Core and discuss how this fictional startup will use it effectively.

                                                      Figure 1 – Architecture diagram of AWS IoT Core components

In our example, since the startup is interested in building a smart exercise bracelet, that is the device we will be highlighting throughout this post. We will discuss how the smart exercise bracelet connects to the cloud and then collects and sends data to AWS. This smart exercise bracelet will collect data such as heart rate, blood pressure, and steps walked and send that data to AWS. Below is an example of the data this startup is sending to the cloud.

{
"heart_rate": "95",
"blood_pressure": "120/80",
"steps_walked": "1000"
}

Throughout this post, we’ll refer to this use case and the data shown above to paint a picture of how this fictional startup will use AWS IoT Core.

FreeRTOS

IoT devices are usually limited in many ways. They need to be small and power efficient but still capable enough to perform the functions that you need (i.e. stream data to the cloud, collect data, etc.). Building these hardware devices is no easy task, but what is equally important is the software that runs on an IoT device as well. AWS helps you develop your IoT solution from the ground up. FreeRTOS, a real-time operating system for micro-controllers supported by AWS, makes the task of programing, deploying, securing, connecting, and managing small, low-powered edge devices very easy. By providing the kernel, the operating system (OS), and the necessary libraries, FreeRTOS can securely connect your edge device to the cloud in no time. For this startup, you can use FreeRTOS to make the process of developing on the smart bracelet easier.

Device Registry

One of the auxiliary parts of AWS IoT Core is the Device Registry. You can think of the Device Registry like a database that keeps track of all of your devices. In AWS IoT Core, devices are known as “Things.” Things can be thought of as the blanket term used to describe a single device. The Registry stores data about the Things like its serial number, version type, location, owner, and contact information. This part of AWS IoT Core is helpful if one or more devices need maintenance. You can quickly find where these devices are or filter by a common feature (i.e. if all ModelZ exercise bracelets have an issue). While this is an optional part of AWS IoT Core, we recommend customers with a large number of devices to utilize it in order to take the heavy lifting of managing devices off their shoulders.

Device SDK

The AWS IoT Device SDK and the AWS IoT API provide you the tools you need to connect your device to the cloud. The IoT Device SDK includes open-source libraries, developer guides with samples, and porting guides so you can build innovative IoT products or solutions on your choice of hardware platforms. This SDK is for use on your IoT device, and supports different languages such as C++, Java, JavaScript, and Python as well as support for Android and iOS. AWS IoT provides secure, bi-directional communication between your device and the AWS Cloud. You can use your custom IoT data endpoint to communicate with the AWS Cloud, configure rules for data processing and integration with other services, organize resources associated with each device, configure logging, and create and manage policies and credentials to authenticate devices. The Device SDK can be installed onto the smart bracelet directly, or it is included in FreeRTOS as one of the libraries that you will utilize as the CTO so you can connect to the AWS Cloud easily.

Authentication and Authorization

Authentication asks the question, “Who are you? And is this person who they say they are?” With regard to IoT, authentication verifies the identity of a device. There are two different types of authentication we’ll talk about in this context. Server authentication is the process where devices or other clients ensure they are communicating with an actual AWS IoT endpoint. Client authentication is the process where devices or other clients authenticate themselves with AWS IoT. There are a number of ways to achieve both server and client authentication.

A common way for server/client authentication is to use X.509 certificates, which is a standard of defining the format of public key certificates. X.509 certificates are used in many internet protocols, including Transport Layer Security (TLS)/Secure Sockets Layer (SSL), which is the basis for HTTPS, the secure protocol for browsing the web. While there are simpler use cases where you have access to the device and the ability to configure it with the necessary certificate, you might also need to support the scenario of doing the configuration using alternative authentication methods (such as temporary credentials through Amazon Cognito).

With authentication done, the next important concept is Authorization, or the answer to the question, “What will the device be allowed to do or access on the cloud?” Control of the access to the AWS IoT Core data plane is managed by AWS IoT Core policies. These policies are JSON documents that follow the same conventions as policies in Identity and Access Management (IAM). IAM is also your solution for bridging permissions between AWS IoT Core messaging and the rest of the AWS services.

You are intrigued by the idea of using Cognito for signing your users in into a mobile application, so you use IAM policies to authenticate them into viewing different dashboards or viewing the data that pertains to them specifically. You can use a unique X.509 certificate per device to adhere to security best practices on AWS. This way, if one device gets hacked, the entire fleet of devices is not affected by one certificate being compromised.

Collecting Data and Streaming it to AWS

Next, we will talk about collecting data and streaming it to AWS. The device gateway is where a majority of the IoT “work” is being done.

Before we get into what the device gateway does, let’s talk about topics. Topics are the mechanism of organizing data within AWS IoT Core, and it’s really how we make sense of the data coming in from devices and going to a) other devices and/or b) the AWS Cloud. Devices can publish to a topic (meaning they send data to that topic) and devices or administrators can also subscribe to a topic (meaning they receive the data being published to that topic).

You can see an example of a topic here:

StartupX/smart-bracelets/ModelX/bracelet7

So, if we name a specific smart bracelet bracelet7, this is the topic that the specific smart bracelet, bracelet7, would publish to. The owner of bracelet7 may subscribe to this topic using their phone to receive the data coming in from bracelet7.

The way topics are designed is very important. The following description will break down this example even further and show other important aspects of topics. There’s a topic design whitepaper that details more information about how to design topics. However, we’ll highlight what one should know about them in this post. Typically, topics follow a general-to-specific hierarchy format, and each topic is named and created based on the purpose of the data that the device is collecting and sending to the cloud.

You can start with StartupX, which is the name of the fictional startup that wants to connect their devices to the cloud, then segment it by smart-bracelets i.e. StartupX/smart-bracelets, which is the specific type of device they are collecting data from. Instead of smart bracelets, you can have bikes or weights, etc. so the topic can be transformed and look like one of the following:

StartupX/bikes
StartupX/weights

You can also have different models of smart bracelets, such as the ModelX that you see in this example. When you have multiple devices, like ModelX smart bracelets, you can label and number them so that you can track a specific device. In this specific example, that would be bracelet7. One thing to note about this hierarchy format within a topic is it allows us to collect data on different levels within the hierarchy. You can collect data at the StartupX/smart-bracelets level to get data about all the smart bracelets, and you can also collect data at the bracelet7 specific level to get data about bracelet7 only.

Device Gateway

The Device Gateway is where all of the connections and communication are handled. It provides bi-directional communication, so not only receiving data from devices but also sending it back out to devices. More specifically, this happens in the message broker, which is housed by the device gateway and operates on a publish/subscribe model.

You can have a number of messaging patterns like one publisher that publishes to a number of subscribers, one publisher that publishers to one subscriber. You can even have multiple publishers publishing to the same topic. The publish/subscribe model here is important because it enables decoupling of the devices and their respective communication. If the publisher goes down for any reason, subscribers can still be up and running and vice versa. The Device Gateway is fully managed, and can scale to billions of devices. It supports different protocols like MQTT, a lightweight protocol that is good for sporadic packets, HTTP 1.1, and WebSockets.

After we have the topic set, we can use it as the mechanism of streaming data to the cloud. The data that the bracelet sends will go to the message broker, and then it can be directed to a rule in AWS IoT Core that tells where the data goes and signals what to do with it.

Rules Engine

The Rules Engine feature of AWS IoT Core gives devices the ability to interact with AWS services. Rules are analyzed and actions are performed based on the MQTT topic stream.

Not only does the Rules Engine allow you to interact with other AWS services, but you can interact with third party services as well like Apache Kafka, Salesforce, or Snowflake. You can use rules to support tasks like streaming the data into an Amazon Kinesis Data Firehose, putting it in an Amazon SQS queue, triggering a script that processes the data with AWS Lambda, storing the metadata into Amazon DynamoDB, or storing the raw data for historical or backup purposes in Amazon S3. Before AWS IoT can perform these actions with the Rules Engine, you must authorize it and grant it permission to access your AWS resources on your behalf.

You can set a rule based on the topic above that can stream into Amazon DynamoDB to store data, or AWS Lambda can capture the data from the stream to process it for any calculations you would like to do with the data.

Device Shadow

Up next, we have the Device Shadow feature of AWS IoT Core. You can think of the Device Shadow as a virtual representation of your device in the cloud – it keeps track of the state changes to your device. This is very helpful when your device has intermittent internet connection. The Shadow is also the location where you send changes to when you want the state of your device to be updated. If you send these state changes directly to your device, they may get lost if your device is offline. While your device isn’t connected to the internet, it collects state changes and when your device comes back online, it will help it catch up to whatever state it’s supposed to be in.

Let’s see how the Device Gateway, Rules Engine, and Device Shadow all look like in action. Taking our topic example from before, we have a topic specific to bracelet7 where it will publish information like steps walked, heart rate, and blood pressure. This is being handled by the message broker in the Device Gateway. The data collected from the devices would go to the Rules Engine, where it would then be matched to a database or a persistence layer that is most appropriate. We can also have another topic specific to bracelet7 but this time use it to send and receive messages from its shadow. This topic can have messages that when processed would put the device in a power saving mode for example. This is sent first to the Shadow and then to the device, all through the Shadow topic. Using the same topic, bracelet7 would then send a confirmation back to the shadow when it’s able make that state change and go into power saving mode because we always want our shadow to have the current state information of our device. See the diagram below for a visual on how this process with Device Shadow works.

                                                                      Figure 2 – Device Shadow process

While Device Shadow solves a significant problem when it comes to managing IoT devices, AWS IoT has a plethora of other mechanisms that are helpful in context of managing devices.

AWS IoT Greengrass

AWS IoT Greengrass is an open-source runtime that extends the cloud to the edge and helps you build, deploy, and manage device software. It allows you to run compute tasks like AWS Lambda functions locally, perform data aggregation and analytics and machine learning (ML) inference even at remote sites with intermittent internet connectivity. IoT devices, including Greengrass devices, can be easily operated and maintained without having consistent internet connection.

Implementing AWS IoT Greengrass can be the second phase of your project to reach customers that use the rest of your products supporting healthy lifestyle like air quality sensors, noise sensors, luminescence sensors and so on. These devices have even less powerful hardware than the bracelet which is why they might need to rely on a home hub like device. A hub device would have more capable hardware, run a less limited operating system, and would be able to supplement the sensors in the process of conveying the data to the cloud. This kind of design can help avoid loss of data or functionality during periods of inconsistent internet connection or provide functionality independent of cloud services.

AWS IoT Device Defender

AWS IoT Device Defender is a fully managed service that helps you secure your fleet of IoT devices. You can continuously audit your IoT configurations to ensure they aren’t deviating from security best practices. You can maintain and enforce IoT configurations such as ensuring device identity, authenticating and authorizing devices, and encrypting device data. You can also monitor security metrics from devices and get alerts and set alarms based on deviations from the expected behavior for each device.

You decide to use AWS IoT Device Defender so you can rotate your certificates. A good example use case would be to install a bootstrap certificate on your devices during manufacturing time and then rotate that certificate afterwards using AWS IoT Device Defender once the device is connected to the AWS Cloud in order for it to have one unique X.509 certificate per device.

AWS IoT Device Management

AWS IoT Device Management helps track, monitor, and manage device fleets for hundreds of thousands to millions of devices. You can use this service to ensure your IoT devices work properly and securely after they have been deployed. If you need to securely access your devices, monitor their health, detect and remotely troubleshoot problems, and manage software and firmware updates, use this service. You can securely register, organize, and remotely manage IoT devices at scale, manage permissions, and register devices individually or in bulk. You can query the state of any IoT device in your fleet and send firmware updates over-the-air through a fully managed web application. It’s agnostic to the device type and OS, so you can manage devices from constrained micro-controllers to connected cars all with the same service. It allows you to scale your fleets and reduce the cost and effort of managing large and diverse IoT device deployments.

AWS IoT Device Management is appealing to you as the CTO because you can push software and firmware updates to all devices at once and monitor the health of your devices. This helps with organizing devices as well.

Thing Groups

If we continue with the smart bracelet example, you can easily see that you can have hundreds and thousands of devices of the same model (ModelX for instance). They share the same characteristics and are in most cases are subject to the same needs. Managing tasks like permission assignment (via policies), firmware updates, or anything else that we need done with similar devices at once can be done with Static Thing Groups and/or Dynamic Thing Groups. You can have even a hierarchy of things built with multiple layers allowing us to create the structure that makes the management of our Things easier and simpler.

Jobs

Now that you can easily perform tasks only for your ModelX bracelets, you can start thinking about tasks like updating the software version on these bracelets. AWS IoT Core provides another useful feature with Jobs. Jobs allow you to initiate operations on your devices remotely. Performing actions like software updates, configuration changes, certificate renewals and anything else that would usually require direct access to the device itself can easily be done with Jobs. Rotating a certificate to provision a unique certificate per device is something that you can do for the smart bracelets you sell to customers.

Tunnels

You initiated an update to all of the home hubs, but two of the devices ended up with some issues. Accessing these devices remotely when they are deployed in various environments with different network setup and different security measures makes this task very complicated. In order to facilitate a way to troubleshoot, make configuration changes, make updates or any other operational task, AWS IoT Core has the Tunnels feature. The Tunnels feature allows you to establish a secure, bi-directional communication with your remote devices in a way that a developer can log on to the device and do troubleshooting without alterations of the network, which can be hard or complicated. The Secure Tunneling doesn’t require any inbound firewall rules or any other changes that might compromise the security of the remote site.

AWS IoT Analytics

There are a number of services in AWS that complement the IoT suite of services that the customers can use. With AWS IoT Analytics, you can analyze your entire fleet of connected devices without managing hardware or infrastructure. As your needs change, compute power and data stores automatically scale up or down so you always have the right capacity for your IoT applications, and you only pay for the resources that you use. IoT data is highly unstructured, which makes it difficult to analyze with traditional analytics and business intelligence tools that are designed to process structured data. IoT data comes from devices that often record fairly noisy processes (such as temperature, motion, or sound). The data from these devices can frequently have significant gaps, corrupted messages, and false readings that must be cleaned up before analysis can occur. Augmenting the data collected from IoT devices with information from other sources like weather information, for example, is also very important. AWS IoT Analytics filters, transforms, and enriches IoT data before storing it in the most appropriate data store for analysis. See the diagram below for a breakdown of the different capabilities within AWS IoT Analytics.

                                                                      Figure 3 – IoT Analytics capabilities

Buy vs. Build – IoT

So far, we’ve talked about AWS IoT Core in the AWS Cloud, but there are a lot of considerations that customers need to take if they were to do this without AWS or on-premises. First, for all the different parts of AWS IoT Core that we outlined in this post, (Device Gateway, Device Shadow, Device Registry, Rules Engine, etc.) you would need to build out all the parts and features of AWS IoT Core on your own. You would then need to think about how to scale the infrastructure of these parts out as you add more devices. And you would also be managing the security and authentication on your own. With AWS, you can connect your devices immediately and use all the parts of AWS IoT Core. Security and reliability of the infrastructure itself are managed for you, and you only have to worry about security and reliability of the data in the AWS Cloud itself. And the architecture would be serverless, so you don’t have to worry about the underlying infrastructure. You need to think if you would rather build this out all from scratch or leverage the buy value of using AWS IoT Core.

About the Authors 

Christine Samson is an AWS Startup Solutions Architect based in New York City. She provides customers with technical guidance for emerging technologies within the cloud, such as IoT, Serverless, and Security. She has a BS in Computer Science with a certificate in Engineering Leadership from the University of Colorado Boulder. She enjoys exploring new places to eat, playing the piano, and playing sports such as basketball and volleyball.

Zoran Nakev is a Sr. Startup Solutions Architect based in New York City. He works with startups in different industries who share the AWS Platform as the main environment for achieving their goals. He is a tech enthusiast who likes to spend his free time with family and friends and loves movies, music and long walks with his family dog.