AWS GovCloud vs. Commercial Cloud: Eine Aufschlüsselung nach dem Ostküsten-Zusammenbruch

Am Montag hatte ein Teil des Internets einen schlechten Tag, dank eines weiteren AWS-Ausfalls. Diesmal fiel us-east-1 aus, Amazons berüchtigtste und älteste Region. Dienste erstickten, Login-Bildschirme froren ein, und über Apps und Systeme, die auf die kommerzielle AWS-Cloud angewiesen sind, herrschte kurz das Chaos. Eine Gruppe von Nutzern zuckte dagegen größtenteils kaum: die auf AWS GovCloud.

Als sich der Staub legte, brach eine hitzige Diskussion unter Cloud-Ingenieuren, Regierungsauftragnehmern und neugierigen Zuschauern aus. Sie wollten verstehen, was genau passiert war und warum GovCloud-Nutzer vom Ausfall isoliert schienen.

Was ist überhaupt GovCloud?

Zuerst eine schnelle Auffrischung für Uneingeweihte. AWS GovCloud ist Amazons luftdichter, compliance-schwerer Cousin seiner kommerziellen Cloud. Es ist für US-Regierungsbehörden und Auftragnehmer konzipiert, die mit sensiblen Workloads umgehen, die unter anderem FedRAMP High, ITAR oder CJIS-Compliance erfordern. Es läuft in isolierten Regionen (us-gov-west-1 und us-gov-east-1) und teilt keine Infrastruktur mit der Standard-AWS-Umgebung.

Diese Isolation erfüllt Compliance-Vorgaben, und diese Woche machte sie den ganzen Unterschied.

Was lief in us-east-1 schief?

Die kommerzielle Region us-east-1, die Nord-Virginia abdeckt, ist seit langem das Arbeitstier von AWS. Sie ist der Standard für viele Dienste und Kunden und beherbergt Teile von AWS' globaler Kontrollebene wie IAM (Identity and Access Management). Als sie stolperte, spürten deshalb selbst Dienste, die in anderen Regionen liefen, die Schockwellen.

Nutzer berichteten flächendeckend von Login-Fehlern, Timeouts und kaskadenartigen App-Störungen. GovCloud dagegen, das seine eigene IAM- und Kontrollebene in us-gov-west-1 untergebracht hat, war völlig unbetroffen.

GovClouds physische und logische Trennung

Laut mehreren Branchenprofis, die sich zur Situation äußerten, sind GovCloud und die kommerzielle AWS auch in der Praxis getrennt, als physisch unterschiedliche Infrastrukturen mit separaten Kontrollebenen, Software-Bereitstellungsplänen und Compliance-Modellen.

Wie ein Ingenieur es ausdrückte:

"GovCloud ist physisch von den kommerziellen Regionen wie us-east-1 mit einer separaten Kontrollebene isoliert und war daher vom Ausfall-Kaskade unbetroffen."

Andere fügten hinzu, dass die AWS-Partitionen wie völlig unterschiedliche Anbieter agieren. GovCloud spricht nicht mit kommerziellen Regionen, es sei denn, ein Kunde richtet benutzerdefinierte VPNs oder Netzwerkverbindungen ein. Selbst AWS-Globaldienste, die auf der kommerziellen Seite normalerweise in us-east-1 leben, haben separate Gegenstücke in GovCloud, gehostet in ihrer eigenen "globalen" Region, typischerweise us-gov-west-1. Diese physische und logische Trennung ist beabsichtigt, und sie hat funktioniert.

Warum hatten einige Bundesangestellte trotzdem Probleme?

Die Kern-Dienste von GovCloud waren unberührt, und doch berichteten einige Bundesangestellte von Problemen beim Zugriff auf Anwendungen oder beim Anmelden bei Plattformen. Das sorgte für Verwirrung, und die Antwort liegt in den Details der Bereitstellungsarchitektur.

Nicht jede Regierungs-Workload läuft in GovCloud. Viele Behörden hosten weniger sensible Apps in kommerziellen AWS-Regionen, um Geld zu sparen und Komplexität zu reduzieren. FedRAMP Moderate Workloads können beispielsweise legal in Standardregionen wie us-east-1 laufen.

Wenn eine Behörde also ihren Authentifizierungsdienst, einen Teil ihres App-Stacks oder SaaS von Drittanbietern in der kommerziellen Cloud behalten hatte, steckte sie in Schwierigkeiten, als us-east-1 dunkel wurde.

Ein Nutzer erklärte es so:

"Es ist möglich, dass einige Bundesangestellte am Montag Probleme mit AWS hatten, weil nicht alle AWS-Bundesregierungslösungen in GovCloud laufen... GovCloud sollte nur verwendet werden, wenn es für eine spezifische Anforderung benötigt wird; es ist teurer, es gibt mehr Papierkram, und Features erscheinen dort später."

Ein anderer fasste es mit einer Netflix-Analogie zusammen:

"Es ist, als würde man sagen, Netflix war offline, als Sie ein lokales ISP-Problem hatten. Netflix war nicht down, aber für den Endbenutzer fühlte es sich so an."

Ein irreführendes Sicherheitsnetz?

GovClouds Isolation ist zugleich seine Superkraft und eine Quelle von Missverständnissen. Rein infrastrukturell tat GovCloud seine Aufgabe und blieb stehen, als us-east-1 umfiel. Das heißt aber nicht, dass jede Bundesanwendung in AWS sicher war. Über Abhängigkeiten von kommerziellen Diensten, Hybrid-Bereitstellungen oder einfach gemeinsame Anbieter, die nicht isoliert waren, erreichten die Welleneffekte trotzdem Benutzer.

Selbst innerhalb von GovCloud hätten Apps versagen können, wenn sie externe Abhängigkeiten hatten, etwa eine API oder Ressource, die auf us-east-1 zeigte. GovCloud blieb technisch online, aber je nach Architektur könnten Benutzer trotzdem auf Probleme gestoßen sein.

Warum GovCloud niemals der Standard sein wird

Angesichts dessen, wie gut es während des Ausfalls funktionierte, könnten Sie fragen, warum nicht mehr Bundesbehörden alles nach GovCloud verlagern. Dafür gibt es drei Gründe.

GovCloud ist teuer. Höhere Kosten und eingeschränkter Zugang machen es zu einer großen Last für kleinere Behörden oder weniger kritische Workloads. Es bekommt Features langsamer, weil Compliance-Prüfungen dazu führen, dass neue AWS-Dienste spät oder manchmal gar nicht in GovCloud ankommen. Und es ist komplex: Nur geprüfte US-Bürger können darauf zugreifen, und das Verwalten und Warten von GovCloud-Workloads bringt mehr Bürokratie mit sich.

Deshalb wird GovCloud selektiv eingesetzt. Behörden wägen Kosten, Risiko und Compliance-Anforderungen ab, bevor sie entscheiden, wo sie jede Workload ausführen.

Die Erkenntnis: Trennung ist wichtig, Architektur auch

Der us-east-1-Ausfall zeigte AWS' gespaltene Persönlichkeit in vollem Umfang. GovCloud blieb dank seiner absichtlichen Partitionierung online, aber nicht jeder, der sich sicher glaubte, war es auch. Isolation hilft, doch die Zuordnung der Abhängigkeiten wiegt schwerer.

Wenn Sie für Resilienz bauen, ob im privaten oder öffentlichen Sektor, reicht es nicht aus, darauf zu vertrauen, dass Ihre Kerndienste in einer "sicheren" Region sind. Sie müssen wissen, wo Ihre Abhängigkeiten leben, wie Ihre Authentifizierung gehandhabt wird und ob Ihre Failover wirklich Failover sind. AWS mag Ihnen die Werkzeuge geben, für die Resilienz sind Sie selbst verantwortlich.