PCG logo
Fallstudie

Unterstützung für den Support: Scalable Capital mit AWS AppStream

Über Scalable Capital

Scalable Capital wurde im Jahr 2014 gegründet. Das internationale Team, das an den Standorten München, Berlin und London arbeitet, vereint umfassende Kenntnisse von Kapitalmarkt und Finanzindustrie mit jahrzehntelanger Forschungserfahrung in der Risikomodellierung, Know-how zu digitalen Geschäftsmodellen sowie technischem und rechtlichem Wissen.

Die Herausforderung

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 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

image-4d89439d8b20

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 squidExternal Link 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-BlogpostExternal Link 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. HierExternal Link 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.0External Link.

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-InstanzExternal Link.

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 skalierenExternal Link.

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 typeExternal Link und app blocks and applicationsExternal Link verwendet. Diese Funktion wurde jedoch erst kurz vor der Deadline des Projekts veröffentlicht und konnte nicht in unsere Lösung einfließen.

Resultate und Vorteile

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.

Über PCG

Die Public Cloud Group (PCG) unterstützt Unternehmen bei ihrer digitalen Transformation durch den Einsatz von Public Cloud-Lösungen.

Mit einem Portfolio, das darauf ausgerichtet ist, Unternehmen aller Größe auf ihrer Cloud Journey zu begleiten, sowie der Kompetenz von zahlreichen zertifizierten Expert:innen, mit denen Kunden und Partner gerne zusammenarbeiten, positioniert sich PCG als verlässlicher und vertrauenswürdiger Partner der Hyperscaler.

Als erfahrener Partner der drei relevanten Hyperscaler (Amazon Web Services (AWS), Google Cloud und Microsoft Cloud) hält PCG die höchsten Auszeichnungen der jeweiligen Anbieter und berät Sie als unsere Kunden in Ihrer Cloud Journey unabhängig.


Genutzte Services

Weiterlesen

Artikel
AWS Lambda: Vermeiden Sie diese Fallstricke

Ein großartiges Angebot, um schnell Ergebnisse zu erzielen, aber wie jedes gute Tool muss es richtig eingesetzt werden.

Mehr erfahren
Fallstudie
Finanzdienste
Cloud Migration
Die Cloud Journey der VHV Gruppe - Mit Strategie zum Erfolg

Wie meistert ein Versicherungskonzern mit über 4.000 Mitarbeitern den Spagat zwischen Compliance, Modernisierung und Kosteneffizienz?

Mehr erfahren
Fallstudie
Finanzdienste
DevOps
KYC – Archivsystem für die digitale Bank

Aufbau eines KYC-Cloud-Archivs für eine digitale Bank zur Speicherung von KYC-Kundendaten.

Mehr erfahren
Fallstudie
Software
DevOps
Mehr Tempo für die Buchhaltung

Was als Start-up im elterlichen Keller begann, hat sich innerhalb von wenigen Jahren zum führenden Anbieter cloudbasierter Buchhaltungs- und Finanzsoftware entwickelt: sevDesk.

Mehr erfahren
Alles sehen

Gemeinsam durchstarten

United Kingdom
Arrow Down