Drosselung für Amazon Route 53-API-Anfragen

Wichtig

Amazon Route 53 hat sein API-Drosselungsverhalten aktualisiert. Das Update beinhaltet die Erhöhung des Limits für Anfragen pro Sekunde und die Einführung einer änderungsbasierten Drosselung. Auf dieser Seite werden die aktualisierten Grenzwerte ausführlich beschrieben.

Amazon Route 53 drosselt API-Anfragen pro Konto, um die Servicestabilität aufrechtzuerhalten und eine faire Nutzung für alle Kunden sicherzustellen. Route 53 wendet zwei unabhängige Grenzwerte an:

• Anforderungsrate: Die Anzahl der API-Anfragen pro Sekunde.

• Änderungsdurchsatz: Die Anzahl der einzelnen DNS-Datensatzänderungen pro Sekunde, zusammengefasst für die API-Aktionen, die DNS-Daten ändern.

Eine Anfrage kann durch beide Grenzwerte gedrosselt werden. Wenn eine Anfrage gedrosselt wird, gibt Amazon Route 53 einen HTTP 400-Fehler () zurück. Bad request Der Antwort-Header umfasst außerdem ein Code-Element mit dem Wert Throttling und ein Message-Element mit dem Wert Rate exceeded.

Wie wird die Drosselung angewendet

Amazon Route 53 verwendet einen Token-Bucket-Algorithmus. Jedes Limit hat einen Bucket, der eine maximale Anzahl von Token enthält. Jede Anforderung (für das Anforderungsratenlimit) oder jede Änderung (für das Änderungsdurchsatzlimit) entfernt Token aus dem jeweiligen Bucket. Der Bucket wird jede Sekunde mit einer festen Rate bis zu seiner maximalen Kapazität aufgefüllt. Wenn Nachfüllmarken ankommen, obwohl der Eimer bereits voll ist, wirft Route 53 sie ab.

Zwei Werte beschreiben jeden Bucket:

• Die maximale Kapazität des Buckets ist Ihr Burst: Die Anzahl der Anfragen oder Änderungen, die Route 53 gleichzeitig verarbeiten kann, wenn der Bucket voll ist.

• Die Bucket-Nachfüllrate ist Ihre Dauerrate: die Anzahl der Anfragen oder Änderungen pro Sekunde, die Sie unbegrenzt beibehalten können.

Sie können Refill-Token verwenden, sobald sie hinzugefügt werden. Sie müssen nicht warten, bis der Eimer vollständig aufgefüllt ist.

Anzahl der Tokens, Bucketgrößen und Nachfüllraten anfragen

Route 53 wendet die Drosselung der Anforderungsrate auf zwei Ebenen an:

• Kontoebene: Alle Amazon Route 53-API-Anfragen von Ihrem Konto beziehen sich auf einen Bucket.

• Konto- und Betriebsebene: Jede API-Aktion hat auch ihren eigenen Bucket.

Eine Anfrage verbraucht ein Token aus beiden Buckets und wird gedrosselt, wenn einer der Buckets leer ist. Für die folgenden Aktionen gelten unterschiedliche Standardgrenzwerte für die Anforderungsrate.

Grenzwerte für die Anforderungsrate pro API-Aktion

API-Aktion	Maximale Kapazität des Buckets	Rate zum Nachfüllen von Eimern
Alle Amazon Route 53-API-Aktionen zusammen (Kontoebene)	50	10
Jede einzelne API-Aktion, die unten nicht aufgeführt ist (Standardeinstellung pro Aktion)	50	10
AssociateVPCWithHostedZone	20	5
ChangeCidrCollection	40	5
CreateCidrCollection	40	5
CreateHealthCheck	50	0.5
CreateHostedZone	40	2
CreateReusableDelegationSet	40	2
CreateTrafficPolicyInstance	1	1
DeleteCidrCollection	40	5
DeleteHealthCheck	15	3
DeleteHostedZone	40	5
DeleteReusableDelegationSet	40	5
DeleteTrafficPolicyInstance	1	1
DisassociateVPCFromHostedZone	10	5
GetHealthCheckLastFailureReason	4	1
GetHealthCheckStatus	4	1
UpdateHealthCheck	50	5
UpdateTrafficPolicyInstance	1	1

Die vollständige Liste der Amazon Route 53-API-Aktionen finden Sie unter Aktionen in der Amazon Route 53-API-Referenz.

CreateHealthCheck-Anforderungen

Sie können alle zwei Sekunden eine CreateHealthCheck-Abfrage pro AWS-Kontoübermitteln. Dies entspricht der in der vorherigen Tabelle aufgeführten Nachfüllrate von 0,5 Anfragen pro Sekunde.

Ändern Sie die Durchsatzbegrenzung

Zusätzlich zum Limit für die Anforderungsrate unterliegen die API-Aktionen, die DNS-Daten ändern, einem Grenzwert für den Änderungsdurchsatz. Dieses Limit verwendet einen separaten Token-Bucket, der aufgrund der Anzahl der DNS-Datensatzänderungen, die eine Anfrage vornimmt, erschöpft wird, nicht aufgrund der Anzahl der Anfragen. Der Änderungsdurchsatz ist pro API-Aktion begrenzt AWS-Konto, nicht pro API-Aktion. Alle folgenden Aktionen beziehen sich auf einen Bucket, der eine maximale Kapazität von 1.500 Änderungen (Burst) hat und bei 100 Änderungen pro Sekunde (dauerhaft) aufgefüllt wird.

Änderungen werden wie folgt gezählt:

Pro Vorgang verbrauchte Token

Operation	Verbrauchte Tokens
ChangeResourceRecordSets	1 proCREATE, 1 proDELETE, 2 pro UPSERT
AssociateVPCWithHostedZone	2
DisassociateVPCFromHostedZone	2
CreateHostedZone	2
DeleteHostedZone	2

Alle anderen Amazon Route 53-API-Aktionen verbrauchen keine Token für den Änderungsdurchsatz und sind nur durch die Anforderungsrate begrenzt.

Beispiel: Sie können eine einzelne Anfrage mit 1.000 Änderungen (ein Burst) einreichen, was 1.000 Token verbraucht. Nach dem Burst füllt sich der Bucket mit 100 Tokens pro Sekunde wieder auf. Wenn Sie weiterhin 100 Änderungen pro Sekunde einreichen, können Sie diese Rate auf unbestimmte Zeit aufrechterhalten. Wenn Sie versuchen, 500 Änderungen pro Sekunde aufrechtzuerhalten, ist der Bucket leer und nachfolgende Anfragen werden gedrosselt, bis er wieder gefüllt ist.

Überwachen Sie die API-Drosselung

Sie können Ihre Amazon Route 53-API-Nutzung überwachen, indem Sie in Ihren Anwendungsprotokollen auf HTTP 400-Antworten achten oder indem Sie die API-Nutzung anhand CloudWatch von Metriken verfolgen. Wenn Sie Drosselungsfehler erhalten, überschreiten Ihre Anfragen eines der in den vorherigen Abschnitten beschriebenen Grenzwerte.

Wiederholungen und exponentieller Backoff

Wenn Sie eine API-Anfrage abfragen oder erneut versuchen, empfehlen wir, einen exponentiellen Backoff-Algorithmus zu verwenden, um das Schlafintervall zwischen Anfragen zu berechnen. Bei exponentiellem Backoff werden die Wartezeiten zwischen Wiederholungsversuchen bei aufeinanderfolgenden Fehlerantworten immer länger. Implementieren Sie ein maximales Verzögerungsintervall und eine maximale Anzahl von Wiederholungsversuchen und ziehen Sie in Betracht, Jitter (zufällige Verzögerung) hinzuzufügen, um aufeinanderfolgende Kollisionen zu vermeiden. Weitere Informationen finden Sie in der Builders' Library unter Timeouts, Wiederholungen und Backoff mit Jitter. AWS

Jedes AWS SDK implementiert eine automatische Wiederholungslogik, einschließlich eines adaptiven Wiederholungsmodus, der die clientseitige Anforderungsrate als Reaktion auf eine Drosselung anpasst. Für Workloads, die sich diesen Grenzwerten regelmäßig nähern, sollten Sie erwägen, adaptive Wiederholungen zu aktivieren. Weitere Informationen finden Sie im Referenzhandbuch für AWS SDKs und Tools unter Verhalten bei Wiederholungen.

Beantragen einer Limit-Erhöhung

Sie können über den Support eine Erhöhung der API-Anforderungsrate oder des Grenzwerts für den Änderungsdurchsatz beantragen. AWS Um eine Erhöhung zu beantragen:

• Öffnen Sie das AWS Support Center.

• Erstellen Sie einen Fall und wählen Sie „Servicelimit erhöhen“.

• Wählen Sie als Limittyp die Option Route 53 aus.

• Geben Sie Ihre aktuelle Nutzung und das Limit an, das Sie benötigen.

Bewährte Methoden für die API-Drosselung

• Gleichen Sie die Anforderungsrate gegen die Batchgröße ab: Wenn Sie durch das Limit der Anforderungsrate gedrosselt werden, senden Sie mehr Änderungen pro Anfrage. Wenn Sie durch das Limit für den Änderungsdurchsatz gedrosselt werden, reduzieren Sie Ihre Gesamtänderungsrate. Weder sehr kleine noch sehr große Chargen sind für sich genommen optimal.

• Verwenden Sie Batching aus Gründen der Atomarität: Alle Änderungen in einer einzelnen ChangeResourceRecordSets Anfrage werden atomar angewendet, sodass sie zusammen erfolgreich sind oder fehlschlagen.

• Änderungen im Laufe der Zeit verteilen: Verteilen Sie die Änderungen gleichmäßig über Sekunden, anstatt große Batches gleichzeitig einzureichen.

• Verlassen Sie sich bei gelegentlichen Spitzen auf Burst, nicht auf anhaltenden Durchsatz: Die Burst-Kapazität eignet sich für legitime Datenverkehrsspitzen; es handelt sich nicht um eine dauerhafte Betriebsobergrenze.

• Wiederholen Sie den Vorgang mit exponentiellem Backoff: Wenn Sie HTTP 400-Antworten erhalten, versuchen Sie es nach einer Verzögerung, die mit jedem Versuch zunimmt, erneut (siehe). Wiederholungen und exponentieller Backoff

• Das Anforderungslimit wird proaktiv erhöht: Wenn Sie mit einem Anstieg der Arbeitslast rechnen, fordern Sie eine Erhöhung an, bevor Sie das Limit erreichen (siehe). Beantragen einer Limit-Erhöhung

Eine umfassendere Anleitung zu Amazon Route 53 finden Sie unterBewährte Methoden für Amazon Route 53.