Wer heute eine Webanwendung oder API in der Cloud betreibt, kommt an einer Web Application Firewall kaum vorbei. Die Frage ist nur: welche? Cloudflare, AWS und Microsoft Azure bieten alle drei eine WAF an, doch die Preismodelle, Architekturen und Funktionsumfänge unterscheiden sich deutlich. Cloudflare bündelt seine WAF in Flatrate-Pläne, AWS rechnet pro Regel und Anfrage ab, und Azure kennt zwei völlig unterschiedliche Produktlinien: Application Gateway WAF v2 und Front Door WAF. Für Teams in Deutschland und der DACH-Region, die gerade eine Cloud-Migration planen oder ihre bestehende Absicherung überdenken, macht das den Vergleich unübersichtlich.
Dieser Artikel stellt die drei Anbieter Stand September 2026 gegenüber: mit aktuellen Preisen direkt von den Hersteller-Seiten, technischen Spezifikationen, Kostenszenarien auf Basis realer Traffic-Werte, einem Migrationsleitfaden und einer klaren Einschätzung, welche Lösung zu welchem Einsatzszenario passt.
Der Vergleich lohnt sich gerade jetzt. Alle drei Anbieter haben ihre WAF-Produkte in den vergangenen Monaten umgebaut: Microsoft zieht Kunden von klassischen WAF-Profilen zu einem neuen Policy-Modell, AWS hat seine Preisdokumentation im August 2026 aktualisiert und neue Traffic-Funktionen ergänzt, und Cloudflare hat sein Bot-Management über mehrere Pläne hinweg feiner gestaffelt. Wer seine Entscheidung noch auf Preisangaben von 2024 oder 2025 stützt, rechnet mit veralteten Zahlen.
Was eine Web Application Firewall 2026 leisten muss
Eine Web Application Firewall filtert HTTP- und HTTPS-Verkehr, bevor er eine Anwendung erreicht, und blockiert Muster wie SQL-Injection, Cross-Site-Scripting oder automatisierten Bot-Traffic. Anders als eine klassische Netzwerk-Firewall arbeitet sie auf Layer 7 und versteht den Inhalt einer Anfrage, nicht nur Quelle und Ziel eines Pakets. Wie sich eine WAF von einem API Gateway abgrenzt, das eher Routing und Authentifizierung übernimmt, haben wir in unserem Vergleich von WAF und API Gateway bereits eingeordnet.
2026 hat sich der Druck auf diese Schicht erhöht. Angriffe verlagern sich zunehmend auf APIs statt auf klassische Weboberflächen, Bot-Netzwerke automatisieren Scraping und Credential Stuffing, und Regulierung wie NIS2 verlangt von Betreibern kritischer Dienste nachweisbare Schutzmaßnahmen. Gleichzeitig hat sich die Kategorie Security Misconfiguration in der aktuellen OWASP-Rangliste von Platz 5 auf Platz 2 vorgearbeitet, was zeigt, wie oft falsch konfigurierte Schutzschichten selbst zum Risiko werden. Unseren Blick auf die komplette Rangliste gibt es im Artikel zu den OWASP Top 10 2025. Eine WAF ersetzt saubere Konfiguration nicht, reduziert aber die Angriffsfläche, solange sie richtig eingerichtet ist.
Für DACH-Unternehmen kommt ein zweiter Faktor hinzu: die Herkunft der Daten. Wer personenbezogene Daten verarbeitet und dabei eine WAF eines US-Anbieters einsetzt, sollte klären, wo Logs und Metadaten gespeichert werden und ob Standardvertragsklauseln oder EU-Rechenzentren zum Einsatz kommen. Alle drei Anbieter bieten inzwischen EU-Regionen für ihre Kontrollebenen an, die konkrete Ausgestaltung unterscheidet sich aber je nach Produkt und Tarif und gehört in jedes Lastenheft, bevor eine Entscheidung fällt.
Hinzu kommt ein praktischer Punkt, der in vielen Vergleichen fehlt: die Reaktionszeit im Ernstfall. Wenn ein Angriff läuft, zählt jede Minute bis zur ersten Gegenmaßnahme. Cloudflares zentrales Regelwerk lässt sich innerhalb weniger Minuten global anpassen, weil eine Änderung sofort im gesamten Edge-Netzwerk greift. Bei AWS und Azure hängt die Reaktionsgeschwindigkeit stärker davon ab, wie gut das eigene Team mit den jeweiligen APIs und Automatisierungswerkzeugen vertraut ist, denn ohne vorbereitete Skripte oder Runbooks dauert eine manuelle Regeländerung im Portal spürbar länger als bei Cloudflare.
Cloudflare WAF im Überblick
Cloudflare betreibt sein WAF-Angebot nicht als Einzelprodukt, sondern als Bestandteil seiner Site-Pläne, die auf einem globalen Edge-Netzwerk laufen. Laut offiziellen Angaben von Cloudflare erstreckt sich dieses Netzwerk 2026 über mehr als 330 Städte in über 125 Ländern. Traffic wird dadurch dort gefiltert, wo er ankommt, nicht erst nach dem Umweg zu einer zentralen Region.
Der kostenlose Plan enthält bereits ein Basis-Regelwerk und einfachen Bot-Schutz, allerdings mit begrenztem Anfragevolumen. Ab dem Pro-Plan kommt das vollständige Managed Ruleset hinzu, das sich eng an den OWASP Core Rule Set anlehnt, dazu Super Bot Fight Mode. Der Business-Plan ergänzt eigene Regeln, Page Shield gegen Angriffe auf clientseitige Skripte und ein deutlich größeres Anfragekontingent. Ganz oben steht Enterprise mit individuellem Zuschnitt und einem separat verhandelten Bot-Management-Add-on. Praktisch für Teams, die parallel eigene Regeln testen wollen: Wer Schwachstellen vor dem Go-Live prüfen möchte, findet in unserem Vergleich von Burp Suite und OWASP ZAP zwei Werkzeuge dafür.
Der große Vorteil von Cloudflare liegt im Bündel: WAF, CDN, unmetered DDoS-Schutz und DNS laufen über dieselbe Plattform und denselben Preis. Der Nachteil zeigt sich, sobald der Traffic wächst, denn die Anfragekontingente sind je Plan gedeckelt, und ein Sprung in den nächsten Tarif kostet spürbar mehr.
Technisch bindet sich Cloudflare außerdem enger an das eigene Produktportfolio als AWS oder Azure. Wer bereits Cloudflare Workers für Edge-Logik nutzt, kann WAF-Ereignisse direkt in eigenen Code einspeisen, etwa um Anfragen dynamisch umzuleiten statt sie nur zu blocken. Für Teams ohne Cloudflare-Erfahrung bedeutet das aber auch, sich in ein neues Ökosystem mit eigener Terminologie einzuarbeiten, von Zonen über Rulesets bis zu Page Rules, was anfangs mehr Zeit kostet als ein einzelnes Regelwerk zu pflegen.
AWS WAF im Überblick
AWS WAF verfolgt einen anderen Ansatz. Statt fester Pläne zahlen Kunden für jede einzelne Komponente: pro Web ACL, pro Regel oder Regelgruppe und pro Million geprüfter Anfragen. Das Produkt ist eng mit dem restlichen AWS-Ökosystem verzahnt und lässt sich vor CloudFront, Application Load Balancer, API Gateway, AppSync oder Cognito schalten.
Zu den AWS Managed Rules zählt unter anderem ein Core Rule Set, das sich an OWASP-Klassifizierungen orientiert, sowie eine Regelgruppe für bekannte fehlerhafte Eingabemuster. Für Bot-Erkennung gibt es die separat abgerechnete Bot-Control-Regelgruppe in zwei Varianten: Common Bot Control für breite Erkennung und Targeted Bot Control für gezielte Abwehr etwa gegen Scraping oder Account-Takeover-Versuche. Beide Varianten liefern laut AWS-Dokumentation ein monatliches Freikontingent, bevor Anfragen kostenpflichtig werden.
Die AWS-Sicherheitsdokumentation aktualisierte ihre Best-Practice-Beispiele zuletzt am 4. September 2026 und zeigt darin, wie Teams typische Regelpakete zusammenstellen und deren monatliche Kosten kalkulieren. Das Modell ist transparent, verlangt aber, dass Teams selbst genau nachrechnen, was sie tatsächlich brauchen. Ohne Cloudflares Edge-Netzwerk läuft die Filterung dort, wo die jeweilige AWS-Ressource liegt, was bei global verteilten Nutzern zu höherer Latenz führen kann als bei einem Anycast-Netzwerk.
Wer AWS WAF über mehrere Konten hinweg zentral verwalten will, kann zusätzlich AWS Firewall Manager einsetzen, um Regelwerke organisationsweit auszurollen und durchzusetzen, statt jedes Konto einzeln zu pflegen. Das ist besonders für Konzerne mit mehreren AWS-Konten je Abteilung relevant, kostet aber wiederum eine eigene monatliche Gebühr pro verwalteter Richtlinie. Für Einzelprojekte lohnt sich der Aufwand selten, für gewachsene AWS-Landschaften mit Dutzenden Konten dagegen meist schon, weil sich Inkonsistenzen zwischen Teams sonst kaum vermeiden lassen.
Azure WAF im Überblick: Application Gateway und Front Door
Microsoft bietet WAF-Schutz über zwei unterschiedliche Produkte an, was den Vergleich zusätzlich verkompliziert. Application Gateway WAF v2 ist die regionale Variante, gebunden an eine Azure-Region und typischerweise für interne oder regional begrenzte Workloads gedacht. Azure Front Door WAF dagegen läuft, ähnlich wie Cloudflare, über ein globales Edge-Netzwerk, das Microsoft mit mehr als 80 Regionen und über 500 Rechenzentren weltweit angibt.
Bei Application Gateway WAF v2 zahlen Kunden pro Policy, pro eigener Regel, für das Default Ruleset als Managed Ruleset und zusätzlich nach geprüften Anfragen, getrennt nach eigenen und verwalteten Regeln. Front Door dagegen bündelt WAF-Funktionen in die Tarifstufe: Der Standard-Tarif deckt nur eigene Regeln ab, ohne Managed Ruleset, während Premium ein vollständiges Managed Ruleset samt eigenem Bot-Manager-Regelsatz einschließt. Microsoft hat die alten klassischen WAF-Profile bereits seit April 2025 nicht mehr für Neukunden geöffnet, sie laufen laut Preisdokumentation zum 31. März 2027 endgültig aus. Wer heute plant, landet also zwangsläufig beim v2-Modell oder bei Front Door.
Für Unternehmen, die ohnehin auf Microsoft 365, Entra ID oder anderen Azure-Diensten aufbauen, liegt der Charme in der einheitlichen Verwaltung über dasselbe Portal und dieselben Compliance-Werkzeuge. Wer produktiv mit HTTP-Sicherheitsheadern arbeitet, findet ergänzend unsere Anleitung zu HTTP Security Headers mit Helmet.js, die sich unabhängig vom gewählten WAF-Anbieter umsetzen lässt.
Ein Detail, das in Vergleichen häufig untergeht: Azure Policy erlaubt es, WAF-Konfigurationen als Compliance-Regel im gesamten Tenant durchzusetzen, etwa um sicherzustellen, dass niemand versehentlich eine Ressource ohne aktive WAF-Richtlinie ausrollt. Für Teams mit strengen internen Governance-Vorgaben, wie sie in regulierten Branchen üblich sind, ist das ein handfester organisatorischer Vorteil gegenüber Anbietern, bei denen jedes Team seine WAF-Konfiguration unabhängig pflegt.
Preisvergleich 2026: Was Cloudflare, AWS und Azure WAF wirklich kosten
Die folgende Tabelle zeigt die offiziellen Einstiegspreise der drei Anbieter, Stand September 2026. Cloudflare-Preise gelten bei jährlicher Abrechnung, AWS- und Azure-Preise sind nutzungsbasiert und variieren mit dem tatsächlichen Traffic.
| Tarif | Basispreis | Enthaltene Regeln | Bot-Schutz | Anfragekontingent |
|---|---|---|---|---|
| Cloudflare Free | 0 $/Monat | Basis-Managed-Rules | Basis | ca. 10.000/Monat |
| Cloudflare Pro | 20 $/Monat | Volles Managed Ruleset (OWASP-nah) | Bot Fight Mode | ca. 1 Mio./Monat |
| Cloudflare Business | 200 $/Monat | Managed + eigene Regeln, Page Shield | Super Bot Fight Mode | ca. 10 Mio./Monat |
| Cloudflare Enterprise | individuell | Vollausbau | Bot Management (Zusatzkosten) | individuell |
| AWS WAF (Web ACL) | 5 $/Monat | je 1 $/Regel oder Regelgruppe | Bot Control ab 10 $/Monat | 0,60 $/Mio. Anfragen |
| Azure App Gateway WAF v2 | 5 $/Monat (Policy) | 20 $/Managed Ruleset, 1 $/eigene Regel | über eigene Regeln | 0,6–1 $/Mio. Anfragen |
| Azure Front Door Standard | 35 $/Monat | nur eigene Regeln | nicht enthalten | nutzungsbasiert |
| Azure Front Door Premium | 330 $/Monat | Managed Ruleset inklusive | Bot-Manager-Ruleset inklusive | ca. 1,50 $/Mio. Anfragen |
Auffällig: Cloudflare deckelt den Preis über feste Kontingente, während AWS und Azure App Gateway jede zusätzliche Regel und jede Million Anfragen einzeln berechnen. Azure Front Door Premium wiederum bündelt fast alles in eine hohe Grundgebühr, ähnlich wie Cloudflare Business, allerdings mit anderem Rechenweg für Mehrverbrauch. Quellen für alle Werte sind die offiziellen Preisseiten von Cloudflare, AWS und Azure.
Technische Spezifikationen im direkten Vergleich
Preise allein sagen wenig über die technische Passung aus. Die folgende Tabelle stellt die wichtigsten Architektur- und Funktionsmerkmale gegenüber.
| Merkmal | Cloudflare WAF | AWS WAF | Azure WAF |
|---|---|---|---|
| Bereitstellungsmodell | Globales Edge-Netzwerk (Anycast) | Regional, an CloudFront/ALB/API Gateway gebunden | Regional (App Gateway) oder global (Front Door) |
| Netzwerkgröße | 330+ Städte, 125+ Länder | 750+ CloudFront-PoPs, 100+ Städte, 50+ Länder | 80+ Regionen, 500+ Rechenzentren |
| Preismodell | Flatrate je Site-Plan | Vollständig nutzungsbasiert | Nutzungsbasiert oder gebündelt (Front Door) |
| Managed Ruleset / OWASP CRS | Ab Pro-Plan enthalten | Core Rule Set als Managed-Rule-Gruppe | Default Ruleset (App Gateway) bzw. inklusive bei Front Door Premium |
| Bot-Management | Bot Fight Mode ab Pro, Super Bot Fight ab Business | Bot Control (Common/Targeted), separat abgerechnet | Bot-Manager-Ruleset in Front Door Premium |
| Rate Limiting | Im Plankontingent enthalten | Rate-based Rules, regulär abgerechnet | Über eigene Regeln konfigurierbar |
| Eigene Regeln (Custom Rules) | Ab Business-Plan | Ja, Kern des Produkts | Ja, 1 $/Regel/Monat (App Gateway) |
| DDoS-Integration | Unmetered DDoS-Schutz auf allen Plänen | AWS Shield Standard inklusive, Advanced kostenpflichtig | Azure DDoS Protection separat, Front Door mit integriertem L7-Schutz |
| Multi-Cloud-Fähigkeit | Ja, unabhängig vom Origin-Anbieter | An AWS-Ressourcen gebunden | An Azure-Ressourcen gebunden |
| Kostenloser Einstieg | Ja (Free-Plan) | Nein, nur Bot-Control-Freikontingent | Nein |
| Infrastructure-as-Code | Terraform-Provider, API | Terraform-Provider, CloudFormation | Terraform-Provider, Bicep/ARM |
Die Netzwerkgröße ist mehr als eine Marketingzahl. Sie bestimmt, wie nah die Filterung am Nutzer stattfindet und wie schnell verdächtiger Traffic abgefangen wird, bevor er den Ursprungsserver überhaupt erreicht. Bei regional gebundenen Diensten wie Application Gateway WAF v2 liegt dieser Vorteil naturgemäß nicht vor.
Bemerkenswert ist außerdem, wie unterschiedlich die drei Anbieter DDoS-Schutz und WAF miteinander verzahnen. Cloudflare behandelt beides als untrennbares Paket, jeder Plan ab Free bringt unmetered DDoS-Abwehr automatisch mit. AWS trennt WAF und AWS Shield sauber, Shield Standard ist zwar kostenlos in CloudFront und Route 53 enthalten, für tiefere Schutzstufen braucht es aber Shield Advanced als eigenes, kostenpflichtiges Produkt. Azure verhält sich ähnlich zweigeteilt: Netzwerkweiter DDoS-Schutz läuft separat, während Front Door zumindest auf Layer 7 einen integrierten Basisschutz mitbringt. Wer DDoS-Abwehr fest einplant, sollte diese Zusatzkosten von Anfang an mit in die Kalkulation aufnehmen, nicht erst nachträglich.
API-Sicherheit als Sonderfall
Klassische WAF-Regeln wurden ursprünglich für HTML-Formulare und Browser-Traffic entwickelt. APIs verhalten sich anders: Sie senden strukturierte JSON- oder GraphQL-Payloads, oft ohne klassische Session-Cookies, und werden häufiger von Maschinen als von Menschen aufgerufen. Alle drei Anbieter haben ihre Produkte in den vergangenen Jahren um API-spezifische Funktionen erweitert, mit unterschiedlicher Reife.
Cloudflare bietet auf Business- und Enterprise-Plänen eine API-Schema-Validierung an, die Anfragen gegen eine hochgeladene OpenAPI-Spezifikation prüft und Abweichungen markiert oder blockiert. AWS WAF lässt sich vor API Gateway und AppSync schalten und kann darüber auch GraphQL-Endpunkte absichern, verlangt aber, dass Teams eigene Regeln für JSON-Body-Inspektion definieren, da die Standard-Regelgruppen primär für klassische Web-Payloads gebaut sind. Azure wiederum bindet WAF-Schutz über Front Door direkt vor Azure API Management ein, sodass Authentifizierung, Rate Limiting und Schema-Validierung im selben Produkt zusammenlaufen.
Für reine API-first-Produkte, bei denen kein klassisches Frontend mehr existiert, lohnt sich ein genauer Blick auf diese Funktionen, weil generische WAF-Regelwerke Angriffe auf APIs, etwa exzessive Datenexposition oder fehlerhafte Objektberechtigungen, oft nicht zuverlässig erkennen. Eine WAF ist hier eine zusätzliche Schicht, kein Ersatz für saubere Autorisierungslogik auf Anwendungsebene.
In der Praxis bedeutet das für Entwicklerteams, dass eine WAF-Entscheidung selten isoliert getroffen werden sollte. Wer bereits ein API-Gateway oder eine dedizierte API-Security-Lösung betreibt, sollte prüfen, welche Erkennungsfunktionen sich überschneiden, statt dieselbe Schutzlogik doppelt zu pflegen. Überschneidungen sind nicht per se schädlich, sie kosten aber unnötig Zeit bei der Fehlersuche, wenn zwei Systeme dieselbe Anfrage aus unterschiedlichen Gründen blockieren und niemand im Team sofort erkennt, welches Regelwerk zuerst gegriffen hat.
Managed Rulesets und OWASP Core Rule Set im Vergleich
Alle drei Anbieter lehnen ihre Standard-Regelwerke an das offene OWASP Core Rule Set an, setzen es aber unterschiedlich um. Cloudflare pflegt ein eigenes Managed Ruleset, das kontinuierlich mit Bedrohungsdaten aus dem eigenen Netzwerk aktualisiert wird und ab dem Pro-Plan automatisch aktiv ist. AWS bietet die AWS Managed Rules als separate Regelgruppen an, darunter ein Core-Rule-Set-Äquivalent und eine Gruppe gegen bekannte fehlerhafte Eingaben, die sich einzeln zubuchen und kombinieren lassen. Azure nennt sein Standardregelwerk schlicht Default Ruleset und bindet es entweder kostenpflichtig in Application Gateway ein oder liefert es gebündelt mit Front Door Premium.
Der praktische Unterschied zeigt sich bei Tuning und Wartung. Bei AWS und Azure zahlt man für jede zusätzliche Regelgruppe, was Teams dazu zwingt, genau abzuwägen, welche Schutzebenen sie wirklich brauchen. Cloudflare nimmt diese Entscheidung großteils ab, da das Regelwerk im Plan enthalten ist, lässt Teams aber weniger granular sehen, wofür sie eigentlich zahlen. Wer eigene Regeln ergänzen will, kann das bei allen drei Anbietern, wenn auch mit unterschiedlicher Syntax: Cloudflare nutzt eine eigene Expression Language, AWS setzt auf strukturierte Rule-Statements in JSON, Azure konfiguriert Regeln über Match-Bedingungen im Portal, per ARM-Template oder Bicep.
Ein weiterer Unterschied liegt darin, wie schnell neue Regeln gegen aktuelle Bedrohungen ausgerollt werden. Cloudflare aktualisiert sein Managed Ruleset zentral für alle Kunden gleichzeitig, sobald ein neues Angriffsmuster im eigenen Netzwerk beobachtet wird, ohne dass Nutzer manuell eingreifen müssen. AWS und Azure veröffentlichen Updates für ihre Managed Rules ebenfalls automatisch, überlassen es Kunden aber, ob eine neue Version sofort aktiv wird oder erst nach eigener Prüfung. Für Teams mit wenig Kapazität zur laufenden Pflege ist die automatische Variante von Cloudflare oft die praktikablere Wahl, für Teams mit strengen Change-Management-Prozessen kann die Kontrolle bei AWS und Azure dagegen ein Vorteil sein.
// Beispiel: AWS WAF Rate-based Rule als Terraform-Ressource
resource "aws_wafv2_web_acl" "api_protection" {
name = "api-protection"
scope = "REGIONAL"
default_action {
allow {}
}
rule {
name = "rate-limit-per-ip"
priority = 1
action {
block {}
}
statement {
rate_based_statement {
limit = 2000
aggregate_key_type = "IP"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "rate-limit-per-ip"
sampled_requests_enabled = true
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "api-protection"
sampled_requests_enabled = true
}
}Bot-Management und Rate Limiting im Vergleich
Automatisierter Traffic ist 2026 einer der Hauptgründe, warum Teams überhaupt eine WAF einführen, sei es gegen Scraping, Credential Stuffing oder das Abgreifen von Ticket- und Sneaker-Drops. Cloudflare unterscheidet zwischen Bot Fight Mode auf dem Pro-Plan, der offensichtliche Bots blockiert, und Super Bot Fight Mode auf Business, das verhaltensbasierte Erkennung ergänzt. Die volle Bot-Management-Suite mit granularer Steuerung guter und schlechter Bots bleibt Enterprise-Kunden vorbehalten und wird separat verhandelt.
AWS trennt Bot Control in zwei Varianten. Common Bot Control erkennt breite Kategorien wie Suchmaschinen-Crawler oder einfache Scraper und liefert laut AWS-Dokumentation die ersten 10 Millionen Anfragen im Monat kostenlos. Targeted Bot Control geht tiefer, etwa gegen Account-Takeover-Versuche, mit einem kleineren Freikontingent von 1 Million Anfragen. Danach greift die reguläre Abrechnung pro Million Anfragen zusätzlich zur monatlichen Grundgebühr von 10 $ je Web ACL.
Azure bündelt sein Bot-Manager-Ruleset ausschließlich in Front Door Premium, ohne separate Abrechnung nach Anfragen. Wer nur Application Gateway WAF v2 nutzt, muss Bot-Abwehr über eigene Regeln nachbauen, etwa durch Rate Limiting nach IP oder User-Agent, was mehr manuelle Pflege verlangt als ein dediziertes Bot-Produkt. Bei Rate Limiting insgesamt gilt: Cloudflare liefert es im Plankontingent mit, AWS und Azure behandeln es als reguläre Regel mit den üblichen Kosten pro Regel und Anfrage.
Ein oft unterschätzter Punkt bei Bot-Schutz ist die Pflege guter Bots. Suchmaschinen-Crawler, Uptime-Monitore und legitime Preisvergleichs-Bots sollen weiterlaufen, während schädliche Automatisierung blockiert wird. Cloudflare pflegt dafür eine Liste verifizierter guter Bots, die sich in den meisten Fällen automatisch von Blockregeln ausnehmen lässt. Bei AWS und Azure liegt diese Feinabstimmung stärker in der Verantwortung des eigenen Teams, was mehr Kontrolle, aber auch mehr Pflegeaufwand bedeutet, besonders wenn sich die Liste erwünschter Bots über die Zeit ändert.
Kostenszenarien und unabhängige Einschätzungen
Konkrete, unabhängig gemessene Latenz- oder Erkennungsraten für alle drei Produkte sind öffentlich kaum zu finden, die Anbieter veröffentlichen dazu keine vergleichbaren Zahlen. Was sich dagegen sauber berechnen lässt, ist die Kostenstruktur bei identischer Last, direkt aus den offiziellen Preisangaben. Für ein Szenario mit 10 Millionen Anfragen im Monat, einem Regelwerk und fünf eigenen Regeln ergibt sich nach den AWS-eigenen Rechenbeispielen aus der Sicherheits-Best-Practice-Dokumentation ein Betrag von etwa 18 $ monatlich bei AWS WAF: 5 $ für den Web ACL, 7 $ für sieben Regeln beziehungsweise Regelgruppen und 6 $ für die geprüften Anfragen.
Bei Azure Application Gateway WAF v2 kommt für dasselbe Szenario laut offizieller Preisseite ein Betrag von rund 46 $ monatlich zusammen, weil das Managed Ruleset dort mit 20 $ Grundgebühr plus separater Anfragenabrechnung zu Buche schlägt. Cloudflare deckt ein Volumen von 10 Millionen Anfragen erst im Business-Plan ab 200 $ monatlich ab, dafür sind darin bereits DDoS-Schutz, CDN und ein deutlich breiteres Funktionspaket enthalten, ein direkter Kostenvergleich hinkt hier also etwas.
Skaliert man dasselbe Rechenmodell auf 100 Millionen Anfragen im Monat, ein realistischer Wert für mittelgroße SaaS-Plattformen oder stark frequentierte Onlineshops, verschiebt sich das Bild spürbar zugunsten der nutzungsbasierten Modelle bei kleineren Regelmengen, während gebündelte Pläne mit steigendem Volumen relativ günstiger werden. Die folgende Tabelle rechnet das exemplarisch durch, bei gleichbleibender Regelanzahl.
| Anbieter | Grundgebühr | Kosten für Regeln | Kosten für 100 Mio. Anfragen | Geschätzt gesamt |
|---|---|---|---|---|
| AWS WAF (1 Web ACL, 7 Regeln) | 5 $ | 7 $ | 60 $ (0,60 $/Mio.) | ca. 72 $/Monat |
| Azure App Gateway WAF v2 (1 Policy, 5 Regeln + Ruleset) | 25 $ | 5 $ | ca. 160 $ (gemischt 0,6–1 $/Mio.) | ca. 190 $/Monat |
| Azure Front Door Premium (Ruleset inklusive) | 330 $ | inklusive | ca. 150 $ (ca. 1,50 $/Mio.) | ca. 480 $/Monat |
| Cloudflare Business (bis 10 Mio. im Kontingent) | 200 $ | inklusive | Mehrverbrauch nach Zusatzvereinbarung | ab 200 $/Monat, variabel |
Bei 100 Millionen Anfragen bleibt AWS WAF rechnerisch am günstigsten, sofern man mit wenigen, gezielt ausgewählten Regeln auskommt. Sobald jedoch zusätzliche Managed-Rule-Gruppen, Bot Control und Rate-based Rules dazukommen, nähert sich die AWS-Rechnung schnell dem Niveau von Azure App Gateway an, da jede weitere Komponente separat abgerechnet wird. Cloudflare Business deckt dieses Volumen bereits im Grundkontingent ab, größere Ausreißer nach oben verhandelt Cloudflare individuell nach.
Redaktionelle Einordnungen bestätigen dieses Bild aus unterschiedlichen Blickwinkeln. Eine 2026er Analyse von Reintech beschreibt AWS WAF als Lösung mit tiefer AWS-Integration, Cloudflare als edge-first ausgelegt und Azure als Ökosystem-Entscheidung für bestehende Microsoft-Kunden. Der unabhängige Vergleichsdienst openappsec.io ordnet in seiner 2026er Marktübersicht alle drei Anbieter als ausgereifte, aber unterschiedlich komplexe Optionen ein, während Vergleichsplattformen wie SpotSaaS die operative Komplexität von AWS WAF als höher einstufen als bei Cloudflares plangebundenem Modell, weil Teams bei AWS jede Regel und jedes Kontingent selbst im Blick behalten müssen.
Reale Einsatzszenarien: Fünf Beispiele aus der Praxis
Wie sich die drei WAFs in der Praxis schlagen, hängt stark vom jeweiligen Betriebsmodell ab. Fünf typische Szenarien zeigen, wo welche Lösung ihre Stärken ausspielt.
- Online-Handel mit Spitzenlast an Aktionstagen: Ein Shop, der an Tagen wie Black Friday ein Vielfaches des normalen Traffics verarbeitet, profitiert von Cloudflares Edge-Netzwerk und dem inkludierten, unmetered DDoS-Schutz, ohne dass eine kurzfristige Lastspitze sofort die Rechnung sprengt.
- SaaS-Produkt vollständig auf AWS: Ein Team, dessen gesamte Infrastruktur bereits auf CloudFront, ALB und API Gateway läuft, spart sich einen zusätzlichen Anbieter und kann AWS WAF direkt über dieselben IAM-Rollen und CloudWatch-Dashboards steuern wie den Rest der Plattform.
- Behörde oder Konzern mit Microsoft-Rahmenvertrag: Organisationen, die ohnehin Microsoft 365, Entra ID und Azure DevOps einsetzen, können Azure Front Door Premium in bestehende Compliance- und Reporting-Prozesse einbinden, ohne ein weiteres Vertragsverhältnis aufzubauen.
- Ticket- oder Release-Plattform mit hohem Bot-Druck: Seiten, die zu Verkaufsstarts massenhaft automatisierte Zugriffe abwehren müssen, brauchen dedizierte Bot-Erkennung, wie sie AWS mit Targeted Bot Control oder Cloudflare mit Super Bot Fight Mode anbieten, deutlich mehr als reine Rate-Limit-Regeln.
- Fintech-Anwendung mit strengen Audit-Anforderungen: Wo jede Regeländerung dokumentiert und über Infrastructure-as-Code nachvollziehbar sein muss, punkten AWS und Azure mit granularer, versionierbarer Regelkonfiguration über Terraform, während Cloudflares plangebundenes Modell hier weniger Feinsteuerung bietet.
In allen fünf Fällen gilt: Die WAF ersetzt keine sauber gehärtete Anwendung. Wer zusätzlich absichern will, wie eine WAF selbst konfiguriert wird, findet in unserer Anleitung zu ModSecurity 3 mit Nginx eine quelloffene Alternative zum Selbstbetrieb, etwa als zweite Verteidigungslinie hinter einem Cloud-WAF.
Interessant sind auch hybride Setups, bei denen zwei Anbieter parallel laufen: eine Organisation mit Kernanwendungen auf AWS betreibt beispielsweise Cloudflare als vorgelagerte Schicht für öffentliche Marketing-Seiten, während interne Dashboards direkt über AWS WAF abgesichert bleiben. Das erhöht zwar die Komplexität und verlangt zwei getrennte Regelwerke, verteilt aber auch das Risiko, falls ein Anbieter einen Ausfall oder eine Fehlkonfiguration erleidet. Für sehr große Plattformen mit mehreren unabhängigen Produktlinien ist das kein Nischenfall, sondern in der Praxis eher die Regel als die Ausnahme.
Migrationsleitfaden: Von einer WAF zur anderen wechseln
Ein WAF-Wechsel ist selten trivial, weil jede Fehlkonfiguration sofort Kunden aussperren oder umgekehrt echten Angriffsverkehr durchlassen kann. Der folgende Ablauf hat sich in der Praxis bewährt.
- Bestehende Regeln, Ausnahmen und Blocklisten aus der alten WAF vollständig dokumentieren, inklusive der Begründung, warum jede Ausnahme existiert.
- Die neue WAF zunächst im reinen Log-Modus betreiben, ohne aktive Blockierung, um zu sehen, wie sie denselben Traffic bewerten würde.
- Log-Ausgaben mehrere Tage lang mit der alten WAF vergleichen und Abweichungen bei Falsch-Positiven gezielt untersuchen.
- Kritische eigene Regeln, etwa für interne APIs oder Partnerintegrationen, einzeln nachbauen und gegen echte Testanfragen prüfen.
- DNS- oder Routing-Umstellung in einem Wartungsfenster mit niedriger Last durchführen, nicht während Spitzenzeiten.
- Nach der Umstellung mindestens 48 Stunden engmaschig überwachen und einen dokumentierten Rollback-Pfad zur alten Konfiguration bereithalten.
- Regelwerk erst nach dieser Beobachtungsphase von Log-Only auf aktives Blocken umstellen, schrittweise nach Regelkategorie statt auf einen Schlag.
Besonders der Schritt vom Log-Modus in den aktiven Blockmodus wird oft zu früh gegangen. Alle drei Anbieter unterstützen einen reinen Beobachtungsmodus, und es lohnt sich, ihn tatsächlich für mehrere Tage laufen zu lassen, bevor produktiver Traffic blockiert wird.
Ein häufiger Fehler bei der Migration ist, alte Ausnahmeregeln unreflektiert zu übernehmen, ohne zu prüfen, ob der ursprüngliche Grund noch besteht. Über Jahre gewachsene WAF-Konfigurationen enthalten oft Altlasten, etwa eine Ausnahme für einen längst abgeschalteten Partnerdienst. Eine Migration ist der richtige Zeitpunkt, jede Regel neu zu begründen statt sie blind zu kopieren. Teams, die diesen Schritt überspringen, übertragen mit hoher Wahrscheinlichkeit auch alte Schwachstellen in die neue Umgebung.
Vor- und Nachteile im Überblick
Nach Preisen, Architektur und Funktionsumfang lässt sich der Vergleich noch einmal auf die Kernargumente verdichten, die in der Praxis tatsächlich den Ausschlag geben.
Cloudflare WAF
- Vorteil: Globales Edge-Netzwerk, planbare Flatrate-Kosten, DDoS-Schutz und CDN im selben Paket, kostenloser Einstieg.
- Nachteil: Anfragekontingente je Plan gedeckelt, eigene Regeln erst ab Business-Plan, weniger granulare Kostenkontrolle als bei AWS.
AWS WAF
- Vorteil: Feingranulare, transparente Abrechnung, enge Integration in bestehende AWS-Infrastruktur, starke Infrastructure-as-Code-Unterstützung.
- Nachteil: Kein genereller Freiplan, Kosten steigen mit jeder zusätzlichen Regel und jedem Regelwerk, regionale statt globale Filterung ohne CloudFront davor.
Azure WAF
- Vorteil: Enge Anbindung an Microsoft-Ökosystem, Front Door Premium bündelt Managed Ruleset und Bot-Schutz in einer Gebühr, globales Netzwerk bei Front Door.
- Nachteil: Zwei getrennte Produktlinien mit unterschiedlichem Funktionsumfang verwirren, klassische WAF-Profile laufen 2027 aus, Application Gateway WAF v2 bleibt regional gebunden.
Compliance und Zertifizierungen für den DACH-Markt
Für regulierte Branchen zählt neben Preis und Technik auch, welche Nachweise ein Anbieter liefern kann. Alle drei WAF-Anbieter stützen sich auf Zertifizierungen ihrer jeweiligen Cloud-Plattform, darunter ISO 27001, SOC 2 Typ II und PCI DSS für die zugrundeliegende Infrastruktur. Das bedeutet aber nicht automatisch, dass die WAF-Konfiguration selbst compliant ist, denn dafür bleibt weiterhin das jeweilige Kundenteam verantwortlich, das Regeln, Logging und Zugriffsrechte korrekt einrichten muss.
Für Betreiber kritischer Infrastruktur, die unter das neue KRITIS-Dachgesetz oder die NIS2-Umsetzung fallen, wird zunehmend verlangt, Sicherheitsmaßnahmen wie eine WAF nicht nur zu betreiben, sondern auch nachvollziehbar zu dokumentieren und regelmäßig zu prüfen. Azure und AWS bieten dafür detaillierte Audit-Logs, die sich in bestehende SIEM-Systeme einspeisen lassen, Cloudflare liefert vergleichbare Logs über seine Logpush-Funktion ab dem Business-Plan. Wer noch keine zentrale Log-Auswertung betreibt, sollte das spätestens jetzt einplanen, unabhängig davon, welcher WAF-Anbieter am Ende gewählt wird.
Wichtig ist dabei auch die Aufbewahrungsdauer der Logs. Manche Prüfstellen verlangen eine Nachvollziehbarkeit von mehreren Monaten rückwirkend, was bei den Standardkontingenten aller drei Anbieter nicht automatisch enthalten ist und oft ein separates Log-Archiv erfordert, etwa in einem eigenen Object-Storage-Bucket. Wer das erst im Ernstfall bemerkt, wenn ein Auditor konkrete Nachweise verlangt, hat ein Problem, das sich mit wenig Aufwand hätte vermeiden lassen, wenn die Aufbewahrung von Anfang an mitgeplant worden wäre.
Für wen eignet sich welche Lösung?
Die Entscheidung hängt weniger von der reinen Feature-Liste ab als davon, wo eine Infrastruktur bereits steht und wie vorhersehbar der Traffic verläuft.
- Kleine Teams und Start-ups mit begrenztem Budget fahren mit Cloudflares Free- oder Pro-Plan meist am günstigsten, solange das Anfragevolumen moderat bleibt.
- Unternehmen mit vollständig AWS-basierter Architektur profitieren von der engen Integration und der feingranularen Kostenkontrolle von AWS WAF.
- Organisationen mit Microsoft-Rahmenverträgen und bestehender Azure-Governance sollten Front Door Premium gegenüber Application Gateway WAF v2 bevorzugen, sobald globale Reichweite gefragt ist.
- Seiten mit stark schwankendem, schwer planbarem Traffic wie Nachrichtenportale oder Ticketverkäufe sind mit Cloudflares plangebundenem Modell und dessen DDoS-Bündel oft besser bedient als mit reiner Pay-per-Use-Abrechnung.
- Regulierte Branchen mit Audit-Pflicht, etwa im Finanzsektor, sollten die Infrastructure-as-Code-Reife von AWS oder Azure gegenüber Cloudflares eher plangebundenem Ansatz höher gewichten.
- Multi-Cloud-Setups, die Origin-Server bei mehreren Anbietern gleichzeitig betreiben, fahren mit Cloudflare als neutraler Schicht davor am konsistentesten, weil die WAF nicht an einen einzelnen Cloud-Anbieter gebunden ist.
Zur schnellen Orientierung fasst die folgende Tabelle die Empfehlung noch einmal nach Ausgangslage zusammen.
| Ausgangslage | Empfehlung |
|---|---|
| Kein bestehender Cloud-Anbieter, kleines Budget | Cloudflare Free oder Pro |
| Vollständig AWS-basierte Infrastruktur | AWS WAF mit Firewall Manager bei mehreren Konten |
| Microsoft-Rahmenvertrag, hohe Compliance-Anforderungen | Azure Front Door Premium |
| Stark schwankender, schwer planbarer Traffic | Cloudflare Business |
| Multi-Cloud oder Origin bei mehreren Anbietern | Cloudflare als neutrale Edge-Schicht |
Das Urteil: Welche WAF gewinnt 2026?
Eine einzelne Gewinnerin gibt es nicht, dafür unterscheiden sich die drei Produkte in Architektur und Abrechnung zu stark. Für reine Kostenplanbarkeit bei kleinem bis mittlerem Traffic liegt Cloudflare vorn, mit einem Free-Plan bei 0 $ und einem klaren Sprung auf 200 $ im Business-Tarif für 10 Millionen Anfragen im Monat, DDoS-Schutz inklusive. Für Teams, die bereits tief in AWS stecken und jede Kostenposition einzeln nachvollziehen wollen, bleibt AWS WAF mit rund 18 $ im vergleichbaren Szenario die günstigste und zugleich transparenteste Option, verlangt dafür aber mehr Pflegeaufwand bei Regeln und Kontingenten.
Azure liegt bei reiner Kostenbetrachtung meist in der Mitte, mit 46 $ für Application Gateway WAF v2 im selben Szenario oder deutlich höheren, aber breiter ausgestatteten 330 $ Grundgebühr bei Front Door Premium. Den Ausschlag gibt am Ende seltener der Preis, sondern die Frage, wo eine Organisation bereits investiert hat: in Microsofts Ökosystem, in AWS-Infrastruktur oder in eine anbieterunabhängige Edge-Schicht. Wer 2026 neu plant und noch keine Cloud-Bindung hat, sollte mit Cloudflares Free- oder Pro-Plan pilotieren, da sich dort ohne Vorabinvestition am schnellsten Erfahrungswerte sammeln lassen, bevor eine größere Migration ansteht.
Für die reine Zahl aus der Überschrift gilt: Zwischen 0 $ im Cloudflare-Free-Plan und 330 $ Grundgebühr bei Azure Front Door Premium liegt eine Preisspanne, die sich nicht allein mit Feature-Unterschieden erklären lässt, sondern vor allem mit dem jeweiligen Geschäftsmodell der drei Anbieter. Cloudflare verdient an Volumen über viele kleine Kunden, AWS verdient an granularer Nutzung innerhalb eines größeren Cloud-Vertrags, und Microsoft bündelt WAF-Kosten in ein Premium-Produkt, das sich erst bei entsprechendem Umsatz und Enterprise-Anforderungen wirklich rechnet. Wer diese Logik versteht, verhandelt und plant gezielter, als wenn er nur die nackten Tabellenwerte vergleicht.
Häufig gestellte Fragen
Ist eine WAF für kleine Webseiten überhaupt notwendig?
Auch kleine Seiten werden regelmäßig von automatisierten Scans erfasst, unabhängig von ihrer Bekanntheit. Cloudflares kostenloser Plan bietet einen Basisschutz ohne laufende Kosten und ist für die meisten kleinen Projekte ein sinnvoller Einstieg.
Kann man Cloudflare WAF vor eine AWS- oder Azure-Infrastruktur schalten?
Ja, Cloudflare arbeitet unabhängig vom Hosting-Anbieter und lässt sich per DNS vor beliebige Origin-Server legen, auch wenn diese bei AWS, Azure oder einem anderen Anbieter liegen.
Was kostet AWS WAF bei sehr geringem Traffic?
Auch bei minimaler Nutzung fällt die Grundgebühr von 5 $ pro Web ACL und Monat an, zuzüglich der Kosten für aktivierte Regeln. Ein komplett kostenloser Einstieg wie bei Cloudflare existiert bei AWS WAF nicht, abgesehen vom Freikontingent bei Bot Control.
Wann lohnt sich Azure Front Door Premium gegenüber Application Gateway WAF v2?
Sobald mehrere Regeln, ein Managed Ruleset und Bot-Schutz gleichzeitig gebraucht werden, gleicht die gebündelte Grundgebühr von Front Door Premium die vielen Einzelposten von Application Gateway WAF v2 häufig aus, besonders bei globalem Publikum.
Ersetzt eine Cloud-WAF eine eigene Anwendungshärtung?
Nein. Eine WAF filtert bekannte Angriffsmuster, ersetzt aber keine sauber implementierte Authentifizierung, keine geprüften Eingaben im Code und keine aktuellen Abhängigkeiten.
Wie lange dauert eine Migration zwischen zwei WAF-Anbietern realistisch?
Für ein mittelgroßes Projekt mit einigen Dutzend eigenen Regeln sind je nach Testtiefe ein bis drei Wochen realistisch, hauptsächlich wegen der empfohlenen Beobachtungsphase im Log-Only-Modus vor der Umstellung auf aktives Blocken.
Bieten alle drei Anbieter eine Testphase ohne Vertragsbindung?
Cloudflare erlaubt über den Free-Plan einen zeitlich unbegrenzten Basistest ohne Zahlung. AWS und Azure verlangen dagegen von Beginn an eine nutzungsbasierte Abrechnung, auch wenn kleine Testmengen nur wenige Dollar kosten.
Lässt sich eine WAF auch nachträglich in eine bestehende Kubernetes- oder Container-Infrastruktur einbinden?
Ja, bei allen drei Anbietern lässt sich die WAF vor einen Ingress-Controller oder Load Balancer schalten, ohne den Anwendungscode selbst zu verändern. Cloudflare arbeitet dabei über DNS, AWS über ALB- oder CloudFront-Integration, Azure über Application Gateway oder Front Door vor dem Kubernetes-Cluster.
