Cloud-Infrastruktur: das gemeinsame Fundament all Ihrer Projekte

Eine Website, dann ein CRM, dann einige Automatisierungen, dann ein erster KI-Assistent. Wenn jedes Projekt mit eigenen Zugängen, eigenem Hosting und eigener Rechnung kommt, weiß nach einigen Jahren niemand mehr, wer welche Schlüssel hat, welche Daten gesichert werden und warum die Rechnung gestiegen ist. Eine Cloud-Infrastruktur baut man andersherum: zuerst ein gemeinsames Fundament, auf das sich jedes Projekt setzt.

Dieser Leitfaden unserer Rubrik Infrastruktur und Cloud erklärt, was dieses Fundament enthält, wo man es aufsetzt, was es kostet und was es dauerhaft trägt. Wenn Ihre Werkzeuge heute in Abonnements stecken, die Sie gern wieder selbst in die Hand nehmen würden, setzt unser SaaS-Ausstieg dieses Fundament auf einen eigenen Server, mit getesteten Backups und Dokumentation.

Kurz gesagt

• Das Fundament, das die großen Anbieter Landing Zone nennen, bündelt, was all Ihre Projekte teilen: Konten, Identitäten und Rechte, Netzwerk, Protokolle, Backups, Budgets, Geheimnisse und Dokumentation.
• Google empfiehlt, es vor dem ersten Projekt aufzusetzen, und weist darauf hin, dass die erste Version oft nicht die letzte ist.
• Der Ort wird nach vier Kriterien gewählt: Art der Daten, verfügbare Kompetenzen, Kosten auf Dauer und wie leicht man wieder herauskommt.
• Bei einem großen Anbieter folgt die Rechnung der Nutzung: Budgets und Alarme ab dem ersten Tag. Bei Microsoft Azure warnt ein Alarm, er stoppt den Verbrauch nicht.
• Ein Fundament ist so viel wert wie sein Betrieb: tatsächlich wiederhergestellte Backups, Überwachung, Updates, ein schriftlicher Wiederanlaufplan.

Was ist ein Fundament der Cloud-Infrastruktur?

Die drei großen Anbieter haben einen Namen dafür. In seinem Leitfaden zum Entwurf von Landing Zones beschreibt Google Cloud sie als „modulare und skalierbare Konfiguration“, die es einer Organisation ermöglicht, seine Cloud zu nutzen, nennt sie auch „Cloud-Fundament“ und fügt hinzu, sie sei „oft eine Voraussetzung“ für den Einsatz der Workloads eines Unternehmens (eigene Übersetzung). AWS macht sie auf der Seite „Landing zone“ seines Migrationsleitfadens zu einer Basis, um mit einer Mehrkonten-Architektur, Identitäts- und Zugriffsverwaltung, Governance, Datensicherheit, Netzwerkdesign und Protokollierung zu starten. Microsoft unterscheidet in seiner Vorstellung der Azure-Zielzone die Plattformzone, „die zentrale Grundlage, die Governance, Sicherheit und gemeinsame Ressourcen für alle Ihre Workloads festlegt“, von den Zonen, in denen die Teams ihre Projekte bereitstellen.

Das Wort stammt von den großen Anbietern, die Frage gehört ihnen nicht: Auch auf einem dedizierten Server oder einem VPS muss man entscheiden, wer Zugang hat, wohin die Backups gehen und wer bei einem Ausfall benachrichtigt wird. Wir sprechen daher von einem Fundament, egal wo es aufgesetzt wird.

Was enthält eine Landing Zone?

Google nennt vier Elemente, die eine Landing Zone zu entwerfen verlangt: die Bereitstellung der Identitäten, die Ressourcenhierarchie, das Netzwerk und die Sicherheitskontrollen. Je nach Bedarf des Unternehmens kommen weitere hinzu, darunter Überwachung und Protokollierung, die Backup- und Notfallwiederherstellungsstrategie, Compliance und Kostenkontrolle. Für ein mittelständisches Unternehmen sieht das so aus.

Infrastructure as Code beschreibt das Fundament in Dateien, statt es in einer Konsole zusammenzuklicken. Google empfiehlt sie, zum Beispiel mit Terraform, weil sie die Bereitstellung „wiederholbar und modular“ macht (eigene Übersetzung): Wenn man neu aufbauen oder umziehen muss, existiert das Rezept. Die Dokumentation taucht in keinem Schema auf, aber sie ermöglicht es jemand anderem als ihrem Autor, an einem Sonntag einzugreifen.

Der Tresor schließlich tut mehr, als Geheimnisse aufzubewahren: Gut angebunden lässt er Ihre Automatisierungen und KI-Agenten einen Schlüssel nutzen, ohne ihn je zu lesen. Darum geht es in unserem Artikel über den Tresor für Geheimnisse.

Nichts zwingt dazu, alles am ersten Tag aufzusetzen. Google sagt es selbst: Die erste Iteration einer Landing Zone ist oft nicht die endgültige Version, und es empfiehlt, den ersten Entwurf auf das auszurichten, was die ersten Projekte verlangen, und den Rest später hinzuzufügen (eigene Übersetzung).

Warum ist das Fundament der gemeinsame Nenner Ihrer Projekte?

Nehmen wir ein Unternehmen mit vierzig Mitarbeitenden, ein für diesen Zweck konstruiertes Beispiel. Seine Website wird von der Agentur gehostet, die sie gebaut hat, sein CRM ist ein Abonnement, seine Automatisierungen laufen auf dem persönlichen Konto eines Mitarbeiters, und ein KI-Assistent wurde gerade an die Kreditkarte eines anderen gehängt. Projekt für Projekt nichts Schockierendes. An dem Tag, an dem der erste Mitarbeiter geht, weiß niemand, welche Automatisierungen stehen bleiben, welche Schlüssel er hatte und wo die Backups des CRM sind, falls es welche gibt.

Jedes Projekt hat dieselben Antworten improvisiert: wer Zugang hat, was gesichert wird, wer zahlt und wie viel. Das Fundament antwortet einmal, und jedes Projekt erbt die Antwort. Microsoft formuliert es auf seine Weise: „Jedes Abonnement und seine Azure-Ressourcen erben die Governance- und Sicherheitsrichtlinien“, die darüber festgelegt sind, und die Zielzone nimmt neue Technologien auf, KI eingeschlossen, „ohne Änderungen an der Gesamtarchitektur zu erfordern“. Derselbe Text setzt eine gesunde Grenze: nur zentralisieren, was „klare wirtschaftliche, betriebliche oder Governance-Vorteile über mehrere Workloads hinweg“ bringt. Das Fundament ist kein weiteres Projekt: Es ist das, was Ihre Projekte gemeinsam haben, und nichts anderes.

So arbeiten wir für unsere eigenen Werkzeuge.

Wo setzt man seine Infrastruktur auf: großer Anbieter, europäische Cloud oder dedizierter Server?

Für das Cloud-Hosting eines Unternehmens gibt es drei Optionsfamilien, die sich nicht ausschließen.

• Ein großer Anbieter (AWS, Google Cloud, Microsoft Azure). Ein riesiger Dienstekatalog, eine Rechnung, die der Nutzung folgt. Bei AWS wird die Landing Zone mit dem Dienst AWS Control Tower oder maßgeschneidert erstellt, und „jede Option erfordert ein anderes Maß an AWS-Kenntnissen“ (eigene Übersetzung). Das ist die richtige Wahl, wenn Ihre Projekte diese Dienste brauchen und jemand sie betreiben kann.
• Eine europäische Cloud. In Frankreich qualifiziert die Cybersicherheitsbehörde ANSSI bestimmte Angebote unter dem Namen SecNumCloud. Auf ihrer Seite zur Cloud beschreibt sie diese als „vertrauenswürdige“ Angebote, deren Nutzung „für den Schutz sensibler Daten empfohlen“ wird.
• Ein dedizierter Server oder ein VPS. Feste, planbare Kosten, aber ein Betrieb, der fast vollständig bei Ihnen liegt: Updates, Backups, Überwachung. Das ist unsere Wahl für unsere eigenen Werkzeuge.

Zur Entscheidung vier Kriterien:

1. Die Art der Daten. Gesundheitsdaten, personenbezogene Daten in großer Menge, Betriebsgeheimnisse: Sie entscheiden oft über den Ort, vor allem anderen.
2. Die verfügbaren Kompetenzen. Ein großer Anbieter verlangt Kenntnis seiner Konsole, seiner Rechte und seiner Abrechnung; ein Server, dass man ihn warten kann. Wählen Sie, was jemand, bei Ihnen oder bei einem Dienstleister, auch in zwei Jahren noch betreiben kann.
3. Die Kosten auf Dauer. Vergleichen Sie über drei Jahre, Betriebsstunden eingeschlossen, nicht nach dem Preis des ersten Monats.
4. Die Abhängigkeit vom Anbieter. Ein in Code beschriebenes Fundament und Daten in offenen Formaten halten die Ausgangstür offen.

Die Frage der Souveränität geht über diesen Leitfaden hinaus: Wir behandeln sie in unserer Analyse der Abhängigkeit Europas von der amerikanischen Cloud.

Nichts hindert daran, zu kombinieren: Ihre Verwaltungswerkzeuge auf einem eigenen Server, ein rechenintensives Projekt bei einem großen Anbieter. Das Fundament bleibt dann ein einziges Regelwerk, an beiden Orten angewandt.

Was kostet das Fundament, und wie vermeidet man die Überraschungsrechnung?

Ein Fundament kostet zweimal: bei der Einrichtung und dann jeden Monat im Betrieb, und diese zweiten Kosten zählen vor allem in Stunden. Google warnt, dass Entwurf und Bereitstellung einer Landing Zone mehrere Wochen dauern können (eigene Übersetzung). Für den Vergleich mit Ihren aktuellen Abonnements ist unsere Methode beschrieben in die echten Kosten eines SaaS-Ausstiegs über drei Jahre.

Bei einem großen Anbieter folgt die Rechnung der Nutzung, und eine vergessene Ressource kostet weiter. Google nennt übrigens die Werkzeuge zur Steuerung der internen Kostenverteilung unter den Gründen, eine Landing Zone vor dem ersten Projekt aufzusetzen (eigene Übersetzung). Legen Sie daher ab dem ersten Tag ein Budget pro Projekt und Alarme fest.

Man muss allerdings wissen, was ein Alarm tut. Die Dokumentation von Microsoft zu Azure-Budgets ist eindeutig: Wenn ein Schwellenwert überschritten wird, „sind die Ressourcen nicht betroffen, und Ihr Verbrauch wird nicht gestoppt“. Der Alarm kommt zudem mit Verzögerung, und eine Kostenabweichung vom Montag wird womöglich erst am Dienstag gemeldet.

Um automatisch zu handeln, muss man das Budget mit einer „Aktionsgruppe“ verknüpfen. Die anderen Anbieter haben ihre eigenen Regeln: Lesen Sie die Ihres Anbieters, bevor Sie sich auf einen Alarm verlassen.

Dieselbe Überlegung gilt außerhalb der großen Clouds. Auf Palmora Property, einem Immobilienportal, das wir betreiben, liefen Automatisierungen in einem minutengenau abgerechneten Continuous-Integration-Dienst; nach drei Nächten mit mehr als vier Stunden abgerechneter Minuten haben wir sie auf einen dedizierten Server zurückgeholt. Umgekehrt kosten manche Bausteine wenig: Der Plan für Backups außerhalb des Servers von Palmora Property kostet etwa 6 Dollar im Monat. Was kostet, sind die Stunden im Betrieb.

Warum zählt der Betrieb mehr als die Einrichtung?

Ein Fundament bricht nicht am Tag seiner Einrichtung. Es verfällt still: ein fehlschlagendes Backup, ein ablaufendes Zertifikat, ein aufgeschobenes Update, ein nie entzogener Zugang. Vier Routinen machen den Unterschied.

• Tatsächlich wiederhergestellte Backups. Ein nie wiederhergestelltes Backup bleibt eine Hypothese. Auf Palmora Property beurteilen wir eine Wiederherstellung nach der Zahl der wiedergefundenen Tabellen und Datensätze, nicht nach dem Rückgabecode des Werkzeugs, der schon bei bloßen Warnungen einen Fehler meldet. Details in unserem Leitfaden zu Backups eines eigenen Servers.
• Eine Überwachung, die warnt. Google spricht von Dashboards und Alarmen, die „jede Anomalie, die Handeln erfordert“, melden (eigene Übersetzung). Es muss sie aber auch jemand erhalten und lesen.
• Geplante Updates, mit einer Möglichkeit, zurückzugehen, falls eines einen Dienst bricht. Unser Leitfaden zu selbst gehostetem n8n in Produktion zeigt das an einem Werkzeug, das sich fast jede Woche ändert.
• Ein schriftlicher Wiederanlaufplan. Google zählt die Backup- und Notfallwiederherstellungsstrategie zu den Elementen einer Landing Zone; für ein mittelständisches Unternehmen ist es eine Seite, die sagt, was neu gestartet wird, in welcher Reihenfolge und wen man benachrichtigt.

Wir sprechen aus Erfahrung.

Wenn Sie von Abonnements ausgehen, zählt auch die Reihenfolge, in der Sie sie auf Ihr Fundament zurückholen: Wir beschreiben sie in die Werkzeuge, die man zuerst aus dem SaaS holt.

Was wir anbieten und was wir belegen können

Zwei Fälle, je nach gewähltem Ort.

Ihr Fundament auf einem eigenen Server. Das ist unser Angebot zum SaaS-Ausstieg: das Audit Ihrer Abonnements und ihrer echten Kosten über drei Jahre, bis zu fünf installierte Werkzeuge, Ihre Daten migriert und geprüft, Backups außerhalb des Servers mit getesteter Wiederherstellung und eine Betriebsdokumentation. Es kostet 5.500 € und dauert drei Wochen; die optionale Betreuung kostet 450 € im Monat und umfasst Überwachung, Updates und getestete Backups.

Ihr Fundament bei einem großen Anbieter oder in einer europäischen Cloud. Wir setzen es bei dem Anbieter auf, den Sie gewählt haben oder den wir gemeinsam nach den obigen Kriterien wählen: Organisation der Konten, Identitäten und Rechte, Budgets und Alarme, Protokolle, Backups, in Code beschriebene Infrastruktur und Dokumentation. Danach betreiben wir es oder übergeben es Ihnen mit seiner Dokumentation.

Was wir belegen können, ist unser eigenes Fundament: ein einziger Server und rund ein Dutzend Dienste, mit den Abwägungen und Vorfällen, die das mit sich bringt. Wir beanspruchen keine bereits aufgesetzten Fundamente bei AWS, Google Cloud oder Microsoft Azure. Die drei oben zitierten Leitfäden zeigen es: Die Bausteine eines Fundaments ähneln sich von Anbieter zu Anbieter, es sind die Werkzeuge, die sich ändern. Und wenn Ihr Projekt eine Spezialexpertise für einen Anbieter verlangt, die wir nicht haben, sagen wir es Ihnen, bevor wir beginnen.

Wo man anfängt

1. 01Machen Sie eine Bestandsaufnahme.

   Die Cloud-Konten und Abonnements, wer darauf Administratorzugang hat, welche Daten darin liegen, welche Rechnungen jeden Monat kommen.

2. 02Ordnen Sie Ihre Daten.

   Die sensiblen und die nicht sensiblen: Diese Sortierung entscheidet oft über den Ort.

3. 03Setzen Sie das Minimum des ersten Tages auf.

   Personengebundene Zugänge mit starker Authentifizierung, ein Budget und Alarme, Backups außerhalb des Hauptstandorts mit getesteter Wiederherstellung und eine Seite Dokumentation.

4. 04Holen Sie ein erstes, wenig kritisches Projekt herein.

   Google empfiehlt, zuerst die Workloads bereitzustellen, die am leichtesten in seiner Cloud laufen (eigene Übersetzung): An diesem ersten Projekt spielt sich das Fundament ein.

5. 05Fügen Sie den Rest Projekt für Projekt hinzu.

   Jedes neue Projekt prüft, dass das Fundament trägt, und ergänzt es bei Bedarf. Um zu verschieben, was schon läuft, ohne etwas zu brechen, gehen Sie Workload für Workload vor: Die Methode beschreiben wir in Cloud-Migration: den Bestand verlagern, ohne alles zu brechen.

Wenn Sie dieses Fundament auf einem eigenen Server wollen, installiert es unser SaaS-Ausstieg in drei Wochen, mit getesteten Backups und Dokumentation. Soll es bei einem großen Anbieter oder in einer europäischen Cloud leben, beschreiben Sie uns Ihre Projekte und den angedachten Anbieter: Wir sagen Ihnen, was Ihr Fundament enthalten muss.

Häufige Fragen

Quellen

1. Leitfaden zum Entwurf von Landing Zones (neuer Tab)docs.cloud.google.com
2. Der Seite „Landing zone“ seines Migrationsleitfadens (neuer Tab)docs.aws.amazon.com
3. Seiner Vorstellung der Azure-Zielzone (neuer Tab)learn.microsoft.com
4. Ihrer Seite zur Cloud (neuer Tab)cyber.gouv.fr
5. Dokumentation von Microsoft zu Azure-Budgets (neuer Tab)learn.microsoft.com