SRV408 Deep Dive on AWS IoT

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Juan Villa, AWS Solutions Architect
July 26, 2017
Deep Dive on AWS IoT
Shadows, Rules, and More
SRV408

AWS IoT
Data storage
& analytics
Administration
Sensors
Actuators
Connected Farm
Control
automation

Agenda
• Introduction to AWS IoT
• Telemetry & analytics
• Cloud control
• Mobile control
• Lifecycle management
• Wrap up

Key takeaways
• Messaging
• Be careful with wide fan out
• No message ordering guarantees
• Avoid large fan in
• WebSockets for Amazon Cognito authentication
• Rules
• Send data to multiple data stores at the same time
• Manage device lifecycle events
• Shadows
• Designed for the real world: poor connectivity, out of order messages
• Fine-grained control over software rollouts
• Not ideal for storing time-series analytics data
• Security
• One cert per device
• Set fine-grained permissions for devices and Amazon Cognito users
• Naming conventions can simplify policy management

Administration
Actuators
Control
automation
AWS IoT
Data storage
& analytics
Sensors
Connected Farm

AWS IoT Telemetry & Analytics
1. Connect devices
2. Send data
3. Collect and store the data
4. Do something with the data

AWS IoT Telemetry & Analytics
DEVICE GATEWAY
Communicate with devices via
MQTT and HTTP
AUTHENTICATION
AUTHORIZATION
Secure with mutual
authentication and encryption
RULES ENGINE
Transform messages
based on rules and
route to AWS services
AWS services
- - - - -
3P Services

1) Connect the devices
1. Provision a certificate
2. Attach policy
3. Connect over MQTT

2) Send data
PUBLISH macdonald/sensors/123 (qos: 0)
{
"timestamp": "2016-01-29T10:00:00",
"temperature": 55
"humidity": 39,
"ph": 6.7
}

3) Collect the data
AWS IoT
Data storage
& analytics
Sensors
?

Single consumer (don’t do this)
AWS IoT instance database
PUBLISH sensors/123
PUBLISH sensors/456
SUBSCRIBE sensors/+
PUBLISH sensors/789

Don’t do this: scalability
AWS IoT instance
SUBSCRIBE #

Don’t do this: availability
AWS IoT instance

Don’t do this: maintainability
AWS IoT

Store it in the device shadow (don’t do this)
Sensors
DEVICE SHADOWS

1. AWS services
(Direct Integration)
Rules Engine
Actions
AWS IoT Rules Engine
AWS
Lambda
Amazon
SNS
Amazon
SQS
Amazon
S3
Amazon
Kinesis
Amazon
DynamoDB
Amazon
RDS
Amazon
Redshift
Amazon Glacier
Amazon
EC2
3. External Endpoints
(via Lambda and SNS)
Rules Engine connects AWS
IoT to external endpoints and
AWS services.
2. Rest of AWS
(via Amazon Kinesis,
Lambda, S3, and more)

Example rule
{
"rule": {
"sql": "SELECT * AS message FROM ’macdonald/#'",
"description": "Store all sensor data into dynamodb and firehose",
"actions": [{
"dynamoDB": {
"tableName": "sensor_data",
"roleArn": "arn:aws:iam::123456789012:role/aws_iot_dynamoDB",
"hashKeyField": "sensor_id",
"hashKeyValue": "${topic(2)}",
"rangeKeyField": "timestamp“
"rangeKeyValue": "${timestamp()}",
}
}, {
"firehose": {
"roleArn": "arn:aws:iam::123456789012:role/aws_iot_firehose",
"deliveryStreamName": "my_firehose_stream"
}
}]
}
}
macdonald/sprinkler-456/temperature

IoT SQL Functions
• Math
• abs, acos, asin, atan, atan2, cos, cosh, etc…
• round, ceil, floor, exp,
• Bitwise Ops
• bitand, bitor, bitxor, and bitnot
• String and Arrays
• chr, concat, encode, endswith, get, indexof, length, lower, upper, etc...
• newuuid, parse_time
• Hashing
• md2, md5, sha1, sha224, sha256, sha384, sha512
• IoT
• machinelearning_predict(modelId, roleARN, record)
• get_thing_shadow(thingName, roleARN)
• principal, topic, timestamp, traceid
[…]
"hashKeyValue": "${topic(2)}",
“rangeKeyField": "timestamp“
"rangeKeyValue": "${timestamp()}”
[…]

Different data scenarios
Want to run a lot of queries constantly?
Use Amazon Kinesis Firehose to write into
Amazon Redshift
Need fast lookups, e.g., in Rules or Lambda functions?
Write into DynamoDB, add indexes if necessary
Have a need for heavy queries but not always-on?
Use Firehose and S3, process with Amazon EMR or Athena.

Takeaways
• Avoid single “firehose” MQTT consumer architecture
• Rules route data into the rest of AWS at scale
• Fork data into multiple data stores simultaneously
• Avoid the device shadow for analytics

Administration
AWS IoT
Data storage
& analytics
Sensors
Connected Farm
Actuators
Control
automation

Automated Sprinkler Service
Amazon
Kinesis
Amazon Machine
Learning
Amazon
Redshift
Rules
Engine
Device
Gateway
Sensor
Sprinkler
Amazon Kinesis–
enabledapp

Talking back to the sprinklers
Amazon
Kinesis
Amazon Machine
Learning
Amazon
Redshift
Rules
Engine
Sensor
Device
Gateway
Sprinkler
Amazon Kinesis–
enabledapp

Publish on/off to the sprinkler (don’t do this)
Device
Gateway
Sprinkler
Control
logic
SUBSCRIBE
macdonald/sprinkler-456

Publish on/off to the sprinkler (don’t do this)
Device
Gateway
Sprinkler
Control
logic
PUBLISH
{ "water": "on" }

Direct publishing: why not?
Device
Gateway
Sprinkler
(offline) Control
logic
PUBLISH
{ "water": "on" }
X

Sprinkler
Control
logic
on
off
Device
Gateway
off
on

• Connection blips
• Messages aren’t ordered
So then what?

Device Shadows
Shadow
State
Apps
offline

Device Shadows
Device Controller
reported
state
desired
state

Device Shadows
Device Controller
reported
state
desired
state
HTTP/
WebSockets
MQTT

AWS IoT Shadow - Simple yet powerful
{
"state" : {
“desired" : {
"lights": { "color": "RED" },
"engine" : "ON"
},
"reported" : {
"lights" : { "color": "GREEN" },
"engine" : "ON"
},
"delta" : {
"lights" : { "color": "RED" }
} },
"version" : 10
}
Thing
Report its current state to one or multiple shadows
Retrieve its desired state from shadow
Mobile App
Set the desired state of a device
Get the last reported state of the device
Delete the shadow
Shadow
Shadow reports delta, desired and reported
states along with metadata and version

Device Shadows and versioning
Sprinkler
Control
logic
on (version=1)
off (version=2)
Device
Gateway
off (version=2)
on (version=1)
(old message ignored by device)

Takeaways
• Plan for devices losing connectivity
• Send devices’ commands through shadows
• Query device state through shadows
• Version numbers control concurrency

Data storage
& analytics
Sensors
Talking back to the sprinklers: manual override
Control
automation
AWS IoT
Administration
Actuators

AWS IoT
DEVICE SHADOW
Persistent thing state
during intermittent
connections
APPLICATIONS

Using Cognito with IoT
DEVICE SHADOW
during intermittent
connections
APPLICATIONS
AMAZON
COGNITO
PERMISSIONS APIs
Configure device and
Cognito User permissions
end-user
(farmer)

end-user
(farmer)
Using Cognito with IoT
DEVICE SHADOW
during intermittent
connections
APPLICATIONS
AMAZON
COGNITO
PERMISSIONS APIs
Configure device and
Cognito User permissions

Policy for Cognito with IoT
aws iot attach-principal-policy --policy-name farm-sensors
--principal us-east-1:xxxx-yyyy-zzzz
Cognito Identity = us-east-1:xxxx-yyyy-zzzz
You will need a trusted entity to attach the Cognito principal to an IoT policy
• Only needed for iot-data plane calls such as DeleteThingShadow,
UpdateThingShadow, GetThingShadow, Connect, Publish, and Subscribe
• Can use API Gateway, Cognito Sync Triggers, or other techniques for
attaching the Cognito principal ID to the IoT Policy

Overall Cognito “pairing” workflow
1. Create a Cognito identity pool
2. Customer signs in using mobile app
3. Associate their user with their “farm”
4. Create a scope-down policy in IoT for their user
5. Attach that policy to their Cognito user in IoT

Managing fine-grained permissions
• One “farm owner” needs permissions to many shadows
• "arn:aws:iot:…:thing/sprinkler123abc"
• "arn:aws:iot:…:thing/sprinkler456def"
• …
• Listing each is tedious

Best practice: Thing name prefixing
• Prefix thing name with logical owner
• sensor123abc -> macdonald-sensor123abc
• IAM policies support wildcards
• "arn:aws:iot:…:thing/sensor123abc"
• "arn:aws:iot:…:thing/sensor123abc"
• "arn:aws:iot:…:thing/sensor456def"
• …
• "arn:aws:iot:…:thing/macdonald-*"

Takeaways: Cognito authorization
• Cognito enables secure human control over IoT devices
• IoT scope-down policy supports fine-grained control
• Naming conventions simplify policy management

Actuators
Data storage
& analytics
Device lifecycle management
Control
automation
AWS IoT
Sensors
Maintenance
1

Lifecycle workflow
Notify operator
1
Connected Disconnected Still
disconnected?

AWS IoT Rules Engine & Amazon SNS
Push Notifications
Apple APNS Endpoint, Google GCM Endpoint, Amazon ADM Endpoint, Windows
WNS
Amazon SNS -> HTTP Endpoint (or SMS or email)
Call HTTP-based third-party endpoints through SNS with subscription and retry
support
SNS
2

Detecting disconnects
DisconnectedConnected
Graceful disconnect
Crash
Back online

Lifecycle events
• Connect
• PUBLISH lifecycle/sensor-123
{"status": "online"}
• Disconnect (graceful)
{"status": "offline"}
• Disconnect (crash)
{"status": "offline", "isCrash": true}

Handling lifecycle events
SELECT
status,
topic(2) as deviceId,
timestamp() as time,
isCrash
FROM lifecycle/#
WHERE status='offline'
- Look up mobile push ID for device owner
- Send SNS mobile push
AWS Lambda function

Delayed lifecycle events
SELECT
status,
topic(2) as deviceId,
timestamp() as time,
isCrash
FROM lifecycle/#
Device Status Time
sensor-123 connected 11:30
…
- Double-check the status in DynamoDB
- Send SNS push notification if still offline
- Store update device status in DynamoDB
- If offline: enqueue an SQS message with
DelaySeconds
AWS Lambda function
SQS Message (15 minutes later)
Amazon
DynamoDB

Generating lifecycle events
• Connect
{"status": "online"}
• Disconnect (graceful)
{"status": "offline"}
• Disconnect (crash)
{"status": "offline", "isCrash": true}

Lifecycle events: connecting
$aws/events/presence/connected/clientId
{
"clientId": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"timestamp": 1460065214626,
"eventType": "connected",
"sessionIdentifier": "00000000-0000-0000-0000-000000000000",
"principalIdentifier": "000000000000/XXX:some-user/XXX:some-user"
}
Automatic lifecycle message

Lifecycle events: disconnecting
$aws/events/presence/disconnected/clientId
{
"clientId": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"timestamp": 1460065214626,
"eventType": ”disconnected",
"sessionIdentifier": "00000000-0000-0000-0000-000000000000",
"principalIdentifier": "000000000000/XXX:some-user/XXX:some-user"
}
Automatic lifecycle message

Last Will and Testament (LWT)
CONNECT message parts:
Protocol: MQTT 3.1.1
ClientId: abc
KeepAlive: 60 seconds
LastWill PUBLISH message:
Topic: foo/bar
QoS: 1
Payload: {"foo": "bar"}

Takeaways: lifecycle management
• Use automatic lifecycle events
• Use LWT for lifecycle events
• SQS delayed messages and DynamoDB can reduce
false positives

AWS IoT
DEVICE SDK
Set of client libraries to
connect, authenticate, and
exchange messages
DEVICE GATEWAY
Communicate with devices via
MQTT and HTTP
AUTHENTICATION
AUTHORIZATION
Secure with mutual
authentication and encryption
RULES ENGINE
Transform messages
based on rules and
route to AWS services
AWS services
- - - - -
3P services
DEVICE SHADOW
during intermittent
connections
APPLICATIONS
AWS IoT API
DEVICE REGISTRY
Identity and management of
your things

Key takeaways
• Messaging
• Be careful with wide fan out
• No message ordering guarantees
• Avoid large fan-in
• WebSockets for Cognito authentication
• Rules
• Send data to multiple data stores at the same time
• Manage device lifecycle events
• Shadows
• Designed for the real world: poor connectivity, out of order messages
• Fine-grained control over software rollouts
• Not ideal for storing time-series analytics data
• Security
• One cert per device
• Set fine-grained permissions for devices and Cognito users
• Naming conventions can simplify policy management

AWS Marketplace
Really quick…

AWS Marketplace – IoT Software on AWS
EDGE, GATEWAY AND
CONNECTIVITY
DEVELOPMENT
PLATFORMS & TOOLS
DATA ANALYTICS AND
MACHINE LEARNING
IoT HARDWARE
AND SENSORS
aws.amazon.com/mp/iot

Working with system
integrator Pinacl, Newport
used the Davra
ConnecThing.io IoT platform
from AWS Marketplace to
connect sensors and create a
unified city dashboard.
Newport wanted to implement
IoT proofs of concept to
improve flood control, waste
management, and air quality
measurement—without
buying and managing costly
server infrastructure.
• Deployment in weeks
instead of months
• Ability to start with just a
few sensors and scale up
as needed
• Freedom to experiment at
low cost and risk
“ Pinacl presented a smart city solution with the Davra
ConnecThing.io platform from AWS Marketplace in
record time. We were able to complete a full evaluation
ahead of schedule and quickly see our smart city
initiative, the Newport Intelligence Hub, coming to light.
Shaun Powell, Digital Lead, Newport City Council
CHALLENGE SOLUTION BENEFITS
About Newport
Newport is a vibrant city of more
than 300,000 in Wales, UK,
seeking to invigorate its
economy and improve quality of
life for citizens and visitors using
forward-thinking technology.
Company: Newport City Council
Industry: Government
Country: Wales, UK
Councilors: 50
Website: www.newport.gov.uk
Newport, Wales Deploys Innovative Smart City
Technology in Weeks with IoT Platform from
AWS Marketplace

Thank you!
Kudos to Daniel Austin, Brett Francis, Olewale
Oladehin, and especially David Yanacek!

Appendix:
Managing Software Updates

Data storage
& analytics
Managing software updates
Control
automation
AWS IoT
Administration
Actuators
Sensors

Firmware topic (don’t do this)
• Have all devices subscribe to a topic
• Publish updated binaries to this topic
SUBSCRIBE sensor/firmware
PUBLISH sensor/firmware
01100100 01101111 00100000
01101110 01101111 01110100
00100000 01100100 01101111
00100000 01110100 01101000
01101001 01110011

Firmware topic (don’t do this)
Pros:
• Sending an update is easy
Cons:
• Large messages not supported
• Offline devices miss updates
• No control over rollout

Firmware version shadow (don’t do this)
• One thing shadow for the current firmware version
• All devices subscribe to shadow updates
• Messages include a CloudFront download URL
SUBSCRIBE
$aws/shadow/firmware-thing
PUBLISH $aws/shadow/firmware-thing
{
"desired": {
"version": “123.45"
"url": “https://abc123.cloudfront.net/newversion"
}
}
SUBSCRIBE
$aws/shadow/firmware-thing

Firmware version shadow (don’t do this)
Pros:
• Sending an update is easy
• Offline devices eventually see updates
• Bulk download happens through CloudFront
Cons:
• No control over rollout
• Shadow protocol is chatty

Firmware in device shadows
• Set each device’s shadow to its desired firmware version
• Devices subscribe to their own shadow
• Messages include a CloudFront download URL

SUBSCRIBE
$aws/shadow/sensor-abc123
PUBLISH $aws/shadow/sensor-abc123
{
"desired": {
"version": “123.45"
"url": "https://abc123.cloudfront.net/newversion"
}
}
SUBSCRIBE
$aws/shadow/sensor-def456
PUBLISH $aws/shadow/sensor-def456
{
"desired": {
"version": “123.45"
"url": "https://abc123.cloudfront.net/newversion"
}
}

Pros:
• Full control over rollout / rollback
• Offline devices eventually see updates
• Bulk download happens through CloudFront
Cons:
• Sending updates requires sending multiple messages

Takeaway
• Be careful with wide fan out to millions of devices
• Wide fan out is supported, but won’t be instant
• Encourage safe device management

SRV408 Deep Dive on AWS IoT

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to SRV408 Deep Dive on AWS IoT

Similar to SRV408 Deep Dive on AWS IoT (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Recently uploaded

Recently uploaded (20)

SRV408 Deep Dive on AWS IoT