Anfang März 2026 trafen iranische Drohnen drei AWS-Einrichtungen im Nahen Osten. Zwei in den Vereinigten Arabischen Emiraten wurden direkt getroffen. Eine in Bahrain wurde durch eine nahegelegene Explosion beschädigt. Feuer, strukturelle Schäden, Wasserschäden durch Löscharbeiten, Stromausfälle. Das volle Programm.
AWS forderte seine Kunden auf, ihre Daten zu sichern, eine Migration der Workloads in andere Regionen in Betracht zu ziehen und den Datenverkehr von Bahrain und den VAE wegzuleiten. Das ist AWS, der größte Cloud-Anbieter der Welt, der Ihnen klar sagt: Wir können Ihre Verfügbarkeit hier nicht garantieren.
Dies ist der erste bestätigte militärische Angriff auf einen Hyperscale-Cloud-Anbieter. Es wird nicht der letzte sein.
Die Cloud hat eine Adresse
Die Streaming-Branche hat ein Jahrzehnt damit verbracht, so zu tun, als sei „die Cloud“ eine abstrakte, unendlich widerstandsfähige Schicht, die einfach funktioniert. Das ist sie nicht. Die Cloud läuft auf physischen Servern, in physischen Gebäuden, mit physischen Stromversorgungen. Und diese Gebäude haben Koordinaten, die in das Navigationssystem einer Drohne eingegeben werden können.
Banking-Apps, Zahlungsdienste, Lieferplattformen, Unternehmenssoftware: Sie alle fielen in der Golfregion aus, als die Drohnen einschlugen. Streaming-Dienste, die Origin-Server oder Packaging-Pipelines in me-central-1 oder me-south-1 betrieben, waren keine Ausnahme.
Wenn Ihr HLS-Origin in einer einzigen AWS-Region steht, ist Ihr Stream genau so widerstandsfähig wie die Betonwände dieses Rechenzentrums. Das ist keine Metapher mehr.
Warum Streaming besonders verwundbar ist
Eine Website, die 30 Minuten ausfällt, ist schmerzhaft. Ein Livestream, der 30 Sekunden ausfällt, ist eine Katastrophe. Zuschauer gehen. Sie kommen für den Rest des Events nicht zurück. Werbeeinnahmen verdampfen. Vertragsstrafen greifen.
Streaming hat einzigartige Schwachstellen, die allgemeine Cloud-Resilienz-Ratschläge nicht abdecken:
Manifest-Kontinuität. Wenn ein CDN mitten im Stream ausfällt, muss der Player das nächste Segment von woanders holen, ohne die ABR-Sitzung zu unterbrechen. Wenn Ihre Manifeste nicht für Multi-CDN-Auslieferung konzipiert sind, bedeutet ein Failover einen kompletten Neustart des Players für jeden Zuschauer.
Origin-Shield-Abhängigkeit. Die meisten Architekturen verwenden einen einzigen Origin-Shield zwischen dem Packager und dem CDN-Edge. Wenn dieses Shield in einer Region sitzt, die offline geht, haben Ihre Edge-Knoten nichts mehr, von dem sie abrufen können. Der Cache läuft ab und es ist vorbei.
DRM-Lizenzserver. Die Widevine- und PlayReady-Lizenzakquise erfolgt beim Stream-Start und in den Schlüsselrotationsintervallen. Wenn Ihr Lizenzserver in einer einzigen Region läuft und diese Region ausfällt, können neue Zuschauer die Wiedergabe nicht starten. Bestehende Zuschauer werden bei der nächsten Schlüsselrotation getrennt.
Werbeinfrastruktur. SSAI-Entscheidungsserver, Ad-Tracking-Beacons, Companion-Ad-APIs: Sie alle haben ihre eigenen Infrastrukturabhängigkeiten. Ein Stream kann technisch weiterlaufen, während die Werbe-Pipeline zusammenbricht und Ihren monetarisierten Stream in kostenlosen Content verwandelt.
Was Sie dagegen tun können
Die gute Nachricht: Nichts davon ist unlösbar. Die schlechte Nachricht: Die meisten Streaming-Betreiber haben nichts davon jemals getestet.
1. Kennen Sie Ihre tatsächliche Abhängigkeitskette
Bevor Sie etwas reparieren können, müssen Sie das Problem sehen. Die meisten Streaming-Ingenieure haben ein ungefähres mentales Modell ihrer Architektur, haben aber nie wirklich jedes Origin, jedes CDN, jeden DRM-Endpunkt, jeden Ad-Server und jede DNS-Abhängigkeit kartiert.
Lassen Sie Ihre Stream-URL durch einen geeigneten Analysator laufen. Schauen Sie sich den vollständigen Manifest-Baum an. Prüfen Sie, woher jedes Segment tatsächlich geliefert wird. Identifizieren Sie, welches CDN die Hauptlast trägt. Prüfen Sie, ob Ihre Redundanz real ist oder nur ein Punkt auf einer Präsentationsfolie.
Testen Sie die Resilienz Ihres Streams jetzt mit dem iReplay.TV Stream Analyser →
Der Analysator zeigt Ihnen das CDN, das Ihre Segmente ausliefert, die Origin-Kette hinter Ihren Manifesten, Ihre Segmentdauern (die sich direkt auf die Failover-Zeit auswirken) und ob Ihr Stream einen regionalen Ausfall überstehen könnte. Fünf Minuten Analyse können Sie davor bewahren, Ihre Single Points of Failure während eines Live-Events zu entdecken.
2. Implementieren Sie echtes Multi-CDN, nicht Checkbox-Multi-CDN
Zwei CDN-Verträge zu haben, ist keine Multi-CDN-Strategie. Ein echtes Multi-CDN-Setup bedeutet:
- Ihre Manifeste enthalten Segment-URLs, die zu mehreren CDN-Endpunkten aufgelöst werden können
- Ihr Player oder Ihre Manifest-Manipulationsschicht kann das CDN mitten in der Sitzung wechseln, ohne die Wiedergabe zu unterbrechen
- Sie haben das Failover unter realer Last getestet, nicht nur auf einem Whiteboard
- Ihr Origin kann den Ansturm bewältigen, wenn der gesamte Traffic plötzlich zum überlebenden CDN wechselt
Die meisten Streaming-Betreiber stellen bei ihrem ersten echten Ausfall fest, dass ihr „Multi-CDN“ in Wirklichkeit zwei CDNs mit manuellem DNS-Wechsel und einem 30-Minuten-TTL ist. Das ist keine Resilienz. Das ist Hoffnung.
3. Verteilen Sie Ihr Origin und Packaging
Wenn Ihr Live-Packager in einer einzigen Cloud-Region läuft, haben Sie einen Single Point of Failure. Punkt. Betreiben Sie redundantes Packaging in mindestens zwei geografisch getrennten Regionen. Verwenden Sie unterschiedliche Cloud-Anbieter, wenn Sie die betriebliche Komplexität verkraften können.
Für VOD stellen Sie sicher, dass Ihr Origin-Speicher regionübergreifend repliziert wird mit automatischem Failover. S3-Cross-Region-Replikation ist die offensichtliche AWS-Antwort, aber nach März 2026 ist die klügere Frage: Sollte Ihr Backup-Origin überhaupt bei AWS liegen?
4. Überprüfen Sie Ihre DRM- und Werbeinfrastruktur
DRM-Lizenzserver und SSAI-Entscheidungsengines sind die versteckten Single Points of Failure in den meisten Streaming-Architekturen. Sie werden oft in einer einzigen Region gehostet, bei einem einzigen Anbieter, ohne Failover-Plan außer „Es ist noch nie ausgefallen.“
Bis eine Drohne das Gebäude trifft.
Prüfen Sie, wo Ihr Widevine/PlayReady-Proxy läuft. Prüfen Sie, wo Ihr SSAI-Entscheidungsserver steht. Prüfen Sie, ob Ihre Ad-Beacons einen regionalen Ausfall überstehen können. Der Stream-Analysator kann Ihnen helfen, einige dieser Abhängigkeiten aufzudecken.
5. Entwerfen Sie für den Degraded Mode, nicht nur für volle Verfügbarkeit
Infrastrukturresilienz bedeutet, den Stream am Leben zu halten. Aber Resilienz in der realen Welt bedeutet auch, einen Plan zu haben, wenn der Stream nicht am Leben bleiben kann. Die besten Nachrichten- und Sport-Apps werden nicht einfach schwarz, wenn das CDN ausfällt. Sie degradieren anmutig.
Offline-Wiedergabe für Kurzinhalte. Kurznachrichten, Highlights, voraufgezeichnete Bulletins: Diese können auf das Gerät vorgeladen und lokal bereitgestellt werden, wenn die Konnektivität abnimmt oder die Backend-Infrastruktur ausfällt. HLS unterstützt Offline-Wiedergabe nativ auf Apple-Plattformen, und die meisten modernen Player unterstützen sie auch auf Android. Wenn Ihre App Nachrichten oder Kurzinhalte liefert, gibt es keine Entschuldigung dafür, die neuesten Clips nicht auf dem Gerät zu cachen. Wenn das Rechenzentrum in Bahrain ausfällt, haben Ihre Nutzer immer noch etwas zum Anschauen. Der Schlüssel ist, den Offline-Cache im Normalbetrieb aggressiv zu aktualisieren, damit der Inhalt relevant bleibt.
Push-Benachrichtigungen als alternativer Verbreitungskanal. Wenn Ihre Streaming-Infrastruktur teilweise ausgefallen ist, werden Push-Benachrichtigungen zu Ihrem Notfallwarnsystem. Eine durchdachte Benachrichtigungsstrategie kann Nutzer zu funktionierenden Spiegeln umleiten, textbasierte Nachrichtenzusammenfassungen liefern oder einfach den Ausfall bestätigen und Erwartungen setzen. Die Push-Infrastruktur (APNs, FCM) läuft auf den eigenen Systemen von Apple und Google, völlig unabhängig von Ihrem Streaming-Backend. Wenn Ihr CDN ausfällt, aber Ihre Benachrichtigungs-Pipeline noch funktioniert, können Sie Ihr Publikum informiert und engagiert halten, anstatt es stillschweigend zur Konkurrenz abwandern zu lassen.
Audio-Only-Fallback. Ein vollständiger Videostream mit 4 Mbps ist eine Menge Infrastruktur, die unter Stress am Laufen gehalten werden muss. Ein Audio-Only-Stream mit 64 kbps kostet etwa 60-mal weniger in der Auslieferung und kann mit einem Bruchteil der Bandbreite und Serverkapazität betrieben werden. Besonders für Nachrichteninhalte ist Audio-Only ein völlig akzeptabler Degraded Mode. Viele Zuschauer hören Nachrichtenstreams bereits beim Pendeln oder Multitasking. Eine explizite Audio-Only-Variante in Ihre ABR-Leiter einzubauen, bedeutet, dass Ihr Dienst auch dann weiterläuft, wenn die Videoauslieferung beeinträchtigt ist. Es eröffnet auch die Möglichkeit der Auslieferung über Protokolle, die widerstandsfähiger gegen Paketverlust sind, oder sogar über einfache Podcast-Infrastruktur als letzten Ausweg.
Hier liegt das Problem: Eine überraschende Anzahl von Streams läuft noch mit Legacy-MPEG-2-Transport-Stream-Packaging, bei dem Audio und Video zusammen gemultiplext sind. Keine Möglichkeit, nur Audio anzufordern. Keine Möglichkeit, anmutig zu degradieren. Der Player lädt das vollständig gemultiplexte Segment herunter oder nichts. Wenn Ihr Stream noch auf MPEG-2 TS ohne eigenständige Audio-Variante läuft, verpassen Sie den günstigsten Resilienz-Hebel, der Ihnen zur Verfügung steht. Der Wechsel zu fMP4/CMAF mit einer separaten Audio-Only-Variante in Ihrer Master-Playlist ist die Lösung. Der iReplay.TV Stream Analyser sagt Ihnen in Sekunden, ob Ihr Stream eine Audio-Only-Variante hat oder ob Sie noch im TS-Only-Territorium feststecken.
Das sind keine Trostpreise. Es ist der Unterschied zwischen „Die App ist kaputt“ und „Die App funktioniert noch, nur gerade etwas anders.“ Nutzer verzeihen vorübergehende Beeinträchtigungen. Stille verzeihen sie nicht.
Die neue Realität
Der Iran-Konflikt erzwang ein Gespräch, auf das die Streaming-Branche nicht vorbereitet war. Cloud-Infrastruktur ist nicht unbesiegbar. Geografische Diversifizierung ist nicht optional. Und „Es wird uns wahrscheinlich nicht passieren“ ist keine Resilienz-Strategie.
Die Iranischen Revolutionärgarden haben explizit US-Technologieunternehmen als legitime militärische Ziele benannt. Google, Microsoft und Oracle betreiben alle Rechenzentren in derselben Region. Der nächste Angriff könnte einen anderen Anbieter, eine andere Region oder einen Seekabel-Landepunkt treffen. Die Glasfaserrouten in den und aus dem Golf sind begrenzt, und sie werden nicht weniger verwundbar.
Wenn Ihre Streams von Infrastruktur im Nahen Osten abhängen, oder wenn Ihre globale Architektur versteckte Abhängigkeiten von einem einzigen Cloud-Anbieter hat, ist jetzt der richtige Zeitpunkt, das herauszufinden. Nicht während des nächsten Angriffs.
Analysieren Sie die Resilienz Ihres Streams → ireplay.tv/tools/stream-analyser