Globale Cloud-Infrastruktur und Ressourcenorganisation

Eine Region ist ein geografisches Gebiet, in dem ein Anbieter Cloud-Dienste aus einer Gruppe von Rechenzentren anbietet. Mit der Regionswahl platzierst du die meisten Ressourcen, etwa eine Datenbank, in diesem Gebiet. Regionen sind für einen unabhängigen Betrieb ausgelegt, was hilft, regionale Ausfälle einzugrenzen.

Lies den Standort richtig

AWS, Microsoft Azure und Google Cloud verwenden unterschiedliche Namen für ähnliche Standorte. Ein Anzeigename hilft Menschen, einen Ort zu erkennen; ein Code identifiziert ihn in Befehlen und Vorlagen.

Ein Name allein kann täuschen. Azure West Europe (westeurope) liegt in den Niederlanden, North Europe in Irland. Google Cloud europe-west4 liegt in den Niederlanden, während europe-west1 in Belgien liegt. AWS Europe (Frankfurt) verwendet eu-central-1. Wenn ein bestimmtes Land vorgeschrieben ist, überprüfe den dokumentierten physischen Standort.

Die Anbieter betreiben mehrere Dutzend Regionen in Nord- und Südamerika, Europa, im asiatisch-pazifischen Raum, im Nahen Osten und in Afrika. Ihre Präsenz wächst weiter. Für eine Standortentscheidung ist eine aktuelle Infrastrukturkarte nützlicher als eine auswendig gelernte Regionszahl.

Unterscheide Standort und Geltungsbereich

Der Geltungsbereich einer Ressource beschreibt das Gebiet, zu dem sie gehört oder das sie bedienen kann.

Die Bezeichnung „regional“ allein sagt wenig über den Schutz vor Ausfällen aus. Eine regionale Ressource kann aus mehreren Zonen erreichbar sein und zugleich von Infrastruktur in einer einzigen Zone abhängen. Prüfe ihre Redundanzeinstellung, um herauszufinden, ob sie einen Zonenausfall übersteht.

Auch beim Standort musst du den Datenfluss prüfen. Eine Datenbank kann in der gewählten Region laufen, während eine Sicherungs- oder Replikationsfunktion ihre Daten anderswohin kopiert. Georedundanter Speicher von Azure ist ein Beispiel. Prüfe, wohin die primären Daten, Sicherungen und Replikate gelangen, bevor du die Region als vollständige Grenze für die Datenresidenz betrachtest.

Prüfe das Angebot der Region

Dienstlisten und Preise unterscheiden sich je nach Region. Stelle sicher, dass die benötigte Datenbankfunktion, Maschinengröße und die gewünschten Optionen für Ausfallsicherheit verfügbar sind. Möglicherweise muss auch der Zugang für ein Konto aktiviert werden: AWS-Regionen, die nach dem 20. März 2019 eingeführt wurden, sind standardmäßig deaktiviert, und manche Azure-Regionen haben Zugangsbeschränkungen.

Angenommen, eine Maschine wurde in eu-west-1 erstellt, aber eine AWS-Ressourcenliste zeigt nun us-east-1 an. Die leere Liste bedeutet nicht, dass die Maschine gelöscht wurde. Wechsle zur Region, in der sie erstellt wurde, und prüfe das ausgewählte Konto und die Filter. Das Ändern der Ansicht lässt die Maschine weiterlaufen und die Kosten weiter anfallen.

Eine Verfügbarkeitszone ist eine isolierte Gruppe von einem oder mehreren Rechenzentren innerhalb einer Region. Ihre Stromversorgung, Kühlung und Netzwerkanbindung sind unabhängig von denen anderer Zonen. AWS und Azure nennen sie Availability Zone; Google Cloud nennt sie Zone.

Verstehe die physischen Ebenen

Ein Rechenzentrum ist ein Gebäude mit Servern und unterstützender Ausstattung. Eine Zone kann mehrere solcher Gebäude nutzen, und eine Region fasst Zonen zusammen. Wer eine Zone als genau ein Gebäude betrachtet, erhält ein falsches Bild von den Ausfallgrenzen des Anbieters.

Zonen liegen weit genug auseinander, um das gemeinsame Risiko durch einen lokalen Brand, ein Stromproblem oder eine Überschwemmung zu verringern, aber nahe genug für schnelle Kommunikation. AWS platziert Zonen innerhalb von etwa 100 km voneinander; Azure beschreibt Zonen als gewöhnlich höchstens 100 km voneinander entfernt und strebt für die Kommunikation einen Hin- und Rückweg von unter etwa 2 ms an. Schnelle Verbindungen machen synchrone Replikation praktikabel: Ein Schreibvorgang wird erst bestätigt, nachdem die erforderlichen Kopien über Zonen hinweg gespeichert wurden.

Ein großes regionales Ereignis kann dennoch mehrere Zonen betreffen. Mehrere Zonen schützen vor dem Ausfall einer Zone; eine zweite Region bietet einen separaten Standort für die Wiederherstellung nach einem regionalen Ausfall.

Lies Zonenkennungen

AWS hängt einen Buchstaben an einen Regionscode an, wie bei eu-central-1a. Google Cloud ergänzt einen Bindestrich und einen Buchstaben, wie bei europe-west4-a. Azure verwendet logische Zonennummern wie 1, 2 und 3.

Übereinstimmende Namen bei verschiedenen Kunden können täuschen. Azure-Zone 1 kann in verschiedenen Abonnements unterschiedlichen physischen Zonen zugeordnet sein. AWS ordnete Namen in seinen ältesten Regionen für Konten, die vor November 2025 erstellt wurden, unabhängig voneinander zu; neuere Konten nutzen eine einheitliche Zuordnung. Eine AWS-AZ-ID wie euc1-az1 bezeichnet über Konten hinweg dieselbe physische Zone. Teams, die die physische Platzierung abstimmen, vergleichen AZ-IDs oder dokumentierte Zuordnungen physischer Zonen.

AWS gibt an, dass jede Region mindestens drei Zonen hat. Viele Azure-Regionen haben drei, manche jedoch keine. Google-Cloud-Regionen haben mehrere Zonen. Prüfe die gewählte Region und die Zonenunterstützung des Dienstes gemeinsam.

Wähle den benötigten Schutz

Azure Storage zeigt, warum die Anzahl der Kopien allein nicht ausreicht. LRS hält drei lokale Kopien in einem Rechenzentrum vor. ZRS verteilt Kopien über drei Zonen. GRS ergänzt eine Kopie in einer zweiten Region für die Wiederherstellung. Drei Kopien in einem Gebäude teilen weiterhin dessen Risiken; die Platzierung in drei Zonen beseitigt diese besondere Abhängigkeit.

Anbieter staffeln Aktualisierungen über Zonen hinweg, um die Auswirkungen einer fehlerhaften Änderung zu begrenzen. Kopien können auch Übertragungskosten verursachen: Mit Stand Oktober 2026 berechnen AWS und Google Cloud viele zonenübergreifende Übertragungen, während Azure für Übertragungen zwischen Zonen innerhalb derselben Region keine Gebühren erhebt. Beim Vergleich einer vollständigen Lösung sind die dienstspezifischen Preise weiterhin wichtig.

Ein Edge-Standort oder Point of Presence (PoP) bringt ausgewählte Dienste nahe an die Nutzer. Diese Standorte bieten Caching und Netzwerkeinstiegspunkte. Sie bieten nicht den breiten Katalog an Rechen- und Datenbankdiensten einer Region. Anbieter haben Hunderte von Edge-Standorten, die weiter verteilt sind als ihre Regionen.

Verfolge eine Anfrage durch ein CDN

Ein Content Delivery Network (CDN) speichert wiederverwendbare Kopien in der Nähe der Leser. Amazon CloudFront, Azure Front Door und Google Cloud CDN sind Beispiele.

1. Das Routing sendet die Anfrage an einen geeigneten Edge-Standort. CloudFront verwendet DNS-basierte Auswahl; andere Dienste nutzen Anycast, bei dem mehrere Standorte dieselbe IP-Adresse bekannt geben, oder eine Kombination.
2. Der Standort prüft seinen Cache, einen Speicher für wiederverwendbare Inhalte.
3. Bei einem Cache-Treffer gibt er eine nutzbare gespeicherte Kopie zurück. Bei einem Cache-Fehltreffer ruft er das Objekt vom Ursprung ab, dem maßgeblichen Speicher oder Server.
4. Geeignete Inhalte bleiben für spätere Anfragen im Cache, abhängig von ihrer Gültigkeitsdauer (TTL) und den Cache-Regeln.

CloudFront nutzt außerdem größere regionale Edge-Caches zwischen vielen Edge-Standorten und dem Ursprung. Ein aus einem kleinen Cache verdrängtes Objekt kann dort noch verfügbar sein, sodass ein weiterer Zugriff auf den Ursprung entfällt.

Die Bilder einer Nachrichtenseite stammen aus Frankfurt. Ein Leser in São Paulo ist etwa 9.800 km Luftlinie entfernt. Selbst ein idealer Hin- und Rückweg über Glasfaser dauert etwa 98 ms, tatsächliche Wege dauern länger. Bei einem Cache-Fehltreffer muss der Inhalt weiterhin vom Ursprung abgerufen werden. Spätere Leser können das zwischengespeicherte Bild lokal innerhalb weniger Millisekunden erhalten.

Bilder, Videos, Skripte, Stylesheets und Downloads eignen sich gut, weil viele Menschen dieselben Bytes anfordern. Ein persönlicher Warenkorb benötigt normalerweise eine aktuelle Antwort vom Ursprung. Ein Edge-Standort kann die Verbindung verbessern, ohne dass sich jede Antwort zwischenspeichern lässt. Edge-Standorte können auch DNS-Anfragen beantworten, wie bei Route 53, oder Datenverkehr in ein Anbieter-Backbone aufnehmen, wie bei AWS Global Accelerator.

Unterscheide nahe gelegene Infrastrukturangebote

Azure Arc ergänzt eine Verwaltungsverbindung: Azure Resource Manager kann Server und Kubernetes-Cluster außerhalb von Azure verwalten, auch On-Premises und in anderen Clouds. Dadurch wird ein Kundengebäude nicht zu einer Azure-Region.

Verfolge zwischengespeicherte Daten über Grenzen hinweg

Ein globales CDN kann Inhalte in mehreren Ländern speichern. Eine Regel, die ausländische Betrachter blockiert, steuert den Zugriff des Publikums; sie legt nicht fest, wo Cache-Kopien oder Verarbeitung stattfinden. Inhalte mit einer strengen Landesgrenze benötigen ein CDN, das die zulässigen Standorte garantiert, oder einen Bereitstellungsweg, der die Zwischenspeicherung im Ausland vermeidet. Prüfe dies unabhängig von der Region des Ursprungs.

Hochverfügbarkeit bedeutet, Nutzer auch beim Ausfall von Komponenten weiter zu bedienen. Ein Single Point of Failure ist jede einzelne Abhängigkeit, deren Verlust die Anwendung stoppt. Zwei Webserver haben weiterhin einen gemeinsamen Single Point of Failure, wenn beide von einer ungeschützten Datenbank abhängen.

Schütze den gesamten Anfrageweg

Betreibe Anwendungsinstanzen in verschiedenen Zonen. Ein Load Balancer prüft ihren Zustand und sendet Anfragen an funktionsfähige Instanzen. Schütze auch die Datenebene mit einer zonenredundanten Datenbank oder einem synchronen Standby in einer anderen Zone, etwa einer Amazon-RDS-Multi-AZ-Konfiguration.

Halte Anwendungsinstanzen nach Möglichkeit zustandslos. Speichere die Sitzung eines Nutzers in einem gemeinsam genutzten, ausfallsicheren Datendienst statt nur im Arbeitsspeicher einer Instanz. Dann kann eine funktionsfähige Instanz in einer anderen Zone die nächste Anfrage beantworten, ohne dass der Warenkorb oder die Sitzung des Nutzers verloren geht.

Eine einzelne virtuelle Maschine bleibt in ihrer ausgewählten Zone. Wähle mehrere zonale Instanzen oder eine Dienstoption, die Zonenredundanz bietet.

Rechne Betriebszeit in Ausfallzeit um

Ein Jahr mit 365 Tagen hat 8.760 Stunden. Wandle die Verfügbarkeit in einen Anteil um, ziehe ihn von eins ab und multipliziere mit dem Zeitraum:

Bei 99,9 % beträgt der nicht verfügbare Anteil 0,001, die Ausfallzeit also 8,76 Stunden pro Jahr. Bei 99,95 % sind es 4,38 Stunden. Bei 99,99 % sind es etwa 52,6 Minuten. Diese Umrechnungen beschreiben einen Prozentsatz über den jeweiligen Zeitraum; eine tatsächliche Dienstvereinbarung legt außerdem fest, wie Verfügbarkeit gemessen wird.

Nimm für eine ideale Veranschaulichung an, dass jede von zwei Zonen die vollständige Anwendung betreiben kann, jede zu 99,9 % verfügbar ist und ihre Ausfälle unabhängig voneinander sind. Die Wahrscheinlichkeit, dass beide ausfallen, beträgt:

Die resultierende Verfügbarkeit beträgt 99,9999 %, also etwa 32 Sekunden jährliche Ausfallzeit. Gemeinsame Softwarefehler, Konfigurationsfehler und regionale Abhängigkeiten verletzen die Unabhängigkeitsannahme. Diese Berechnung erklärt den Nutzen von Redundanz; sie ist nicht die zugesicherte Betriebszeit der Anwendung.

Halte genügend verbleibende Kapazität vor

Ein Onlineshop benötigt bei Spitzenlast sechs Instanzen. Zwei Instanzen in jeder von drei Zonen ergeben normalerweise sechs, nach dem Ausfall einer Zone aber nur vier. Damit nach dem Verlust einer beliebigen Zone sechs verfügbar bleiben, muss jede der beiden verbleibenden Zonen drei Instanzen bereitstellen. Stelle insgesamt neun bereit.

Bei zwei Zonen muss jede alle sechs aufnehmen, sodass sich insgesamt 12 ergeben. Allgemein gilt bei gleicher Instanzzahl in allen Zonen:

Dabei ist $N$ die bei Spitzenlast benötigte Kapazität und $z$ die Anzahl der Zonen. Runde auf, weil eine Instanz eine ganze Einheit ist. Für zehn Instanzen über vier Zonen ergibt zehn geteilt durch drei aufgerundet vier pro Zone: insgesamt 16. Nach dem Verlust einer Zone bleiben 12, was ausreicht. Dieser Plan setzt voraus, dass die benötigte Kapazität bereits läuft; das Warten auf neue Instanzen schafft eine zusätzliche Abhängigkeit bei der Wiederherstellung.

Eine zweite Region unterstützt die Wiederherstellung nach einer regionalen Katastrophe. Sie kann auch entfernte Nutzer bedienen, länderspezifische Standortvorgaben erfüllen oder einen Dienst beziehungsweise Kapazität bieten, die in der ersten Region nicht verfügbar sind. Jeder dieser Gründe stellt andere Anforderungen an die Planung.

Lege zwei Wiederherstellungsziele fest

Das Wiederherstellungspunktziel (RPO) ist der maximal akzeptable Datenverlust, ausgedrückt als Zeitspanne. Das Wiederherstellungszeitziel (RTO) ist die maximal akzeptable Zeit bis zur Wiederherstellung des Dienstes. Eine Datensicherung kann aktuelle Daten bewahren, deren Wiederherstellung aber zu lange dauern; ein schneller Neustart kann dennoch zu viele Daten verlieren.

Ein Unternehmen kopiert seine nächtliche Datensicherung um 01:00 Uhr und verliert die Hauptregion um 17:00 Uhr. In der verfügbaren Wiederherstellungskopie fehlen 16 Stunden an Änderungen. Damit wird ein RPO von einer Stunde verfehlt. Häufiger abgeschlossene Sicherungen oder kontinuierliche Replikation sind nötig; ein Zeitplan hilft nur, wenn die Kopien den Wiederherstellungsstandort tatsächlich rechtzeitig erreichen.

Stimme die Bereitschaft auf die Wiederherstellungszeit ab

Mehr laufende Ressourcen vorzuhalten kostet gewöhnlich mehr und verringert den Wiederherstellungsaufwand. Sicherung und Wiederherstellung dauern häufig Stunden oder länger. Aktiv-Aktiv kann die Wiederherstellung in Sekunden bis Minuten ermöglichen, doch das Ergebnis hängt vom Aufbau der gesamten Anwendung ab.

Verstehe die Datenlücke

Zwischen Regionen erfolgt die Replikation gewöhnlich asynchron: Ein Schreibvorgang wird bestätigt, bevor die entfernte Kopie vollständig ist. Frankfurt und der Raum Washington, D.C. liegen etwa 6.500 km auseinander, sodass allein ein idealer Hin- und Rückweg über Glasfaser etwa 65 ms dauert. Bei jedem Schreibvorgang darauf zu warten, würde zusätzliche Verzögerung verursachen.

Der zeitliche Abstand zwischen den aktuellen Daten und der entfernten Kopie ist die Replikationsverzögerung. Sie kann bei hoher Last oder Netzwerkproblemen wachsen. Überwache sie im Hinblick auf das RPO. Eine zweite Region mit einem alten Replikat bietet geografische Trennung, ohne das Ziel für den Datenverlust zu erfüllen.

Nutze Azure-Paare richtig

Azure paart viele Regionen, etwa North Europe mit West Europe und East US mit West US. Die Paarung unterstützt zeitlich gestaffelte Plattformaktualisierungen, die Priorisierung bei der Wiederherstellung und die Georeplikation mancher Dienste. Die meisten Paare bleiben innerhalb eines geografischen Gebiets. Brazil South ist eine Ausnahme: Die Partnerregion ist South Central US.

Ein Paar stellt weder eine Anwendungskopie bereit noch organisiert es alle Failover-Schritte. Viele neuere Azure-Regionen haben kein Paar, und Kunden können eine andere zulässige sekundäre Region wählen. Prüfe das Replikationsverhalten jedes Dienstes.

Globales Routing kann Nutzer über Route 53, Azure Front Door oder die globale Lastverteilung von Google Cloud zu funktionsfähigen Regionen leiten. Plane Kosten für doppelte Ressourcen und regionsübergreifende Übertragungen ein und teste den vollständigen Wiederherstellungsweg einschließlich Kontingenten und manuellen Schritten. Müssen Daten in einem Land mit nur einer Region bleiben, nutze dessen Zonen und lokale Wiederherstellungsmöglichkeiten; eine Kopie im Ausland würde gegen die Standortvorgabe verstoßen.

Latenz ist die Verzögerung auf dem Übertragungsweg. Die Paketumlaufzeit (RTT) misst die Zeit für eine Anfrage und ihre Antwort, gewöhnlich in Millisekunden. Die Bandbreite misst, wie viele Daten eine Verbindung pro Sekunde überträgt. Mehr Bandbreite hilft bei der Übertragung einer großen Datei, kann aber die Laufzeit zu einer entfernten Region nicht beseitigen.

Schätze das physikalische Minimum ab

Licht bewegt sich durch Glasfaser mit ungefähr 200.000 km/s. Jeder Kilometer fügt in eine Richtung etwa 5 Mikrosekunden hinzu. Um eine minimale RTT abzuschätzen, verdopple die Entfernung für den Hin- und Rückweg, dividiere durch diese Geschwindigkeit und rechne dann Sekunden in Millisekunden um:

Das ergibt etwa 1 ms pro 100 km. Die Luftlinienentfernung ist eine untere Schranke: Tatsächliche Kabel nehmen längere Wege, und Router, Warteschlangen und Verarbeitung verursachen zusätzliche Verzögerungen.

Für Nutzer in Sydney liegt Singapur etwa 6.300 km entfernt. Verdoppelt ergibt das 12.600 km. Die Division durch 200.000 ergibt 0,063 Sekunden oder etwa 63 ms. Northern Virginia liegt etwa 15.700 km entfernt, was mindestens etwa 157 ms ergibt. Eine Region in Sydney kann die Laufzeit auf wenige Millisekunden verringern.

Zähle wiederholte Wege

Eine Verzögerung kann gering erscheinen, bis eine Aufgabe sie wiederholt. Angenommen, der Aufbau einer Verbindung und der Erhalt einer ersten Antwort benötigen vier aufeinanderfolgende Hin- und Rückwege. Bei je 157 ms beträgt der Anteil für die Übertragung 628 ms. Bei je 5 ms sind es 20 ms. Die genaue Anzahl der Wege hängt von der Wiederverwendung der Verbindung und dem Verhalten des Protokolls ab; zähle die Wege, die die Workload tatsächlich zurücklegt.

Derselbe Effekt tritt zwischen Anwendungsteilen auf. Eine Seite führt 50 Datenbankabfragen nacheinander aus. Fügt jede entfernte Abfrage 15 ms hinzu, verlängert die Folge die Zeit um 750 ms. Bei 1 ms innerhalb derselben Region sind es 50 ms. Das sind die Kommunikationszeiten der Abfragen; die Datenbankarbeit kann zusätzliche Zeit beanspruchen. Wenn häufig miteinander kommunizierende Komponenten zusammengehalten werden, fällt der Zeitnachteil durch die Entfernung nicht wiederholt an.

Wähle die passende Änderung

Ein Edge-Cache hilft, wenn er die Anfrage beantworten kann. Er kann eine nicht zwischengespeicherte Datenbanktransaktion nicht für jeden Nutzer lokal machen. Ebenso lässt eine Erhöhung der Bandbreite die Entfernung zum Ursprung unverändert.

Miss von tatsächlichen Nutzerstandorten aus

Netzwerkwege folgen verfügbaren Verbindungen, Peering und Verkehrsbedingungen, nicht der kürzesten Linie auf einer Karte. Vergleiche gemessene RTTs oder Antwortzeiten der Anwendung von den Orten aus, an denen Nutzer sich tatsächlich verbinden. Teste repräsentative Zeiten und Anfragen, bevor du dich für eine Region entscheidest. Eine nahe Region ist eine aussichtsreiche Kandidatin; Messungen zeigen, ob ihr tatsächlicher Netzwerkweg für die Workload gut geeignet ist.

Eine sinnvolle Regionswahl beginnt mit der Workload: Wer nutzt sie, welche Dienste benötigt sie, wohin dürfen ihre Daten gelangen und wie muss sie wiederhergestellt werden? Vergleicht man Regionen ohne diese Anforderungen, erhält man möglicherweise einen niedrigen Preis für einen Standort, an dem die Anwendung nicht laufen kann.

Filtere vor der Bewertung

Sechs Faktoren sind häufig wichtig: Compliance und Datenresidenz, Latenz für Nutzer, Verfügbarkeit von Diensten und Funktionen, Preis, Möglichkeiten zur Ausfallsicherheit und Nachhaltigkeit. Trenne Muss-Anforderungen von Präferenzen. Eine Beschränkung auf ein Land oder ein fehlender unverzichtbarer Dienst schließt eine Region aus. Ein guter Preis kann das Nichterfüllen dieser Anforderung nicht ausgleichen.

Wähle für die verbleibenden Regionen eine einheitliche Bewertungsskala und Gewichte, die zusammen 100 % ergeben. Höhere Bewertungen sollten immer eine bessere Eignung bedeuten, also auch eine höhere Preisbewertung für geringere Kosten. Multipliziere jede Bewertung mit ihrem Gewicht und addiere die Ergebnisse.

Arbeite eine Entscheidung durch

Ein Unternehmen in Deutschland verlangt die Speicherung seiner Daten in der EU. Es streicht eine US-Region, bevor es zwei zulässige Kandidaten vergleicht. Die Bewertungen reichen von 1 bis 5, wobei 5 am besten ist.

Das Unternehmen gewichtet die Latenz mit 50 %, den Preis mit 30 % und die Dienste mit 20 %:

B liegt knapp vorn. Für eine Handelsanzeige ändert das Unternehmen die Gewichte auf 70 %, 20 % und 10 %:

Die Empfehlung ändert sich, weil sich die Priorität des Unternehmens geändert hat. Gib die Gewichte und die Belege für die Bewertungen an, damit eine andere Person die Wahl nachvollziehen kann. Eine genau aussehende Gesamtbewertung ist nur so nützlich wie diese Grundlagen.

Berechne die Kosten der gesamten Lösung

Die Preise für Rechenleistung unterscheiden sich je nach Region aufgrund von Energie, Grundstücken, Nachfrage und anderen lokalen Kosten. Beziehe Speicher, Sicherungen, Kapazität in einer zweiten Region und Datenübertragungen in den Vergleich ein. Übertragungen zwischen Regionen und ins Internet werden häufig berechnet; eingehende Daten sind gewöhnlich kostenlos. Werden datenintensive Anwendungsteile in verschiedenen Regionen platziert, kann dies eine kleine Ersparnis bei der Rechenleistung zunichtemachen.

Für Ausfallsicherheit musst du die Zonenunterstützung und einen zulässigen Wiederherstellungsstandort prüfen. Für Nachhaltigkeit musst du den in der Region genutzten Strom betrachten; Anbieter veröffentlichen Kennzahlen wie den regionalen Anteil CO₂-freier Energie bei Google Cloud. Sauberer Strom kann den Fußabdruck derselben Workload verringern.

Teste schließlich die führenden Regionen mit tatsächlichen Latenzmessungen und dem Preisrechner des Anbieters. Halte den gewählten Standort, Muss-Anforderungen, Gewichte und Gründe fest. Die Migration von Ressourcen und gespeicherten Daten ist aufwendig. Überprüfe die Wahl daher erneut, wenn sich Nutzerstandorte, Gesetze, Dienste oder die regionale Präsenz des Anbieters ändern.

Datenresidenz beschreibt, wo Daten gespeichert und verarbeitet werden. Datenlokalisierung ist eine gesetzliche Anforderung, bestimmte Daten innerhalb eines Landes zu halten. Datensouveränität betrifft die Gesetze und Behörden, die für Daten maßgeblich sein können, auch über das Unternehmen, das sie innehat. Lokale Speicherung und rechtliche Kontrolle hängen zusammen, beantworten aber unterschiedliche Fragen.

Verfolge mehr als nur die Datenbank

Eine Datenbank in Azure germanywestcentral legt ihren primären Speicher in Deutschland an. Untersuche auch Sicherungen, Replikate, Protokolle, Supportzugriffe, globale Identitätsdienste und CDN-Caches. Jeder dieser Punkte kann einen weiteren Standort ins Spiel bringen. Microsofts EU Data Boundary, die im Februar 2025 fertiggestellt wurde, ergänzt Zusagen zur Speicherung und Verarbeitung in der EU und EFTA für erfasste Dienste und Daten, mit dokumentiertem Geltungsbereich und Ausnahmen.

Eine wirksame Prüfung fragt sowohl, wohin jede Kopie gelangt, als auch, welche Organisation Zugriff erhalten kann. Richtlinien können Ressourcenstandorte einschränken; vom Kunden kontrollierte Verschlüsselungsschlüssel und Kontrollen für Supportzugriffe befassen sich mit anderen Teilen des Problems. Eine einzelne Maßnahme kann nicht jede Frage beantworten.

Wende die Übermittlungsregeln der DSGVO an

Die Datenschutz-Grundverordnung (DSGVO) gilt für die Verarbeitung innerhalb ihres räumlichen Geltungsbereichs. Dazu gehören Niederlassungen im EWR und bestimmte Organisationen im Ausland, die Menschen in der EU Waren oder Dienstleistungen anbieten oder sie beobachten. Der EWR umfasst die EU, Island, Liechtenstein und Norwegen. Die DSGVO erlaubt eine Speicherung im Ausland, wenn die jeweils geltenden Bedingungen erfüllt sind; sie schreibt keine allgemeine Speicherung ausschließlich im EWR vor.

Für eine Übermittlung an einen eigenständigen Empfänger außerhalb des EWR sieht Kapitel V diese Wege vor:

Japan, das Vereinigte Königreich und die Schweiz sind Beispiele für Zielländer mit einem Angemessenheitsbeschluss. Das am 10. Juli 2023 angenommene EU–US Data Privacy Framework (DPF) gilt für teilnehmende zertifizierte US-Organisationen. Es ersetzte den früheren Privacy Shield, der am 16. Juli 2020 im Urteil Schrems II für ungültig erklärt wurde. Das Gericht der Europäischen Union wies im September 2025 eine Klage gegen das DPF ab; im Oktober 2026 war ein Rechtsmittel anhängig. Für eine Übermittlungsentscheidung sind der aktuelle Status des Rahmens und die Zertifizierung des Empfängers zu prüfen.

Unterscheide Zugriff und Speicherung

Werden Daten aus dem EWR einer eigenständigen Supportorganisation außerhalb des EWR zugänglich gemacht, kann dies eine Übermittlung sein, selbst wenn die Datenbank vor Ort bleibt. Der Europäische Datenschutzausschuss (EDPB) unterscheidet dies vom Zugriff eines Mitarbeiters desselben Verantwortlichen auf Daten während eines Auslandsaufenthalts; dies ist keine Übermittlung an einen anderen Empfänger nach Kapitel V. Die Verarbeitung benötigt weiterhin angemessenen Schutz.

Der US-amerikanische CLOUD Act von 2018 kann Anbieter, die der US-Gerichtsbarkeit unterliegen, im Rahmen eines anwendbaren Rechtsverfahrens zur Herausgabe von Daten in ihrem Besitz, Gewahrsam oder unter ihrer Kontrolle verpflichten, einschließlich im Ausland gespeicherter Daten. Die Adresse eines Servers allein kann daher die Frage der Souveränität nicht klären.

Eine niederländische Klinik, die einen Anbieter mit Sitz in den USA nutzt, wählt eine EU-Region, erfasst Empfänger und Supportdatenflüsse im Ausland, prüft den anwendbaren Weg über das DPF oder SCCs und verwaltet Verschlüsselungsschlüssel und Richtlinien für zulässige Standorte. Sie dokumentiert diese Entscheidungen neben ihren übrigen Datenschutzpflichten. Andere Länder und Verträge bringen eigene Beschränkungen mit sich, insbesondere für Gesundheits-, Finanz- und Regierungsdaten.

Eine souveräne Cloud ergänzt Kontrollen über Daten, Betrieb und die Abhängigkeit von globalen Systemen, um die Anforderungen eines Rechtsraums zu erfüllen. Eine normale Region im richtigen Land bietet eine Standortwahl. Ein souveränes Angebot kann außerdem ändern, wer den Dienst betreibt und wie unabhängig er laufen kann.

Stelle drei unterschiedliche Fragen

Datensouveränität fragt, wo Daten vorgehalten werden und wer den Zugriff und die Verschlüsselungsschlüssel kontrolliert. Operative Souveränität fragt, wer den Dienst verwaltet und unterstützt und wo diese Personen arbeiten. Technische Souveränität fragt, ob die Umgebung ohne die globalen Systeme des Anbieters betrieben werden kann. Bewerte jede Dimension anhand der tatsächlichen rechtlichen, vertraglichen oder sicherheitsbezogenen Anforderung.

Vergleiche separate Umgebungen

Regierungsumgebungen unterstützen Programme wie FedRAMP, wobei sich der Umfang je nach Dienst unterscheidet und Kunden Verantwortung tragen. Die Umgebungen in China sind von den globalen Diensten getrennt und erfordern die passenden Konten und Endpunkte. Separate Cloud-Partitionen haben eigene Identitäts- und API-Grenzen; eine Anmeldung bei der globalen Cloud erreicht ihre Ressourcen nicht automatisch.

Ermittle die Stufe des europäischen Angebots

Mit Stand Oktober 2026 ist die AWS European Sovereign Cloud verfügbar; ihre erste Region wurde im Januar 2026 in Brandenburg eröffnet. Sie ist physisch und logisch von anderen AWS-Regionen getrennt und wird in der EU von EU-Einwohnern unter in Deutschland eingetragenen Unternehmen betrieben.

Microsoft Sovereign Cloud umfasst Sovereign-Public-Cloud-Kontrollen in öffentlichen Regionen, Sovereign Private Cloud mit Azure Local am Standort eines Kunden und nationale Partnerclouds wie Bleu in Frankreich und Delos Cloud in Deutschland. Diese Angebote unterscheiden sich in ihrer Betriebsorganisation.

Das Angebot von Google Cloud umfasst Data Boundary-Kontrollen innerhalb der Public Cloud, Dedicated-Angebote auf separater partnerbetriebener Infrastruktur und Air-Gapped-Umgebungen auf Basis von Google Distributed Cloud, die getrennt von Google und dem Internet laufen. S3NS in Frankreich und das Thales-Angebot in Deutschland veranschaulichen den Ansatz mit lokalem Partner. Aus Produktnamen allein geht nicht hervor, welche Dienste, Standorte oder Unabhängigkeitszusagen ein Vertrag umfasst.

Wähle ausreichend Kontrolle, ohne benötigte Funktionen zu verlieren

Ein Händler kann seine Anforderungen möglicherweise mit einer gewöhnlichen EU-Region, Garantien für Übermittlungen und kundenverwalteten Schlüsseln erfüllen. Eine Behörde mit einer nationalen Qualifizierungsanforderung prüft, ob ein bestimmtes Partner- oder souveränes Angebot diese Qualifizierung für die benötigten Dienste besitzt. Für klassifizierte Offline-Arbeit kann eine vollständig isolierte Umgebung nötig sein.

Strengere Isolation kann die Dienstauswahl verringern, neue Funktionen verzögern, Kosten erhöhen und weniger Wiederherstellungsregionen übrig lassen. Vergleiche den tatsächlichen Dienstkatalog, die Zugangsberechtigung, Betriebszusagen und zulässigen Wiederherstellungsstandorte. Die Bezeichnung „souverän“ allein bedeutet keine Immunität gegen jedes ausländische Gesetz.

Anbieter platzieren bereitgestellte Dienstressourcen in Verwaltungscontainern. Diese Container trennen Kosten, Zugriff und Dienstlimits. Ihre Namen unterscheiden sich: Ein AWS-Konto, ein Azure-Abonnement und ein Google-Cloud-Projekt übernehmen weitgehend vergleichbare Rollen.

Unterscheide einen Container von einer Person

Eine Person kann auf mehrere Container zugreifen und ein Container kann vielen Personen dienen. Durch die Freigabe des Zugriffs wird eine Ressource nicht in einem zweiten Container platziert. Gibt man beispielsweise einem Analysten die Berechtigung, einen Datensatz in einem anderen Projekt abzufragen, verbleibt der Datensatz in seinem ursprünglichen Projekt.

Ein AWS-Konto hat eine 12-stellige Konto-ID. Sein Root-Benutzer ist mit der E-Mail-Adresse verknüpft, mit der das Konto erstellt wurde, und hat weitreichende Rechte. Schütze ihn mit Mehrfaktorauthentifizierung und verwende ihn nur für Aufgaben, die Root-Zugriff erfordern. Für die tägliche Arbeit werden normalerweise Rollen und andere autorisierte Identitäten genutzt. Eine Konto-ID bezeichnet eine Ressourcengrenze, keinen namentlich genannten Mitarbeiter.

Verstehe die Verzeichnisbeziehung in Azure

Ein Microsoft-Entra-Mandant ist das Identitätsverzeichnis einer Organisation. Ein Abonnement bildet eine Grenze für Ressourcenverwaltung und Abrechnung und vertraut genau einem Mandanten. Ein Mandant kann viele Abonnements unterstützen. Eine angemeldete Person kann in einigen davon Berechtigungen haben und in anderen keine.

Der Ausdruck „Azure-Konto“ kann sich auf eine Anmeldeidentität oder eine Abrechnungsvereinbarung beziehen und ist daher zu ungenau, wenn es darum geht, wohin eine virtuelle Maschine gehört. Bestimme Abonnement und Mandant getrennt.

Lies Google-Cloud-Projektkennungen

Ein Projekt hat einen Anzeige-Namen, eine dauerhafte Projekt-ID und eine vom Anbieter vergebene Projektnummer. Der Name kann geändert werden und muss nicht eindeutig sein. Die ID ist weltweit eindeutig und kann nach dem Erstellen nicht geändert werden. Sie besteht aus 6–30 Kleinbuchstaben, Ziffern oder Bindestrichen, beginnt mit einem Buchstaben und darf nicht mit einem Bindestrich enden. Beispielsweise ist lumen-shop-prod eine Projekt-ID, während „Lumen Shop Production“ ihr Anzeigename sein kann.

Projekte organisieren bereitgestellte Dienste, während Organisations- und Ordnerressourcen darüber die Projekte organisieren. Die Abrechnung wird separat verknüpft, sodass mehrere Projekte ein Abrechnungskonto teilen können, ohne zu einem Projekt zu werden.

Teile die Arbeit in sinnvolle Bereiche auf

Ein Unternehmen trennt seinen Shop in Entwicklung, Test und Produktion. Es verwendet drei AWS-Konten, drei Azure-Abonnements oder drei Google-Cloud-Projekte. Jede Umgebung erhält einen eigenen Berechtigungsbereich und eine eigene Kostenübersicht. Die Trennung begrenzt den Schaden, den ein Fehler in der Entwicklung verursachen kann, wenn die Berechtigungen entsprechend konfiguriert sind.

Container haben außerdem Kontingente, etwa regionale Limits für virtuelle CPUs. Neue Container können mit niedrigen Kontingenten beginnen, und viele Limits lassen sich auf Anfrage erhöhen. Eine Wiederherstellungsumgebung benötigt ausreichende Kontingente, bevor ein Ausfall eintritt; eine funktionierende Vorlage allein reserviert weder Kapazität noch erhöht sie diese Limits.

Teams teilen Container häufig nach Umgebung, Abteilung oder Produkt auf, damit Kosten und Zugriffe nachvollziehbar bleiben. Die geografische Platzierung ist eine separate Entscheidung: Ein Container kann Ressourcen in mehreren Regionen enthalten.

Ressourcen, die gemeinsam erstellt, geändert und entfernt werden, teilen einen Lebenszyklus. Azure-Ressourcengruppen machen diesen Lebenszyklus zu einer Verwaltungsgrenze. Tags und Labels ergänzen durchsuchbare Beschreibungen für Ressourcen, ohne deren physische Platzierung zu ändern.

Nutze Azure-Ressourcengruppen

Für gewöhnliche bereitgestellte Azure-Dienstressourcen liegt eine Ressourcengruppe innerhalb eines Abonnements. Jede solche Ressource gehört zu einer Gruppe; Gruppen können keine anderen Gruppen enthalten. Ressourcen auf Abonnementebene und Verwaltungsobjekte existieren in höheren Bereichen, sodass die Hierarchie auch Objekte außerhalb von Ressourcengruppen enthält.

Eine Gruppe hat einen Standort für ihre Metadaten, also die Einträge, die die Gruppe und ihre Ressourcen beschreiben. Dieser Standort zwingt nicht jedes Mitglied in dieselbe Region. Ein Webserver in einer Region und seine Wiederherstellungsressource in einer anderen können einer Gruppe angehören.

Das Löschen einer Ressourcengruppe löscht ihren Inhalt. Das ist für vorübergehende Arbeiten praktisch und gefährlich, wenn nicht zugehörige Produktionsressourcen enthalten sind. Eine Löschsperre kann versehentliches Löschen verhindern, bis eine berechtigte Person sie entfernt. Wähle eine Gruppe, deren Mitglieder Entscheidungen über Erstellung, Zugriff und Stilllegung gefahrlos teilen können.

Dieser Azure-CLI-Befehl erstellt beispielsweise eine Gruppe für den Produktionsshop:

az group create --name rg-shop-prod-weu --location westeurope

Eine separate Gruppe rg-shop-test enthält eine entbehrliche Testumgebung. Wird diese Testgruppe entfernt, wird ihr Inhalt gemeinsam gelöscht. Die Produktionsgruppe bleibt getrennt. Das Muster im Namen bezeichnet Ressourcentyp, Anwendung, Umgebung und Standort und erleichtert so das Überfliegen von Listen.

Auf Gruppenebene zugewiesener Zugriff, etwa Reader, gilt für die Ressourcen der Gruppe. Viele Ressourcentypen können vorbehaltlich dienstspezifischer Einschränkungen zwischen Gruppen oder Abonnements verschoben werden. Eine solche Verschiebung ändert die Zuordnung für die Verwaltung; sie migriert eine Ressource nicht in eine andere Region.

Vergleiche die Gruppierung bei AWS

AWS Resource Groups können Ressourcen anhand übereinstimmender Tags oder eines CloudFormation-Stacks zusammenfassen. Eine Ressource kann in mehreren solchen Gruppen erscheinen. Das Löschen einer AWS Resource Group entfernt die Gruppierung, während ihre Ressourcen bestehen bleiben. Das unterscheidet sich vom erforderlichen Azure-Lebenszykluscontainer für gewöhnliche bereitgestellte Ressourcen. In Google Cloud bilden Projekte die wichtigste Gruppierungsgrenze für Dienstressourcen.

Ergänze nützliche Tags und Labels

Tags in AWS und Azure und Labels in Google Cloud weisen Schlüssel-Wert-Beschreibungen zu. Beispiele sind environment=prod, cost-center=4120 und owner=web-team. Sie helfen, Bestandslisten und Kostenberichte zu filtern oder Ressourcen für die Automatisierung auszuwählen.

Verwende vereinbarte Schlüssel und Werte. Schreibt ein Team „prod“ und ein anderes „Prod“, kann ein Bericht Ressourcen getrennt ausweisen, die zusammengehören. Tags einer Azure-Ressourcengruppe werden standardmäßig nicht an ihre Ressourcen weitergegeben; eine Richtlinie oder Automatisierung kann die vorgesehenen Werte anwenden.

Ein Tag ist beschreibende Metadateninformation. Ein Label mit der Aufschrift „privat“ isoliert keinen Netzwerkverkehr, und eine Gruppe namens „Europa“ verschiebt ihre Ressourcen nicht dorthin. Zugriffsvorschriften, Netzwerke und Regionseinstellungen übernehmen diese Steuerung.

Eine Verwaltungshierarchie ordnet Container in einer Baumstruktur. Übergeordnete Bereiche ermöglichen einer Organisation, viele Konten, Abonnements oder Projekte gemeinsam zu verwalten. Vererbung bedeutet, dass anwendbare Einstellungen einer übergeordneten Ebene an ihre untergeordneten Elemente weitergegeben werden.

Vergleiche die Baumstrukturen der Anbieter

Azure gibt jedem Mandanten eine Stammverwaltungsgruppe, die standardmäßig „Tenant root group“ heißt. Verwaltungsgruppen können sechs Ebenen tief verschachtelt werden, ohne die Stammgruppe und die Abonnementebene mitzuzählen. Jede Verwaltungsgruppe und jedes Abonnement hat genau ein übergeordnetes Element.

AWS Organizations hat ein Verwaltungskonto, das die Organisation erstellt und konsolidierte Rechnungen bezahlt. Organisationseinheiten (OUs) gruppieren Konten und können fünf Ebenen unterhalb des Stamms verschachtelt werden. Ein Konto gehört jeweils zu einer Organisation. Das Verwaltungskonto hat eine eigene Rolle und wird nicht durch die Service-Kontrollrichtlinien der Organisation gesteuert.

Die Organisation von Google Cloud ist mit der Domain des Unternehmens verknüpft. Ordner setzen eine Organisation voraus und können verschachtelte Ordner enthalten. Ein Lernender, der eine kostenlose Testversion nutzt, kann ein Projekt ohne Organisation haben.

Verfolge eine vererbte Regel

Ein Unternehmen trennt Retail und Logistics, jeweils mit Produktion und Entwicklung. Azure nutzt Verwaltungsgruppen für die Abteilungen mit darunterliegenden Abonnements. AWS nutzt Abteilungs-OUs mit darunterliegenden Konten. Google Cloud nutzt Abteilungsordner mit darunterliegenden Projekten.

Erlaubt eine Azure-Verwaltungsgruppenrichtlinie Bereitstellungen nur in EU-Regionen, erben darunterliegende Abonnements diese Einschränkung. Der Gruppenname ist lediglich eine Bezeichnung; die Richtlinie setzt die Standortregel durch. Bei AWS kann die Service-Kontrollrichtlinie (SCP) einer OU eine maximale Berechtigungsgrenze für Mitgliedskonten festlegen. Eine SCP selbst gewährt einem Benutzer keine Berechtigung, in diesen Konten zu arbeiten.

Verstehe vererbten Zugriff

Bei der rollenbasierten Zugriffssteuerung von Azure und den IAM-Zulassungsrichtlinien von Google Cloud addieren sich Gewährungen über Bereiche hinweg. Eine Gewährung von Leserechten auf einer untergeordneten Ebene hebt den von einer übergeordneten Ebene geerbten Schreibzugriff nicht auf. Um diesen weitreichenden Zugriff zu entfernen, ändere den Bereich, in dem er gewährt wird, oder nutze eine geeignete Verweigerungsmaßnahme.

Azure Policy kann nicht konforme Ressourcenkonfigurationen wie einen verbotenen Standort ablehnen. Dies ist getrennt von den Rollenzuweisungen, die Zugriff gewähren. Google-Cloud-Verweigerungsrichtlinien können bestimmte Berechtigungen blockieren. Richtlinien von AWS Organizations unterscheiden sich ebenfalls von Kontozugriffsgewährungen; IAM Identity Center kann Berechtigungssätze über mehrere Konten hinweg zuweisen.

Ein Prüfungsteam, dem an der Spitze einer Azure- oder Google-Cloud-Hierarchie geeigneter Lesezugriff gewährt wird, kann Ressourcen in den darunterliegenden Abteilungen lesen. Die Zugehörigkeit zu einer AWS-OU allein gibt diesem Team keinen Kontozugriff.

Trenne Baumstruktur und geografische Karte

Das Verschieben eines Abonnements oder Projekts ändert seine vererbten Richtlinien und Zugriffe. Die Ressourcen bleiben in ihren bestehenden Regionen. Prüfe vor einer Verschiebung die wirksamen Regeln des neuen Zweigs: Eine logische Neuorganisation kann die Berechtigungen vieler Personen beeinflussen, ohne einen einzigen Server zu verschieben.

Eine Schaltfläche im Browser, ein Befehl und ein Programm können alle denselben Cloud-Vorgang anfordern. Jedes sendet eine authentifizierte Anfrage an eine Programmierschnittstelle (API). Die Schnittstelle verändert die Arbeitsweise einer Person oder Anwendung; Berechtigungen und Dienstlimits gelten weiterhin.

Stimme die Schnittstelle auf die Aufgabe ab

Die grafischen Werkzeuge sind die AWS Management Console, das Azure-Portal und die Google-Cloud-Konsole. Die wichtigsten CLI-Programme sind aws, az und gcloud. Azure PowerShell und AWS Tools for PowerShell bieten eine weitere Art von Befehlen. Mobile Apps eignen sich für Statusprüfungen und Warnungen.

Beispielsweise listet aws ec2 describe-instances --region eu-central-1 EC2-Instanzen in Frankfurt auf. az group list listet Azure-Ressourcengruppen und gcloud compute zones list Google-Cloud-Zonen auf. Dies sind API-Clients, keine getrennten Ressourcenbestände.

AWS CloudShell, Azure Cloud Shell und Google Cloud Shell stellen die jeweilige CLI in einem Browser bereit. Sie verringern den Installationsaufwand und nutzen den angemeldeten Cloud-Kontext. Du musst weiterhin prüfen, auf welches Konto, Abonnement oder Projekt die Sitzung ausgerichtet ist.

Folge dem richtigen API-Weg

In Azure erstellen, ändern oder löschen Vorgänge der Steuerungsebene Ressourcen über Azure Resource Manager. Dieser wendet Autorisierung und Richtlinien auf Ressourcenverwaltungsanfragen an. Vorgänge der Datenebene nutzen den eigenen Endpunkt des Dienstes, etwa beim Hochladen einer Datei in ein bestehendes Speicherkonto. Ein Programm kann beide Arten von Vorgängen über verschiedene Clients ausführen.

SDKs unterstützen Sprachen wie Python, JavaScript, Java, C# und Go. Sie helfen beim Signieren von Anfragen, bei Dienstaufrufen und bei erneuten Versuchen nach vorübergehenden Fehlern. Eine Webanwendung nutzt ein SDK, wenn jeder Upload eines Nutzers einen Speichervorgang auslösen muss; dafür muss keine Person die Konsole bedienen.

Prüfe den Zielkontext

Standardwerte können unbemerkt das falsche Ziel auswählen. Die AWS-Konfiguration kann eine Standardregion festlegen. Die Google-Cloud-Konfiguration kann ein Projekt und eine Region für Rechenressourcen auswählen, zum Beispiel mit gcloud config set project lumen-shop-prod und gcloud config set compute/region europe-west4.

Azure verwendet ein ausgewähltes Abonnement, während Befehle zum Erstellen von Ressourcen ihre dokumentierten Standortparameter oder Standardwerte nutzen. Der Metadatenstandort einer Ressourcengruppe legt nicht generell den Standort jeder Ressource fest. Prüfe das Ziel des Befehls, bevor du ihn ausführst.

Verwende nach Möglichkeit kurzlebige Zugangsdaten wie Rollen oder angemeldete Sitzungen. Halte Zugriffsschlüssel aus Quellcode und gemeinsam genutzten Dokumenten heraus. Der Wechsel von der Konsole zu einer CLI umgeht keine Zugriffskontrollen: Ein verweigerter API-Vorgang bleibt verweigert, unabhängig davon, welcher Client ihn sendet.

Eine einzelne temporäre Ressource von Hand zu erstellen, kann praktisch sein. Um dieselbe Umgebung für Test, Produktion und Wiederherstellung neu aufzubauen, ist ein Prozess nötig, der kleine Unterschiede durch wiederholte Klicks vermeidet. Infrastructure as Code (IaC) speichert die Ressourcenbeschreibung in Textdateien und verwendet ein Bereitstellungswerkzeug, um die Umgebung zu erstellen oder zu aktualisieren.

Beschreibe einen Zustand oder eine Abfolge

Eine deklarative Vorlage gibt an, was vorhanden sein soll, etwa zwei virtuelle Maschinen mit gewählter Größe und gewähltem Standort. Das Bereitstellungswerkzeug vergleicht diesen Sollzustand mit der aktuellen Umgebung und ermittelt die Änderungen. Ein imperatives Skript listet Aktionen der Reihe nach auf, etwa „Erstelle die Gruppe und dann die Maschinen“.

Ein Stack gruppiert die Ressourcen, die von einer CloudFormation-Bereitstellung verwaltet werden. Parameterwerte ermöglichen es einem Team, eine Vorlage für verschiedene Standorte oder Größen wiederzuverwenden, ohne mehrere Dateikopien zu pflegen.

Verwende eine getestete Umgebung erneut

Ein Team hat eine in Frankfurt, eu-central-1, getestete Webshop-Vorlage. Um seine Wiederherstellungsinfrastruktur in Irland vorzubereiten, gibt es eu-west-1 als Regionsparameter an. Für Tests gibt es eine kleinere Maschinengröße an. Die Versionsverwaltung zeichnet die Vorlage und ihre überprüften Änderungen auf und macht so die vorgesehene Konfiguration für das Team sichtbar.

Die Wiederverwendung von Infrastrukturcode kopiert nicht die aktuellen Daten der Anwendung. Diese Daten werden weiterhin durch Sicherungen oder Replikation bereitgestellt, und die gewählte Wiederherstellungsregion muss weiterhin die benötigten Dienste, Berechtigungen und Kontingente bieten sowie rechtlich geeignet sein. Vorlagen machen den Aufbau einheitlicher Infrastruktur wiederholbar; der vollständige Wiederherstellungsplan umfasst diese weiteren Abhängigkeiten.

Wende Änderungen einheitlich an

Ein idempotenter Vorgang kann wiederholt werden, ohne nach Erreichen seines vorgesehenen Ergebnisses eine weitere Änderung hinzuzufügen. Bei unveränderter Konfiguration, unveränderten Eingaben und Ressourcen sollte eine deklarative Bereitstellung, die den Sollzustand erreicht hat, keine weiteren Infrastrukturänderungen erzeugen. Ein Skript, das nur aus Erstellungsbefehlen besteht, kann bei erneuter Ausführung fehlschlagen oder Duplikate erzeugen.

Konfigurationsdrift ist eine Abweichung zwischen der deklarierten Konfiguration und den laufenden Ressourcen. Jemand könnte in der Konsole eine Maschinengröße erhöhen, ohne die Vorlage zu aktualisieren. Die Drifterkennung von CloudFormation oder ein terraform plan können helfen, solche Unterschiede zu erkennen. Ein Terraform-Plan zeigt vorgeschlagene Änderungen; prüfe sie, bevor du sie anwendest.

IaC macht Änderungen überprüfbar, bewahrt ihren Verlauf und hilft beim Neuaufbau verlorener Umgebungen. Es erfordert auch, die Dateien zu pflegen und das Werkzeug zu verstehen. Nutze die manuelle Schnittstelle für eine einmalige Erkundung und überführe anschließend dauerhafte, wiederholte Umgebungsänderungen in Code, damit die überprüfte Beschreibung aktuell bleibt.