AWS Architecture Monthly

We see more of a continuum building between cloud and edge. Customers build incredible applications that use Amazon Web Services (AWS) for data processing, analytics, storage, Internet of Things (IoT), and machine learning (ML). Increasingly, edge computing use cases (like ML inference used in Industrial IoT and manufacturing) are requiring processes be closer to end users and IoT devices.

Edge services are infrastructure and software that deliver data processing, analysis, and storage as close to the endpoint as necessary. This includes deploying services, APIs, and tools to locations outside AWS data centers. Services can also be deployed onto customer-owned infrastructure and IoT devices. As such, edge and IoT are likely to increasingly interoperate. An architectural pattern becoming more common is an edge computing environment placed near sensors that generate data. An example is achieving faster incident detection by forward deploying optimized ML models to an edge gateway with AWS IoT Greengrass.

To realize the benefits of an edge-to-cloud continuum, customers want similar consistency, security, and reliability that they expect from their global cloud infrastructure. You only need to build an application once. You will then have the flexibility to deploy it on the cloud, in your data centers, and at the edge. In any location or platform, you will get consistent performance with centralized management and governance. This significantly shortens the development lifecycle, reduces development costs, increases agility, and improves scalability.

One emerging trend where the lines between IoT and edge are starting to blur is in the convergence of information technology (IT) and operational technology (OT). IoTenabled devices and connected equipment drive the adoption of edge solutions where infrastructure and applications are being placed within operations facilities. Increasingly, use cases like predictive maintenance and factory floor automation require real-time inference. Often these environments are disconnected from, or only partially connected to the cloud.

Architects have more choice than ever in how they build out capabilities along the edge-to-cloud continuum. Services such as AWS Outposts and AWS Wavelength bring managed cloud services and infrastructure closer to physical points of operation. AWS Panorama is an ML appliance that organizations use to bring computer vision (CV) to on-premises cameras to make predictions locally with high accuracy and low latency. AWS Snowcone is ruggedized, secure, and purpose built for use outside of a traditional data center. With AWS IoT SiteWise Edge software, you can locally collect, organize, process, and monitor equipment data. Architects have increasing flexibility when selecting where to run workloads.

What are the general architecture pattern trends for IoT at the edge?

Customers are connecting their physical assets to the digital world to inform data-driven decisions. Edge solutions encompass a wide range of industries, each with a unique set of requirements and nuances. At AWS, we group these solutions into six patterns: Hybrid Edge, Industrial Edge, Connected Devices, Edge Networking, Rugged Edge, and 5G. Each use case provides customers the ability to create real-time, low-latency systems.

Hybrid solutions bring together cloud services and infrastructure nearer to devices. This enables highly responsive applications like connected vehicles and smart factories. These solutions consist of services such as AWS Outposts and Amazon EKS Anywhere. Edge Networking moves traffic to the AWS edge network, where customers can use services like Amazon CloudFront to benefit from perimeter protection and edge compute. For Industrial and Rugged Edge, customers are running applications in ruggedized environments that constrict connectivity or power. Customers can collect and process data locally with compute applications using AWS Snow Family. Customers use services like AWS IoT SiteWise to ingest and visualize data from industrial equipment. For each of these patterns, customers are beginning with the purpose-built solution that solves their use case at the edge. They augment those primary services with services like AWS Lambda and Amazon Managed Grafana to deliver consistent computing paradigms and visualization for their workloads.

When putting together an AWS architecture to solve business problems specifically for IoT customers, what are some of the considerations?

Edge applications rely on the cloud for storage, but must also do some processing close to the point of operation. This enables outcomes with optimized latency and cost. For example, industrial machines operating on assembly lines must detect and adjust to variations in the dimensions and quality of materials in real time. Self-driving cars must be able to ingest and process information offline. The edge is moving the point of processing to where you need it. Concepts of cloud computing like security, agility, and consistency must be considered when building edge applications.

Customers can translate best practices learned from the cloud to their edge workloads. Use the same security principles for encryption in transit and encryption at rest that you’d typically use in the cloud. Mirror best practices in managing PKI on premises and in the cloud, such as maintaining current cipher suites and limiting access to encryption keys. Determine how to best manage your physical hardware and what levels of redundancy you need for your workload. Think about the cloud as a set of technology services from which patterns emerge to guide designing for an edge environment.

What’s your outlook for IoT, and what role will cloud play in future development efforts?

We see the IoT business as an on-ramp for big data processing, app modernization, and AI/ML. The proliferation of devices means that our customers increasingly need solutions to connect them and manage the data they generate. There are two key trends that we think are important drivers of the future of IoT and the role of the cloud:

1. Merging between AI and IoT (or AIOT). This is occurring within virtually every industry. This merging will test how much data devices can process, and the boundaries of that processing. With the cloud, the smart products of today will evolve to the connected robots and vehicles of tomorrow.

Andy Jassy, Amazon President and CEO, made a strong case for the evolution of IoT, edge, and cloud:

“When we think about 10 years from now and when we think about hybrid, we don’t think the on-premises part is going to be in data centers. We think the on-premises part will be billions of these devices that sit at the edge—in our houses, in our offices, in factories and oil fields and agricultural fields and planes and ships, and automobiles—everywhere. These devices have relatively little CPU and relatively little disc, and so the cloud becomes disproportionately important in implementing all of those devices.”

Technologies such as 5G, LoRaWAN, and digital twins will also contribute to the merging of AI and IoT.

2. Merging of IoT and OT, or industrial IoT (IIoT). IIoT brings machine data, computing power, and people together to improve the performance and
productivity of industrial processes. With IIoT, industrial companies can digitize processes, transform business models, and improve performance and productivity. We are finding that IIoT workloads are typically new workloads for the cloud enabled by increasing maturity of the edge-to-cloud continuum.

Early adopters are using AWS IoT services and technologies with a wide variety of services to deliver productivity gains in smart manufacturing. IIoT is driving Industry 4.0 and the factory of the future. This gives manufacturers the ability to automate and optimize their operating efficiency. For instance, robotics and automated machinery can work more efficiently and accurately, when reinforced by local intelligent workloads.

We are very much at “Day 1” with IIoT. Demand for cross-site visibility and smarter insights from IoT data will drive integrating on-premises IIoT workloads with the cloud. In time, most digital data will come from IoTconnected sensors and devices.

Over the last decade we’ve witnessed an increase in IoT security issues. These issues can be against a single device or an entire IoT system. A compromised IoT device is usually a result of an increased attack surface with any number of exposed attack vectors.

Network communications, required by IoT, increase the attack surface. Artifacts, such as a password, are used to authenticate and authorize communications across the network. If passwords are somehow accessed, bad actors can gain the needed information to leverage an attack vector, such as a server that the device communicates with. Perpetrators can lift information about the application from the device, such as the application code from flash memory. This can increase the attack surface, since they are then able to grasp the application scope.

Hardware security, either using discrete components, embedded enclaves, or Physical Unclonable Function (PUF), plays a vital role in protecting customers against both approaches. The root of trust (a source that can always be trusted within a cryptographic system) must be generated by the hardware security and never be read into main memory. It should have physical security so information cannot be directly read into other components such as main memory and application flash. And it should have a cryptography library that performs and accelerates encryption operations.

Hardware security protects the client private key used in the Transport Layer Security (TLS) for network authentication and authorization. Hardware security protects the private key used for flash disk encryption, secure boot, and verifies firmware over-the-air updates.

What are the major trends with IoT device hardware security today?

Although the Trusted Platform Module (TPM) has been a component of high-end assets and laptops for almost two decades, the adoption of IoT hardware security hasn’t been nearly as pervasive. This can be because of cost, as hardware security also increases both hardware and software design complexity.

In such cases, we are seeing semiconductor companies include hardware security in microprocessors and microcontrollers. This makes their use much more common since increased security benefits everyone in the IoT value chain. Some examples include the Espressif ESP32-SE and the Xilinx Kria. Within the popular ESP32-SE module, Espressif has designed in the Microchip ECC608A secure element. Similarly, Xilinx has designed Zynq® UltraScale+™ MPSoC with an Infineon TPM 2.0.

With the hardware security built into the main compute module, IoT devices can now be designed with decreased hardware complexity. We see this trend across classic TPMs, secure elements, secure enclaves, and other embedded security approaches.

Companies such as Espressif and Xilinx then provide integration guidance to software designers and engineers. They share implementation best practices that reduce software complexity. These designs are not common across all semiconductors. I would encourage customers to look for modules that offer reduced complexity, like the Espressif and Xilinx modules, as well as others like the Microchip SAMA527 Wireless System-on-Module (SOM). Similarly, Espressif and SiFive deliver secure enclave technologies and Arm TrustZone serves as the foundation for Arm’s Platform Security Architecture (PSA).

What has AWS IoT been doing to help customers use hardware security effectively?

There are three things that AWS IoT has been doing to help customers use hardware
security effectively.

1. Working with partners. AWS Partners provide a spectrum of hardware security solutions. The AWS Partner Network works with our partners to verify and demonstrate AWS IoT integrations. You can view our partner hardware security solutions on the AWS Partner Device Catalog.
2. Ensuring that IoT provisioning works seamlessly. We have the provisioning options our customers need to tackle a wide variety of use cases. Since 2016, AWS IoT provided Just-in-Time Registration (JITR) and Just-in-Time Provisioning (JITP). Other options include Fleet Provisioning and Bulk Registration. The option you choose really depends on the type of hardware security you have and the user experience you want for the IoT device.
3. Ensuring the device software works with hardware security. AWS provides the software our customers need in order to integrate AWS device software with hardware security to ensure end-to-end IoT security. This includes AWS IoT Device SDKs, FreeRTOS, and AWS IoT Greengrass.
   

What are some of the decisions I need to make when selecting hardware security?

You’ll need to make decisions that involve security cryptographic strength, materials used in manufacturing, and consider options such as easy-to-use software development kits (SDKs).

The main thing you’re protecting in hardware security is the private key. The private key represents the device identity. Your security hardware must permit secure connection software, like mbedTLS, to use that key without ever loading it into the device main memory. Virtually all modules, enclaves, and secure partitions do this differently. When the protection and cryptography is safer and faster, the module will typically be more expensive. The module you choose corresponds to the value of the asset and the overall IoT system that you’re protecting. In other words, the choice will be different if a connected light bulb is installed in a home bathroom or a submarine.

Speaking of submarines, let’s discuss environmental conditions. The packaging of the hardware security chip, and other materials, may need to withstand extreme environmental conditions such as moisture, pressure, and temperature. These constraints will be stated in the hardware security datasheet.

Another consideration is the form factor. This is especially important when the hardware security is not included in the microprocessor or microcontroller. It is possible that the available package (the enclosure around the chip that goes on the board) might not fit in your industrial design. In this case, you may want to consider a microcontroller that has built-in hardware security.

Where can customers find more information about designing in hardware security if they’re not already doing so?

There are at least three places where customers can seek help about using hardware security modules with AWS IoT.

A bit more technical understanding might be required to make the right hardware security or secure enclave decision for your use case. Here are a few blogs I would recommend to get started: an AWS blog about modules manufactured by Microchip, a blog about modules manufactured by Infineon, and a blog focusing on Arm TrustZone.