View a markdown version of this page

Drosselung von Anfragen für die Amazon EC2 EC2-API - Amazon Elastic Compute Cloud
Wie wird die Drosselung angewendetToken-Limits anfragenLimits für RessourcentokensÜberwachen Sie die API-DrosselungWiederholungen und exponentieller BackoffSehen Sie sich Ihre aktuellen API-Limits anAnfordern einer -Limit-Erhöhung

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.

Drosselung von Anfragen für die Amazon EC2 EC2-API

Amazon EC2 drosselt EC2-API-Anfragen für jedes AWS Konto pro Region. Wir tun dies, um die Leistung des Service zu verbessern und eine faire Nutzung für alle Amazon EC2 EC2-Kunden sicherzustellen. Durch die Drosselung wird sichergestellt, dass Anfragen an die Amazon EC2 EC2-API die maximal zulässigen API-Anforderungsgrenzen nicht überschreiten. API-Anfragen unterliegen den Anforderungsbeschränkungen, unabhängig davon, ob sie von folgenden Quellen stammen:

  • Eine Drittanbieteranwendung

  • Ein Befehlszeilentool

  • Die Amazon EC2 EC2-Konsole

Wenn Sie ein API-Drosselungslimit überschreiten, erhalten Sie den RequestLimitExceeded Fehlercode.

Wie wird die Drosselung angewendet

Amazon EC2 verwendet den Token-Bucket-Algorithmus, um API-Drosselung zu implementieren. Mit diesem Algorithmus verfügt Ihr Konto über einen Bucket, der eine bestimmte Anzahl von Token enthält. Die Anzahl der Token im Bucket entspricht Ihrem Drosselungslimit für eine bestimmte Sekunde.

Amazon EC2 implementiert zwei Arten der API-Drosselung:

Anforderungsratenbegrenzung

Bei der Begrenzung der Anforderungsrate wird jede API einzeln bewertet, und die Anzahl der Anfragen, die Sie pro API stellen, wird eingeschränkt. Jede Anfrage, die Sie stellen, entfernt ein Token aus dem API-Bucket. Beispielsweise beträgt die Token-Bucket-Größe für eine API-AktionDescribeHosts, die nicht mutiert, 100 Token. Sie können in einer Sekunde bis zu 100 DescribeHosts Anfragen stellen. Wenn Sie in einer Sekunde mehr als 100 Anfragen haben, werden Sie für diese API gedrosselt und die verbleibenden Anfragen innerhalb dieser Sekunde schlagen fehl. Anfragen für andere APIs sind jedoch nicht betroffen.

Eimer werden automatisch mit einer festgelegten Geschwindigkeit wieder aufgefüllt. Wenn der Bucket seine maximale Kapazität unterschreitet, wird ihm jede Sekunde eine bestimmte Anzahl von Tokens hinzugefügt, bis er seine maximale Kapazität erreicht hat. Wenn der Eimer voll ist, wenn die Nachfüll-Token eintreffen, werden sie weggeworfen. Der Eimer kann nicht mehr als die maximale Anzahl an Tokens aufnehmen. Beispielsweise beträgt die Bucket-Größe für eine API-AktionDescribeHosts, die nicht mutiert, 100 Token und die Nachfüllrate beträgt 20 Token pro Sekunde. Wenn Sie 100 DescribeHosts Anfragen in einer Sekunde stellen, wird der Bucket auf null (0) Token reduziert. Der Bucket wird dann jede Sekunde um 20 Token aufgefüllt, bis er seine maximale Kapazität von 100 Token erreicht hat. Das bedeutet, dass ein leerer Bucket nach 5 Sekunden seine maximale Kapazität erreicht, wenn während dieser Zeit keine Anfragen gestellt werden.

Sie müssen nicht warten, bis der Bucket vollständig gefüllt ist, bevor Sie API-Anfragen stellen können. Sie können Nachfüll-Token verwenden, wenn sie dem Bucket hinzugefügt werden. Wenn Sie die Nachfüll-Token sofort verwenden, erreicht der Bucket nicht seine maximale Kapazität. Beispielsweise beträgt die Bucket-Größe für eine API-AktionDescribeHosts, die nicht mutiert, 100 Token und die Nachfüllrate beträgt 20 Token pro Sekunde. Wenn Sie den Bucket leeren, indem Sie 100 API-Anfragen pro Sekunde stellen, können Sie weiterhin 20 API-Anfragen pro Sekunde stellen, indem Sie die Nachfüll-Token verwenden, wenn sie dem Bucket hinzugefügt werden. Der Bucket kann nur dann bis zur maximalen Kapazität aufgefüllt werden, wenn Sie weniger als 20 API-Anfragen pro Sekunde stellen.

Weitere Informationen finden Sie unter Größen und Nachfüllraten für Token-Buckets anfragen.

Begrenzung der Ressourcenrate

Einige API-Aktionen, wie z. B. RunInstances undTerminateInstances, wie in der folgenden Tabelle beschrieben, verwenden zusätzlich zur Begrenzung der Anforderungsrate eine Begrenzung der Ressourcenrate. Diese API-Aktionen verfügen über einen separaten Ressourcentoken-Bucket, der je nach Anzahl der Ressourcen, die von der Anfrage betroffen sind, aufgebraucht wird. Wie bei Anforderungstoken-Buckets gibt es auch bei Ressourcentoken-Buckets eine maximale Anzahl an Buckets, sodass Sie überlastet werden können, und eine Nachfüllrate, die es Ihnen ermöglicht, eine konstante Anzahl von Anfragen so lange wie nötig aufrechtzuerhalten. Wenn Sie ein bestimmtes Bucket-Limit für eine API überschreiten, auch wenn ein Bucket noch nicht aufgefüllt wurde, um die nächste API-Anfrage zu unterstützen, ist die Aktion der API eingeschränkt, obwohl Sie das gesamte API-Drossellimit noch nicht erreicht haben.

Beispielsweise RunInstances beträgt die Bucket-Größe für Ressourcentokens 1000 Token, und die Nachfüllrate beträgt zwei Token pro Sekunde. Daher können Sie sofort 1000 Instances starten, indem Sie eine beliebige Anzahl von API-Anfragen verwenden, z. B. eine Anfrage für 1000 Instances oder vier Anfragen für 250 Instances. Wenn der Ressourcentoken-Bucket leer ist, können Sie bis zu zwei Instances pro Sekunde starten, indem Sie entweder eine Anfrage für zwei Instances oder zwei Anfragen für eine Instance verwenden.

Weitere Informationen finden Sie unter Größen und Nachfüllraten von Buckets für Ressourcentokens.

Größen und Nachfüllraten für Token-Buckets anfragen

Zur Begrenzung der Anforderungsrate werden API-Aktionen in die folgenden Kategorien eingeteilt:

  • Non-mutating Aktionen — API-Aktionen, die Daten über Ressourcen abrufen. Diese Kategorie umfasst im Allgemeinen alle Describe* List*Search*,, und Get* API-Aktionen wie DescribeRouteTablesSearchTransitGatewayRoutes, undGetIpamPoolCidrs. Für diese API-Aktionen gelten in der Regel die höchsten API-Drosselungsgrenzen.

  • Ungefilterte und nicht paginierte, nicht mutierende Aktionen — Eine bestimmte Teilmenge nicht mutierender API-Aktionen, die, wenn sie ohne Angabe einer Paginierung oder eines Filters angefordert werden, Token aus einem kleineren Token-Bucket verwenden. Es wird empfohlen, Seitennummerierung und Filterung zu verwenden, sodass Tokens vom standardmäßigen (größeren) Token-Bucket abgezogen werden.

  • Mutierende Aktionen — API-Aktionen, die Ressourcen erstellen, ändern oder löschen. Diese Kategorie umfasst im Allgemeinen alle API-Aktionen, die nicht als nicht mutierende Aktionen eingestuft sind, wie z. B., AllocateHosts undModifyHosts. CreateCapacityReservation Diese Aktionen haben eine niedrigere Drosselungsgrenze als API-Aktionen ohne Mutationen.

  • Resource-intensive Aktionen — Mutierende API-Aktionen, deren Ausführung am meisten Zeit in Anspruch nimmt und die meisten Ressourcen beansprucht. Für diese Aktionen gilt eine noch niedrigere Drosselungsgrenze als für mutierende Aktionen. Sie werden getrennt von anderen mutierenden Aktionen gedrosselt.

  • Nicht mutierende Konsolenaktionen — Non-mutating API-Aktionen, die von der Amazon EC2 EC2-Konsole angefordert werden. Diese API-Aktionen werden getrennt von anderen nicht mutierenden API-Aktionen gedrosselt.

  • Unkategorisierte Aktionen — Dies sind API-Aktionen, die ihre eigenen Token-Bucketgrößen und Wiederauffüllraten erhalten, obwohl sie per Definition in eine der anderen Kategorien passen.

Kategorie „API-Aktion“ Aktionen Maximale Kapazität des Buckets Nachfüllrate des Eimers
Non-mutating Aktionen

Die Get* API-Aktionen Describe* List*Search*,, und, die nicht in einer anderen Kategorie enthalten sind.

 100 20
Ungefilterte und nicht paginierte, nicht mutierende Aktionen

  • DescribeInstances

  • DescribeInstanceStatus

  • DescribeNetworkInterfaces

  • DescribeSecurityGroups

  • DescribeSnapshots

  • DescribeSpotInstanceRequests

  • DescribeVolumes

 50 10
Mutierende Aktionen

Alle mutierenden API-Aktionen, bei denen es sich nicht um Resource-intensive Aktionen oder Unkategorisierte Aktionen handelt.

 50 5
Resource-intensive Aktionen

  • AcceptVpcPeeringConnection

  • AuthorizeSecurityGroupIngress

  • CancelSpotInstanceRequests

  • CreateKeyPair

  • CreateVpcPeeringConnection

  • DeleteVpcPeeringConnection

  • RejectVpcPeeringConnection

  • RevokeSecurityGroupIngress

  • RequestSpotInstances

 50 5
Aktionen auf der Konsole, die nicht mutieren

DieDescribe*, List*Search*, und Get* API-Aktionen, die von der Amazon EC2 EC2-Konsole aufgerufen werden, aber nicht in einer anderen Kategorie enthalten sind.

 100 10
Nicht kategorisierte Aktionen Maximale Kapazität des Buckets Nachfüllrate des Eimers
AcceptVpcEndpointConnections 10 1
AdvertiseByoipCidr 1 0.1
AssignIpv6Addresses 100 5
AssignPrivateIpAddresses 100 5
AssignPrivateNatGatewayAddress 10 1
AssociateCapacityReservationBillingOwner 1 0.5
AssociateEnclaveCertificateIamRole 10 1
AssociateIamInstanceProfile 100 5
AssociateNatGatewayAddress 10 1
AttachVerifiedAccessTrustProvider 10 2
AuthorizeClientVpnIngress 5 2
CancelDeclarativePoliciesReport 1 1
CopyImage 100 1
CreateClientVpnRoute 5 2
CreateCoipCidr 5 1
CreateCoipPool 5 1
CreateDefaultSubnet 1 1
CreateDefaultVpc 1 1
CreateLaunchTemplateVersion 100 5
CreateNatGateway 10 1
CreateNetworkInterface 100 5
CreateRestoreImageTask 50 0.1
CreateSnapshot 100 5
CreateSnapshots 100 5
CreateSpotDatafeedSubscription 50 3
CreateStoreImageTask 50 0.1
CreateSubnetCidrReservation 5 1
CreateTags 100 10
CreateVerifiedAccessEndpoint 20 4
CreateVerifiedAccessGroup 10 2
CreateVerifiedAccessInstance 10 2
CreateVerifiedAccessTrustProvider 10 2
CreateVolume 100 5
CreateVpcEndpoint 4 0.3
CreateVpcEndpointServiceConfiguration 10 1
DeleteClientVpnRoute 5 2
DeleteCoipCidr 5 1
DeleteCoipPool 5 1
DeleteCoipPoolPermission 5 1
DeleteNatGateway 10 1
DeleteNetworkInterface 100 5
DeleteSnapshot 100 5
DeleteSpotDatafeedSubscription 50 3
DeleteSubnetCidrReservation 5 1
DeleteQueuedReservedInstances 5 5
DeleteTags 100 10
DeleteVerifiedAccessEndpoint 20 4
DeleteVerifiedAccessGroup 10 2
DeleteVerifiedAccessInstance 10 2
DeleteVerifiedAccessTrustProvider 10 2
DeleteVolume 100 5
DeleteVpcEndpoints 4 0.3
DeleteVpcEndpointServiceConfigurations 10 1
DeprovisionByoipCidr 1 0.1
DeregisterImage 100 5
DescribeAggregateIdFormat 10 10
DescribeByoipCidrs 1 0.5
DescribeCapacityBlockExtensionOfferings 10 0,15
DescribeCapacityBlockOfferings 10 0,15
DescribeDeclarativePoliciesReports 5 5
DescribeHostReservations 5 2
DescribeHostReservationOfferings 5 2
DescribeIdentityIdFormat 10 10
DescribeIdFormat 10 10
DescribeInstanceTopology 1 1
DescribeMovingAddresses 1 1
DescribePrincipalIdFormat 10 10
DescribeReservedInstancesOfferings 10 10
DescribeSecurityGroupReferences 20 5
DescribeSpotDatafeedSubscription 100 13
DescribeSpotFleetInstances 100 5
DescribeSpotFleetRequestHistory 100 5
DescribeSpotFleetRequests 50 3
DescribeStaleSecurityGroups 20 5
DescribeStoreImageTasks 50 0.5
DescribeVerifiedAccessInstanceLoggingConfigurations 10 2
DetachVerifiedAccessTrustProvider 10 2
DisableFastLaunch 5 2
DisableImageBlockPublicAccess 1 0,1
DisableSnapshotBlockPublicAccess 1 0,1
DisassociateCapacityReservationBillingOwner 1 0.5
DisassociateEnclaveCertificateIamRole 10 1
DisassociateIamInstanceProfile 100 5
DisassociateNatGatewayAddress 10 1
EnableFastLaunch 5 2
EnableImageBlockPublicAccess 1 0,1
EnableSnapshotBlockPublicAccess 1 0.1
GetAssociatedEnclaveCertificateIamRoles 10 1
GetDeclarativePoliciesReportSummary 5 5
GetHostReservationPurchasePreview 5 2
ModifyImageAttribute 100 5
ModifyInstanceMetadataDefaults 2 2
ModifyInstanceMetadataOptions 100 5
ModifyLaunchTemplate 100 5
ModifyNetworkInterfaceAttribute 100 5
ModifySnapshotAttribute 100 5
ModifyVerifiedAccessEndpoint 20 4
ModifyVerifiedAccessEndpointPolicy 20 4
ModifyVerifiedAccessGroup 10 2
ModifyVerifiedAccessGroupPolicy 20 4
ModifyVerifiedAccessInstance 10 2
ModifyVerifiedAccessInstanceLoggingConfiguration 10 2
ModifyVerifiedAccessTrustProvider 10 2
ModifyVpcEndpoint 4 0.3
ModifyVpcEndpointServiceConfiguration 10 1
MoveAddressToVpc 1 1
ProvisionByoipCidr 1 0.1
PurchaseCapacityBlock 10 0,15
PurchaseCapacityBlockExtension 10 0,15
PurchaseHostReservation 5 2
PurchaseReservedInstancesOffering 5 5
RejectVpcEndpointConnections 10 1
RestoreAddressToClassic 1 1
RevokeClientVpnIngress 5 2
RunInstances 5 2
StartDeclarativePoliciesReport 1 1
StartInstances 5 2
TerminateInstances 100 5
UnassignPrivateIpAddresses 100 5
UnassignPrivateNatGatewayAddress 10 1
WithdrawByoipCidr 1 0.1

Größen und Nachfüllraten von Buckets für Ressourcentokens

In der folgenden Tabelle sind die Bucket-Größen und Nachfüllraten für Ressourcentokens für API-Aktionen aufgeführt, bei denen die Begrenzung der Ressourcenrate verwendet wird.

API-Aktion Maximale Kapazität des Buckets Rate der Bucket-Nachfüllungen
RunInstances 1000 2
TerminateInstances 1000 20
StartInstances 1000 2
StopInstances 1000 20

Überwachen Sie die API-Drosselung

Sie können Amazon verwenden CloudWatch , um Ihre Amazon EC2 EC2-API-Anfragen zu überwachen und Metriken rund um die API-Drosselung zu sammeln und zu verfolgen. Sie können auch einen Alarm einrichten, der Sie warnt, wenn Sie kurz davor sind, die API-Drosselungsgrenzen zu erreichen. Weitere Informationen finden Sie unter Überwachen Sie EC2 Amazon-API-Anfragen mit Amazon CloudWatch.

Wiederholungen und exponentieller Backoff

Ihre Anwendung muss möglicherweise eine API-Anfrage erneut versuchen. Beispiel:

  • Um zu überprüfen, ob der Status einer Ressource aktualisiert wurde

  • Um eine große Anzahl von Ressourcen aufzuzählen (z. B. alle Ihre Volumes)

  • Um eine Anfrage erneut zu versuchen, nachdem sie mit einem Serverfehler (5xx) oder einem Drosselungsfehler fehlschlägt

Bei einem Client-Fehler (4xx) müssen Sie die Anfrage jedoch überarbeiten, um das Problem zu beheben, bevor Sie die Anfrage erneut versuchen.

Der Ressourcenstatus ändert sich

Bevor Sie mit der Abfrage beginnen, um nach Statusaktualisierungen zu suchen, sollten Sie der Anfrage Zeit geben, bis sie möglicherweise abgeschlossen ist. Warten Sie beispielsweise einige Minuten, bevor Sie überprüfen, ob Ihre Instance aktiv ist. Wenn Sie mit dem Polling beginnen, sollten Sie ein angemessenes Schlafintervall zwischen aufeinanderfolgenden Anfragen verwenden, um die Rate der API-Anfragen zu senken. Um die besten Ergebnisse zu erzielen, verwenden Sie ein zunehmendes oder variables Energiesparintervall.

Alternativ können Sie Amazon verwenden, EventBridge um Sie über den Status einiger Ressourcen zu informieren. Sie können beispielsweise das Ereignis EC2 Instance State-change Notification verwenden, um Sie über eine Statusänderung für eine Instance zu informieren. Weitere Informationen finden Sie unter Automatisieren von Amazon EC2 mit EventBridge.

Erneute Versuche

Wenn Sie eine API-Anfrage abfragen oder erneut versuchen müssen, empfehlen wir die Verwendung eines exponentiellen Backoff-Algorithmus zur Berechnung des Schlafintervalls zwischen API-Anfragen. Die Idee hinter dem exponentiellen Backoff ist, bei aufeinander folgenden Fehlermeldungen progressiv längere Wartezeiten zwischen den Wiederholversuchen zu verwenden. Sie sollten ein maximales Verzögerungsintervall sowie eine maximale Anzahl von Wiederholversuchen implementieren. Sie können auch Jitter (randomisierte Verzögerung) verwenden, um aufeinanderfolgende Kollisionen zu verhindern. Weitere Informationen finden Sie unter Timeouts, Wiederholungen und Backoff mit Jitter.

Jedes AWS SDK implementiert eine automatische Wiederholungslogik. Weitere Informationen finden Sie unter Verhalten bei Wiederholungsversuchen im Referenzhandbuch für AWS SDKs und Tools.

Sehen Sie sich Ihre aktuellen API-Limits an

In der Service Quotas Quotas-Konsole können Sie Ihre aktuellen Limits und Standardlimits für jede Amazon EC2 EC2-API-Aktion für Sie AWS-Konto einsehen.

Wie hängen Kontingente mit Ihrer Drosselungsgrenze zusammen

Jedes API-Throttle-Limit besteht aus zwei Quoten, die zusammen die Rate an Burst- und Daueranfragen definieren:

  • Maximale Bucket-Kapazität — bestimmt die maximale Anzahl von Anfragen, die Sie in einem Burst stellen können. Dies ist Ihre Burst-Rate.

  • Bucket-Nachfüllrate — bestimmt die Anzahl der Token, die dem Bucket pro Sekunde hinzugefügt werden. Dies ist Ihre anhaltende Rate.

Beispiel: RunInstances Drosselbegrenzung anzeigen

Um die RunInstances Drosselgrenze anzuzeigen, suchen Sie nachRunInstances. Auf der Konsole wird Folgendes angezeigt:

  • RunInstancesmaximale Kapazität des Buckets anfordern — zum Beispiel 5 (Burst)

  • RunInstancesRefillrate des Buckets anfordern — zum Beispiel 2 pro Sekunde (dauerhaft)

Diese beiden Kontingente zusammen definieren die vollständige RunInstances Drosselgrenze.

Die Quotenwerte verstehen

  • Der Wert „Angewendetes Kontingent“ auf Kontoebene gibt an, ob Kontingentüberschreitungen auf Ihr Konto angewendet wurden. Dies ist Ihr aktuelles effektives Kontingent.

  • Der AWS Standardkontingentwert gibt das standardmäßige API-Drosselungskontingent an.

Anmerkung

Es kann bis zu 24 Stunden dauern, bis alle Kontingentanpassungen in der Service Quotas Quotas-Konsole angezeigt werden.

Um Ihre aktuellen Kontingente einzusehen

  1. Öffnen Sie die Service Quotas-Konsole unter https://console.aws.amazon.com/servicequotas/home/services/ec2/quotas/.

  2. Suchen Sie nach dem Namen der API-Aktion (z. B.RunInstances) und dem Kontingentnamen, um die entsprechenden Kontingenteinträge zu finden.

In der folgenden Tabelle werden die Kontingentnamen beschrieben.

Muster der Kontingentnamen Description
{API_NAME}maximale Kapazität des Buckets anfordern Burst-Rate — die maximale Anzahl verfügbarer Token
{API_NAME}Nachfüllrate für den Bucket anfragen Dauerhafte Rate — pro Sekunde hinzugefügte Tokens
{API_NAME}maximale Kapazität des Buckets für ungefilterte Anfragen Burst-Rate — die maximale Anzahl von Tokens, die für ungefilterte (nicht paginierte) Anfragen verfügbar sind
{API_NAME}Nachfüllrate des Buckets für ungefilterte Anfragen Dauerhafte Rate — Tokens, die pro Sekunde für ungefilterte (nicht paginierte) Anfragen hinzugefügt werden

Anfordern einer -Limit-Erhöhung

Sie können eine Erhöhung der API-Drosselungslimits für Ihre beantragen. AWS-Konto

Empfehlungen

  • Fordern Sie in einer einzigen Anfrage höchstens das Dreifache Ihres bestehenden Limits an.

  • Priorisieren Sie die Erhöhung der Eimer-Nachfüllraten, bevor Sie die maximale Eimerkapazität erhöhen.

  • Wenn die angeforderte Nachfüllrate der Eimer die maximale Kapazität des Buckets überschreiten würde, erhöhen Sie gleichzeitig die maximale Kapazität des Buckets.

  • Geben Sie alle API-Aktionen an, für die eine Erhöhung erforderlich ist. Grenzwerte gelten für einzelne API-Aktionen, nicht für API-Aktionskategorien.

  • Für die folgenden API-Aktionen gibt es sowohl Grenzwerte für die Anforderungsrate als auch für die Ressourcenrate: RunInstances StartInstancesStopInstances,, undTerminateInstances. Geben Sie unbedingt an, welches Limit erhöht werden soll

Um Zugriff auf diese Funktion zu beantragen

  1. AWS Support Zentrum öffnen.

  2. Wählen Sie Create case (Fall erstellen) aus.

  3. Wählen Sie Konto und Fakturierung aus.

  4. Wählen Sie für Service die Optionen Allgemeine Informationen und Erste Schritte aus.

  5. Wählen Sie als Kategorie die Option Nutzung AWS und Dienste aus.

  6. Wählen Sie Next step: Additional information (Nächster Schritt: Zusätzliche Informationen).

  7. Geben Sie unter Subject (Betreff) Request an increase in my Amazon EC2 API throttling limits ein.

  8. Kopieren Sie für Beschreibung die folgende Vorlage und geben Sie die erforderlichen Informationen ein.

    Please increase the API throttling limits for my account. 
Related page: https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-throttling.html
Description: Brief notes about your use case. If available, include the IDs
    of a few Amazon EC2 requests that were throttled.
Time window: One-hour window when peak throttling or usage occurred.
region_1 request rate increases:
    action: new_bucket_maximum_capacity
    action: new_bucket_refill_rate
    action: new_bucket_maximum_capacity|new_bucket_refill_rate
region_1 resource rate increases:
    action: new_bucket_maximum_capacity
    action: new_bucket_refill_rate
    action: new_bucket_maximum_capacity|new_bucket_refill_rate
region_2 request rate increases:
    action: new_bucket_maximum_capacity
    action: new_bucket_refill_rate
    action: new_bucket_maximum_capacity|new_bucket_refill_rate
region_2 resource rate increases:
    action: new_bucket_maximum_capacity
    action: new_bucket_refill_rate
    action: new_bucket_maximum_capacity|new_bucket_refill_rate

  9. Klicken Sie auf Next step: Solve now or contact us ( ()Nächster Schritt): Jetzt lösen oder Support kontaktieren).

  10. Wählen Sie auf der Registerkarte Kontakt Ihre bevorzugte Kontaktsprache und Kontaktmethode aus.

  11. Wählen Sie Absenden aus.