Neon: Kubernetes IP-Erschöpfung hat Dienste gestört

Das Unternehmen

Neon ist ein vollständig verwalteter Serverless PostgreSQL-Anbieter, der für Cloud-native Workloads optimiert ist. Speicher und Rechenleistung sind von einander entkoppelt, wodurch schnelles Autoscaling, Branching und nutzungsbasierte Effizienz möglich sind. Entwickler nutzen Neon für Produktions- und Entwicklungsdatenbanken und profitieren von schnellem Start, dynamischen Umgebungen und kosteneffizientem Scaling.

Was passierte bei der Neon-Störung?

Neon zu zwei Ausfällen mit insgesamt 5,5 Stunden Dauer in der AWS-Region us-east-1. Kunden konnten inaktive Datenbanken weder starten noch erstellen, während aktive Datenbanken nicht betroffen waren.Die Ursache war eine Erschöpfung der IP-Adressen in Kubernetes-Subnets, ausgelöst durch eine Überlastung der Control Plane und Fehlkonfigurationen im AWS CNI.

‍

Als Sofortmaßnahme wurden die IP-Zuweisungsparameter neu konfiguriert und die Prewarmed-Compute-Pools hochskaliert. Neon arbeitet an einer Umstrukturierung der Architektur, um ähnliche Störungen in Zukunft zu vermeiden.

Zeitstrahl

Wann begann der Neon-Incident?

Die erste Störung begann am 16. Mai 2025 um 14:13 UTC, als Kunden Ausfälle beim Aktivieren von Datenbanken bemerkten. Der zweite Vorfall trat am 19. Mai 2025 um 13:17 UTC auf, ausgelöst durch das Zurücksetzen vorheriger Fixes.

‍

Wie wurde der Neon-Incident erkannt und eskaliert?

Interne Alarmierungen erkannten bei beiden Incidents die Service-Störungen innerhalb weniger Minuten. Bei einer ersten Analyse wurde umgehend die IP-Erschöpfung als Ursache erkannt. Als das Ausmaß der Störung deutlich wurde, erfolgte zügig die Eskalation zu einem High-Severity-Incident.

‍

Wann wurde die Neon-Störung behoben?

Am 16. Mai begannen Gegenmaßnahmen innerhalb von 2 Stunden, die vollständige Behebung erfolgte nach rund 3,5 Stunden um 17:43 UTC.

‍
Am 19. Mai erfolgten erste Maßnahmen innerhalb von 90 Minuten, und die Störung wurde nach rund 4 Stunden um 17:10 UTC vollständig behoben.

‍

16 Mai MTTD: ca. 2 Minuten

17 Mai MTTR: ca. 3,5 Stunden

18 Mai MTTD: ca. 1 Minute

19 Mai MTTR: ca. 4 Stunden

‍

Wer war von der Neon-Störung betroffen und wie schwerwiegend war sie?

Kunden, die Neon-Datenbanken mit Scale-to-Zero-Konfigurationen in AWS us-east-1 nutzten, waren direkt betroffen. Sie konnten keine inaktiven Datenbanken aktivieren oder neu erstellen, was zu einer Unterbrechung von Entwicklungsabläufen und CI/CD-Prozessen führte.

‍

Am stärksten betroffen waren:

‍

• Datenbanken mit Autosuspend-Konfiguration (konnten nicht neu gestartet werden)
  
• Workflows zur Datenbankerstellung
  
  

Teilausfälle:

‍

• Proxy-Rate-Limit-Fehler während der Mitigationsschritte („Rate Limit Exceeded“)
  
• Aktive Datenbanken und Kunden außerhalb von AWS us-east-1 waren nicht betroffen.

Wie hat Neon während der Störung kommuniziert?

Neon kommunizierte während der gesamten Störung regelmäßig und transparent, vor allem über kurze öffentliche Updates, in denen die Störungen bestätigt und ausführliche Postmortems angekündigt wurden.

‍

Während die internen Maßnahmen schnell voranschritten, fehlten in den externen Mitteilungen allerdings Details in Echtzeit – besonders während des Regressionsvorfalls am 19. Mai. Kunden, die auf präzise Informationen angewiesen waren, waren über den zeitlichen Rahmen der Problemlösung verunsichert.

Welche Muster hat die Störung bei Neon aufgezeigt?

Die Störung zeigte wiederkehrende Risiken bei skalierter Infrastruktur:

• IP-Erschöpfung als versteckter Infrastruktur-Engpass
  
• Konfigurationsregressionen während der Incident-Behebung
  
• Kubernetes-Cluster, die unter dynamischer Last die vorgesehenen Pod-Limits überschreiten

Kurzfassung

Am 16. und 19. Mai 2025 kam es bei Neon zu zwei Ausfällen mit insgesamt 5,5 Stunden Dauer, verursacht durch IP-Erschöpfung in Kubernetes-Subnets in AWS us-east-1. Nutzer konnten keine Datenbanken mit Autoscaling-Konfigurationen aktivieren. Neon reagierte mit schnellen Gegenmaßnahmen und transparenter, wenn auch knapper Kommunikation. Die Incidents unterstreichen die Bedeutung robuster Infrastrukturschutzmaßnahmen, wirksamer Konfigurationsverwaltung und klarer, zeitnaher Kommunikation bei kritischen Störungen.

‍