The Internet of Things on AWS – Official Blog

Deploying and managing an IoT workload on AWS

Introduction

When implementing an Internet of Things (IoT) workload, companies are faced with multiple options when it comes to choosing a platform. From building it entirely from scratch, including your own device hardware, all the way to purchasing preconfigured hardware and just connecting to a completely Software as a service (SaaS) IoT platform.

The goal of this blog is to help you understand what skills and knowledge are required for designing an IoT solution and help you decide what components you would want to build versus buy. If you’re thinking of migrating your IoT workload to AWS, then please review the Planning a Seamless Migration to AWS IoT Core blog as a first step to understand key reasonings, incentives, and support offered by AWS that can help simplify your migration process.

Common AWS IoT architecture components

A diagram that shows the common components for an IoT device and AWS Cloud.

Device manufacturing

When developing and manufacturing device hardware, there are several factors to consider. Based upon your requirements, hardware must be selected to meet the current and future needs of your solution. Decisions must be made in regards to common IoT constraints such as managing power (supply and consumption), connectivity, security, and operating system.

If you are not building hardware in-house, then an Original Device Manufacturer (ODM) will need to be chosen. ODMs have the production line, tooling, and processes in place to produce large volumes of devices. They are able to build to the specification provided by you, which typically includes the printed circuit board (PCB) schematics, a bill of materials, firmware, and provisioning requirements.

Considerations for device hardware constraints include:

  1. Power consumption: How and where devices are to be used has a large impact on how they will be powered. A wearable device will require a small battery whereas a television will be able to leverage an AC power supply. For devices requiring batteries, you need to determine if they will be rechargeable, replaceable, or expected to last the life-time of the hardware.
  2. Operating system and firmware: The selection of an operating system or firmware will depend on the type of device and the tasks it is expected to perform. Small, low-power devices could require a real-time operating system, such as FreeRTOS, whereas larger, dedicated-power devices may utilize a full-stack operating system such as Linux.
  3. Connectivity: There are a multitude of connectivity and protocol options for IoT solutions, such as Ethernet, Wi-Fi, Cellular, LoRaWAN, and Bluetooth Low Energy (BLE). Device geography, availability, power consumption, security, and use case will determine which connectivity option is best for your solution.

To help with this component, AWS offers the AWS Partner Device Catalog, which offers a list of AWS partner manufactured devices that have completed the AWS Device Qualification Program. Devices from this list can help you go to market faster and ensure your device is compatible with AWS IoT and AWS best practices. In addition, if you’ve manufactured your own devices, you can use the AWS IoT Core Device Advisor to validate their ability to reliably and securely connect with AWS IoT Core.

Device provisioning

How you provision devices in your IoT solution will vary based on the capabilities of your device and its manufacturing process. The main focus here is on how your device and its credentials are created.

Security should be a high priority for you, your customers, and device manufacturers. When using X.509 certificates, the manufacturing process must specify when devices will receive their unique certificate and private key pairing as well as how they will be registered in your IoT solution.

Considerations for device provisioning and certificate management include:

  1. Manufacturer selection: A complete certificate chain of trust starts when you develop hardware in-house or select an OEM partner. If going with the latter, their processes will need to be inspected to ensure that certificate integrity is maintained throughout their supply chain.
  2. Certificate Authority (CA): To provide flexibility in the manufacturing of device, AWS has several options available including using your own CA, a third-party CA, or the Amazon Root certificate authority (CA).
  3. Hardware security module: Secure elements built into IoT devices form the basis for device security. This enables encryption and tamper-proof storage of certificates and secrets and firmware and applications to be validated. To help with this, AWS has a range of connectivity modules powered by AWS IoT ExpressLink which include software implementing AWS mandated security requirements.
  4. External resources: Resources may need to be created in your IoT solution to enable a custom provisioning process. These resources have to be designed to scale as your device fleet grows. With AWS, this could be an AWS Lambda function that acts as a Pre-provisioning hook.
  5. Device-level logic: A device may require on-device logic to successfully, reliably, and securely be provisioned. With AWS, the AWS IoT SDKs have been built to enable this on-device logic.

For more information on provisioning and registering devices securely with AWS IoT Core, please review the Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core AWS whitepaper and the AWS IoT Core Device Provisioning documentation.

Device management

With a mature provisioning process, a device can be secure and up-to-date from the first time it connects but it may require updates, such as firmware or certificate rotation, to remain fully compliant and provide the best user experience. Solutions for these updates will need to be designed to react to interruptions in delivery, connectivity, rollback routines, and to scale automatically.

Considerations for your device management strategy include:

  1. Organize devices: The ability to quickly identify and interact with devices gives you the ability to troubleshoot and potentially isolate them if they become out of compliance. When operating fleets of devices, you need to have solutions in-place to organize, index, and categorize your devices at scale. With AWS, you could use Fleet Hub for AWS IoT Device Management.
  2. Monitor devices: Monitoring the status of your device fleet is important in helping identify any malfunctioning or out-of-compliance devices. Ensure you have a monitoring solution in place to collect observational and security data, such as device metrics, logs, or configuration. AWS IoT Device Defender provides auditing and ongoing intelligent monitoring for security of your fleet.
  3. Respond to events: By defining a minimum set of logs, metrics, and alarms, your operations team can defend against significant business interruptions. A scalable alerting solution that integrates with your monitoring solution will be required for this. With AWS, you could use Amazon CloudWatch.
  4. Enable Over-The-Air (OTA) Updates: Devices should be designed to receive and apply updates. Your IoT solution should be designed to send updates and monitor a device’s update progress. With AWS, you could use AWS IoT Device Management Jobs.

To help with this component, AWS IoT Device Management, AWS IoT Device Defender, and AWS IoT Core offer a full set of capabilities to address device organization, monitoring, alerting, and OTA updates across your fleet of IoT devices.

Device data ingestion

Not all IoT solutions will focus just on data ingestion, but for the ones that do, this will be a primary component that affects the solution’s entire architecture. The requirements for this component will affect your solution’s scale, cost, security, and performance which means you should design your IoT solution’s architecture to meet your current and potential future data ingestion.

Considerations for your data ingestion strategy include:

  1. Data size: Assuming your devices are not hardware constrained, for optimal efficiency, try to keep the size of your messages consistent and consider batching of smaller messages to accomplish this. Keep in mind, batching can occur on and after message transmission such as batching messages using IoT Rules after they’ve been ingested by IoT Core.
  2. Data frequency & structure: Consider how often your devices transmit messages and if your solution is designed to scale for this. In addition to frequency, the structure of your data will determine if your IoT workload is messaging or streaming based.
  3. MQTT topic design: If you’re using this protocol, you should strive to find a balance between a schema that enforces least privilege communication and also allows for supporting future device deployments. A good topic schema will implement a common naming structure to provide for flexible message filtering and message routing.
  4. Data storage: Analyze the flow and usage of your messages to identify the right storage solutions. These storage solutions will have multiple considerations such as your specific use case, overall message structure, scale (for current and future growth), and cost.
  5. Routing: Once ingested, you’ll need an easy, rules-based solution to route messages to either storage or other services. These rules can then be used for further message batching, processing, or even alerting.
  6. Edge Gateway: A common architecture pattern is to have a gateway, or broker, for ingesting, processing, and/or batching data before transmitting to your IoT solution. This can be implemented as either a local endpoint, closer to your devices, or cloud, closer to your IoT solution, based gateway.

To help with this component, AWS IoT Core enables you to connect billions of IoT devices and route trillions of messages to other AWS services, such as Amazon SQS, Amazon Kinesis, and Amazon SNS, without managing any infrastructure. AWS also offers AWS IoT Greengrass which is an open-source edge runtime that provides the capabilities of an edge gateway. For more information on patterns for data ingestion with AWS IoT Core, please refer to the AWS IoT blog 7 patterns for IoT data ingestion and visualization- How to decide what works best for your use case.

Real-time video and data streams

In addition to the items discussed in the previous section, you will need to consider a few more if your IoT workload consists of video or other high volume data streams. An IoT workload that handles streams of data typically deals with high frequencies and raw, unstructured data for applications such as video processing and analysis.

Considerations streaming based workloads include:

  1. Producing: How your data streams are produced can directly affect how they are ingested, processed and stored in your IoT solution downstream. Aspects such as your device’s streaming protocol, network availability, accessibility and cost constraints will affect how your streams are produced.
  2. Consuming: The consumption and processing of your data streams can affect the required scale and overall cost of your IoT solution. High frequencies of data, such as video streams, will lead to the need for a robust architecture that is highly available, easy to manage, and can handle your throughput requirements. Consider the direct business value of these streams in your overall IoT solution to determine the most cost-effective and scalable way to consume and process them.

To help with this type of architecture, AWS offers AWS IoT Greengrass, Amazon Kinesis, and Amazon Kinesis Video Streams. AWS IoT Greengrass is an open-source edge runtime that provides the capabilities to easily consume and process data streams at the edge and transfer them to AWS via AWS-provided components. Amazon Kinesis is a cost-effective, managed service that can process and analyze streaming data produced either directly from a device, the AWS IoT Greengrass Stream manager component or an AWS IoT Rule. Amazon Kinesis Video Streams is a managed AWS service that can be used to securely view, process and analyze video streams produced either directly by a device or the AWS IoT Greengrass Edge connector for Kinesis Video Streams, regardless of the source protocol.

Device command-and-control

Command-and-control is the operation of sending a message to a device requesting it to perform an action with an optional acknowledgement of success or failure. This can be accomplished with either a command message to your device or by changing and relaying your device’s state from your IoT solution. Evaluating and optimizing your IoT solution’s messaging needs for data ingestion versus command-and-control ensures that you get the best outcomes in balancing performance and cost.

Consider the following patterns for your device command-and-control strategy:

  1. Command messaging: Use direct device message(s) with your messaging protocol of choice to transmit command(s) directly to a device. You will need device-level logic in place to accept and execute the command as well as report the device’s execution status. Please be aware that this pattern will require your IoT solution to ensure the command message is delivered or results in an actionable failure should your device be offline or disconnected.
  2. Device state: A device’s persisted state will need to be handled by your IoT solution and can be used to set device commands and update their execution status. This persisted state could be a simple document that is sent to the device when changes are made from the IoT solution and sent back if the device makes changes as well. This pattern will allow your IoT solution to interact with your device, whether it’s connected or not.

To help with this component, AWS IoT Core offers the AWS IoT Device Shadow service, the MQTT5 request/response pattern, and AWS IoT Device Management offers the AWS IoT Jobs feature. For more information on patterns for implementing device command-and-control, please see the Device Commands section of the AWS IoT Lens for the AWS Well-Architected Framework whitepaper.

Cloud architecture

When an IoT solution exists in the cloud, you may start with one regional service or with a small fleet of devices to test with your requirements. This will be fine for proof-of-concepts or demonstrations, but when you move the solution into production you need to ensure it’s built with cloud-based best practices in mind.

The AWS Well-Architected framework can help you in the design, build or even review of your solution to ensure it is using AWS in a secure, high-performing, resilient, and efficient manner. For more information on cloud based best practices with AWS IoT, please see the IoT Lens – AWS Well-Architected Framework.

Conclusion

In this blog we broke down a typical IoT solution into its essential technical components and identified what requirements and considerations to keep in mind for each one. While building an IoT solution is undeniably complex, AWS IoT is here to help simplify and streamline the journey. In addition, consider decreasing your time-to-market by using AWS IoT solutions built by AWS Partners.

About the Authors

Kai-Matthias Dickman is a Specialist Solution Architect for IoT at Amazon Web Services (AWS). He enjoys working with developers and decision makers at large enterprises to drive the adoption of AWS IoT services. Kai has in-depth knowledge of IoT and cloud and works in this role with global customers ranging from start-up to enterprises to enable them to build IoT solutions with the AWS Eco system.

Nicholas Switzer is an IoT Specialist Solutions Architect at Amazon Web Services. He joined AWS in 2022 and specializes in IoT and Edge Computing and the connected product space. He is based in the US and enjoys building smart products that improve everyday life.