Internet of Things

LECTURE 8
Securely Connecting AWS IoT Devices to the Cloud
Handling AWS IoT Device Data and States
AWS IoT Scenario
Let’s begin by examining our use case. A food services company trucks ice
cream products to stores throughout the greater Seattle area. One of the biggest
challenges in the distribution process is maintaining the cold chain. Over the
past few months, their business has experienced 30 percent spoilage while the
products are in transit.
The problem could be with the truck refrigeration units turning off, high
summer temperatures, truck doors being left open, electrical issues, or
something they simply haven't thought of yet.
The company wants to use AWS IoT Core to monitor various aspects of truck
operation and determine the exact causes of the spoilage.
AWS IoT Core
AWS IoT Core is a managed cloud service.
With AWS IoT Core, you can securely connect devices with cloud applications
and other devices.
You can process and act on device data and build applications that interact with
devices even when they are offline.
You can also create applications where your users can control these devices
from their phones or other mobile devices.
Devices and data collection
Devices and data collection
Devices and data collection
Devices and data collection
Devices and data collection
Devices and data collection
Devices and data collection
Command and control of devices
Using AWS IoT Core, you can send commands and updates to your devices such
as updating firmware, changing device states, and restarting or shutting down
a device.

The bidirectional communication available in AWS IoT Core means that the
company could also send messages and alerts, such as the following:
◦ A text message to the driver to confirm whether the freezer door is fully closed and latched.
◦
A message to the truck to switch to the backup battery bank or to turn on a warning light in the cab if
the temperature in the truck falls below optimal levels.
Proof of concept
Armed with this knowledge, you will assist the company to create a proof of
concept. This will entail installing a single temperature sensor in the truck and
securely connecting the device to AWS IoT Core. Following this, you will
confirm that the sensor can publish messages to the cloud. The messages will
communicate the temperature in the back of the truck, the power going to the
freezer unit, and a timestamp.
Connected Devices to
AWS IOT Core
AWS IOT Core
Device gateway
The device gateway is responsible for the secure authentication and
authorization between AWS IoT Core and the various devices and applications
(also referred to as clients) connected to it.
IoT devices and clients need to communicate with each other and with the AWS
IoT services. A protocol called MQTT (Message Queuing and Telemetry
Transport) is used for this purpose.
MQTT is a lightweight, publish/subscribe communication protocol that is used
with IoT devices.
Message broker
The message broker is a high throughput publish-subscribe messaging agent
that securely transmits messages to and from all of your IoT devices and
applications with low latency based on the MQTT.
With the publish-subscribe model you can pick and choose the information you
want to gather. Clients send data by publishing a message on a topic.
Clients receive messages by subscribing to a topic.
Topics filter and select messages for reception. You define the name of the
topics, each one associated with some data point to publish-subscribe.
Security and identity
Security is mandatory for IoT systems and has two main components:
•Authentication: Verifies the identity of a user or service
•Authorization: Grants or denies the user or service permissions to access a resource
There are two areas where security must be applied in IoT systems.
AWS IoT certificates and policies
The first is within the AWS IoT workflow itself. This area of security uses AWS
IoT certificates and policies.

Devices and things, and the applications that communicate with them, must
authenticate themselves and must be authorized to perform their functions
(such as sending and receiving messages). Servers that handle communication
and messages, such as gateways and brokers, must also be authenticated and
authorized.
AWS IoT supports three types of identity principals for device or client
authentication. This course will focus on X.509 client certificates and IAM
users, groups, and roles.
Example
A temperature sensor is able to communicate with a mobile app through a message broker.
Authentication was done through certificates, and authorization was issued through AWS IoT
policies, which are attached to the certificate
IAM
In the second category, users (both human operators and software actors) need to interact with
the IoT system or with each other.
In this case, authentication and authorization are provided through the AWS Identity and Access
Management (IAM) service credentials or, in the case of third-party authentication.
Principle of least privilege
Controlling who can do what is mandatory in IoT systems. Access should only be
granted to authorized users, and they should have permissions limited to their
exact needs. For example, a system engineer might need to activate or
deactivate sensors, whereas an operator might only need to read sensor data
and gather data logs.
Device registry
The device registry is a database of devices. It catalogs static metadata and
attributes about the devices, such as serial numbers, manufacturer, firmware
version, internal identifiers, and device capabilities.
Using the registry for your devices is optional. You don't need to create an AWS
IoT thing in the registry to connect a device to AWS IoT. The registry, however,
enhances search capabilities by maintaining a list of devices and their
attributes. The registry can also publish event messages when things, thing
types, and thing groups are created, updated, or deleted.
You can search for and manage devices using the AWS IoT console, AWS IoT API,
or the AWS Command Line Interface (AWS CLI).
Organizing Devices and
Things
Provisioning devices
The temperature sensor device has been placed on the truck. The next step in the proof of
concept is to bring the devices online so they are ready to be used. This is called provisioning.

When you provision a device, you create and register a thing, which is a virtual representation
of the physical device in the cloud.
The information used to register the device within AWS IoT Core:
◦ Thing Name
◦ Thing attributes
◦ Thing type
Thing Name
All of your things must have a unique name in the same AWS Region.

When naming things, keep the following best practices in mind:

• Do not use personally identifiable information in your thing name. The thing name can appear in
unencrypted communication and reports.
• Do not use a colon character ( : ) in a thing name. The colon character is used as a delimiter by other
AWS IoT services, and this can cause them to parse strings and thing names incorrectly.

Standardize your naming convention before the number of devices in your fleet grows too large.
Doing so simplifies management, communication, and access rights.
Thing attributes
Thing attributes are descriptive information about a thing such as function, location, technical
specifications, and so on.

Attributes, which are name-value pairs you can use to store information about the thing, such as
its serial number or manufacturer, can be helpful when searching for devices of particular type
or location.

When creating a thing, you can list up to three attributes. Using the device registry, you can
search your registered devices based on attributes and tags.
Thing type
Things can be assigned to thing types. A thing type organizes things into logical categories that
share common attributes, such as light bulbs, thermostats, and motion sensors.

Thing types can list up to 50 attributes, whereas things that aren't associated to a thing type have
only have three attributes. A thing can only be associated with one thing type. However, there is
no limit on the number of thing types you can create in your account.

Names for thing types do not require a universally unique name. However, they must be unique
within your account.
JSON data
JSON data
JSON data
JSON data
JSON data
Managing thing types
Thing types are immutable, which means the thing type name can't be changed
after it's created. If you need to change a thing type, first you deprecate the
existing thing type so no new things can be associated with it. Then,
disassociate all things from the existing thing type.
Finally, you create a new thing type that reflects the changes you want to make
and associate the things with this new thing type. You can then delete a thing
type with no things associated with it.
Thing groups
A thing group is a method to manage several things at once. Using thing groups, you can set
policies for your devices at an organizational level, instead of at the device level, and more
easily control or target updates and changes.
You can also create a hierarchy of groups—groups containing other groups. A thing can be a
member of up to 10 thing groups.
Thing groups Cont.
Securing Devices and
Authorizing action
Authorization and Authentication of IoT
Devices
When connecting devices to IoT Core, authentication and authorization perform different roles in
securing the devices. As previously discussed, there are two areas where security must be
applied in IoT systems:
• AWS IoT certificates and policies – Used for devices and things and the applications that communicate
with them
• IAM roles and policies – Used for both human operators and software actors that need to interact with
the IoT system or with each other
Device authorization
Authorization is the process of granting permissions to an authenticated identity.
After identities are authenticated, they still do not have permissions to access resources.
For devices and users to gain permissions, they must be authorized to do so.
This is achieved through use of AWS IoT policies
AWS IoT policies
Devices, mobile applications, web applications, and desktop applications all use an authenticated
identity. The identity can run AWS IoT operations only if it has a policy that grants it permission.
AWS IoT policies are attached to X.509 certificates. The policy defines what an authenticated
identity can do and grants the necessary permissions for the device to do its job.
AWS IoT policies primarily control a resource’s access to the AWS IoT Core data plane. When you
send data to and receive data from AWS IoT Core, you are using the AWS IoT Core data plane.
This means that the data plane defines whether you can connect to the message broker, send
or receive MQTT messages, or publish-subscribe to a specific topic.
IAM
In addition to the authentication and authorization of devices handled by AWS
IoT Core. IAM roles work with IAM policies to grant AWS IoT Core permissions
to access the rest of AWS.
Users (both human operators and software actors) need to interact with the IoT
system or with each other. In this case authentication and authorization are
provided through IAM policies that grant an IAM identity, or AWS resource,
permissions to access a service or perform a function with AWS.
◦ IAM roles and policies allow AWS IoT to access other AWS resources in your account on your behalf. For
example, if you want to have a device publish its state to an Amazon DynamoDB table, IAM roles allow
AWS IoT to interact with DynamoDB.
◦ Non-devices (mobile, web, or desktop applications) can authenticate with AWS IoT services, through
IAM users, groups, and roles. Web and desktop applications use IAM or federated identities. AWS CLI
commands use IAM.
IAM
AWS IoT policy format
AWS IoT policies define which AWS IoT Core actions can be taken by a
thing. Policies are JSON documents that contain a set of permissions. The
policies are then attached to the device, user, or role to give them the
permissions written in the policy.
An AWS IoT policy contains one or more policy statements. Each policy
statement contains the following three keys:
• Effect – Indicates whether the policy allows or denies access.
• Action – Includes a list of actions that the policy allows or denies.
• Resource – Specifies a list of resources to which the actions apply. If no resource is
listed, then the action applies to the resource to which the policy is attached.
Example
Policy actions
AWS IoT Core also defines a set of policy actions that describe the operations and resources to
which you can grant or deny access. Examples of actions include the following:
•iot:Connect represents permission to connect to the message broker.

•iot:Publish represents permission to publish to an MQTT topic.

•iot:Subscribe represents permission to subscribe to an MQTT topic or topic filter.
• iot:Receive represents permission to receive messages on a subscribed topic.
•iot:GetThingShadow represents permission to get a device's shadow.
Thing policy variables
Thing policy variables make it easier to write AWS IoT Core policies that grant or deny
permissions based on thing properties like thing names, thing types, and thing attribute values.
You can use thing policy variables to apply the same policy to control many AWS IoT Core
devices.
In the example policies shown so far, the variable ${iot:Connection.Thing.ThingName} is used in
the Resource value of the policy statement. This variable resolves to the name of the thing in the
AWS IoT Core registry for which the policy is being evaluated
Uncovering How
Devices Communicate
Information
Scenario Sensors
•The state of the freezer door with a digital I/O switch tells how long
the door is open.
•The on-board freezer’s internal temperature sensor gathers the
fluctuations in the trailer's temperature.
•The voltage meter going to the freezer unit measures if the freezer
is powered regularly.
•A date and time stamp associated with the other measurements
provides the option to cross reference events with weather patterns
and specific drivers.
These sensors gathering data represent devices. Collecting the data
they can provide remotely is called telemetry, which we will discuss
deeper later in this course.
Building intelligence on this data
To manage this type of scenario, you need to learn about telemetry—how the data gathered by
devices is sent to and used in the AWS Cloud. For example, sensors in the ice cream truck could
send temperature, weight, and motion readings to AWS IoT Core for analysis and processing.
To better use IoT devices, you need to understand how a specific protocol, Message Queuing
Telemetry Transport (MQTT), helps with communication between AWS IoT Core and devices.
This communication is accomplished through a concept called the publish-subscribe model.
Building intelligence on this data Cont.
You need to know how devices can feed into other Amazon Web Services (AWS) services. Based
on telemetry data, you might need to send a notification to a mobile device, or to store a value
into an Amazon Simple Storage Service (Amazon S3) bucket. Rules for AWS IoT Core is how
messages are routed to other services. For more information, see Rules for AWS IoT
Finally, you need to understand how telemetry works when devices are offline, whether
unintentionally or by design. The ice cream truck in our scenario will likely travel through areas
with poor or no network connectivity. AWS IoT Device Shadows are a way to alleviate this
problem by keeping a connection agnostic version of the last reported state of the IoT device.
Devices and clients
IoT devices and applications (a companion app for example) might need to
communicate with each other, and with the AWS IoT Core services. A protocol
called MQTT is used to accomplish this.
The key takeaway about this protocol is how it provides communication. MQTT
uses a publish-subscribe model. Let's review this concept first.
The publish-subscribe model
To illustrate this concept, let's review a familiar and relatable scenario. You
probably listen to podcasts or watch videos on Twitch. Let's focus on your
favorite content creator. IOT Device
one piece of information the device can provide topics coming from the IoT device
The creator has a new video or episode of a podcast regularly. How do you know
when something new is ready for you to enjoy on a specific channel? You could
visit the site once in a while, but one day you might have two new episodes, or
none.
To avoid losing time and visiting their site for nothing, there is a user-friendly
option: you subscribe to the channel or to the podcast. This way, any time your
favorite content creator publishes new content, you get notified on your mobile
device, since you subscribed. message on a topic
The publish-subscribe model message on a topic
Let's review the relationship reversing the roles. When you like some content
from this content creator, you decide to leave a review or click the "like" button
to signal your positive enthusiasm. You just published your opinion.
At the other end of this relationship, the content creator is interested to know
how their fans appreciate the content. To learn about this feedback, they
subscribe to be notified when listeners leave a comment or a like status.
summary of the substitution
Using Topics to Gather Specific Data
As mentioned earlier in the presentation of the publish-subscribe model, IoT
devices and applications use MQTT topics that act as a routing mechanism for
messages in the MQTT protocol. Topics define a message support that contains
an element of information to publish or subscribe to. You can define numerous
topics for your devices, providing a wide range of available messages from
captured data to intrinsic details.
Topic name
Devices and applications communicate through topics, which filter and select
messages for reception. You define the name of the topics, each one associated
with some data point to publish-subscribe.
MQTT uses a publish-subscribe messaging model, where devices can publish
messages to a topic, and other devices can subscribe to that topic to receive
messages.
A topic is a string that identifies a particular message channel in MQTT. Topics
are hierarchical and use a forward slash (/) as a delimiter. For example, a topic
might be "home/living-room/temperature" where "home" is the top-level
topic, "living-room" is a sub-topic, and "temperature" is a further sub-topic.
Topic name
You can also view this structure as
a namespace hierarchy.
Topics use a forward slash (/) to
separate the levels in the
hierarchy. A design best practice is
that topic levels structure follows
a general to specific pattern. As
the topic scheme flows left to
right, the topic levels flow general
to specific.
Topic name
•The maximum number of forward slashes (/) in the MQTT topic name for AWS IoT Core is
seven.
•MQTT topics are case sensitive; it is important to use a standard set of naming conventions
when designing MQTT topics.
•Publish Topic names cannot contain wildcards (# , +). Topics that start with $ are reserved by
AWS IoT Core
Back to our ice cream truck scenario
Topic filters
A topic helps you to subscribe to a single topic name (like any topic names presented so far in this
lesson), or it can include wildcard characters. Subscribers can use these wildcards to define a
filter for topics. Filters are a way to subscribe to multiple topics in a single request. Typical usage
of wildcards help you to subscribe to the following:
•Multiple devices on one specific topic
•Many topics on a single device
•Mix of multiple topics on multiple devices
Topic wildcards
Usage rules
Wildcard character Matches

• Must be the last character in the topic filter.

• Must be the only character in its level of the
All strings at and following its level in topic hierarchy.
#
the topic hierarchy. • Can be used in a topic filter that also contains
the + wildcard character.

Any string in the level that contains • Must be the only character in its level of the
+ the character. topic hierarchy.
• Can be used in multiple levels of a topic filter.
Wildcard topics using the Apartments
scenario
Wildcard topics using the ice cream
trucks scenario
An example of a broker
Defining the Message Broker
Defining the Message Broker
Defining the Message Broker
Defining the Message Broker
Defining the Message Broker
Defining the Message Broker
Back to our ice cream truck scenario
In our ice cream scenario, a temperature sensor can publish a message on the
topic about the temperature of the main freezer of the truck. The message is
relayed to IoT Core and is handled by the Message Broker.
The Message Broker is aware that there are subscriptions for this topic and
maintains a list of all client sessions and the subscriptions for each session.
When a message is published on a topic, the broker checks for sessions with
subscriptions that map to the topic. The broker then forwards the published
message to all sessions that have a currently connected client.
Data accumulation
Accumulating every bit of data from a sensor means that you will have a large amount of received
data. Imagine our scenario with our ice cream truck fleet with 10 trucks, each with five sensors. If
each sensor publishes, say, three elements of data (timestamp, temperature or door status, and
sensor health) every 15 seconds, this represents 60 data points every minute for each truck, so 600
pieces of information every minute.
Data Mining this data using AWS analytics services can provide some insight into the operation of the
fleet. These services help in operational monitoring, which is more of a reactive option, delayed in
time.
But for a day-to-day operation, with near real-time monitoring, there might be specific elements you
want to be aware of as they happen, to mitigate a situation or take a proper business decision backed
by data.
Imagine a sudden drop in temperature in a truck freezer. Having a direct notification of this specific
event would be helpful to the driver, while a review of the warehouse data feed would only show a
monthly average temperature for the month, not useful in the moment while a truck displays a
temperature drop at the moment.
 Introducing rules
Taking actions on IoT data begins with rules in AWS IoT. Rules
are one of the primary methods of filtering and directing
communication from AWS IoT Core to other AWS services.

By using rules, your devices can interact with AWS services.

When data comes into the AWS IoT Core, rules are analyzed
and actions are performed based on the MQTT topic stream.
You can use rules to support different tasks, such as the
following:

• Writing data from a device to an Amazon DynamoDB table.

• Invoking an AWS Lambda function to extract or transform specific data.

• Saving a file or a set of data to Amazon S3.

Rule anatomy
Rules have at a minimum the following:
•A name
•A query statement, and
•At least one action to take
You can also have additional information, such as the following:
•A description
•An error action (an action that is taken in the case of an error), and
•Tags
Query language
Rule query statements in AWS IoT are written with a syntax that is similar to the
structured query language (SQL) used in the database world. The AWS IoT
console presents a structured development environment to create query
statements to filter and route MQTT messages.
The rule query shown in the following example is selecting all of the messages
sent to the all sensors of the maincargo in truck_1 with a temperature (reported as temp)
higher than 37 topic. This query acts as a filter to ignore messages that do not
match the criteria.
Action
Different actions are available. For example, taking the selected messages and
storing them into the Amazon S3 bucket, or sending a notification (publish)
through the Amazon Simple Notification Service (Amazon SNS), and many
more.
When creating the action, an IAM role is specified to grant AWS IoT permission
to publish to the SNS topic.
Managing messaging costs
When you are planning to send messages at scale, in the order of tens of
thousands or more in short time period, you can use the Basic Ingest feature to
reduce messaging costs.
With Basic Ingest, you can securely send device data to the AWS services
supported by AWS IoT rule actions without incurring messaging costs. Basic
Ingest optimizes data flow by removing the publish-subscribe Message Broker
from the ingestion path, making it more cost effective.
What happens when connections are
interrupted
The keep alive mechanism, or "Can you
still hear me?"
MQTT uses a TCP/IP connection which is normally left open by the client so that
it can send and receive data at any time.
If there are no messages or data going back and forth for a certain time period,
then the client will try to confirm its connection to the broker by generating
a PINGREQ. The client will expect to receive a PINGRESP from the Message Broker,
as illustrated in the following image.
This period of time between exchanges is known as the Keep Alive period and is configurable.
The Keep Alive mechanism ensures that the connection between client and broker is open, and
both are aware of being connected.
For example, the client could set its Keep Alive time to 60 seconds. That means that every 60
seconds, the client will send a PINGREQ, and expect a PINGRESP from the broker.
The keep alive mechanism, or "Can you
still hear me?"
The last will and testament (LWT), or "It
was nice working with you."
The Message Broker will disconnect unresponsive clients. That way, there is no
mystery about whether a client is working or not.
Ideally, when a client is unexpectedly disconnected, you would like a
notification to go out to all the interested entities.
This is the function of the LWT. The LWT message is used to notify subscribers
of an unexpected shut down of the publisher.
When the client first connects to the broker, the client sets an LWT message. It
instructs the broker to publish a message to a topic. Then, a rule can send a
message (through a service like Amazon SQS) to all subscribers in the case of an
abnormal or abrupt client disconnection.
Example sequence of actions: Keep
alive and LWT
Example sequence of actions: Keep
alive and LWT
Example sequence of actions: Keep
alive and LWT
Example sequence of actions: Keep
alive and LWT
Example sequence of actions: Keep
alive and LWT
Example sequence of actions: Keep
alive and LWT
Introducing device shadows
A device shadow is a representation and record of the state of a device at a specific point in
time. A shadow is a JSON document used to store and retrieve last report state information for
a device. The device shadow service acts as an intermediary (like the avatar), allowing devices
and applications to retrieve and update a device's state. The shadows live in the AWS Cloud
where IoT Core accesses them reading and writing to them. This is illustrated using our ice
cream truck and IoT Core later in this section.
Device shadows Example
Introducing device shadows
While devices, apps, and other cloud services are connected to AWS IoT, they can
access and control the current state of a device through its shadows. For example,
an app can request a change in the temperature sensor of our ice cream truck by
updating a shadow. AWS IoT publishes a message that indicates the change to the
device. The device receives this message, updates its state to match, and publishes a
message with its updated state. The Device Shadow service reflects this updated
state in the corresponding shadow. The app can subscribe to the shadow's update or
it can query the shadow for its current state.
When a device goes offline, an app can still communicate with AWS IoT and the
device's shadows. When the device reconnects, it receives the current state of its
shadows so that it can update its state to match that of its shadows, and then
publish a message with its updated state. Likewise, when an app goes offline and
the device state changes while it's offline, the device keeps the shadow updated so
the app can query the shadows for its current state when it reconnects.
Back to our scenario
Back to our scenario
Back to our scenario
Back to our scenario
Device shadow document
A device's shadow is a JSON document that is used to store and retrieve state information for a device.
A device shadow document contains the following five elements:
•Device state [variables (attributes) and values]: There are two possible states: desired and reported.
•Metadata: A timestamp for each attribute included in the state node.
•Timestamp: The Epoch date and time the message was generated by AWS IoT.
•ClientToken: A value that allows to match a request message and a response from a client or device.
•Version: The current version of the document for the device's shadow shared in AWS IoT. It is
increased by one over the previous version of the document.
Device shadow document
Device shadows and
the ice cream truck
scenario
A truck reports its attributes
A client requests an adjustment but the
device is offline
The device regains connectivity and
gets a request for change
The device confirms the change is
applied
The End