Wie man in AWS eine skalierbare mandantenfähige IoT SaaS-Plattform mit Multi-Account-Strategie aufbaut

Wenn Sie eine IoT SaaS-Plattform aufbauen möchten, bei der Ihr Kunde und nicht Sie bestimmt, wie seine IoT-Geräte mit den Services interagieren, werden Sie schnell verstehen, dass eine einzelne Cloud-Architektur nicht für alle Szenarien optimiert werden kann. Dieser Blog-Beitrag stellt eine Implementierungsstrategie für den Aufbau von mandantenfähigen IoT SaaS-Plattformen auf der Grundlage realer Kundenerfahrungen und der Probleme vor, die sich aus der Kombination von Geräteflotten mit unterschiedlichen Betriebsprofilen in einem einzigen Amazon Web Services (AWS)-Konto ergeben. Er skizziert eine Möglichkeit, allen Kunden der IoT SaaS-Plattform eine gemeinsame Erfahrung zu bieten, erlaubt aber gleichzeitig die Segmentierung von Kunden und ihren Geräteflotten mithilfe der Infrastrukturgrenzen und Automatisierungsfunktionen in AWS.

Einleitung

Während das Internet der Dinge (IoT) immer allgegenwärtiger wird, möchten viele Lösungsanbieter IoT-Anwendungen erstellen und verwalten, die sich in bestehende Software-as-a-Service (SaaS)-Angebote integrieren. Bei der Betrachtung eines SaaS-Angebots, das IoT-Geräteflotten umfasst, muss die Architektur nicht nur das Mandantenmanagement, sondern auch die Flottenzuordnung und -isolation berücksichtigen. Dieser Blog führt durch eine Referenzarchitektur, die AWS Control Tower mit einer Multi-Account-Strategie verwendet, um eine skalierbare mandantenfähige IoT SaaS-Plattform zu implementieren.

Es gibt mehrere Möglichkeiten, die Architektur mit unterschiedlichen Bereitstellungsmodellen zu erstellen. Sie entscheiden sich vielleicht dafür, ein einzelnes AWS-Konto zu verwenden. Alternativ könnten Sie mehrere AWS-Konten verwenden. Gründe hierfür können Limits in AWS-Konten, die Isolation von Mandanten, spezifische Bereitstellungseinschränkungen von Services in AWS-Regionen oder andere architektonische Überlegungen sein.

Die Umsetzung einer Multi-Account-Strategie bei AWS hilft, neue Anwendungsversionen schnell zu testen und bereitzustellen, sowie die gesamte Umgebung sicher zu verwalten. Das Multi-Account-Bereitstellungsmodell löst insbesondere bei IoT-Workloads technische Herausforderungen, bei denen der Cloud-Workload dem Verhalten der Geräteflotte entsprechen muss, was wir im nächsten Abschnitt näher erläutern werden.

Umgang mit den Herausforderungen einer mandantenfähigen IoT SaaS-Plattform

Beim Aufbau einer mandantenfähigen IoT SaaS-Plattform, bei der Kunden die Geräte erstellen und bereitstellen, müssen verschiedene Herausforderungen gelöst werden, um eine erfolgreiche Implementierung zu erreichen, wie z.B.:

• Isolation der Daten – Bei einer Mehrmandanten-Struktur muss der SaaS-Anbieter berücksichtigen, wie er die Grenze in Bezug auf die Isolation der Daten basierend auf Vorschriften oder Kundenanforderungen setzen soll. Bei einem IoT-Workload verbinden sich viele Geräte und Gateways und senden unterschiedliche Datentypen mit unterschiedlichen Schemata. Ein AWS-Konto definiert klare Grenzen und erleichtert die Verwaltung von Limits und individuellen Bedürfnissen der einzelnen Kundenflotte, da Sie unterschiedliche Richtlinien auf Ebene des AWS-Kontos erstellen können.
• Datenschutz – IoT wird weltweit und in vielen Branchen eingesetzt. Darüber hinaus variieren die Datenschutzbestimmungen je nach Branche und Region. Mandantenspezifische IoT-Endpunkte, die auf deren Anforderungen basieren, ermöglichen Flexibilität, um als globale SaaS-Plattform agieren zu können.
• Bereitstellung und Onboarding von Geräten – Sie müssen über eine Strategie zum Onboarding von Geräten an mehreren mandantenspezifischen Endpunkten ohne Änderung der Geräteidentität verfügen. In den Best Practices der IoT-Sicherheit wird empfohlen, Geräte mit einer eindeutigen, kryptografischen Identität bereitzustellen, die an jedem IoT-Endpunkt authentifiziert wird.
  Die Programmierung und Festlegung der Root-Identität im Gerät erfolgt in der Regel in einer kontrollierten Kunden-Umgebung, wie z. B. während der Herstellung. Es kann Monate oder Jahre dauern, bis ein Gerät die globale Lieferkette durchläuft, bevor es im Feld installiert wird. Die direkte Kopplung der Geräteidentität an den IoT-Endpunkt eines Mandantenkontos während der Herstellung führt zu einer unflexiblen Lieferkette. Es verursacht für die Hersteller außerdem eine Fragmentierung der Stock Keeping Units (SKUs). Sie müssen berücksichtigen, dass das Onboarding der Geräte-Identität an einem IoT-Endpunkt erst spät im Lebenszyklus des Geräts erfolgen kann.

Die Referenzarchitektur in diesem Blog geht auf die oben genannten Herausforderungen ein, vereinfacht die Bereitstellung sowie den Betrieb und verbessert die Datenverwaltung.

Im Folgenden werden die entscheidenden Punkte der Architektur (Abbildung 1) erläutert:

• Automatisierung der Plattformerstellung – Beim Onboarding eines neuen Mandanten erstellt die Architektur ein neues AWS-Konto, das dedizierte, auf die Region bezogene AWS IoT Core-Endpunkte für Mandanten einrichtet. Anschließend werden andere damit verbundene AWS-Dienste und -Anwendungen in jedem neuen Konto bereitgestellt. Dieser automatisierte Prozess hilft bei der Lösung einiger Herausforderungen bezüglich der Isolation von Daten, dem Datenschutz sowie dem Management von Limits.
• Bereitstellung und Onboarding von Geräten – Verwenden Sie einen zentralisierten Onboarding-Dienst, um IoT-Geräte für die zugewiesenen mandantenspezifischen IoT-Endpunkte zu registrieren und weiterzuleiten. Dies hilft bei der Herausforderung einer mandantenspezifischen Gerätebereitstellung während der Herstellung und der späten Zuweisung zu einem spezifischen Mandanten.

Abbildung 1 – Übersicht über die IoT-Multi-Account-Architektur auf AWS-Kontoebene

Automatisierung der Erstellung von mandantenfähigen Umgebungen mit AWS Control Tower und AWS Service Catalog

Automatisierung und Geschwindigkeit sind der Schlüssel zu einer besseren Kundenerfahrung. Insbesondere beim Onboarding eines Mandanten. Nutzen Sie AWS Control Tower und AWS Service Catalog, um den Onboarding-Prozess für Mandanten inklusive der Erstellung des AWS-Kontos zu automatisieren. Diese Services verbessern den Prozess aus Kundensicht und reduzieren die Time-to-Market Ihres Produkts.

Durch das Aktivieren von AWS Control Tower sehen Sie eine Landing Zone, auch Control Tower – Master genannt, die in einer Region deployed wurde. AWS Control Tower erstellt außerdem ein Audit-Konto und ein Log Archive-Konto (Abbildung 2). AWS Control Tower stellt Konfigurationen oder System-Controls bereit, um Ihre Umgebungen auf Sicherheits- und Compliance-Risiken zu scannen. Sie können diese Controls als Policy-as-Code verwalten und auf die neu erstellten AWS-Konten anwenden.

Abbildung 2 – Eine Organisationsansicht der AWS Control Tower Konsole

Sobald AWS Control Tower aktiviert ist, können Sie ein neues AWS-Konto mit der AWS Control Tower Account Factory erstellen und eine IoT-Anwendung (Endpunkt) bereitstellen. Account Factory automatisiert den Prozess der Erstellung neuer AWS-Konten und wendet Sicherheits- und Compliance-Best-Practices an. Es stellt auch während des Kontoerstellungsprozesses die Mandanten-Anwendungsinfrastruktur bereit, die AWS IoT Core nutzt.

Gehen wir durch die AWS Control Tower Konsole, um die wichtigsten Einstellungen besser zu verstehen.

1. In der AWS Control Tower Konsole wählen Sie „Account factory“ in der Navigationsleiste.
2. Klicken Sie auf die Schaltfläche „Create Account“ und die Seite „Create account“ wird angezeigt.
3. Auf dieser Seite geben Sie Kontodetails wie eine E-Mail-Adresse für das AWS-Konto, eine AWS IAM Identity Center Identifikation und Ihre Organisationsinformationen an (Abbildung 3).
   

   Abbildung 3 – Erstellung eines AWS-Kontos in der AWS Control Tower Account Factory

4. Scrollen Sie nach unten zum Punkt „Account factory customization“ (AFC). (Abbildung 4) In diesem Abschnitt geben Sie ein Produkt oder eine Anwendung an, das/die nach dem Erstellen eines AWS-Kontos bereitgestellt werden soll.
   Hinweis: Alle Produkte müssen in Service Catalog als Produkte registriert sein, um in der Dropdown-Liste angezeigt zu werden. Sie können ein Produkt im Service Catalog erstellen, indem Sie selbst eine Vorlage entwickeln oder die vorkonfigurierten Bibliotheken verwenden. Weitere Informationen finden Sie unter Getting Started Library.
   Im dargestellten Szenario heißt das Produkt „iot application for tenant“ und ist als Produkt vorregistriert, so dass AFC während des Kontoerstellungsprozesses seine Bereitstellung auslösen kann. Weitere Informationen finden Sie unter Customize accounts with Account Factory Customization (AFC).
5. Zuletzt wählen Sie aus, wo das Produkt bereitgestellt werden soll. Die Account Factory stellt in Ihrer primären Region bereit (dort, wo Sie AWS Control Tower aktiviert haben) oder in „All Governed Regions“. In diesem Szenario wird das Produkt in der primären Region Nord-Virginia bereitgestellt.
   

   Abbildung 4 – Konfiguration in der Account Factory Customization in AWS Control Tower

6. Nach der Kontoerstellung sehen Sie die Konten, die unter AWS Control Tower registriert und verwaltet werden.
   

   Abbildung 5 – Liste der von AWS Control Tower bereitgestellten und verwalteten AWS-Konten mit Organisationsstruktur und Blueprints (Vorlagen), die für die Kontoerstellung verwendet wurden

Bereitstellung und Onboarding von IoT-Geräten in AWS-Konten der Mandanten

Nachdem Sie nun AWS-Konten mit der bereitgestellten IoT-Anwendung haben, geht es mit der Gerätebereitstellung und dem Onboarding weiter. Um die Gerätebereitstellung während der Herstellung von individuellen Mandantenkonten zu entkoppeln, verwenden Sie AWS Control Tower, um einen zentralen Geräte-Onboarding-Service in einem dedizierten AWS-Konto zu erstellen. Dieses Szenario verwendet die Device Lobby Referenzarchitektur, die eine Methode zum Onboarding von IoT-Geräten in AWS IoT Core mithilfe von QR-Codes bereitstellt.

Abbildung 6 – AWS Device Lobby Architektur

Ähnlich wie die Lobby eines Gebäudes oder Campus einen öffentlichen Eingang für Besucher bietet, stellt die IoT Device Lobby einen Einstiegspunkt in AWS für nicht zugeordnete IoT-Geräte bereit. Dieser Ansatz ermöglicht ein flexibles Onboarding von Mandantengeräten durch einen Zuordnungsprozess, der eine eindeutige Geräteidentität mit dem IoT Core Endpunkt eines Mandanten verknüpft. Sobald der Service die Geräte beansprucht, fungiert das Device Lobby Service-Konto als Routing-Schicht, um die Geräte an den AWS IoT Core Endpunkt des Mandanten über ein definiertes MQTT-Topic zu senden (Abbildung 7).

Diese Architektur unterstützt Mandanten bei der Herstellung von Geräten, die dann zu ihren Endpunkten weitergeleitet werden können, wann immer dies während des Lebenszyklus der Geräte erforderlich ist. Die IoT Device Lobby Architektur unterstützt auch die Migration von Geräten von einer Region oder einem Konto in ein anderes, ohne dass sie erneut bereitgestellt werden müssen. In dieser Situation stattet der Service die Geräte mit dem zentralen Endpunkt aus, der den Device Lobby Service hostet, und den eindeutigen Anmeldeinformationen, die entweder auf der Public Key Infrastructure (PKI) der Plattform oder des Mandanten basieren, als es hergestellt wurde.

Weitere Informationen finden Sie unter IoT Device Lobby Architecture [EN, Extern].

Abbildung 7 – Weiterleitung von IoT-Geräten und Registrierung in AWS-Konten der Mandanten mit der Device Lobby Architektur

Um die Device Lobby Architektur bereitzustellen, erstellen Sie ein dediziertes AWS-Konto, um den Service zu hosten. Da nur eine einzelne Instanz des Device Lobby-Dienstes benötigt wird, kann er nach der Bereitstellungsanleitung direkt im dedizierten Konto bereitgestellt werden. Optional können Sie ein Produkt im AWS Service Catalog erstellen, sodass Sie es mit der gleichen Konfiguration in Entwicklungs-, Test- und Staging-Konten ausführen können. Weitere Informationen finden Sie unter Device Lobby Configuration [EN, Extern].

Abbildung 8 – Das Produkt Device Lobby Service hinzugefügt in Service Catalog

Nachdem Sie das Device Lobby Service-Konto für die IoT SaaS-Plattform eingerichtet haben, müssen auch die Blueprints des AWS-Kontos für die mandantenfähigen IoT-Anwendungen eine Richtlinie, für die vertrauenswürdige Verbindung zwischen AWS-Konten, enthalten. Diese Richtlinie ermöglicht es dem Device Lobby Service, Geräte zu registrieren und eine Verbindung zum IoT-Endpunkt des AWS-Kontos des Mandanten herzustellen.

Die Verwendung der Device Lobby Architektur bietet der IoT SaaS-Plattform einen hohen Grad an Flexibilität beim Onboarding von Geräten auf beliebige Mandantenkonten oder Regionen, ohne dass die Geräte speziell für ein einzelnes Mandantenkonto bereitgestellt werden müssen. Aufgrund der Zeit, die für den Aufbau und die Bereitstellung von Geräten im Feld benötigt wird, kann dieser Ansatz die IoT-Reise Ihrer Kunden erheblich beschleunigen, da er bestehende Geräte-SKUs wiederverwendet. Diese Lösung kann auch zu größeren Skaleneffekten in der Lieferkette für Geräte führen.

Fazit

In diesem Blogbeitrag haben wir besprochen, wie IoT SaaS-Plattformen die Isolation der Daten, den Datenschutz sowie das Management von Servicelimits angehen können, wenn IoT-Geräteflotten mehrerer Kunden gehostet werden. AWS Control Tower hilft, den manuellen und potenziell fehleranfälligen Prozess der Verwaltung mehrerer AWS-Konten, aus denen sich eine SaaS-Plattform zusammensetzen kann, zu entfernen. Sie können das Onboarding von Geräten auf mehrere AWS-Konten, die die IoT Workloads der Mandanten hosten, mit einem zentralen Dienst wie der Device Lobby Architektur verwalten. Darüber hinaus ermöglicht eine Multi-Account-Strategie das Hosten separater und unterschiedlicher

Geräteflotten in jedem AWS-Konto eines Mandanten, das den IoT SaaS-Service umfasst. Dies führt zu einer besseren Abgrenzung zwischen den Flotten der Mandanten und einem einfacheren Management unterschiedlicher Servicekontingente und Richtlinien pro Mandanten, was letztlich zu einer robusteren und besser skalierbaren IoT SaaS-Plattform in AWS führt.

Um mehr über AWS Control Tower zu erfahren, besuchen Sie den AWS Control Tower Workshop [EN]. Um mit AWS IoT-Diensten zu beginnen, probieren Sie den AWS IoT Immersion Day Workshop [EN] aus.

Über die Autoren

	Tomo Sakatoku ist ein leitender Enterprise-Architekt bei Amazon Web Services in Seattle. Tomo ist leidenschaftlich dabei, wenn es darum geht, mit AWS-Kunden herausfordernde Probleme zu lösen. Außerdem liebt er es, abzuschalten und Tennis zu spielen sowie mit seiner Familie zu reisen.
	Ben Cooke ist ein leitender IoT-Lösungsarchitekt bei Amazon Web Services in Austin, Texas, wo er sich auf die Architektur von IoT-Systemen konzentriert. Wenn er nicht gerade mit AWS-Partnern und Kunden zusammenarbeitet, findet man Ben bei Abenteuern mit seiner Familie oder beim Basteln in seiner Garage.