When you set out to build an IoT SaaS platform where your customer, not you, determines how their IoT devices interact with the services, you will quickly understand that no single cloud architecture can be optimized for all scenarios. This blog post introduces an implementation strategy for building multi-tenant IoT SaaS platforms based on real customer experiences and the struggles that arise from mixing device fleets with differing operational profiles with a single AWS account. It outlines a means to provide a common experience for all customers of the IoT SaaS platform yet enables the segmentation of customers and their device fleets using the AWS infrastructure boundaries and automation capabilities.
Introduction
As the Internet of Things (IoT) becomes more pervasive, many solution providers want to build and manage IoT applications that integrate with existing Software-as-a-Service (SaaS) offerings. When considering a SaaS offering that includes IoT device fleets, the architecture must accommodate not only tenant management, but also fleet association and isolation. This blog explores a reference architecture that uses AWS Control Tower with a multi-account strategy to implement a multi-tenant IoT SaaS platform.
There are several ways to design the architecture with different deployment models. You may choose to deploy it into a single Amazon Web Services (AWS) account. Alternately, you might deploy it across multiple AWS accounts because of AWS account limits, tenant isolation, region specific deployment limitations, or other architecture considerations.
Establishing a multi-account strategy on AWS helps to quickly test and deploy new application versions, and securely manage the environment. The multi-account deployment model resolves technical challenges in IoT workloads in particular where the cloud workload needs to match the device fleet behavior, which we will discuss further in the next section.
Addressing the challenges of a multi-tenant IoT SaaS platform
Building a multi-tenant IoT SaaS platform service where customers create and deploy the devices presents challenges that must be resolved to have a successful implementation, such as the following:
Data Isolation – With a multi-tenant structure, the SaaS provider needs to consider how to set the data isolation boundary based on regulations or customer requirements. With an IoT workload, many devices and gateways connect and send different data types and with different schemas. Having a boundary defined by AWS account makes it easier to manage quotas and individual customer fleet needs because you can establish different account-level policies.
Data Privacy – IoT is used globally and across many industries. In addition, data privacy regulations vary by industry and region. Having separate IoT endpoints for each tenant that are based on their requirements provides flexibility to operate as a global SaaS platform.
Device Provisioning and Onboarding – You must have a strategy to onboard devices to multiple tenant endpoints without changing the root device identity in the field. IoT security best practices recommends the provisioning of devices with unique, cryptographic identity that is authenticated at each IoT endpoint.
Programming and establishing the root identity in the device typically occurs in a controlled customer environment, such as during manufacturing. It can take months or years for a device to move through the global supply chain before it’s installed in the field. Tightly coupling the device’s identity to a tenant account’s IoT endpoint during manufacturing creates an inflexible supply chain. It also causes SKU fragmentation for the manufacturers. You must consider that onboarding the device identity to an IoT endpoint can occur later in the device’s lifecycle.
The reference architecture in this blog addresses the above challenges, simplifies the deployment and operation, and enhances data governance.
The following discusses the key points in the architecture (Figure 1):
Platform creation automation – When you onboard a new tenant, the architecture creates a new AWS account which establishes tenant-dedicated and region-specific AWS IoT Core endpoints. Afterward, it deploys other related AWS services and applications in each new account. This automated process helps to solve some of the data isolation, privacy and quota management challenges.
Device provisioning and onboarding – Use a centralized onboarding service to claim and route IoT devices to designated tenant IoT endpoints. This helps solve the tenant-specific device provisioning challenge during manufacturing and late tenant binding.
Figure 1 – Overview of the IoT multi-account architecture by AWS account level
Automating the tenant environment creation using AWS Control Tower and AWS Service Catalog
Automation and speed are key to a better customer experience. Especially when onboarding a tenant. Use AWS Control Tower and AWS Service Catalog to automate the tenant onboarding process including AWS account creation. These services improve the customer’s process and reduces your product’s time to market.
By enabling AWS Control Tower, you see a landing zone, named Control Tower – Master, deployed into the Region. AWS Control Tower also creates an audit account and a log archive account (Figure 2). AWS Control Tower provides configuration, or system controls, to scan your environments for security and compliance risks. You can manage these controls as policy-as-a-code and apply them to the newly created AWS accounts.
Figure 2 – An organization view of AWS Control Tower service console
Once AWS Control Tower is enabled, you can create a new AWS account and deploy an IoT application (endpoint) using AWS Control Tower Account Factory. Account Factory automates the new AWS account creation process, and applies security and compliance best practices controls. It also deploys tenant application infrastructure that uses AWS IoT Core during the account creation process.
Let’s walk through AWS Control Tower console to get a better understanding of the key configuration points.
- In the AWS Control Tower console, choose Account factory in the navigation pane.
- Choose the Create Account button and the Create account page appears.
- In this page, specify account details such as, an account master email address, AWS IAM Identity Center identification, and your organization information (Figure 3).
Figure 3 – Account creation in AWS Control Tower Account Factory
- Scroll down the page to find the Account factory customization (AFC) section. (Figure 4) In this section, specify a product or application you want to deploy after creating an AWS account.
Note: All products need to be registered as Service Catalog products to appear in the dropdown list. You can create a Service Catalog product by developing a template yourself or using the preconfigured libraries. For more information, see Getting Started Library.
In the illustrated scenario, the product is named “iot application for tenant” and is pre-registered as a product, so that AFC can trigger its deployment during the account creation process. For more information, see Customize accounts with Account Factory Customization (AFC). - Lastly, choose where to deploy the product.
Account Factory deploys into your home region (this is where you enabled AWS Control Tower), or in the “All Governed Regions”. This scenario deploys into the home region, which is N. Virginia.
Figure 4 – Configuration in Account Factory Customization in AWS Control Tower
After account creation, you see accounts registered and managed under AWS Control Tower.
Figure 5 – List of AWS accounts deployed and managed by AWS Control Tower, with organization structure, and blueprints (templates) used for the account creation
Provisioning and onboarding IoT devices to tenant accounts
Now that you have AWS accounts with the IoT application deployed. Let’s move on to device provisioning and onboarding. To decouple device provisioning during manufacturing from individual tenant accounts, use AWS Control Tower to create a centralized device onboarding service in a dedicated AWS account. This scenario uses the Device Lobby reference architecture, which provides a method to onboard IoT devices to AWS IoT Core using QR codes.
Figure 6 – AWS Device Lobby architecture
Similar to how a building or campus’ physical lobby provides a public entry point for visitors, the IoT Device Lobby establishes an entry point into AWS for unbound IoT devices. This approach enables flexible onboarding for tenant devices though a claiming process that associates a unique device identity with a tenant IoT Core endpoint. Once the service claims the devices, the Device Lobby service account acts as a routing layer to send the devices to the tenant AWS IoT Core endpoint over a defined MQTT topic (Figure 7).
This architecture supports tenants to manufacture devices that are routed to their endpoints anytime during the devices’ lifecycle. The IoT Device Lobby architecture also supports migrating devices from one region, or account, to another without re-provisioning them. In this situation, the service provisions the devices with the central endpoint that hosts the Device Lobby service and the unique credentials based on either the platform’s or the tenant’s Public Key Infrastructure (PKI) when it was manufactured.
For more information, see IoT Device Lobby Architecture.
Figure 7 – Routing IoT devices and registering in tenant accounts with the Device Lobby architecture
To deploy the Device Lobby architecture, create a dedicated AWS account to host the service. Since only a single instance of the Device Lobby service is needed, it can be deployed in the dedicated account directly following the deployment guide. Optionally, you can create a product in the AWS Service Catalog so that you can run it with the same configuration across development, test, and staging accounts. For more information, see Device Lobby Configuration.
Figure 8 – Device Lobby Service product added in the Service Catalog
Once you establish the Device Lobby service account for the IoT SaaS platform, account blueprints for the tenant IoT applications must include cross-account trust policy. This policy allows the Device Lobby service to register and enable devices to connect to the tenant account IoT endpoint.
Using the Device Lobby architecture enables the IoT SaaS platform to have a great deal of flexibility to onboard devices to any tenant account or region without requiring the devices to be provisioned specifically for a single tenant account. Because of the time required to build and deploy devices to the field, this approach can greatly accelerate your customers’ the IoT journey because it re-uses existing device SKUs. This solution can also lead to greater economies of scale in the device supply chain.
Conclusion
In this post, we discussed how IoT SaaS platforms can address the data isolation, privacy, and service quota management challenges when hosting multiple customer IoT device fleets. AWS Control Tower helps to remove the manual and potentially error prone process of managing multiple accounts that may comprise a SaaS platform. You can manage device onboarding to multiple AWS accounts hosting the tenant IoT workloads with a centralized service such as, the Device Lobby architecture. Furthermore, a multi-account strategy enables the hosting of separate and varying customer device fleets at each tenant AWS account that comprise the IoT SaaS service. This yields better isolation between the tenant fleets and easier management of differing service quotas and policies per tenant which leads to a more robust and scalable IoT SaaS platform on AWS.
To learn more about AWS Control Tower, visit the AWS Control Tower Workshop. To get started with AWS IoT services, check out the AWS IoT Immersion Day Workshop.
About the Authors
Tomo Sakatoku
Tomo is a Principal Enterprise Architect at Amazon Web Services in Seattle. Tomo is passionate about working with AWS customers to solve challenging problems. He also loves to unplug and enjoys playing tennis, traveling with his family.
Ben Cooke
Ben is a Senior IoT Solutions Architect at Amazon Web Services in Austin, TX where he focuses on IoT system architecture. When not working with AWS partners and customers, you will find Ben on adventures with his family or tinkering in his garage.