Das Projekt
Scalable Capital wächst schnell – und ebenso die Notwendigkeit, den Kundensupport zu skalieren. Das Client Success Team, das sich um alle Kundenanfragen kümmert, wird von externen Mitarbeiter:innen unterstützt. Es wird angestrebt, ihnen eine Virtual-Desktop-Interface-(VDI)-Lösung bereitzustellen. Zugriff und Nutzung sollen auf einige wenige spezifische Komponenten beschränkt sein, die zur Erfüllung des Client Success benötigt werden. Zur Schaffung einer skalierbaren Umgebung, die von externen Mitarbeiter:innen genutzt werden kann, soll AWS AppStream verwendet werden.
Die Herausforderung
Die Entscheidung für AWS AppStream war bereits gefallen, und diverse Anforderungen machten das Projekt zusätzlich interessant:
- Die Lösung sollte als IaC mit Terraform bereitgestellt werden.
- Die Lösung sollte hochverfügbar und für Hunderte von Benutzer:innen skalierbar sein.
- Der gesamte ausgehende Datenverkehr sollte auf eine Handvoll zulässiger Domains beschränkt und gefiltert werden.
- Der gesamte ausgehende Datenverkehr musste von einer festen Gruppe statischer IP-Adressen ausgehen.
- Der Zugriff auf die AppStream-Instanzen sollte über GSuite SAML 2.0 Federation verwaltet werden.
Die Lösung
Architekturdiagramm der Lösung. Detaillierte Darstellung: siehe unten
Networking
Eine der größten Herausforderungen bestand darin, eine gute Netzwerkkonfiguration aufzubauen, die die hohen Anforderungen an Sicherheit, Verfügbarkeit und Skalierbarkeit erfüllt. Zunächst richteten wir drei Workload-Subnetze in drei verschiedenen Availability Zones (AZs) ein, um die AppStream-Instanzen zu hosten. Dieses Setup gewährleistet Fehlertoleranz beim Ausfall von bis zu zwei AZs. Darüber hinaus sind die Subnetze so konzipiert, dass sie einen CIDR-Bereich von /21 haben, um für zukünftige Skalierungen ausreichende Kapazitäten zu haben. Darüber hinaus platzierten wir drei von AWS verwaltete NAT-Gateways vor den Workload-Subnetzen, um für den ausgehenden Datenverkehr statische IP-Adressen zu haben, die an anderer Stelle zugelassen werden können.
Ein kniffliges Problem stellte das Filtern des ausgehenden Datenverkehrs und seine Beschränkung auf zulässige Domains dar. Wobei das Filtern an sich nicht kompliziert ist, aber eine Lösung zu finden, die einfach zu warten, zu skalieren und zu verwalten ist, stellt eine größere Herausforderung dar. Darüber hinaus mussten wir nicht nur einzelne IP-Adressen, sondern auch vollständig qualifizierte Domain-Namen (FQDN) auf die Whitelist setzen. Die Verwendung von AWS-Sicherheitsgruppen und NACLs funktioniert nicht mit FQDN. HTTP-Proxies wie squid erfordern die Einrichtung von EC2-Instanzen, Wartung usw. Alternativen von Drittanbietern, etwa Aviatrix, sind vielversprechend, haben aber im Wesentlichen die gleichen Nachteile wie HTTP-Proxies.
Glücklicherweise brachte AWS im November 2020 seine eigene Network-Firewall heraus – mit genau der Funktion, die wir benötigten: Filtern des Datenverkehrs auf Grundlage von Domain-Namen. Dafür muss man den Datenverkehr durch ein sogenanntes Firewall-Subnetz leiten. Dieses Subnetz enthält die Netzwerk-Firewall (im Wesentlichen ein VPC-Endpunkt). Dann müssen die Routentabellen der Workload- und NAT-Gateway-Subnetze angepasst werden, um den ein- und ausgehenden Verkehr durch diese Firewall-Subnetze zu leiten.
Die Netzwerk-Topologie kann in diesem AWS-Blogpost eingesehen werden.
Die Verwendung der AWS Network-Firewall macht die Netzwerkeinrichtung hinsichtlich des Filterns des ausgehenden Datenverkehrs um ein Vielfaches einfacher.
SAML 2.0 Integration mit GSuite
Die externen Mitarbeiter:innen des Client Success Teams erhalten GSuite-Logins und werden bestimmten Gruppen zugewiesen. In AWS Appstream 2.0 ist es möglich, Identity Federation über einen SAML2.0 Identity Provider zu nutzen. Hier ein Beispiel für einen Authentifizierungsworkflow.
Zudem gibt es eine Schritt-für-Schritt-Anleitung zur Einrichtung von GSuite SAML 2.0 im Verbund mit Amazon AppStream 2.0.
Mit GSuite als Identity Provider für AppStream wird der kontrollierte Zugriff externer Mitarbeiter:innen auf Ihre AWS-Konten extrem vereinfacht – deshalb möchten wir dies sehr empfehlen. Achten Sie darauf, dass Sie die Anleitung Schritt für Schritt befolgen und keine Tippfehler machen.
Image für AWS-AppStream-Instanzen
Beim Einrichten der Appstream-Instanzen müssen Sie angeben, ob Benutzer:innen auf den gesamten Desktop zugreifen können oder nur bestimmte Anwendungen starten dürfen. In diesem Fall sollten Benutzer:innen nur den Browser Chrome starten dürfen. Die Appstream-Instanzen werden von Basis-Images, den sogenannten Image Builders, gestartet.
Um Ihr eigenes, benutzerdefiniertes Image zu erstellen, verbinden Sie sich mit einer Image-Builder-Instanz, installieren und konfigurieren Ihre Streaming-Anwendungen und erstellen dann Ihr Image mit einem Snapshot der Image-Builder-Instanz.
Die Konfiguration der Anwendungen in der Image-Builder-Instanz kann etwas aufwendiger sein, da ständig zwischen dem Konfigurations- und dem Testmodus hin- und hergewechselt werden muss. Es gibt zwar die Möglichkeit, ein Bild automatisch zu erstellen, aber wie sich gezeigt hat, bietet diese Option nicht alle benötigten Funktionen. Beispielsweise musste die Chrome-Anwendung hier noch manuell auf den Image-Builder heruntergeladen werden.
Autoskalierung
Der Betrieb vieler Appstream-Instanzen hat seinen Preis. Um Kosten zu sparen, können Sie Ihre Appstream-Instanzen automatisch skalieren.
Bei Scalable Capital nutzen wir zwei Wege der automatischen Skalierung:
- Skalierung auf Grundlage eines Zeitplans: Nehmen wir an, dass alle externen Mitarbeiter:innen in derselben Zeitzone arbeiten. Dann macht es keinen Sinn, Instanzen außerhalb der Bürozeit laufen zu lassen. Deshalb bauen wir zu Arbeitsbeginn eine Basiskapazität auf und skalieren sie herunter, wenn die Mitarbeiter:innen das Gebäude verlassen.
- Skalierung auf Grundlage der Kapazitätsauslastung: Sobald die Anzahl der genutzten Appstream-Instanzen einen bestimmten Schwellenwert (z. B. 80 %) überschreitet, wird skaliert und Instanzen werden hinzugefügt.
In der Realität ist es ein bisschen komplizierter. Wir kombinieren zeitplanbasierte Skalierung und Skalierung auf Grundlage der Kapazitätsauslastung.
Im Prinzip könnte man komplett auf die Autoskalierung verzichten, wenn man den elastic-fleet type und app blocks and applications verwendet. Diese Funktion wurde jedoch erst kurz vor der Deadline des Projekts veröffentlicht und konnte nicht in unsere Lösung einfließen.
Zusammenfassung
Mit dem AWS Appstream 2.0 inklusive Autoscaling und GSuite for Identity Federation konnten wir Scalable Capital eine kostengünstige VDI-Lösung bereitstellen. Als äußerst zuverlässige und skalierbare VDI-Lösung möchten wir AWS AppStream uneingeschränkt empfehlen. Des Weiteren war die Integration der AWS Network Firewall in die Netzwerkarchitektur maßgeblich für die Schaffung einer einfachen und skalierbaren Möglichkeit der Kontrolle und Verwaltung des aus- und eingehenden Datenverkehrs.