Drosselung, Caching und Nutzungspläne

Ohne Drosselung könnte ein einzelner fehlerhafter Client oder eine Verkehrsspitze Ihre Backend-Services überlasten – etwa die Lambda-Kapazität, RDS-Verbindungen oder nachgelagerte APIs. Die Drosselung in API Gateway begrenzt die Anzahl der Anforderungen pro Sekunde und erlaubt kurze Spitzen über der konstanten Rate. Gedrosselte Anforderungen erhalten sofort eine 429 Too Many Requests-Antwort, ohne das Backend zu erreichen, wodurch nachgelagerte Ressourcen vor Überlastung geschützt werden.

Die Drosselung arbeitet auf mehreren Ebenen. Das Limit auf Kontoebene beträgt 10.000 Anforderungen pro Sekunde (RPS) mit einem Burst von 5.000 Anforderungen (Soft Limit, kann erhöht werden). Auf Stage-Ebene können Sie eine standardmäßige Drosselungsrate (RPS) und ein Burst-Limit festlegen, die für alle Methoden in der Stage gelten. Auf Methodenebene können Sie die Stage-Standards für bestimmte Endpunkte überschreiben – beispielsweise einem leseintensiven GET-Endpunkt ein höheres Ratenlimit als einem schreibintensiven POST-Endpunkt geben.

Die Drosselung von API Gateway verwendet einen Token-Bucket-Algorithmus. Tokens sammeln sich in einem Bucket bis zum Burst-Limit (maximale sofortige Kapazität). Jede Anforderung verbraucht ein Token. Tokens werden mit der Rate-Limit (konstante RPS-Rate) aufgefüllt. Ist der Bucket leer, werden Anforderungen gedrosselt. Beispiel: burst=5000, rate=1000 RPS. Zu Beginn können Sie 5000 gleichzeitige Anforderungen verarbeiten; der Bucket wird mit 1000 Tokens pro Sekunde aufgefüllt. So lassen sich kurzfristige Verkehrsspitzen abfangen, während langfristige Ratenlimits eingehalten werden.

Antwort-Caching (verfügbar für REST-API-Stages) speichert Backend-Antworten in einem von API Gateway verwalteten Cache, sodass identische Anforderungen aus dem Cache bedient werden, ohne das Backend aufzurufen. Dies reduziert die Backend-Auslastung und die Latenz und kann bei leseintensiven APIs die Kosten für Lambda-Aufrufe erheblich senken. Der Cache-Schlüssel wird anhand der Anforderung gebildet (Methode, Pfad, Query-Strings und Header entsprechend der Konfiguration). Die Cache-TTL kann von 0 bis 3600 Sekunden konfiguriert werden (Standard: 300 Sekunden).

Standardmäßig ist der Cache-Schlüssel die vollständige Anforderungs-URL. Sie können festlegen, welche Elemente zum Cache-Schlüssel beitragen: Bestimmte Abfrageparameter einschließen (z. B. pageSize, filter), irrelevante Parameter (z. B. timestamp) jedoch ausschließen. Sie können auch bestimmte Header in den Cache-Schlüssel aufnehmen. Schließen Sie vertrauliche Header aus dem Cache-Schlüssel aus, damit keine privaten Daten gemeinsame Cache-Einträge verunreinigen. Stimmen Sie den Cache-Schlüssel so ab, dass Sie die Cache-Trefferrate maximieren und gleichzeitig sicherstellen, dass unterschiedliche logische Anforderungen unterschiedliche zwischengespeicherte Antworten erhalten.

Clients können den Cache für eine bestimmte Anforderung invalidieren, indem sie den Header Cache-Control: max-age=0 einschließen. Sie können den gesamten Stage-Cache auch über die Konsole oder die API leeren. Konfigurieren Sie, ob Clients den Cache invalidieren dürfen – schränken Sie dies in der Produktion ein, damit Clients das Caching nicht absichtlich umgehen. Um selektiv Berechtigungen zum Leeren zu vergeben, fügen Sie eine Ressourcenrichtlinie hinzu oder verwenden Sie einen Lambda-Autorisierer, der prüft, ob der Aufrufer zum Leeren berechtigt ist.

Ein Usage Plan definiert Drosselungs- und Kontingentgrenzen für eine Gruppe von API-Clients. Verknüpfen Sie eine API-Stage mit einem Nutzungsplan und anschließend API keys mit diesem Plan. Jeder API-Schlüssel setzt die Grenzen des Plans unabhängig durch. Mit Nutzungsplänen können Sie abgestufte Zugriffe anbieten: einen kostenlosen Plan mit 100 RPM/10.000 Anforderungen pro Tag und einen Pro-Plan mit 1.000 RPM/100.000 Anforderungen pro Tag. Dies ist das Modell für monetarisierte APIs und Partnerintegrationen, bei denen verschiedene Clients unterschiedliche Ratenbegrenzungen benötigen.

API keys sind undurchsichtige Zeichenfolgentoken, die Clients im Anforderungsheader x-api-key mitsenden. API Gateway validiert den Schlüssel und ordnet die Anforderung dem entsprechenden Nutzungsplan zu. API-Schlüssel sind KEIN Sicherheitsmechanismus – sie dienen ausschließlich zur Identifikation von Clients für Drosselungs- und Kontingentzwecke. Kombinieren Sie API-Schlüssel aus Sicherheitsgründen immer mit einer geeigneten Autorisierung (IAM, Lambda-Autorisierer oder Cognito). Für API-Schlüssel, die keinem Nutzungsplan zugeordnet sind, werden einfach keine Drosselungsgrenzen angewendet.

Zusätzlich zu Drosselungsraten pro Sekunde unterstützen Nutzungspläne quota limits: eine maximale Anzahl von Anforderungen innerhalb eines Zeitraums (DAY, WEEK oder MONTH). Sobald ein Client sein Kontingent ausgeschöpft hat, geben nachfolgende Anforderungen bis zur Zurücksetzung des Kontingents den Status 429 zurück. Kontingentgrenzen eignen sich zur Durchsetzung kostenloser Kontingente, zur Verhinderung des API-Missbrauchs und zur Abstimmung der API-Nutzung mit der Abrechnung. Kontingentzähler sind letztlich konsistent, daher kann ein Client sein Kontingent geringfügig überschreiten, bevor Anforderungen blockiert werden.

Überwachen Sie den Zustand von API Gateway mit diesen CloudWatch-Metriken:

• Count: Gesamtzahl der API-Aufrufe
• 4XXError: Clientfehler einschließlich Drosselungen mit Status 429
• 5XXError: Backend-Fehler
• Latency: End-to-End-Anforderungszeit
• IntegrationLatency: Wartezeit auf das Backend
• CacheHitCount / CacheMissCount: Effektivität des Caches

Richten Sie bei Spitzen bei 4XXError Alarme ein, um Drosselungsprobleme zu erkennen, bevor sie sich auf Benutzer auswirken, und überwachen Sie CacheMissCount, um Probleme bei der Cache-Konfiguration zu identifizieren.

Verwenden Sie caching für leseintensive APIs, deren Antworten sich selten ändern – etwa für Produktkatalogabfragen, Referenzdaten und statische Konfigurationen. Für benutzerspezifische oder sehr dynamische Daten ist Caching kontraproduktiv. Verwenden Sie throttling immer, auch für interne APIs, um Backend-Services vor Überlastung zu schützen. Kombinieren Sie beides: Cachen Sie häufig benötigte Daten, um die Backend-Last zu verringern, und drosseln Sie aggressiv, damit kein einzelner Client die API dominiert. Für die SAA-C03-Prüfung gilt: Caching senkt Kosten und Latenz, Drosselung stellt die Verfügbarkeit sicher.

In dieser Lektion haben Sie gelernt: Throttling auf Konto-, Stage- und Methodenebene schützt Backends mithilfe eines Token-Bucket-Algorithmus mit konfigurierbaren Raten- und Burst-Grenzen. Response Caching speichert Backend-Antworten für konfigurierbare TTLs, um Backend-Last und Latenz bei leseintensiven Endpunkten zu verringern. Usage Plans with API Keys setzen Drosselungsraten und Kontingente pro Client durch und ermöglichen abgestufte Zugriffskontrollen für Partner- und öffentliche APIs. Als Nächstes sehen wir uns ECS-Cluster, Aufgabendefinitionen und Services für containerisierte Workloads an.