TL;DR
DDoS-Scrubbing ist kein nachgelagerter Zusatz, sondern ein Resilienzmechanismus vor der Anwendung. Volumetrischer und anwendungsbezogener Angriffstraffic wird an der Edge erkannt, gefiltert und nur bereinigter Traffic an Backends weitergeleitet. Klare Failure Domains verhindern, dass Schutzschicht, Edge-Verarbeitung und Anwendung gemeinsam ausfallen.
Einleitung
Ein überlastetes Backend ist nicht zwangsläufig zu schwach dimensioniert. Häufig erreicht schlicht zu viel unerwünschter Traffic die Systeme, die ihn verarbeiten sollen. Bei einem volumetrischen DDoS-Angriff kann bereits die Netzwerkanbindung zum Engpass werden. Bei einem anwendungsbezogenen Angriff sind dagegen CPU, Verbindungen oder Datenbankzugriffe betroffen, obwohl das Traffic-Volumen unauffällig wirkt. Beide Szenarien benötigen eine Schutzschicht vor den Backends. Entscheidend ist dabei nicht nur, schädliche Anfragen zu erkennen, sondern ihre Verarbeitung räumlich und logisch von der Anwendung zu trennen. DDoS-Scrubbing an der Edge begrenzt die Last dort, wo sie entsteht, und reduziert die Auswirkungen auf nachgelagerte Systeme.
1. Überlast entsteht auf unterschiedlichen Ebenen
DDoS-Angriffe lassen sich nicht allein anhand ihrer Bandbreite bewerten. Volumetrische Angriffe zielen darauf, Leitungen, Router oder Edge-Kapazitäten zu füllen. Protokollangriffe belasten beispielsweise Verbindungsverwaltung und Zustandsverarbeitung. Auf Layer 7 können dagegen scheinbar gültige HTTP-Anfragen Ressourcen in der Anwendung, im Cache oder in angeschlossenen Datenbanken binden.
Diese Unterschiede bestimmen, wo Schutzmaßnahmen greifen müssen. Ein Filter ausschließlich im Backend kommt zu spät, wenn die Netzwerkanbindung bereits ausgelastet ist. Ein reiner Volumenschutz reicht wiederum nicht aus, wenn wenige, aber teure Requests die Anwendung überfordern. DDoS Protection muss deshalb mehrere Ebenen berücksichtigen: Netzwerk- und Transportschicht, Protokollverhalten sowie HTTP- und API-Muster.
Für den Betrieb bedeutet das: Überlastschutz ist keine einzelne Regel, sondern eine Kombination aus Erkennung, Filterung, Rate-Begrenzung und kontrollierter Weiterleitung. Die Schutzlogik muss so positioniert sein, dass unerwünschter Traffic möglichst wenig nachgelagerte Infrastruktur erreicht.
2. Scrubbing verlagert die Last aus dem Backend
Beim DDoS-Scrubbing wird eingehender Traffic an einer vorgelagerten Schutzschicht analysiert. Schadtraffic wird verworfen oder begrenzt, während legitime Verbindungen weitergeleitet werden. Die Backends erhalten dadurch nicht den vollständigen Angriffsstrom, sondern einen bereinigten Anteil. Das reduziert den Druck auf Netzwerkverbindungen, Connection Pools, CPU und Anwendungskomponenten.
Die Entlastung funktioniert allerdings nur, wenn die Edge selbst ausreichend vom Backend entkoppelt ist. Anycast kann Anfragen auf eine verteilte Edge-Infrastruktur lenken und den Angriffstraffic auf mehrere Verarbeitungspunkte verteilen. Eine Aktiv-Aktiv-Architektur vermeidet dabei die Abhängigkeit von einem einzelnen aktiven Standort oder einer einzelnen Schutzinstanz. Fällt ein Verarbeitungspfad aus, muss der Traffic nicht zwangsläufig auf ein isoliertes Standby-System warten.
Die ayedo Edge Cloud verbindet Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit DDoS Protection und Scrubbing an der Edge. Die zugrunde liegende eigene Netzwerk-Infrastruktur und das eigene Autonomous System bilden dabei eine eigenständige öffentliche Eingangsschicht vor den Anwendungen. Das Backend wird nicht zum primären Ort der Angriffsbewertung.
3. Failure Domains entscheiden über die Resilienz
Eine Schutzarchitektur ist nur belastbar, wenn ihre Failure Domains bewusst voneinander getrennt sind. Die Edge muss einen Ausfall eines Backends überstehen können. Umgekehrt darf ein Problem in einer Anwendung nicht die gesamte Traffic-Verarbeitung blockieren. Ebenso sollte die Schutzfunktion nicht ausschließlich von Komponenten abhängen, die sich im selben Netzwerk- oder Rechenbereich wie das Zielsystem befinden.
Diese Trennung hat konkrete betriebliche Folgen. Health Checks können fehlerhafte Backends aus dem Routing nehmen, während andere verfügbare Ziele weiter Traffic erhalten. Failover muss dabei kontrolliert erfolgen: Ein überlastetes Backend darf nicht durch automatisches Umschalten weitere Systeme in eine Kaskade ziehen. Backend Cloaking reduziert zusätzlich die direkte Erreichbarkeit der Ursprungsinfrastruktur und erschwert es, die Edge als Schutzschicht zu umgehen.
Für die Anwendung bedeutet das nicht, dass sie keine eigenen Schutzmechanismen benötigt. Authentisierung, Autorisierung, Request-Limits und sichere Fehlerbehandlung bleiben Aufgaben der Anwendung. Die Edge begrenzt jedoch die Last, die diese Mechanismen überhaupt verarbeiten müssen. Genau diese Arbeitsteilung macht Resilienz planbarer.
4. DDoS-Schutz braucht betriebliche Sichtbarkeit
Während eines Angriffs reicht die Aussage „der Service ist langsam“ nicht aus. Betreiber müssen unterscheiden können, ob die Ursache in der Edge, im Netzwerkpfad oder im Backend liegt. Traffic- und Usage-Statistiken helfen dabei, Veränderungen bei Volumen, Protokollen und Zielsystemen sichtbar zu machen. Zusammen mit Health Checks entsteht ein differenzierteres Bild als durch reine Backend-Metriken.
Wichtig ist außerdem die Definition von Betriebsgrenzen. Welche Anwendungen dürfen bei Überlast nur eingeschränkt verfügbar sein? Welche APIs benötigen Priorisierung? Welche Backends dürfen nicht öffentlich erreichbar sein? Ohne diese Entscheidungen bleibt Scrubbing technisch aktiv, aber organisatorisch unvollständig. Incident-Runbooks sollten deshalb festlegen, wann Schutzregeln verschärft, Backends aus dem Routing genommen oder Failover-Pfade aktiviert werden.
Die zentrale wirtschaftliche Konsequenz liegt in der Begrenzung des Schadensradius. Ein Angriff muss nicht vollständig verhindert werden, damit die Architektur resilienter ist. Wenn kritische Backends erreichbar bleiben, Wiederanlaufzeiten sinken und die Analyse nicht erst im Anwendungsteam beginnt, werden Ausfallkosten und Betriebsaufwand kontrollierbarer.
Praxis- und Betriebsszenario
Ein Unternehmen betreibt eine öffentliche API in mehreren Kubernetes-Clustern bei unterschiedlichen Providern. Während eines Angriffs steigt das Anfragevolumen stark an; ein Teil der Requests ist volumetrisch, ein anderer erzeugt teure API-Aufrufe. Ohne vorgelagerte Edge erreichen beide Muster die Cluster und erschöpfen zunächst die Loadbalancer- und anschließend die Anwendungskapazität.
Mit einer Anycast-basierten Edge werden Verbindungen zunächst verteilt und dort geprüft. DDoS-Scrubbing verwirft erkennbare Angriffsmuster, während Layer-7-Regeln anwendungsnahe Requests begrenzen. Health Checks nehmen ein überlastetes Cluster aus dem Routing, ohne die übrigen Ziele abzuschalten. Die Cluster bleiben für bereinigten Traffic erreichbar; ihre Provider und ihre konkrete Kubernetes-Ausprägung sind für die Schutzfunktion nicht entscheidend.
FAQ
Reicht DDoS-Scrubbing für den Schutz einer API aus?
Nein. Scrubbing reduziert Angriffslast an der Edge. Authentisierung, Autorisierung, Rate Limits und sichere Verarbeitung ungültiger Requests bleiben zusätzlich erforderlich.
Was unterscheidet volumetrische von anwendungsbezogenen Angriffen?
Volumetrische Angriffe überlasten Übertragungswege oder Edge-Kapazität. Anwendungsangriffe erzeugen oft weniger Traffic, verbrauchen aber gezielt Ressourcen in APIs, Services oder Datenbanken.
Warum ist Backend Cloaking relevant?
Backend Cloaking erschwert den direkten Zugriff auf Ursprungsinfrastruktur. Dadurch kann ein Angreifer die vorgelagerte Schutzschicht weniger leicht umgehen.
Fazit
DDoS-Schutz ist vor allem eine Frage der Architekturgrenzen. Je früher schädlicher Traffic verarbeitet und verworfen wird, desto weniger Ressourcen der Anwendung werden gebunden. Entscheidend sind dabei verteilte Edge-Verarbeitung, getrennte Failure Domains, kontrolliertes Failover und ausreichende Sichtbarkeit im Betrieb. Die ayedo Edge Cloud ordnet diese Aufgaben in einer eigenständigen, aktiv-aktiven Edge-Plattform vor Anwendungen und APIs ein. Resilienz entsteht dadurch nicht durch eine einzelne Schutzregel, sondern durch die Trennung von öffentlichem Traffic-Eingang, Schutzschicht und Backend.