CloudFront 5xx: Was VPC Origins Teams prüfen müssen
CloudFront-VPC-Origins lieferten am 16.07. stundenlang 5xx. Was DACH-Teams zu Failover, Inventar und Edge-Metriken jetzt prüfen sollten.
Am 16. Juli 2026 lieferten CloudFront-Verteilungen mit VPC Origins stundenlang 5xx. Ein internes Limit in der Flotte für private Origins stoppte die Routing-Konfiguration am Edge – oft während der eigene ALB noch gesund wirkte. Wer private Origins hinter CloudFront legt, braucht Failover, bevor der nächste Control-Plane-Fehler die globale Tür zusperrt.
Das Wichtigste in Kürze
- Fenster 07:45–11:18 UTC. Nur VPC Origins betroffen; klassische öffentliche Origins und S3-Origins liefen weiter. AWS nannte ein internes Connection-Management-Limit als Auslöser.
- Workaround war Origin-Typ wechseln. Ohne vorbereitete Staging-Distribution und getestetes IaC bleibt der Hinweis auf dem Status-Dashboard wirkungslos.
- Zweitreihen-Risiko. Canvas, Blackboard, Hugging Face und Identity-Provider hingen mit – auch wenn Ihre eigene App „grün“ war, konnten Login und CDN davor roten 5xx zeigen.
Verwandt:AWS Sovereign Cloud: was wirklich getrennt ist / Die 200 Millisekunden, die Nutzer aus dem SaaS treiben
Was am 16. Juli wirklich gekippt ist
VPC Origins verbinden CloudFront mit Application Load Balancern, Network Load Balancern oder EC2-Instanzen in privaten Subnetzen. Der Edge ist der einzige öffentliche Eingang; der Origin braucht keine öffentliche IP. Genau diese private Verbindungsstrecke hängt an einer AWS-internen Flotte, die Routing-Konfiguration an die Netzwerkprozessoren verteilt.
Als ein internes Limit dieser Flotte erreicht war, lud das System aktualisierte Routing-Daten nicht mehr korrekt. Folge: erhöhte 5xx für Kunden mit VPC-Origin-Connectivity. Andere Origin-Typen blieben laut AWS-Health-Updates außen vor. Die Störung dauerte laut abschließender Zusammenfassung von 07:45 bis 11:18 UTC – gut dreieinhalb Stunden globale Reibung an einer Feature-Kante.
Warum hochverfügbare Setups trotzdem umfielen
Viele Teams bauten VPC Origins genau deshalb: Security-Posture, weniger öffentliche Angriffsfläche, CloudFront als Single Entry. Das reduziert Angriffsfläche, bündelt aber den Datenpfad. Fällt die Connection-Management-Ebene für private Origins aus, hilft weder Multi-AZ im eigenen Account noch ein zweites Region-Replica im gleichen Muster, wenn derselbe globale Config-Pfad greift.
AWS schlug als Workaround vor, den Origin-Typ zu ändern – also von VPC Origin auf eine öffentlich erreichbare Origin-Konfiguration auszuweichen. Das klingt simpel und ist in der Praxis nur dann brauchbar, wenn die Alternative schon als Staging-Distribution oder Terraform-Modul liegt und getestet ist. Wer im Incident erst Security Groups öffnet und DNS dreht, verbrennt die ersten 90 Minuten.
Checkliste für DACH-Platform-Teams
Erstens: Inventar. Welche Distributions nutzen VPC Origins? Welche Business-Pfade hängen daran – Login, API, Media, Partner-Portale? Ohne diese Liste ist jede Status-Page-Meldung nur Lärm.
Zweitens: Failover-Pfad. Halten Sie eine erprobte Alternative bereit: öffentliche Origin hinter strengen Prefix-Lists, zweiter CDN-Einstieg oder gezielter Origin-Group-Failover. Continuous Deployment in CloudFront (Staging-Distribution) eignet sich, um den Wechsel trocken zu proben, bevor die Status-Page rot wird.
Drittens: Observability jenseits des ALB. 5xx am Edge und Origin-Latency-Metriken müssen getrennt alarmieren. Wenn nur der Target-Group-Healthy-Host grün leuchtet, sehen Sie den Control-Plane-Fehler zu spät.
aws cloudfront list-vpc-origins –query ‚VpcOriginList[*].[Id,Arn,Status]‘ –output table
# Distributions mit Origin-Domains listen
aws cloudfront list-distributions \
–query „DistributionList.Items[*].{Id:Id,Origins:Origins.Items[*].DomainName}“ \
–output json
Zweite Reihe: SaaS, die mit Ihnen umfällt
Incident-Tracker meldeten unter anderem Auswirkungen bei Identity-Anbietern, EdTech-Plattformen wie Canvas und Blackboard sowie Entwickler- und AI-Tools. Für den Mittelstand ist das die unangenehme Lektion: Selbst wenn Ihre eigene Distribution sauber ist, kann der IdP davor den Login blockieren. Dependency-Maps sollten deshalb CDN und Identity als First-Class-Risiken führen, nicht nur die eigene Kubernetes-Namespace-Liste.
Region-Failover allein rettet bei globalen Config-Incidents selten. Multi-Cloud als Antwort bringt eigene Betriebslast und trifft oft dieselben SaaS-Abhängigkeiten. Realistischer ist oft: bekannte Workarounds vorbereiten, Status-Feeds automatisieren und Kommunikationsvorlagen für den Business-Impact bereithalten.
Was Sie diese Woche konkret tun
Legen Sie eine 60-Minuten-Übung an: Status „VPC Origins 5xx“ simulieren, Workaround-Runbook öffnen, Staging-Distribution promoten oder IaC-Plan anwenden, Rollback messen. Dokumentieren Sie, welche Security-Ausnahmen der öffentliche Fallback braucht und wer sie freigibt. Danach ist der nächste Incident kein improvisiertes Security-Review um 3 Uhr nachts.
VPC Origins bleiben ein starkes Sicherheitsmuster. Sie sind nur dann hochverfügbar, wenn der Ausfall des privaten Verbindungspfads im Design vorkommt – und geprobt ist.
Häufige Fragen
Was sind CloudFront VPC Origins?
VPC Origins erlauben CloudFront, Inhalte aus privaten Subnetzen zu holen – typisch ALB, NLB oder EC2 ohne öffentliche Exposure. CloudFront wird zum einzigen öffentlichen Eingang, die Verbindung zum Origin läuft über einen von AWS gemanagten privaten Pfad.
Warum half Multi-AZ im eigenen Account nicht?
Der Fehler saß in der Flotte, die Verbindungen zu privaten VPC Origins global verwaltet und Routing-Konfiguration verteilt. Lokale Redundanz im Account ändert nichts an einem Limit in diesem Connection-Management-Pfad.
Welchen Workaround nannte AWS?
Während des Incidents empfahl AWS, den Origin-Typ zu wechseln – weg vom VPC Origin hin zu einer anderen Origin-Konfiguration. Das funktioniert in der Praxis nur mit vorbereitetem Staging, IaC und getesteten Security-Regeln.
Welche Metriken sollte ich alarmieren?
CloudFront 5xx-Error-Rate und Origin-Latency getrennt vom Target-Group-Health. Zusätzlich synthetische Checks von außerhalb der Region und Alerts auf den AWS Health-Feed für CloudFront-Operational-Issues.
Reicht ein zweiter CDN-Anbieter?
Als Teilstrategie ja, als Allheilmittel nein. Viele SaaS-Abhängigkeiten bleiben auf demselben Hyperscaler. Priorisieren Sie Failover für Ihre kritischen Entry-Pfade und Identity, bevor Sie die gesamte Multi-Cloud-Architektur umbauen.
Lesetipps der Redaktion
cloudmagazinAWS Sovereign Cloud: was wirklich getrennt istcloudmagazinDie 200 Millisekunden, die Nutzer aus dem SaaS treibencloudmagazinWenn KI-Agenten reisen: Data-Residency als Operating-ProblemMehr aus dem MBF Media Netzwerk
MyBusinessFutureBillige KI aus China: Was der Einkauf prüfen mussDigital ChiefsWashington entscheidet mit, welche KI hier laufen darfSecurityTodayCodex Security: Offener Client füttert OpenAIBildquelle: KI-generiert (Mai 2026)
