Die meisten von uns besitzen einen Haustürschlüssel. Und die meisten von uns wissen, wer sonst noch Zugang zu unserer Wohnung hat. Bei den Gesundheitsdaten, die in der elektronischen Patientenakte hinterlegt sind, ist das offenkundig nicht so klar. Das zeigen die Antworten der Bundesregierung auf eine Kleine Anfrage der Bundestagsfraktion „Die Linke“.

Die Abgeordneten haben die Regierung unter anderem gefragt, welche Vorkehrungen verhindern sollen, dass etwa die US-Regierung an sensible Gesundheitsdaten von deutschen Versicherten gelangt. Die Antworten der Bundesregierung sind mitunter missverständlich, in Teilen unvollständig und fehlerhaft.

Nachfragen bei dem zuständigen Gesundheitsministerium, verschiedenen Krankenkassen und der Gematik haben nur wenig Licht ins Dunkel gebracht. Offenkundig sollen die Versicherten weitgehend bedingungslos darauf vertrauen, dass ihre sensiblen Daten in der ePA sicher sind.

Krankenkassen verweigern Auskunft

Anlass der Kleinen Anfrage war eine Aussage des Chefjustiziars von Microsoft Frankreich im Juni dieses Jahres. Er hatte in einer öffentlichen Anhörung vor dem französischen Senat nicht ausschließen können, dass der Tech-Konzern Microsoft auf Anordnung US-amerikanischer Behörden auch Daten europäischer Bürger:innen weitergeben müsse.

Hintergrund ist unter anderem der US-amerikanische Clarifying Lawful Overseas Use of Data Act, kurz CLOUD Act, aus dem Jahr 2018. Das Gesetz verpflichtet US-Tech-Anbieter unter bestimmten Voraussetzungen zur Offenlegung von Daten gegenüber US-Behörden – auch wenn sich diese Daten außerhalb der Vereinigten Staaten befinden.

Die Abgeordneten der Linksfraktion fragten die Bundesregierung, ob sie ein ähnliches Szenario bei den in der ePA hinterlegten Gesundheitsdaten ausschließen könne. Die Regierung erwidert, dass sie nichts über die Verträge zwischen den Betreibern der ePA und den Krankenkassen wisse. Sie kenne daher die Regelungen nicht, mit denen die Daten der Versicherten geschützt würden. Betreiber von ePA-Infrastrukturen sind spezialisierte IT-Dienstleister wie IBM Deutschland und das österreichische Unternehmen RISE.

Wir haben uns bei den drei größten gesetzlichen Krankenkassen in Deutschland erkundigt, welche vertraglichen Vereinbarungen sie mit ihren externen Anbietern getroffen haben. Weder die Techniker Krankenkasse noch die Barmer oder die DAK wollten unsere Frage beantworten. Sie verweisen auf die Gematik, die als Nationale Agentur für Digitale Medizin für die Spezifikationen zur technischen Ausgestaltung der ePA zuständig sei. Der Barmer-Sprecher bittet zudem um Verständnis, dass er sich „aus Wettbewerbsgründen“ nicht weiter zu den Vertragsbedingungen äußern könne.

Es ist also unklar, ob es entsprechende Regelungen zum Schutz der Versichertendaten gibt, von denen die Bundesregierung spricht.

Der Schlüssel liegt bei den Betreibern

Desweiteren verweist die Bundesregierung auf „umfangreiche technische und organisatorische Sicherheitsmaßnahmen“, die zum Schutz der Gesundheitsdaten umgesetzt worden seien. So dürften die in der ePA hinterlegten Daten nur verschlüsselt bei den Betreibern gespeichert werden. Ohne „den Schlüssel der Versicherten“ könnten Unbefugte die Daten nicht lesen, betont die Regierung.

Diese Antwort ist mindestens missverständlich formuliert. Tatsächlich verfügt die ePA derzeit über keine patientenindividuelle Verschlüsselung, bei der jede:r Versicherte die eigene Patientenakte mit einem persönlichen Schlüssel absichert. Ältere Versionen der ePA sahen noch eine Ende-zu-Ende-Verschlüsselung der in der Patientenakte hinterlegten Daten vor; die aktuelle „ePA für alle“ bietet dieses Mehr an Sicherheit allerdings nicht mehr.

Außerdem sind die Schlüssel nicht, wie noch bei früheren ePA-Versionen, auf der elektronischen Gesundheitskarte der Versicherten hinterlegt, sondern sie liegen auf den Servern des ePA-Betreibers. Sogenannte Hardware Security Modules in einer „vertrauenswürdigen Ausführungsumgebung“ würden gewährleisten, dass die Betreiber keinen direkten Zugriff auf diese Schlüssel haben, schreibt das Gesundheitsministerium auf Nachfrage von netzpolitik.org.

„Diese speziell abgesicherten Komponenten sind dafür ausgelegt, kryptografische Schlüssel sicher zu verwalten und sensible Daten vor unbefugtem Zugriff zu schützen“, sagt eine Gematik-Sprecherin auf Anfrage. Ein direkter Zugriff auf die Schlüssel, auch durch die Betreiber der ePA, sei technisch ausgeschlossen. Die Schlüssel werden etwa dann zur Entschlüsselung der Gesundheitsdaten verwendet, wenn die Versicherten ihre elektronische Gesundheitskarte beim Besuch einer Praxis oder einer Apotheke in ein Lesegerät schieben.

Offene Eingangstüren

Zwei Aspekte lassen das Gesundheitsministerium und die Gematik bei ihren Ausführungen jedoch unter den Tisch fallen.

Zum einen ist den Sicherheitsfachleuten des Chaos Computer Clubs Bianca Kastl und Martin Tschirsich in den vergangenen Monaten wiederholt gelungen, die Zugriffskontrolle der ePA zu überwinden.

Bei den von ihnen beschriebenen Angriffsszenarien hilft Verschlüsselung nicht mehr viel. „Es ist vollkommen egal, dass das irgendwie verschlüsselt gespeichert wird, wenn an der Eingangstür ein paar Wissensfaktoren reichen, um jede ePA in Zugriff zu bekommen“, sagt Bianca Kastl, die auch Kolumnistin bei netzpolitik.org ist.

Die von ihr und Tschirsich aufgezeigten Sicherheitslücken bestehen teilweise noch immer fort. Eine „endgültige technische Lösung“ will das Bundesamt für Sicherheit in der Informationstechnik (BSI) erst im kommenden Jahr implementieren.

Trügerische Sicherheit

Zum anderen behauptet die Bundesregierung, dass die bestehenden Sicherheitsvorkehrungen einen „technischen Betreiberausschluss“ gewährleisten, „sodass selbst ein fremdbestimmter Betreiber keinen Zugriff auf die Daten der ePA erlangen würde“.

Hauptbetreiber von elektronischen Patientenakten ist die IBM Deutschland GmbH. Unter anderem die Techniker Krankenkasse, die Barmer Ersatzkasse und die AOK haben das Unternehmen damit beauftragt, die ePA und die dazugehörigen Aktensysteme gemäß der von der Gematik gemachten Spezifikationen umzusetzen. Mehr als zwei Drittel aller digitalen Patientenakten laufen auf IBM-Systemen, aus Sicherheitsgründen seien die Daten „über zahlreiche, geographisch voneinander getrennte Rechenzentrums-Standorte in der IBM Cloud in Deutschland verteilt“, so das Unternehmen.

Dieses Sicherheitsversprechen ist jedoch trügerisch. Denn die IBM Deutschland GmbH ist eine Tochter der US-amerikanischen IBM Corp. – und damit potenziell ein „fremdbestimmter Betreiber“. Gemäß CLOUD Act können US-Behörden IBM dazu zwingen, die Daten von deutschen Versicherten an sie auszuleiten.

Gefahr erkannt, Gefahr gebannt?

Welche Risiken der CLOUD Act birgt, hat etwa das baden-württembergische Innenministerium erkannt. Im Juli räumte es in einer Stellungnahme ein, dass US-Behörden theoretisch auf Daten zugreifen könnten, die in der Verwaltungscloud Delos gespeichert sind. Delos Cloud ist ein Tochterunternehmen von SAP und fußt auf Microsoft Azure und Microsoft 365. Dem Ministerium zufolge könnten US-Behörden den Tech-Konzern anweisen, „einen Datenabfluss in seine Software zu integrieren, ohne dass der Kunde darüber in Kenntnis gesetzt wird.“

Dennoch plant die Bundesregierung nach eigenem Bekunden nicht, die technologische Abhängigkeit von nicht-europäischen ePA-Betreibern zu prüfen – obwohl sie die digitale Patientenakte explizit als eine kritische Infrastruktur einstuft.

Anne Mieke-Bremer, Sprecherin für Digitale Infrastruktur der Fraktion Die Linke im Bundestag, kritisiert diese Weigerung der Regierung. „Statt klare Prüfpflichten festzuschreiben, versteckt sie sich hinter lückenhaften Vorgaben“, so Mieke-Bremer. „Und sie gibt sich damit zufrieden, dass die Verträge zwischen Betreibern und Kassen eine Blackbox bleiben.“

Die ePA wirke „zunehmend wie ein mangelhaftes und fahrlässiges Prestigeprojekt“, das voller Lücken und Risiken ist, sagt Stella Merendino, Sprecherin der Linken für Digitalisierung im Gesundheitswesen. „Was mit unseren sensibelsten Gesundheitsdaten passiert, bleibt dabei im Dunkeln.“

Mehr als 40 Nichtregierungsorganisationen sprechen sich in einem offenen Brief gegen die neuberufene irische Datenschutzbeauftragte aus. Zu den Unterzeichnern zählen unter anderem Access Now, ARTICLE 19, European Digital Rights (EDRi) und Statewatch. Ihren offenen Brief gegen die Ernennung von Niamh Sweeney zur dritten Datenschutzkommissarin der irischen Data Protection Commission (DPC) reichten die Organisationen gestern bei der irischen Regierung ein.

Die ehemalige Journalistin Sweeney arbeitete mehrere Jahre in unterschiedlichen Funktionen für den Tech-Konzern Meta. Sie war unter anderem die irische „Head of Public Policy“ von Facebook. Im September dieses Jahres hatte die irische Regierung sie zur Commissioner for Data Protection ernannt.

Bereits unmittelbar nach der Personalentscheidung regte sich Protest. Max Schrems von der österreichischen Nichtregierungsorganisation noyb kritisierte die Entscheidung als Selbstregulierung von und durch Big Tech:

„Wir haben jetzt buchstäblich eine Lobbyistin der US-Big-Tech-Branche, die die US-Big-Tech-Branche für Europa überwacht. 20 Jahre lang hat Irland das EU-Recht nicht wirklich durchgesetzt. Aber zumindest hatte die irische Regierung genug Schamgefühl, um die Durchsetzung heimlich zu untergraben.“

Die NGOs sehen in der Entscheidung ein „besorgniserregendes Level von Missachtung von europäischem Recht“. Sweeney habe sich vor wenigen Monaten noch für große Tech-Unternehmen eingesetzt. Auch fürchten die Unterzeichnenden, dass Sweeney an sogenannte Non-disclosure Agreements gebunden sein könnte, die sie dazu verpflichten, Geschäftsgeheimnisse etwa von Meta zu wahren. Ihre Ernennung stelle die Unabhängigkeit der DPC ernsthaft in Zweifel, so die NGOs.

Undurchsichtiges Auswahlverfahren

Auch das Auswahlverfahren von Niamh Sweeney kritisieren die Nichtregierungsorganisationen in ihrem Schreiben. Laut einem Bericht von Politico gehörte dem Ausschuss, der Sweeney rekrutiert hat, unter anderem der Anwalt Leo Moore an. Moore ist Partner bei der Kanzlei William Fry. Er vertritt nationale sowie multinationale Unternehmen in der Technologiebranche. Ein Mitbewerber Sweeneys hatte Moore Interessenskonflikte unterstellt, seine Beschwerde gegen die Zusammenstellung des Ausschusses blieb allerdings erfolglos.

Auch die DPC selbst wird von den NGOs kritisiert. „Das Fehlen einer wirksamen Durchsetzung ist mittlerweile systemisch geworden, wodurch Irland zum Nadelöhr bei der Anwendung der Datenschutz-Grundverordnung wurde“, schreiben die Bürgerrechtsorganisationen.

Um das Vertrauen in die DPC zu fördern, schlagen die NGOs zwei Maßnahmen vor. Sie fordern zum einen ein neues Auswahlverfahren, um die Stelle der Datenschutzbeauftragten mit einer Person zu besetzen, die nachgewiesenermaßen über ausreichend Qualifikationen bei den Themen Grundrechte und Datenschutz verfügt. Zum anderen drängen sie darauf, das bestehende Auswahlverfahren unabhängig prüfen zu lassen.

Der offene Brief in Wortlaut

Date 14-10-2025

Re: Concerns Regarding the Independence of the Irish Data Protection Commission Following Recent Appointment

For the attention of Michael McGrath, European Commissioner for Democracy, Justice, the Rule of Law and Consumer Protection.

Dear Commissioner,

We, a large group of civil society organisations are writing to you to express our extreme concern regarding the recent appointment of the new Commissioner at the Irish Data Protection Commission (DPC). The person in question has held a long-standing senior public affairs position at one of the largest technology platforms that the DPC is mandated to regulate, and indeed in her latest role (which ended only last August) continued to advocate on behalf of these platforms. All this raises serious questions about the perception and reality of the DPC’s independence at a time when its impartiality is of critical importance for the entire Union.

The GDPR requires, under Article 52, that supervisory authorities act with full independence. Equally, Article 41 of the Charter requires that procedures are handled ‚impartially‘ and ‚fairly‘. This principle is fundamental to the credibility of the Regulation and to the rights it is designed to protect. Its importance is amplified in Ireland, where the DPC has responsibility as lead supervisory authority for many of the world’s largest technology companies. Indeed, the importance of independence has already been affirmed by the Court of Justice in Case C-288/12 Commission v. Hungary, where the premature ending of a data protection supervisor’s mandate was found to have violated EU law. This precedent underlines both the necessity of safeguarding supervisory authorities‘ independence and the Commission’s role in ensuring compliance.

Concerns about enforcement are long-standing and ongoing. At the Irish DPC, investigations against major companies have been seldom in the last several years, with critical decisions often only materialising, if at all, under pressure from the European Data Protection Board (EDPB) and other Member State authorities, or indeed even after intervention by the Court of Justice of the European Union (CJEU). Patterns of delayed or limited enforcement continue to undermine trust in the DPC as an effective enforcer of the law.

Furthermore, recent revelations have confirmed that intimate data, including sensitive information about survivors of sexual abuse, is still being traded through real-time bidding systems with the case having been discussed at a session in the Irish parliament in the last weeks. That this continues today is the direct result of years of inaction by the Irish DPC, despite clear evidence of unlawful practices. This failure is not limited to one case. Since 2017, civil society organisations have filed highly important and strategic complaints in Ireland, yet these cases have either not been treated or have faced years of delay. The absence of meaningful enforcement has become systemic, making Ireland the bottleneck in the application of the GDPR.
The appointment of a Commissioner with such close ties to an industry under investigation threatens to only reinforce perceived distrust in the Irish DPC at precisely a time when even greater assurances of independence are needed given wider geo-political events. Any contractual obligations, such as non-disclosure agreements with entities regulated by the DPC, would exacerbate these risks from the outset.

The broader context only further compounds these concerns. Across the Union, data protection is increasingly under pressure, with proposals to weaken safeguards under the guise of simplification. Enforcement of the GDPR has too often been treated as a secondary priority, despite being essential to the protection of fundamental rights. The credibility of the EU’s digital rulebook depends on strong, impartial, and effective supervisory authorities.

We therefore respectfully urge the European Commission to:

• Assess whether the independence of the Irish DPC can be guaranteed under Article 52 GDPR and Article 41 CFR in light of this appointment;
• Clarify the steps the Commission will take if the independence of a supervisory authority is compromised, including the initiation of infringement procedures where appropriate;
• Develop a work programme to demonstrate how the task entrusted to you in this mandate – the effective enforcement of the GDPR (as set out in your mandate letter) – will be put into practice as a political priority, including EU-level safeguards to prevent conflicts of interest in supervisory authorities, including transparent appointment processes and revolving-door restrictions.

Ensuring that supervisory authorities are independent, impartial, and effective is not only a legal requirement but also a political necessity for safeguarding rights and maintaining public trust. Undermining supervisory authority independence also risks weakening protections guaranteed under the Charter of Fundamenta Rights. We remain at your disposal for further discussion and would be glad to contribute to the Commission’s reflections on this matter.

Yours sincerely,

Access Now
AI Accountability Lab, Trinity College Dublin
AI Forensics
Albanian Media Council
Alliance4Europe
ARTICLE 19
Asociația pentru Tehnologie și Internet (ApTI)
Balanced Economy Project
Bits of Freedom
Center for Countering Digital Hate
Civil Liberties Union for Europe
Coalition for Women In Journalism
Corporate Europe Observatory
Defend Democracy
Ekō
Electronic Frontier Norway
European Digital Rights (EDRi)
Global Witness
HateAid
Homo Digitalis
Hope and Courage Collective
ICCL
Irish Network Against Racism
IT-Pol
Lie Detectors
LobbyControl
New School of the Anthropocene
noyb
Open Markets Institute
Panoptykon Foundation
People Vs Big Tech
Politiscope
The Good Lobby
SOMI
Statewatch
SUPERRR Lab
Uplift, People Powered Change
Vrijschrift.org
Waag Futurelab
WHAT TO FIX
Xnet, Institute for Democratic Digitalisation

Der Ausfall von Amazons AWS-Cloud-Diensten am Montag dieser Woche bereitete nicht nur IT-Experten schlaflose Nächte, sondern etwa auch Besitzern von vernetzten Matratzen. Nun haben Amazons Techniker eine vollständige Analyse der Vorfälle veröffentlicht, die erklärt, wie es zu so weitreichenden Störungen kommen konnte.

Bereits der Titel der Amazon-Analyse weist auf einen Single-Point-of-Failure: „Zusammenfassung der Amazon DynamoDB-Dienst-Störung in der Region Nord Virginia (US-EAST-1)“. Der dort aufgetretene Fehler sorgte nicht nur für Ausfälle von Amazon-Diensten wie Streaming mit Prime oder Amazon Music, sondern legte etwa den Messenger Signal über Stunden lahm. Umso spannender ist, wie es dazu kommen konnte.

AWS-Ausfall: Detaillierter Fehlerverlauf

Während die Techniker bei Wiederherstellung des Normalbetriebs, den Amazon gegen kurz nach Mitternacht zum Dienstag, 21. Oktober, verkündete, bereits eine erste knappe Zusammenfassung des Vorfalls bereitgestellt haben, geht die jetzige Analyse deutlich in die Tiefe. Aus Amazons Sicht hat sich die Fehlerkaskade in drei Etappen abgespielt. Zwischen 8:48 Uhr mitteleuropäischer Sommerzeit am 20. Oktober 2025 und 11:40 Uhr lieferte Amazons DynamoDB erhöhte Fehlerraten bei API-Zugriffen in der Region Nord Virginia (US-EAST-1). Das war laut Amazon die erste Phase der Störung.

Die zweite Phase folgte zwischen 14:30 Uhr und 23:09 Uhr, während der der Network Load Balancer (NLB) erhöhte Verbindungsfehler bei einigen Load Balancern in Nord Virginia aufwies. Dies ging auf Health-Check-Fehler in der NLB-Flotte zurück, die zu diesen erhöhten Verbindungsfehlern führten. Zudem kam die dritte Phase von 11:25 Uhr bis 19:36 Uhr, in der das Starten neuer EC2-Instanzen nicht klappte. Bei einigen der EC2-Instanzen, die ab 19:37 Uhr anliefen, kam es jedoch zu Verbindungsproblemen, die ihrerseits bis 22:50 Uhr andauerten.

DynamoDB-Fehler

Die Probleme mit der DynamoDB erklärt Amazon mit „einem latenten Defekt“ im automatischen DNS-Management, wodurch die Namensauflösung der Endpunkte für die DynamoDB fehlschlug. „Viele der größten AWS-Dienste stützen sich in hohem Ausmaß auf DNS, um nahtlose Skalierbarkeit, Fehlerisolierung und -behebung, geringe Latenz und Lokalität zu gewährleisten. Dienste wie DynamoDB verwalten Hunderttausende von DNS-Einträgen, um eine sehr große heterogene Flotte von Load Balancern in jeder Region zu betreiben“, schreiben die Techniker. Automatisierung ist nötig, um zusätzliche Kapazitäten hinzuzufügen, sofern sie verfügbar sind, und um etwa korrekt mit Hardwarefehlern umzugehen. Zwar sei das System auf Resilienz ausgelegt, jedoch war die Ursache für die Probleme eine latente Race-Condition im DynamoDB-DNS-Management-System, die in einen leeren Eintrag für den regionalen Endpunkt „dynamodb.us-east-1.amazonaws.com“ mündete. Interessierte erhalten in der Analyse dazu einen tiefen Einblick in die DNS-Management-Struktur.

Sowohl der eigene als auch der Traffic von Kunden, die auf DynamoDB aufsetzen, war davon betroffen, da diese mangels korrekter Namensauflösung nicht mehr zu der DynamoDB verbinden konnten. Um 9:38 Uhr haben die ITler den Fehler im DNS-Management gefunden. Erste temporäre Gegenmaßnahmen griffen um 10:15 Uhr und ermöglichten die weitere Reparatur, sodass gegen 11:25 Uhr alle DNS-Informationen wiederhergestellt wurden.

Nicht startende EC2-Instanzen

Die EC2-Instanzen starteten ab 8:48 Uhr nicht mehr, da dieser von sogenannten DropletWorkflow Manager (DWFM) auf verschiedene Server verteilt werden. Die DWFM überwachen den Status der EC2-Instanzen und prüfen, ob etwa Shutdown- oer Reboot-Operationen korrekt verliefen in sogenannten Leases. Diese Prüfungen erfolgen alle paar Minuten. Dieser Prozess hängt jedoch von der DynamoDB ab und konnte aufgrund deren Störung nicht erfolgreich abschließen. Statusänderungen benötigen einen neuen Lease. Die DWFM versuchten, neue Leases zu erstellen, die jedoch zwischen 8:48 Uhr und 11:24 Uhr zunehmend in Time-Outs liefen. Nachdem die DynamoDB wieder erreichbar war, konnten die EC2-Instanzen jedoch mit dem Fehler „insufficient capacity errors“ nicht starten. Das Backlog der ausstehenden Leases erzeugte einen Flaschenhals, sodass neue Anfragen dennoch in Time-Out-Situationen kamen. Gegen 14:28 Uhr konnten die DWFM alle Leases zu allen Droplets genannten Instanzen wieder herstellen, nachdem Neustarts der DWFMs die Warteschlangen geleert hatte. Aufgrund einer temporären Anfragendrosselung, die die IT-Mitarbeiter zur Reduktion der Gesamtlast eingerichtet hatten, kam es jedoch etwa zu Fehlermeldungen der Art „equest limit exceeded“.

Die Droplets/EC2-Instanzen erhalten von einem Network Manager Konfigurationsinformationen, die ihnen die Kommunikation mit anderen Instanzen in der gleichen Virtual Private Cloud (VPC), mit VPC-Appliances und dem Internet erlaubt. Die Verteilung hatte durch die Probleme mit den DWFM ein großes Backlog erzeugt. Ab 15:21 Uhr kam es dadurch zu größeren Latenzen. Zwar starteten neue EC2-Instanzen, sie konnten mangels gültiger Netzwerkkonfigurationen jedoch nicht im Netzwerk kommunizieren. Das haben die ITler gegen 19:36 Uhr in den Griff bekommen, sodass EC2-Starts wieder „normal“ verliefen.

Verbindungsfehler durch Network Load Balancer

Die Network Load Balancer (NLB) von AWS nutzen ein Überwachungssystem (Health-Check-System). Sie umfassen Lastverteilung-Endpoints und verteilen Traffic auf die Backend-Systeme, bei denen es sich typischerweise um EC2-Instanzen handelt. Das Health-Check-System überprüft regelmäßig alle NLB-Knoten und entfernt alle Systeme, die dabei als „ungesund“ auffallen. Die Prüfungen schlugen bei der Störung jedoch zunehmend fehl, da die vom Health-Check-System neu gestarteten EC2-Instanzen keinen Netzwerk-Status melden konnten. Die Prüfungen schlugen in einigen Fällen fehl, obwohl NLB-Knoten und die Backen-Systeme korrekt funktionierten. Die Ergebnisse der Prüfung lieferten abwechselnd korrekten Status und Fehler zurück, wodurch NLB-Knoten und Backend-Systeme aus dem DNS entfernt wurden, um beim nächsten erfolgreichen Durchlauf wieder hinzugefügt zu werden. Das fiel in der Netzwerküberwachung gegen 15:52 Uhr auf.

Die Last im Health-Check-System stieg durch die alternierenden Prüfergebnisse an, wodurch es langsamer wurde und Verzögerungen bei Health-Checks auftraten. Dadurch wurden schließlich Lord-Balance-Kapazitäten reduziert, da diese außer Dienst gestellt wurden. Dadurch kam es zu vermehrten Verbindungsfehlern von Anwendungen, wenn die übriggebliebene noch laufende Kapazität nicht zum Verarbeiten der Anwendungslast ausreichte. Um 18:36 Uhr hat das IT-Team die automatischen Prüfungen für die NLB deaktiviert, wodurch alle verfügbaren, noch in Funktion befindlichen NLB-Knoten und Backend-Systeme wieder in Dienst gestellt werden konnten. Nachdem auch die EC2-Systeme sich erholt hatten, konnten die Health-Checks gegen 23:09 Uhr wieder aktiviert werden.

Im Weiteren erörtert Amazon noch, wie von den gestörten Hauptsystemen abhängige Amazon-Services der zeitliche Störungsverlauf aussah. Das IT-Team will einige Änderungen als Folge der größeren Cloud-Störungen umsetzen. Etwa der DynamoDB „DNS Planner“ und „DNS Enactor“-Automatismus wurde weltweit deaktiviert. Das soll so bleiben, bis unter anderem die aufgetretene Race-Condition gelöst wurde. Die Network Load Balancer sollen eine Geschwindigkeitskontrolle erhalten, die begrenzt, wie viele Kapazitäten ein einzelner NLB nach fehlschlagenden Health-Checks entfernen kann. Für die EC2-Systeme entwickelt Amazon zusätzliche Test-Suites, um etwa den DWFM-Workflow zu analysieren und künftige Regressionen zu vermeiden.

(dmk)