Jetzt noch besser: unser erweitertes Rate Limiting

Ab sofort erhalten Sie ein verbessertes Nutzererlebnis, das nicht nur das Rate Limiting erleichtert, sondern auch zusätzliche Funktionen bietet und für Verbesserungen bei der Observability sorgt.

Das Rate-Limiting-Erlebnis mit der Fastly Next-Gen WAF ist jetzt noch besser und nutzerfreundlicher. Security sollte möglichst effektiv und einfach zu implementieren sein. Als einige Kunden uns mitteilten, dass ihnen die Vorteile unserer Rate-Limiting-Funktion nicht intuitiv klar gewesen waren und sie eine Weile gebraucht hatten, um sie effektiv nutzen zu können, wussten wir, dass wir nachbessern mussten. Schließlich möchten wir unseren Kunden mit jeder Funktion unseres Produkts ein Aha-Erlebnis bieten – am besten auf Anhieb! Zu solchen Aha-Momenten kommt es immer wieder während des Onboardings, wenn Neukunden feststellen, dass wir weit mehr flexible Bereitstellungsoptionen</u> bieten, als sie sich vorstellen konnten. Oder nach der Aktivierung der WAF, wenn ihnen bewusst wird, dass sie dank unserer SmartParse-Technologie</u> schneller als mit jedem anderen Produkt in den Blocking Mode wechseln können. Wir freuen uns also sehr, diese Verbesserungen auf den Markt zu bringen, um für weitere Aha-Erlebnisse beim Rate Limiting zu sorgen. 

Verbesserungen bei der Nutzerfreundlichkeit

Wir haben zwar mehrere Aktualisierungen vorgenommen, aber die größte Veränderung besteht darin, dass für das Rate Limiting von Anfragen kein Action-Signal mehr notwendig ist. Stattdessen haben wir ein neues Drop-down-Menü namens „Match type“ eingeführt. Über dieses Feld können Sie festlegen, welche Client-Anfragen nach Erreichen des Schwellenwerts blockiert oder geloggt werden sollen.

Für das Rate Limiting von Anfragen von Clients, die die in den Rate-Limiting-Regeln festgelegten Bedingungen erfüllen, wird die Option „Rule conditions“ verwendet. Bisher ließ sich dieses Verhalten durch das Einstellen des Zähl- oder Schwellenwertsignals auf denselben Wert wie den des Action-Signals erreichen. Sie werden feststellen, dass der Match Type „Rule conditions“ Ihren Anforderungen bei allgemeinen Rate-Limiting-Anwendungsfälle entspricht.

Dennoch möchten wir Ihnen die Möglichkeit bieten, unser Rate Limiting auch auf Anfragen von Clients anzuwenden, die die festgelegten Rule Conditions nicht erfüllen und mit einem anderen Signal versehen sind. Dies ist beispielsweise bei der Erkennung von Kreditkartenvalidierungsversuchen hilfreich. Unsere Dokumentation enthält ein anschauliches Beispiel für die entsprechende Konfiguration</u>. Für diesen Anwendungsfall können Sie den Match Type „Other signal“ verwenden. An dieser Stelle haben Sie die Möglichkeit, das Action-Signal auszuwählen, das zur Bewertung von Rate-Limiting-Anfragen des Client verwendet wird, die den ursprünglichen Regelbedingungen entsprechen und den Schwellenwert überschreiten.

Außerdem haben sich einige Kunden gewünscht, dass das Rate Limiting auf alle Anfragen von einem Client angewendet wird, der die festgelegten Regelbedingungen erfüllt und einen bestimmten Schwellenwert überschreitet. Dies war in der Vergangenheit zwar möglich, erforderte aber die Implementierung mehrerer Regeln. Wir haben den Workflow jetzt vereinfacht, indem wir den Match Type „All requests“ eingeführt haben.

Verbesserte Observability

Das Festlegen von Rate-Limiting-Regeln ist nur ein Aspekt der Implementierung. Als Nächstes brauchen Sie eine einfache Möglichkeit, um zu überprüfen, auf welche Anfragen das Rate Limiting angewendet werden soll bzw. angewendet wird. Zunächst können Sie dafür eine erweiterte Rate-Limiting-Regel einrichten, mit der Sie festlegen, welche Anfragen „geloggt“ oder „blockiert“ werden sollen. Sobald Sie die entsprechenden Einstellungen vorgenommen haben, können Sie in einem gestapelten Zeitreihendiagramm sehen, auf welche Anfragen die Schwellenwerte für das Rate Limiting angewendet werden und welche Anfragen für das Rate Limiting infrage kommen oder es bereits durchlaufen, weil sie den Schwellenwert überschritten haben.

Außerdem haben wir die Suche in den Anfrage-Logs vereinfacht, damit Sie Anfragen, auf die das Rate Limiting angewendet wurde, leichter finden können. Bislang mussten Sie dafür einen Filter mit der ID der entsprechenden Regel verwenden, die wiederum nicht immer leicht zu finden ist. Jetzt können Sie nach Anfragen ganz einfach über den Suchfilter ratelimited:site.threshold-signal suchen. Hier ist ein Beispiel, wie das Ganze für ein Schwellenwertsignal namens site.normal-ratelimit aussehen würde:

Nächste Schritte

Wenn Sie unser Premier Package</u> nutzen, stehen Ihnen das neue Nutzererlebnis für unser erweitertes Rate Limiting und die Verbesserungen bei der Observability sofort zur Verfügung. Setzen Sie sich andernfalls gerne mit uns in Verbindung</u>, um zu erfahren, wie Sie Ihre Websites und APIs mithilfe unserer Rate-Limiting-Funktionen vor missbräuchlichem Traffic schützen können.

Wie schon erwähnt, arbeiten wir laufend an Verbesserungen unseres Produkts und berücksichtigen dabei das Feedback unserer Kunden. Sie dürfen also gespannt sein, was sonst noch so kommt. Wir freuen uns auch über Anregungen für weitere Funktionen, die wir Ihrer Meinung nach umsetzen sollten.