© Tomasz Wyszolmirski, 123RF

Die wenigsten Unternehmen kommen mit einer einzelnen Cloud aus; Kombinationen aus privaten Clouds, AWS, Azure, Google und anderen Anbietern sind stattdessen die Regel. Wie klappt das sinnvoll?

Schon Herbert Grönemeyer stellte zusammen mit den Fantastischen Vier fest: Es könnte alles so einfach sein, ist es aber nicht. Eine ziemlich präzise Beschreibung der Cloud-Situation im Jahre 2021: Irgendwie in die Cloud wollen fast alle Unternehmen – mal vollständig, mal in manchen Abteilungen. Immer mehr Firmen wagen diesen Schritt auch tatsächlich. Selten jedoch wird die Arbeit mit der Cloud zentral gesteuert. Und schlimmer noch: In die Cloud migrieren viele Firmen höchstens insofern, als dass man Workload aus den eigenen Rechenzentren auf fremde Infrastruktur verschiebt.

Die Cloud an sich aber gibt es in vielen Fällen gar nicht. Stattdessen sind die Zielplattformen oft ein wilder Mix aus dem Platzhirsch AWS (Abbildung 1), dessen ersten Konkurrenten Azure (Abbildung 2), Googles Cloud oder anderen Public-Cloud-Angeboten wie der Open Telekom Cloud. Zusätzlich spielen oft private Cloud-Umgebungen eine Rolle. Viele Firmen sind ganz einfach nicht bereit, kritische Unterlagen und Firmengeheimnisse in die Obhut eines externen Dienstleisters zu geben, und behelfen sich mit Eigenbaulösungen.

Abbildung 1: Public Clouds wie AWS bieten einen riesigen Funktionsumfang – wer in mehreren Clouds parallel unterwegs ist, verliert schnell den Überblick. Quelle: Amazon

Abbildung 2: Auch Microsoft hat bei Azure den Funktionsumfang in den letzten Jahren kontinuierlich erweitert – und versucht, Nutzer exklusiv an sich zu binden. Quelle: Microsoft

Unternehmen – und dort Admins auf der einen Seite und Sicherheitsbeauftragte (Chief Information Security Officer, CISO) auf der anderen – stellt diese Art von Wildwuchs vor erhebliche Probleme. Aus Sicht eines zentralen Administrationsteams, das die Workloads einer Firma über die Grenzen etwaiger Plattformen hinweg verantwortet, stellen diversifizierte Cloud-Setups eine erhebliche Herausforderung im Hinblick auf Wissen und selbst einfache operative Tätigkeiten dar.

Zwar bieten alle Public Clouds ähnliche Funktionen, doch die Art, wie diese zu nutzen sind, unterscheidet sich unter Umständen erheblich. Der für Compliance und Datenschutz Verantwortliche bekommt bei etwaigen Setups ebenfalls schnell graue Haare: Ein Datenschutzverantwortlicher muss sich ja mit den Datenschutzvorgaben sämtlicher genutzten Plattformen im Detail auskennen und nicht nur Compliance-Regelwerke erlassen, sondern auch ihre korrekte Umsetzung regelmäßig überprüfen.

Dieser Artikel richtet sich an leidgeplagte Administratoren und CISOs, die es im beruflichen Alltag mit mehreren Cloud-Umgebungen zu tun haben und diese unter einen Hut bekommen müssen. Welche Werkzeuge erleichtern dem Admin im Alltag die Arbeit? Auf welche Ressourcen kann man bei Azure, AWS und Co. im Compliance-Kontext zurückgreifen? Wie lassen sich Verbindungen zwischen Clouds herstellen, falls das nötig sein sollte? Das Linux-Magazin geht der Sache auf den Grund.

Fünf Problemfelder

Viele Admins stehen in Sachen Multi-Cloud-Setups vor einer echten Katastrophe, ohne sich dieses Umstands überhaupt bewusst zu sein. Im ersten Schritt geht es deshalb darum, die fünf großen Problemdomänen aufzuzeigen, mit denen Administratoren und Datenschützer im Multi-Cloud-Kontext zu tun bekommen. Vier davon betreffen die Admins, eine das Thema Datenschutz.

Da wären zunächst die Themen Governance und Compliance. Fast jedes Unternehmen hat dafür mehr oder minder umfassende Regeln. Häufig fällt das anzuwendende Regelwerk umso komplexer aus, je größer die Organisation ist. Meist bezieht es sich aber explizit nur auf Setups, die unter der Fuchtel des jeweiligen Unternehmens in dessen eigener Infrastruktur stehen. Cloud-Setups werden gelegentlich mit erwähnt, spielen im Detail aber keine Rolle.

Im Falle eines Falles kann das böse ins Auge gehen: Die DSGVO gilt ja in AWS für ein Unternehmen, das dort Daten hostet, ebenso wie in dessen eigenem Rechenzentrum. Verlässt etwa ein Administrator das Unternehmen, muss sein Account in AWS ebenso deaktiviert werden wie der im lokalen LDAP. Das Unternehmen hat zudem sicherzustellen, dass auf AWS keine Daten landen, die dort nicht hingehören, oder dass Ende-zu-Ende-Verschlüsselung zum Einsatz kommt, wenn etwa S3 als Ablageort für sensible Backups dient. Von den diversen Zertifizierungen ist da noch gar nicht die Rede: Wer für sich ISO 27001 oder PCI-DSS in Anspruch nimmt, muss die jeweiligen Regeln überall befolgen, in der Cloud wie bei On-Premises.

Dem Lock-in entkommen

Amazon erweitert das Feature-Set seiner Public Cloud pro Tag gefühlt um Tausende neue Dienste, bis zu “Latte Macchiato as a Service” kann es wohl nicht mehr lange dauern. Ein großer Teil der AWS-Funktionalität ist AWS-spezifisch und steht in Azure oder anderen Umgebungen nicht zur Verfügung. Andere Funktionen aus AWS haben bei Azure und Konsorten ein Pendant, das aber jeweils eine andere API verwendet und in vielen Fällen auch fundamental anders funktioniert. Keiner dieser Dienste ist darauf ausgelegt, mit vergleichbaren Services anderer Umgebungen besonders interoperabel zu sein.

Wer seinen AWS-Workload mit den von AWS dazu gelieferten Werkzeugen überwacht, bekommt ein stabiles und gutes Monitoring-System (Abbildung 3), das sich für Dienste in Azure aber nicht nutzen lässt. Jeder Cloud-Anbieter versucht auf diese Weise, die eigene Klientel heimlich, still und leise an das eigene System zu ketten, weil eine Migration woanders hin später enorm aufwendig und teuer wäre. Hat man dann noch ein eigenes Icinga, Nagios oder Prometheus, das auch noch mitspielen soll, ist das Chaos perfekt.

Abbildung 3: Für einzelne Plattformen spezifizierte Monitoring-Werkzeuge funktionieren dort super, woanders aber gar nicht. Quelle: Amazon

Wer? Wie? Was? Wo?

Agilität ist etwas Feines, und viele Unternehmen investieren viel Geld, um von konventionellen Entwicklungsmodellen zu dynamischeren Ansätzen zu kommen. Das führt im Kontext mehrerer Clouds schnell zu Wildwuchs: Entwickler A klickt sich mal eben eine Instanz in AWS zusammen, Entwickler B bevorzugt Azure, und Entwickler C will offene APIs von OpenStack, weshalb er sich in der Open Telekom Cloud einmietet. Im aus Sicht des Unternehmens besten wie schlechtesten Fall laufen am Ende drei für die Produktion kritische Werkzeuge in verschiedenen Clouds.

Der beste Fall wäre das, weil die Migration in die Cloud und erhöhte Agilität erfolgreich umgesetzt werden konnten; der schlechteste Fall, weil in einem solchen Szenario früher oder später niemand mehr weiß, welche Dienste denn eigentlich wo laufen. Verlassen die ursprünglichen Entwickler dann noch das Unternehmen, ist das Chaos perfekt: Eine AWS-Instanz mit Ubuntu etwa setzt ab Werk gar kein Passwort für das Login per SSH – es funktioniert ausschließlich das Login per SSH-Key. Ist nur ein Schlüssel hinterlegt, ist Holland in Not , wenn dessen Eigentümer die Firma verlässt.

Teure Test-Datenbank

Ein Problem, das viele Firmen im Cloud-Kontext gar nicht im Hinterkopf haben, sind die anfallenden Kosten – kein Wunder, schließlich ist die Cloud ja billig. Oder auch nicht: Legendär sind die Erzählungen vom armen Tropf, der eine fette Datenbankinstanz zu Testzwecken gestartet und dann vergessen hat, und dafür am Monatsende eine Rechnung über 10 000 Euro präsentiert bekommt.

Während die meisten Unternehmen für solche Probleme mittlerweile sensibilisiert sind, fallen Kleinst-Setups, die über Wochen und Monate unbemerkt laufen, oft gar nicht auf. Sie produzieren frei nach dem Motto “Kleinvieh macht auch Mist” trotzdem Kosten. In gewisser Weise hängt dieser Punkt mit dem ersten zusammen – wer darf in einer Public Cloud unter welchen Umständen was innerhalb des Firmen-Accounts tun, und welche Kontrollinstanzen gibt es? Weil Unternehmen es mit diesem Problem gleich mehrfach zu tun bekommen, wenn sie sich in mehreren Clouds bewegen, ist eine zentrale Lösung nötig.

Wissen ist Macht

Die fünfte und letzte Herausforderung im Umgang mit Public Clouds besteht im Aufbau von Wissen innerhalb der Firma. Wenn ein Unternehmen keine ausgemachte IT-Firma ist und ein zentrales Administrationsteam sämtliche Ressourcen betreut, muss diese Mannschaft über genug Know-how verfügen, um jede Art von Workload auf jeder Plattform zu betreuen. Wer sich das Schulungsangebot von AWS, Azure & Co. anschaut, merkt aber schnell: Gerade in kleinen Teams stellt es eine Herausforderung dar, alle Mitglieder mit den nötigen Kenntnissen auszustatten. Das gilt umso mehr, wenn zusätzlich noch eine On-Premises-Umgebung etwa auf Basis von OpenStack ins Spiel kommt, die ebenfalls viel Wissen voraussetzt.

Und nun?

Die Probleme, mit denen Unternehmen in diversifizierten Cloud-Setups konfrontiert sind, liegen damit auf dem Tisch. Was können Datenschützer und Administratoren nun tun, um einige der Herausforderungen zu minimieren oder gleich ganz zu umschiffen? Es gibt keine Instant-Lösung, die alle Aspekte zur Gänze abdeckt. Die sinnvolle Nutzung von Multi-Cloud-Setups ist viel eher ein umfassendes Konzept, das alle relevanten Faktoren einbezieht. Anhand der fünf genannten Faktoren gibt dieser Artikel im Folgenden ein Beispiel, wie das sicher und sinnvoll funktionieren kann.

Gerade das Compliance-Thema ist ein hervorragendes Beispiel dafür, dass in Multi-Cloud-Umgebungen längst nicht alles so schlimm ist, wie es im ersten Augen erscheint. Unternehmen stehen hier vor zwei großen Problemen: Sie müssen einerseits eine sinnvolle Benutzerverwaltung in der Cloud etablieren und auf der anderen Seite sämtlichen Pflichten im Hinblick auf die Datenhaltung genügen, die Vorschriften wie die DSGVO oder hausinterne Compliance-Reglements einfordern.

Der Teil mit der Benutzerverwaltung erweist sich dabei in vielen Fällen als tief hängende Frucht: Selbst in vielen kleineren Firmen gibt es bereits ein zentrales Benutzerverzeichnis, aus dem heraus Dienste wie der Mail-Server oder die Anmeldung an Servern gesteuert werden. Nahezu alle großen Cloud-Anbieter bieten verschiedene Möglichkeiten, solche Benutzerverzeichnisse anzubinden. Wer etwa einen OpenID- oder SAML-Provider aufsetzen kann, findet bei sämtlichen relevanten Public Clouds die Möglichkeit, Single-Sign-On (SSO) darüber zu realisieren. Selbst wenn kein SSO zur Verfügung steht, bieten zumindest AWS, Azure und Google Möglichkeiten, vorhandene Active-Directory-Server oder auch LDAP-Dienste anzubinden. Das Login in die Public Cloud oder in mehrere Public Clouds funktioniert dann so wie das in die Infrastruktur des eigenen Unternehmens. Deaktiviert man im zentralen Nutzerverzeichnis einen Anwender, kann der sich auch in der Cloud nicht mehr anmelden.

Etwas komplexer gestaltet sich die Sachlage, wenn es darum geht, den Abfluss von Daten zu verhindern. Manche Clouds bieten Compliance-Frameworks an, mit denen sich Checks implementieren lassen, die Derartiges verhindern. Wer diese nutzt, tappt letztlich aber wieder in die Lock-in-Falle, weil diese Werkzeuge in den allermeisten Fällen spezifisch auf eine Cloud zugeschnitten sind. Schlauer ist eine Strategie, die mehrere Faktoren vereint.

Grundsätzlich sollten Daten in Public Clouds auf verschlüsselten Volumes liegen. Das verhindert zumindest, dass jemand auf der Cloud-Ebene unbemerkt ein Volume ausliest und die Daten einfach herausträgt. Viel wichtiger aber ist es, auf Firmenebene ein verbindliches Regelwerk zu etablieren. Das muss festlegen, welche Daten in die Cloud dürfen und welche Daten die physischen Server des eigenen Unternehmens nicht verlassen dürfen. Mit Werkzeugen wie InSpec (Abbildung 4) lässt sich zumindest zum Teil automatisiert überprüfen, ob die ausführenden Admins und Entwickler sich an die Regeln halten. Dem Verantwortlichen für Compliance und Datenschutz fällt in so einem Szenario die Aufgabe zu, die Reports von Werkzeugen wie InSpec regelmäßig zu lesen und bei Bedarf Alarm zu schlagen.

Abbildung 4: Kostengrenzen lassen sich bei AWS, Azure & Co. festlegen und verhindern finanzielle Desaster.

Unbedingt beachten sollten Unternehmen in Sachen Compliance den Faktor der Automation. Je einheitlicher der Workload ausfällt, der in verschiedenen Clouds läuft, desto einfacher lässt er sich im Hinblick auf Compliance überwachen. Im Klartext bedeutet das, dass es im Idealfall egal sein sollte, ob ein Workload auf Azure, auf AWS, in Googles Cloud oder sonst wo zum Einsatz kommt: Er sollte agnostisch gegenüber der jeweils verwendeten Plattform sein und überall funktionieren.

Generische Funktionen

So verlockend es aus Sicht des Entwicklers oder Administrators auch erscheinen mag: Wer sein Setup auf verschiedene Clouds ausweitet, sollte auf As-a-Service-Dienste der Anbieter so weit wie möglich verzichten. Die sind in den meisten Fällen absolut spezifisch im Hinblick auf die Plattform, aus der sie stammen. Ein Mittelweg besteht möglicherweise darin, auf Werkzeuge zu setzen, die ein einheitliches Frontend bieten, im Hintergrund aber unterschiedliche Backends für verschiedene Clouds besitzen. Manche Werkzeuge haben etwa selbst eine abstrahierte Database-as-a-Service-Funktion, die je nach Zielplattform deren Funktionalität konsequent verwendet.

Generell sollten Multi-Cloud-Werkzeuge wie Terraform [1] oder Pulumi [2] eine zentrale Rolle spielen, wenn es der Wunsch eines Unternehmens ist, Workloads auf viele Clouds zu verteilen: Sie agieren nach außen hin Cloud-agnostisch und ermöglichen es dem Administrator, mit Wissen über das Tool möglichst viele Features aus den diversen Umgebungen zu nutzen. Hier gibt es jedoch ein paar Einschränkungen: Geht in der Cloud selbst etwas schief, gelingt das Debugging nur mit entsprechendem Fachwissen. Irgendjemand im Unternehmen sollte also über das nötige Wissen verfügen, um im Fall der Fälle gewappnet zu sein. Nicht jedes Teammitglied braucht die entsprechenden Informationen, was den Schulungsaufwand erheblich reduziert.

Standard-Protokolle helfen

Oft besteht in Unternehmen, die Dienste in verschiedenen Clouds ausrollen, keine Notwendigkeit, die einzelnen Setups tatsächlich auch miteinander kommunizieren zu lassen. Falls doch, sei an dieser Stelle der dringende Hinweis erlaubt, das so weit wie möglich mit Standardwerkzeugen und -protokollen zu realisieren. Alle Public-Cloud-Anbieter bieten eine Möglichkeit, eine direkte Verbindung via Routing oder IPsec mit Umgebungen in privaten Netzwerken herzustellen. Es gibt dann quasi aus dem eigenen Setup heraus einen privaten Uplink in die Cloud, der sich per Firewall separat absichern lässt – und zwar in der eigenen Infrastruktur außerhalb der Cloud. Die Einrichtung entsprechender Verbindungen ist zwar eine einmalige Handarbeit, das ausführende Unternehmen profitiert davon aber langfristig.

Gut tun Unternehmen daran, sich im Hinblick auf die Überwachung der eigenen Systeme vorrangig auf externe Werkzeuge und eigene Tools zu verlassen. Das heißt nicht, dass alle Monitoring-Features der Public Clouds außen vor bleiben müssen. Monitoring, Alerting und Trending von AWS werden sich für Azure aber nicht nutzen lassen. Eine zentrale Monitoring-Infrastruktur, die alle Setups in den diversen Cloud-Umgebungen überwacht, stellt deshalb den besseren Ansatz dar. In Form von Prometheus oder InfluxDB steht leistungsfähige Software bereit, die mit den Setups skaliert, ohne anbieterspezifisch zu sein. Mit diesen Werkzeugen lassen sich zusätzlich zu den Workloads in der Cloud die Metadaten der Accounts in den jeweiligen Umgebungen überwachen – etwa die Zahl der gestarteten VMs, der angelegten Netzwerke oder der genutzten IP-Adressen. Das wiederum hilft dabei, verdächtige Aktivitäten schnell aufzuspüren.

Automation ersetzt Features

Auch an dieser Stelle ist der Hinweis auf flächendeckende Automation in Setups angebracht. Werkzeuge wie Terraform leisten dabei enorme Hilfe und bieten die Möglichkeit, Workloads so generisch zu entwickeln, dass sie in den unterschiedlichen Clouds laufen. Es schadet außerdem nicht, so viel Funktionalität wie möglich im Bereich der eigenen Kontrolle zu realisieren. Alle großen Cloud-Anbieter haben etwa verschlüsselte Volumes im Sortiment, pflegen die Schlüssel dafür aber über eigene, proprietäre Werkzeuge. LVM mit LUKS lässt sich freilich auch in einer VM innerhalb einer Cloud verwenden, was die Abhängigkeit von Cloud-spezifischen Schlüsselmanagern merklich reduziert.

Einmal davon abgesehen, dass Administratoren sich heute grundsätzlich mit dem Thema Automation befassen sollten, gibt es im Multi-Cloud-Kontext dafür große zusätzliche Anreize. Einer der wichtigsten ist zweifelsohne, dass sich mit klug eingesetzter Automation eine Art Single Source of Truth für Workloads in verschiedenen Clouds schaffen lässt, die stets einen aktuellen Überblick bietet. Was viele Admins gar nicht wissen: Auch die gängigen Automatisierer, allen voran Ansible, bieten vielfältige Features, um Workloads in Clouds auszurollen. Es ist etwa überhaupt kein Problem, AWS- oder Azure-Instanzen aus Ansible heraus zu starten. Kombiniert man das ganze dann mit einem Werkzeug zur zentralen Verwaltung von Automation, wie Ansible AWX, wird ein Schuh daraus. Das folgende Beispiel veranschaulicht das.

Ansible AWX sowie das darauf basierende Ansible Tower [3] lassen sich zum Beispiel an eine LDAP- oder Active-Directory-Verzeichnisstruktur ankoppeln. Verwenden können die Software dann nur jene Anwender, die einen funktionierenden Account im Unternehmen haben – was erheblich dabei hilft, Compliance durchzusetzen. Aus AWX oder Tower heraus kann man dann diverse Workloads starten, CI/CD-Prozesse lassen sich dabei integrieren: Eine virtuelle Maschine lässt sich mittels Tower also zum Beispiel auch aus einem CI/CD-System heraus starten, ohne die in Tower oder AWX festgelegten Regeln zu umgehen. Weil vergleichbare Werkzeuge wirklich alles penibel mitschreiben und in entsprechenden Status-Dashboards auch grafisch aufbereitet anzeigen, verliert das Administrationsteam nicht so schnell den Überblick. Sogar das zuvor beschriebene Problem mit SSH-Schlüsseln lässt sich auf mehrere Arten lösen.

Benutzerverwaltung

Einerseits besteht die Möglichkeit, mittels Federation und SSO oder über entsprechende VPN-Konfigurationen den firmeninternen Verzeichnisdienst in die Cloud zu exportieren. Neue VMs konfiguriert man dann so, dass sie sich unmittelbar an das Verzeichnis anbinden, etwa per NSS an ein LDAP. Direkt nach dem Start gelingt dann der Login für jeden Nutzer in der passenden LDAP-Gruppe ohne Probleme. Und weil sich in LDAP auch SSH-Schlüssel speichern lassen, klappt das – wie von Ubuntu & Co. gewünscht – komplett ohne Passwort. Scheidet ein Kollege aus und wird im LDAP deaktiviert, verliert er automatisch den Zugriff auf die Ressourcen in der Cloud.

Wer seinen Verzeichnisdienst nicht in die Cloud spiegeln möchte, nutzt einen anderen Teil der Automation. Per Ansible lassen sich ja durchaus auch neue Benutzerkonten anlegen und alte löschen. Das setzt dann zwar voraus, dass das Administrationsteam eine Liste mit “guten” und “bösen” Accounts pflegt und nach jedem Zu- oder Abgang eines Mitarbeiters zumindest einmal einen Ansible-Lauf mit dem passenden Playbook startet. In kleinen Firmen, in denen sich der Aufwand nicht auszahlt, ein LDAP zu pflegen, hält sich die Fluktuation in den meisten Fällen aber in Grenzen.

Benutzerverwaltung und Automation in der Cloud helfen schließlich auch dabei, den Wildwuchs einzudämmen: Eben einmal etwas auszurollen, ohne dass es jemand anders bemerkt, funktioniert in Werkzeugen wie Ansible Tower schlicht nicht. Als Teil des administrativen Dashboards lässt sich der aktuell ausgerollte Workload über alle Plattformen hinweg zentralisiert anzeigen. Das entbindet das Administrationsteam zwar nicht davon, ein wachsames Auge auf die entsprechenden Details im zentralisierten Cloud-Management-Werkzeug zu haben, reduziert die Gefahr von Chaos in Public Clouds aber erheblich.

Kostenfallen entschärfen

Das leitet ausgesprochen dynamisch zum vierten Problem über: dem der galoppierenden Kosten für unbemerkt ausgerollte Workloads. So banal die Erkenntnis auch sein mag: Nutzer, die keine Workloads in Public Clouds starten können, produzieren damit auch keine zusätzlichen Kosten. Wer die Erlaubnis hat, Workloads zu starten, legt im Idealfall ein Compliance-Dokument fest. Weil Vorsicht besser als Nachsicht ist, schadet es aber auch nicht, die festgelegten Regeln der Compliance-Abteilung in konkrete Technik umzusetzen.

Hier gibt es Cloud-spezifische Lösungen wie den AWS Control Tower, der das Erzwingen verschiedener Compliance-Vorgaben ermöglicht. Möchte man es aber, um Lock-ins zu vermeiden, generischer haben, bieten sich wieder Tools wie Ansible Tower oder Terraform nebst entsprechender Compliance-Regeln an. Neben der Anbindung an Verzeichnisdienste wie LDAP bieten diese Werkzeuge in aller Regel auch ein rollenbasiertes System für die Zugriffssteuerung (RBAC), das maschinell definiert, welcher Benutzer etwas darf und welcher nicht. Hinterlegt ein Unternehmen also in Ansible Tower seine AWS- und Azure-Credentials und legt danach per RBAC fest, welche Gruppe dort Instanzen starten darf und welche nicht, reduziert das die Gefahr erheblich, dass unbemerkt ausgerollte Setups in kurzer Zeit horrende Rechnungen generieren.

Komplementär dazu ist es eine gute Idee, in den verschiedenen Clouds mittels der jeweils dafür vorgesehenen Funktionen Kostenobergrenzen für Setups festzulegen. Selbst wenn alle zuvor beschriebenen Kontrollmechanismen versagen, bleibt der finanzielle Schaden dann überschaubar (Abbildung 5).

Abbildung 5: Tools wie InSpec von Chef überwachen in Clouds ausgerollte Workloads automatisch und helfen dabei, Compliance zu erzwingen.

Maßgeschneiderte Schulungen

Das letzte Problem, dem Unternehmen sich im Multi-Cloud-Kontext widmen müssen, ist das des Wissenstransfers. Es ist ja nicht sonderlich kompliziert, in AWS oder Azure eine virtuelle Instanz zu starten oder etwaige Zusatzdienste zu nutzen; grundlegendes Wissen sollte allerdings vorhanden sein. Betreiben Firmen Setups in mehreren Clouds, multipliziert sich das benötigte Wissen mit der Anzahl der genutzten Umgebungen. Verhindern lässt sich das letztlich nur, indem Firmen ihren Admins eine Abstraktionsebene wie Ansible Tower oder Terraform zur Seite stellen und im Hinblick darauf schulen. Nutzt eine Firma Funktionen in Clouds an diesen Tools vorbei, so ist das zumindest ausführlich zu dokumentieren.

Der Anspruch, Setups auf verschiedene Cloud-Plattformen zu verteilen, erhöht die technische Komplexität des Workloads einer Firma erheblich, und damit auch das Risiko, das sie eingeht. Dennoch muss der Admin nicht wie das Kaninchen vor der Schlange sitzen und hoffen, dass nichts passiert. Grundlegende Regeln wie jene, so viel generische Funktionalität wie möglich zu nutzen und beizeiten umfassende Compliance-Vorgaben einzuführen, schaffen mildere Umstände. Werkzeuge, die Workloads in verschiedenen Cloud-Umgebungen betreiben können, mindern zudem den Bedarf an Schulungen für die diversen Zielplattformen. Nicht wegdiskutieren lässt sich bei allen guten Ratschlägen, dass Multi-Cloud-Setups in der Installation und bei der Wartung mehr Aufwand verursachen als ihre uniformen Kollegen. Mit der richtigen Strategie lässt dieses Risiko sich aber kalkulieren.

Unternehmen tun außerdem gut daran, sich die Frage zu stellen, ob eine Multi-Cloud-Strategie wirklich nottut. Nach der Erfahrung des Autors setzen viele Firmen nicht gezielt oder gewollt auf hybride Setups, sondern eher aus Versehen. Admin 1 kennt und mag AWS, Admin 2 bevorzugt Azure, und Admin 3 schwört auf die Dienste von Google. Entsprechend nutzt jeder der drei für seine Arbeit die Plattform, mit deren Verwendung er sich am leichtesten tut, ohne dass es dafür zwingende technische Gründe gäbe. Wer nicht spezielle Features von AWS, Azure oder Google braucht, der kann per Compliance-Vorgabe die zu nutzende Public Cloud auch administrativ vorgeben. Das kostet etwas Flexibilität, reduziert aber die handzuhabende Komplexität erheblich. (jcb)