Ratenbegrenzung für AWS Blu Age Runtime konfigurieren - AWS Mainframe-Modernisierung
Überblick über die RatenbegrenzungKonfigurationseigenschaftenRatenbegrenzung aktivierenIdentifizierung des KundenHeader zur RatenbegrenzungSpeicherverwaltung

AWS Der Mainframe Modernization Service (Managed Runtime Environment Experience) steht Neukunden nicht mehr zur Verfügung. Funktionen, die dem AWS Mainframe Modernization Service (Managed Runtime Environment-Erfahrung) ähneln, finden Sie unter AWS Mainframe Modernization Service (Self-Managed Experience). Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Änderung der Verfügbarkeit von AWS Mainframe Modernization.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Ratenbegrenzung für AWS Blu Age Runtime konfigurieren

AWS Blu Age Runtime enthält eine integrierte Funktion zur Ratenbegrenzung, um die Gapwalk-Anwendung vor übermäßigen Anfragen und potenziellem Missbrauch zu schützen. Das System zur Ratenbegrenzung verwendet den Token-Bucket-Algorithmus, um sowohl Burst-Kapazität als auch dauerhafte Ratenbegrenzung bereitzustellen.

Überblick über die Ratenbegrenzung

Das Ratenbegrenzungssystem bietet die folgenden Funktionen:

Token-Bucket-Algorithmus

  • Ermöglicht Burst-Traffic bis zur konfigurierten Burst-Kapazität

  • Füllt Token mit einer konstanten Geschwindigkeit auf, die auf Anfragen pro Minute basiert

  • Sorgt für eine reibungslose Ratenbegrenzung, ohne legitime Verkehrsspitzen zu blockieren

Identifizierung des Kunden

  • Identifiziert Clients anhand der IP-Adresse mit Proxy-Unterstützung

  • Unterstützungen X-Forwarded-For und X-Real-IP Header

  • Behandelt Loadbalancer- und Reverse-Proxy-Szenarien

Automatische Arbeitsspeicher-Verwaltung

  • Bereinigt automatisch abgelaufene Ratenlimit-Buckets

  • Konfigurierbare Säuberungsintervalle und Ablaufzeiten

  • Beugt Speicherlecks bei Anwendungen mit langer Laufzeit vor

HTTP-Integration

  • Gibt HTTP 429 (Too Many Requests) zurück, wenn die Grenzwerte überschritten werden

  • Schließt Standard-Header für die Ratenbegrenzung in Antworten ein

  • Stellt Informationen zum erneuten Versuch für Kunden bereit

Konfigurationseigenschaften

Konfigurieren Sie die Ratenbegrenzung in Ihrer Datei: application-main.yaml

gapwalk:
  ratelimiting:
    enabled: true                                        # Enable/disable rate limiting
    requestsPerMinute: 1000                              # Sustained rate limit per minute
    burstCapacity: 1500                                  # Maximum burst requests allowed
    includeHeaders: true                                 # Include X-RateLimit-* headers
    cleanupIntervalMinutes: 5                            # Cleanup interval for expired buckets
    bucketExpiryHours: 1                                 # Hours after which unused buckets expire
    errorMessage: "Too many requests. Try again later."  # Custom error message
    whitelistIps: ""                                     # Comma-separated IPs to bypass limiting
    perEndpointLimiting: false                           # Apply limits per endpoint (not implemented)

Beschreibungen der Immobilien

aktiviert

Hauptschalter zum Aktivieren oder Deaktivieren der Funktion zur Ratenbegrenzung. Standard: false

requestsPerMinute

Anzahl der Anfragen, die pro Minute für eine dauerhafte Ratenbegrenzung zulässig sind. Dies entspricht der Token-Nachfüllrate. Standard: 1000

Burst-Kapazität

Maximale Anzahl von Anfragen, die in einem Burst zulässig sind, bevor die Ratenbegrenzung gilt. Sollte höher seinrequestsPerMinute, als um Traffic-Spitzen zuzulassen. Standard: 1500

Header einbeziehen

Ob Header für Standardratenbegrenzungen (X-RateLimit-Limit,X-RateLimit-Remaining,X-RateLimit-Reset) in HTTP-Antworten aufgenommen werden sollen. Standard: true

cleanupIntervalMinutes

Intervall in Minuten zwischen der automatischen Bereinigung abgelaufener Ratenlimit-Buckets. Hilft, Speicherlecks zu verhindern. Standard: 5

bucketExpiryHours

Zeit in Stunden, nach deren Ablauf ungenutzte Ratenlimit-Buckets als abgelaufen gelten und für eine Bereinigung in Frage kommen. Standard: 1

errorMessage

Benutzerdefinierte Fehlermeldung, die in der JSON-Antwort zurückgegeben wird, wenn das Ratenlimit überschritten wird. Standard: "Too many requests. Try again later."

Tipps auf die weiße Liste

Durch Kommas getrennte Liste von IP-Adressen, die die Ratenbegrenzung vollständig umgehen. Nützlich für Integritätsprüfungen oder vertrauenswürdige Systeme. Standard: empty

perEndpointLimiting

Gibt an, ob separate Ratenlimits pro Endpunkt statt nur pro Client angewendet werden sollen. Derzeit nicht implementiert. Standard: false

Ratenbegrenzung aktivieren

So aktivieren Sie die Ratenbegrenzung mit den Standardeinstellungen:

gapwalk:
  ratelimiting:
    enabled: true

Identifizierung des Kunden

Das Ratenbegrenzungssystem identifiziert Kunden anhand der folgenden Prioritätsreihenfolge:

  1. X-Forwarded-For Header (erste IP, wenn durch Kommas getrennt)

  2. X-Real-IP Kopfzeile

  3. Remote-Adresse aus der HTTP-Anfrage

Auf diese Weise wird eine korrekte Identifizierung des Clients gewährleistet, wenn sich die Anwendung hinter folgenden Umständen befindet:

  • Load Balancers

  • Reverse-Proxys

  • CDNs

  • API-Gateways

Beispiel für eine Kundenidentifikation

# Direct connection
Client IP: 192.168.1.100

# Behind load balancer with X-Forwarded-For
X-Forwarded-For: 203.0.113.45, 192.168.1.100
Client IP: 203.0.113.45 (first IP used)

# Behind reverse proxy with X-Real-IP
X-Real-IP: 203.0.113.45
Client IP: 203.0.113.45

Header zur Ratenbegrenzung

Wenn includeHeaders aktiviert, werden die folgenden Header zu HTTP-Antworten hinzugefügt:

X- RateLimit -Limit

Die Obergrenze des Ratenlimits für den Kunden (Anfragen pro Minute)

X- RateLimit -Verbleibend

Die Anzahl der Anfragen, die im aktuellen Ratenlimitfenster noch übrig sind

X- RateLimit -Zurücksetzen

Der Zeitpunkt, zu dem das Ratenbegrenzungsfenster zurückgesetzt wird (Unix-Zeitstempel)

Beispiel für Antwortheader

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 847
X-RateLimit-Reset: 1640995200

Das Ratenlimit hat die Antwort überschritten

Wenn das Ratenlimit überschritten wird, gibt das System Folgendes zurück:

HTTP-Status

429 Zu viele Anfragen

Content-Type

application/json

Retry-After

Anzahl der Sekunden, die gewartet werden müssen, bevor es erneut versucht wird

{
  "error": "Rate limit exceeded",
  "message": "Too many requests. Try again later.",
  "retryAfter": 60,
  "timestamp": 1640995140000
}

Speicherverwaltung

Das System zur Geschwindigkeitsbegrenzung verwaltet den Arbeitsspeicher automatisch, um Datenlecks bei Anwendungen mit langer Laufzeit zu verhindern:

Automatische Säuberung

  • Läuft alle Minuten cleanupIntervalMinutes

  • Entfernt Eimer, die stundenlang unbenutzt waren bucketExpiryHours

  • Protokolliert die Säuberungsaktivitäten zur Überwachung

Speicher-Effizienz

  • Verwendet aus Gründen der Thread-Sicherheit parallele Datenstrukturen

  • Lazy-Bucket-Erstellung (nur bei Bedarf)

  • Effiziente Token-Bucket-Implementierung

Überwachung der Säuberungsaktivitäten

Suchen Sie in den Protokollen nach Säuberungsmeldungen:

INFO  RateLimitingService - Cleaned up 15 expired rate limiting buckets