Wege aus der digitalen Abhängigkeit prüfen: Ein Fahrplan mit Beispielen für „Single Point Of Failure“ mit Special Guests „AWS“ und „Azure“

Wenn die großen Hyperscaler ausfallen, haben auch in Deutschland zahlreiche Unternehmen Probleme - in vielen Bereichen, die mit IT zusammenhängen. Weil sie sich auf eine Architektur verlassen, die Störungen geradezu magisch anzieht. Das kann so nicht weitergehen.

Am 20. Oktober 2025 kam es an der US-Ostküste zu einem großflächigen Ausfall bei Amazon Web Services (AWS) – genauer gesagt in der Region US-East-1.
Was zunächst nach einem regionalen Zwischenfall klang, zog schnell weltweite Folgen nach sich: Online-Angebote wie Amazon-Assistent Alexa und teilweise Services von OpenAI und anderen zentralen Plattformen sowie zahlreiche Unternehmensdienste waren stundenlang gestört. Ursache war laut Amazon ein Fehler in der DNS-Infrastruktur – ein leerer Eintrag, der eine Kaskade interner Ausfälle auslöste.

Rund eine Woche später, am 29. Oktober 2025, begann gegen 16:00 Uhr UTC (in Deutschland ca. 17 Uhr) ein großflächiger Ausfall bei Azure-Diensten von Microsoft – insbesondere beim Dienst Azure Front Door (AFD), der für globales Content-/Routing-Delivery zuständig ist. Der Ausfall betraf nicht nur die Azure-Cloud-Infrastruktur selbst, sondern hatte auch Auswirkungen auf viele abhängige Dienste wie Microsoft 365, Minecraft, Xbox und weitere Applikationen. Microsoft meldete, dass durch eine versehentliche Konfigurationsänderung in Azure Front Door der Ausfall ausgelöst wurde. Der Ausfall dauerte über 8 Stunden, bevor Fehler- und Latenzraten wieder auf das normale Niveau zurückgingen.

Der Vorfall zeigt, wie instabil unsere digitale Infrastruktur werden kann, wenn sie sich auf wenige zentrale Anbieter und Regionen konzentriert. In diesem Logbuch-Eintrag geht es uns nicht primär um Datenschutz, sondern um etwas Grundsätzlicheres: Resilienz und digitale Souveränität.

Das Problem: Wenn eine Region zum Flaschenhals wird

Cloud-Computing hat für Kunden sehr bequeme Skalierbarkeit und Flexibilität ermöglicht. Doch mit der Abhängigkeit von Hyperscalern wie AWS, Microsoft Azure oder Google Cloud entsteht ein neues systemisches Risiko: Wenn eine dieser Plattformen wackelt, sind buchstäblich Millionen Dienste betroffen.

US-East-1 ist eine der ältesten und größten AWS-Regionen. Sie dient vielen Anwendungen als Standard – auch für globale Unternehmen. Fällt diese Region aus, greifen DNS-Abhängigkeiten, IAM-Probleme oder API-Verzögerungen weit über die USA hinaus. Der jüngste Ausfall legte Dienste in Europa, Asien und Australien lahm – obwohl dort physisch gar keine Beeinträchtigungen vorlagen..

Eine reine Architekturentscheidung

Viele Unternehmen nutzen Cloud-Services, ohne die dahinterliegende Architektur kritisch zu hinterfragen. Tatsächlich gibt es nicht nur rein technische oder wirtschaftliche Aspekte, die dazu führen – es gibt sogar einen gewissen psychologischen Faktor, den wir immer wieder persönlich erleben: Wer sich ein M365 Abo (das übrigens aus unserer Sicht abstruse Preissteigerungen erfährt) nicht „gönnen/leisten“ will oder kann, wird in den MS-affinen IT-Kreisen ohnehin nicht so recht als ernstzunehmener Partner beschaut. Kostenlos und Open Source ist Frickelbude, kein Profi-Werkzeug.

Cloud ist kein Selbstzweck – sondern ein Werkzeug, für das man sich bewusst entscheiden sollte – am besten mit entsprechenden Notfall-Plänen bzw. Fallbacks. Es gibt drei typische Risiken zentralisierter Cloud-Modelle:

  1. Single-Point-of-Failure: Eine einzelne Region oder ein Provider kann – wie jüngst geschehen – Auslöser für globale Ausfälle sein.
  2. Geringe Kontrolle über Fehlerbehebung: Kund:innen haben keinen Zugriff auf interne Systeme oder Supportstrukturen des Anbieters. Transparenz entsteht meist erst nach einem Ausfall.
  3. Geopolitische Abhängigkeit: Infrastruktur in den USA unterliegt US-Recht, Zöllen und politischen Entscheidungen. Gerade in Zeiten handelspolitischer Spannungen oder wechselnder Administrationen ist das ein zunehmender Risikofaktor – insbesondere für kritische oder regulierte Unternehmen.

„Digitale Souveränität“ ist kein Schlagwort mehr – sie wird zur Überlebensstrategie.
 Unternehmen in Deutschland und Europa müssen ihre IT-Architekturen so gestalten, dass sie auch bei Ausfällen, regulatorischen Eingriffen oder Handelskonflikten handlungsfähig bleiben.

Das gilt nicht nur für KRITIS-Sektoren (Energie, Verkehr, Gesundheit, Verwaltung), sondern zunehmend auch für alle Organisationen, die unter den europäischen Cloud Resilience Act oder nationale Digitalgesetze fallen.

Wege zu mehr Resilienz und Unabhängigkeit

Multi-Region & Multi-Provider-Strategien

Besonders kritische Systeme, bei denen Ausfallsicherheit wichtig ist, müssen so aufgebaut sein, dass sie nicht von einem einzigen Cloud-Anbieter oder einer Region abhängen. Verteilte Architekturen über mehrere Provider (z. B. AWS + StackIT + Hetzner) erhöhen die Ausfallsicherheit erheblich. Kritische Dienste können in einer europäischen Region gespiegelt werden, während skalierende Komponenten flexibel in andere Clouds ausweichen.

Es geht hier tatsächlich nicht darum, AWS, Azure & Co zu verteufeln, sondern dafür zu sorgen, dass – auch wenn diese Anbieter aus strategischen Gründen genau das anstreben – keine besondere Abhängigkeit existiert.

Hybrid-Cloud & Open-Source-Technologien

Eine Multi-Cloud- oder Hybrid-Strategie ist keine Raketenwissenschaft, wenn man weiß, welche Bausteine sich wirklich bewegen lassen. Und Open Source ist keine reine Idealismus-Veranstaltung, sondern ein Weg, sich von proprietären Systemen unabhängig zu machen.

Es gibt etliche Services, die sich gut portieren lassen.

  1. Web- und API-Services: Fast alles, was auf Docker oder Kubernetes läuft, ist praktisch sofort portabel. Ob AWS, Hetzner, StackIT oder der eigene Server im Keller – Container-Orchestrierung bleibt dieselbe.
    1. Open-Source-Stack: Kubernetes, Docker Compose, Traefik, Nginx, Certbot
    2. Good Practice: statische Images, keine Cloud-spezifischen Secrets oder Storage-Mounts hardcoden.
  2. Datenbanken & Storage: Klar, Daten sind träger als Code – aber mit offenen Systemen ist auch hier Multicloud problemlos machbar.
    1. Open-Source-Alternativen: PostgreSQL, MariaDB, MinIO (S3-kompatibel), Redis, ElasticSearch (oder Open-Forks wie OpenSearch).
    2. Strategie: replizierbare Cluster, externe Storage-Layer (z. B. Ceph oder Longhorn) und regelmäßige Offsite-Backups.
  3. Message- und Event-Systeme: Ohne Events keine moderne Architektur. Gut, dass auch hier Open Source liefert.
    1. Tools: RabbitMQ, Kafka, NATS, Redpanda (Open Fork).
    2. Tipp: Event-Bus unabhängig von Cloud-Queue-Diensten aufbauen (keine Bindung an SQS, Pub/Sub oder EventGrid).
    3. Microservices kommunizieren – egal auf welcher Wolke sie schweben.
  4. CI/CD-Pipelines: Automatisierung ist das Rückgrat jeder resilienten Cloud.
    1. Open-Source-Tools: GitLab CI, ArgoCD, Jenkins, Drone CI.
    2. Funktioniert auf jedem Host, solange Docker & Git vorhanden sind.
    3. Build-, Test-, Deploy-Prozesse wandern einfach mit.
  5. Monitoring, Logging & Observability: Die meisten Teams binden sich hier unnötig fest an Plattformen oder proprietäre Systeme, obwohl offene Tools längst Industriestandard sind.
    1. Stack: Prometheus, Grafana, Loki, Nagios, Zabbix, OpenTelemetry, Elastic- oder OpenSearch-Stack.
    2. Strategie: Sammel- und Analyse-Tools selbst hosten statt in Cloud-Services einbinden.
    3. Einheitliches Monitoring, selbst wenn die Cloud wechselt.
  6. Identity & Access Management: Zugegeben, IAM ist heikel – aber auch hier gilt: besser selbst souverän als blind vertraut.
    1. Open-Source-Lösungen: Keycloak, Authentik, Zitadel.
    2. Integration: unterstützt OIDC, SAML, LDAP – alles standardisiert und portabel.
    3. Nutzerverwaltung funktioniert unabhängig von Azure AD/Entra oder Cognito.

Manches ist leider Nicht Multicloud-Fähig

  • Serverless-Spezialitäten wie AWS Lambda oder Azure Functions – jeder Anbieter kocht da sein eigenes Süppchen.
  • Proprietäre AI/ML-Services, Closed-API-Analytics oder „Magic-Automation-Plattformen“ – zu tief integriert, zu wenig Kontrolle.
  • Managed Services mit API-Lock-in (z. B. BigQuery, DynamoDB, CloudWatch).

Hosting „Made in Germany“

Provider wie Hetzner Online, StackIT (von Schwarz IT) oder andere zertifizierte Rechenzentrumsbetreiber bieten Hosting innerhalb deutscher oder europäischer Rechtsräume. Das bedeutet:

  • Hohe Verfügbarkeit durch lokale Redundanz.
  • Rechtssicherheit und stabile regulatorische Rahmen.
  • Keine Risiken durch US-Zölle, Cloud Act oder willkürliche Exportbeschränkungen.

Notfall- und Failover-Konzepte

Resilienz ist keine Einmal-Entscheidung, sondern eine laufende Praxis: Simulation von Ausfällen, Chaos-Testing, Monitoring und klar definierte Wiederanlaufpläne machen Systeme widerstandsfähiger – und Menschen ruhiger.

  • Status prüfen: Wo liegen Ihre Systeme? Welche Regionen oder Anbieter sind kritisch?
  • Risiken bewerten: Wie würde sich ein mehrstündiger Cloud-Ausfall auf Ihre Abläufe auswirken?
  • Strategie aufbauen: Entwerfen Sie ein Multi-Provider-Szenario – und beginnen Sie mit ersten Pilotprojekten auf europäischer Infrastruktur.
  • Beratung einholen: Gerade bei KRITIS- oder regulierten Unternehmen ist es wichtig, Architekturen frühzeitig zu bewerten – bevor neue Pflichten greifen.

Unsere Leistung: Resilienz & Souveränität in der Praxis

Als Agentur für Software-Entwicklung und KI-Lösungen unterstützen wir Unternehmen dabei, digitale Abhängigkeiten zu reduzieren und systemische Resilienz aufzubauen.

  • Unser Ansatz: Beratung & Architekturplanung. Bewertung aktueller Cloud-Setups, Risikoanalyse, Design resilienter Hybrid- oder Multi-Cloud-Architekturen.
  • Entwicklung & Umsetzung: KI-gestützte Softwarelösungen auf Basis von Open-Source-Technologien – portabel, sicher, zukunftsfähig.
  • Hosting in Deutschland: Implementierung bei Partnern wie Hetzner oder StackIT, auf Wunsch mit vollständigem Betrieb in der EU.
  • Begleitung für regulierte Unternehmen: Unterstützung bei Anforderungen aus dem Cloud Resilience Act, NIS-2, KRITIS-Verordnung u. a.

Cloud-Services bleiben unverzichtbar – doch sie dürfen nicht zur Einbahnstraße werden. Der jüngste AWS-Ausfall war kein einmaliger Zwischenfall, sondern ein Symptom dafür, wie stark unsere digitale Welt von wenigen Knoten abhängt. Resilienz bedeutet, diese Abhängigkeit zu reduzieren – technologisch, organisatorisch und strategisch.

Wer jetzt handelt, gewinnt nicht nur Stabilität, sondern auch Souveränität: Unabhängigkeit von geopolitischen Risiken, besser planbare Kosten, verlässliche Verfügbarkeit und langfristige Sicherheit.

Wir unterstützen Sie dabei.