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.
# Programmatischer Zugriff auf Amazon EC2
Sie können Ihre EC2 Amazon-Ressourcen mithilfe der AWS-Managementkonsole oder einer programmatischen Schnittstelle erstellen und verwalten. Informationen zur Verwendung der EC2 Amazon-Konsole finden Sie im [ EC2 Amazon-Benutzerhandbuch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/).
**Funktionsweise**
+ [ EC2 Amazon-Endpunkte](ec2-endpoints.md)
+ [Eventuelle Konsistenz](eventual-consistency.md)
+ [Idempotenz](ec2-api-idempotency.md)
+ [Drosselung beantragen](ec2-api-throttling.md)
+ [Paginierung](ec2-api-pagination.md)
**Programmierschnittstellen**
+ [AWS Command Line Interface (AWS CLI)](ec2-aws-cli.md)
+ [AWS CloudFormation](ec2-cloudformation.md)
+ [AWS SDKs](sdk-general-information-section.md)
+ [API auf niedriger Ebene](ec2-low-level-api.md)
**Erste Schritte**
+ [Codebeispiele](service_code_examples.md)
+ [Console-to-Code](console-to-code.md)
**Überwachen**
+ [AWS CloudTrail](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitor-with-cloudtrail.html)
+ [Anfragen überwachen](monitor.md)
# Amazon EC2-Serviceendpunkte
Ein Endpunkt ist eine URL, die als Einstiegspunkt für einen AWS Webservice dient. Amazon EC2 unterstützt die folgenden Endpunkttypen:
+ [IPv4 Endpunkte](#ipv4)
+ [Dual-Stack-Endpunkte](#ipv6) (unterstützen sowohl als auch) IPv4 IPv6
+ [FIPS-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#FIPS-endpoints)
Wenn Sie eine Anfrage stellen, können Sie den zu verwendenden Endpunkt angeben. Wenn Sie keinen Endpunkt angeben, wird der IPv4 Endpunkt standardmäßig verwendet. Um einen anderen Endpunkttyp zu verwenden, müssen Sie ihn in Ihrer Anforderung angeben. Beispiele für diese Vorgehensweise finden Sie unter [Angeben von Endpunkten](#examples). Eine Tabelle der verfügbaren Endpunkte finden Sie unter[Service-Endpunkte nach Regionen](#service-endpoints).
## IPv4 Endpunkte
IPv4 Endpunkte unterstützen nur IPv4 Datenverkehr. IPv4 Endpunkte sind für alle Regionen verfügbar.
Wenn Sie den allgemeinen Endpunkt, `ec2.amazonaws.com`, angeben, verwenden wir den Endpunkt für `us-east-1`. Um eine andere Region zu verwenden, geben Sie den zugehörigen Endpunkt an. Wenn Sie beispielsweise `ec2.us-east-2.amazonaws.com` als Endpunkt angeben, leiten wir Ihre Anfrage an den `us-east-2`-Endpunkt weiter.
IPv4 Endpunktnamen verwenden die folgende Benennungskonvention:
+ `service.region.amazonaws.com`
Der IPv4 Endpunktname für die `eu-west-1` Region lautet beispielsweise`ec2.eu-west-1.amazonaws.com`.
## Dual-Stack IPv4 - (und IPv6) Endpunkte
Dual-Stack-Endpunkte unterstützen sowohl den als auch den Datenverkehr. IPv4 IPv6 Wenn Sie eine Anfrage an einen Dual-Stack-Endpunkt stellen, wird die Endpunkt-URL je nach dem von Ihrem Netzwerk und Client verwendeten Protokoll in eine IPv6 oder eine IPv4 Adresse aufgelöst.
Amazon EC2 unterstützt nur regionale Dual-Stack-Endpunkte, was bedeutet, dass Sie die Region als Teil des Endpunktnamens angeben müssen. Dual-Stack-Endpunktnamen verwenden die folgende Namenskonvention:
+ `ec2.region.api.aws`
Beispielsweise ist der Dual-Stack-Endpunktname für die Region `eu-west-1` `ec2.eu-west-1.api.aws`.
## Service-Endpunkte nach Regionen
Im Folgenden sind die Service-Endpunkte für Amazon EC2 aufgeführt. Weitere Informationen zu Regionen finden Sie unter [Regionen und Availability Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/ec2/latest/devguide/ec2-endpoints.html)
## Angeben von Endpunkten
Dieser Abschnitt enthält einige Beispiele dafür, wie Sie einen Endpunkt angeben, wenn Sie eine Anforderung stellen.
------
#### [ AWS CLI ]
Die folgenden Beispiele zeigen, wie Sie mithilfe von einen Endpunkt für die `us-east-2` Region angeben AWS CLI.
+ **Dual-Stack**
```
aws ec2 describe-regions --region us-east-2 --endpoint-url https://ec2.us-east-2.api.aws
```
+ **IPv4**
```
aws ec2 describe-regions --region us-east-2 --endpoint-url https://ec2.us-east-2.amazonaws.com
```
------
#### [ AWS SDK for Java 2.x ]
Die folgenden Beispiele zeigen, wie Sie mithilfe von einen Endpunkt für die `us-east-2` Region angeben AWS SDK for Java 2.x.
+ **Dual-Stack**
```
Ec2Client client = Ec2Client.builder()
.region(Region.US_EAST_2)
.endpointOverride(URI.create("https://ec2.us-east-2.api.aws"))
.build();
```
+ **IPv4**
```
Ec2Client client = Ec2Client.builder()
.region(Region.US_EAST_2)
.endpointOverride(URI.create("https://ec2.us-east-2.amazonaws.com"))
.build();
```
------
#### [ AWS SDK für Java 1.x ]
Die folgenden Beispiele zeigen, wie Sie mithilfe von AWS SDK für Java 1.x einen Endpunkt für die `eu-west-1` Region angeben.
+ **Dual-Stack**
```
AmazonEC2 s3 = AmazonEC2ClientBuilder.standard()
.withEndpointConfiguration(new EndpointConfiguration(
"https://ec2.eu-west-1.api.aws",
"eu-west-1"))
.build();
```
+ **IPv4**
```
AmazonEC2 s3 = AmazonEC2ClientBuilder.standard()
.withEndpointConfiguration(new EndpointConfiguration(
"https://ec2.eu-west-1.amazonaws.com",
"eu-west-1"))
.build();
```
------
#### [ AWS SDK for Go ]
Die folgenden Beispiele zeigen, wie Sie mit dem einen Endpunkt für die `us-east-1` Region angeben. AWS SDK für Go
+ **Dual-Stack**
```
sess := session.Must(session.NewSession())
svc := ec2.New(sess, &aws.Config{
Region: aws.String(endpoints.UsEast1RegionID),
Endpoint: aws.String("https://ec2.us-east-1.api.aws")
})
```
+ **IPv4**
```
sess := session.Must(session.NewSession())
svc := ec2.New(sess, &aws.Config{
Region: aws.String(endpoints.UsEast1RegionID),
Endpoint: aws.String("https://ec2.us-east-1.amazonaws.com")
})
```
------
# Eventuelle Konsistenz in der Amazon-API EC2
Die EC2 Amazon-API folgt aufgrund des verteilten Charakters des Systems, das die API unterstützt, einem Konsistenzmodell. Das bedeutet, dass das Ergebnis eines von Ihnen ausgeführten API-Befehls, der sich auf Ihre EC2 Amazon-Ressourcen auswirkt, möglicherweise nicht sofort für alle nachfolgenden Befehle sichtbar ist, die Sie ausführen. Sie sollten dies berücksichtigen, wenn Sie einen API-Befehl ausführen, der unmittelbar auf einen vorherigen API-Befehl folgt.
Eine eventuelle Konsistenz kann sich auf die Art und Weise auswirken, wie Sie Ihre Ressourcen verwalten. Wenn Sie beispielsweise einen Befehl ausführen, um eine Ressource zu erstellen, wird diese irgendwann für andere Befehle sichtbar sein. Wenn Sie also einen Befehl ausführen, um die Ressource, die Sie gerade erstellt haben, zu ändern oder zu beschreiben, hat sich ihre ID möglicherweise nicht im gesamten System verbreitet und Sie erhalten eine Fehlermeldung, dass die Ressource nicht existiert.
Gehen Sie wie folgt vor, um die letztendliche Datenkonsistenz zu verwalten:
+ Bestätigen Sie den Status der Ressource, bevor Sie einen Befehl zum Ändern der Ressource ausführen. Führen Sie den entsprechenden Befehl `Describe` mit einem exponentiellen Backoff-Algorithmus aus, um sicherzustellen, dass Sie genügend Zeit für die Ausbreitung des vorherigen Befehls im System einplanen. Führen Sie dazu den `Describe` Befehl wiederholt aus, wobei Sie mit einer Wartezeit von einigen Sekunden beginnen und die Wartezeit schrittweise auf einige Minuten erhöhen.
+ Fügen Sie Wartezeiten zwischen aufeinanderfolgenden Befehlen hinzu, auch wenn der Befehl `Describe` eine genaue Antwort zurückgibt. Wenden Sie einen exponentiellen Backoff-Algorithmus an, der mit einer Wartezeit von einigen Sekunden beginnt und die Wartezeit schrittweise auf einige Minuten erhöht.
**Beispiele für eventuelle Konsistenzfehler**
Im Folgenden finden Sie Beispiele für Fehlercodes, auf die Sie aufgrund einer eventuellen Konsistenz stoßen können.
+ `InvalidInstanceID.NotFound`
Wenn Sie den `RunInstances` Befehl erfolgreich ausführen und anschließend sofort einen weiteren Befehl mit der Instanz-ID ausführen, die in der Antwort von angegeben wurde`RunInstances`, wird möglicherweise ein `InvalidInstanceID.NotFound` Fehler zurückgegeben. Das bedeutet nicht, dass die Instanz nicht existiert.
Einige spezifische Befehle, die betroffen sein könnten, sind:
+ `DescribeInstances`: Um den aktuellen Status der Instanz zu überprüfen, führen Sie diesen Befehl mit einem exponentiellen Backoff-Algorithmus aus.
+ `TerminateInstances`: Um den Status der Instanz zu bestätigen, führen Sie zunächst den `DescribeInstances` Befehl mit einem exponentiellen Backoff-Algorithmus aus.
**Wichtig**
Wenn Sie nach dem Ausführen eine `InvalidInstanceID.NotFound` Fehlermeldung erhalten`TerminateInstances`, bedeutet dies nicht, dass die Instanz beendet ist oder beendet wird. Ihre Instance könnte noch laufen. Aus diesem Grund ist es wichtig, zunächst den Status der Instanz mithilfe von zu überprüfen`DescribeInstances`.
+ `InvalidGroup.NotFound`
Wenn Sie den `CreateSecurityGroup` Befehl erfolgreich ausführen und dann sofort einen weiteren Befehl mit der Sicherheitsgruppen-ID ausführen, die in der Antwort von angegeben wurde`CreateSecurityGroup`, wird möglicherweise ein `InvalidGroup.NotFound` Fehler zurückgegeben. Um den Status der Sicherheitsgruppe zu überprüfen, führen Sie den `DescribeSecurityGroups` Befehl mit einem exponentiellen Backoff-Algorithmus aus.
+ `InstanceLimitExceeded`
Sie haben mehr Instances angefordert, als Ihr aktuelles Instance-Limit für den angegebenen Instance-Typ zulässt. Sie könnten dieses Limit unerwartet erreichen, wenn Sie Instances schnell starten und beenden, da beendete Instances nach ihrer Kündigung noch eine Weile auf Ihr Instance-Limit angerechnet werden.
# Sicherstellung der Idempotenz bei Amazon-API-Anfragen EC2
Wenn Sie eine ändernde API-Anfrage stellen, gibt die Anfrage in der Regel ein Ergebnis zurück, bevor die asynchronen Workflows der Operation abgeschlossen sind. Es können auch ein Timeout oder andere Serverprobleme auftreten, bevor Operationen abgeschlossen sind, obwohl die Anfrage bereits ein Ergebnis zurückgegeben hat. Dadurch lässt sich möglicherweise nur schwer feststellen, ob die Anfrage erfolgreich war oder nicht, und es werden möglicherweise mehrere Wiederholungsversuche vorgenommen, um sicherzustellen, dass die Operation erfolgreich abgeschlossen wird. Wenn die ursprüngliche Anfrage und die nachfolgenden Wiederholungsversuche jedoch erfolgreich sind, wird die Operation mehrmals abgeschlossen. Das bedeutet, dass Sie möglicherweise mehr Ressourcen erstellen, als Sie beabsichtigt haben.
*Idempotenz* stellt sicher, dass eine API-Anfrage nicht mehr als einmal abgeschlossen wird. Wenn bei einer idempotenten Anfrage die ursprüngliche Anfrage erfolgreich abgeschlossen wird, werden alle nachfolgenden Wiederholungen erfolgreich abgeschlossen, ohne dass weitere Aktionen ausgeführt werden. Das Ergebnis kann jedoch aktualisierte Informationen enthalten, z. B. den aktuellen Erstellungsstatus.
**Topics**
+ [Idempotenz bei Amazon EC2](#client-tokens)
+ [RunInstances Idempotenz](#run-instances-idempotency)
+ [Beispiele](#Run_Instance_Idempotency_CLI)
+ [Versuchen Sie es erneut mit Empfehlungen für idempotente Anfragen](#recommended-actions)
## Idempotenz bei Amazon EC2
Die folgenden API-Aktionen sind standardmäßig idempotent und erfordern keine zusätzliche Konfiguration. Die entsprechenden AWS CLI Befehle unterstützen standardmäßig auch Idempotenz.
**Standardmäßig ist Idempotent**
+ AssociateAddress
+ CreateVpnConnection
+ DisassociateAddress
+ ReplaceNetworkAclAssociation
+ TerminateInstances
*Die folgenden API-Aktionen unterstützen optional Idempotenz mithilfe eines Client-Tokens.* Die entsprechenden AWS CLI Befehle unterstützen auch Idempotenz mithilfe eines Client-Tokens. Ein Client-Token ist eine eindeutige Zeichenfolge mit bis zu 64 ASCII-Zeichen, bei der Groß- und Kleinschreibung beachtet wird. Um mit einer dieser Aktionen eine idempotente API-Anfrage zu stellen, geben Sie in der Anfrage ein Client-Token an. Sie sollten dasselbe Client-Token nicht für andere API-Anfragen wiederverwenden. Wenn Sie eine Anfrage, die erfolgreich abgeschlossen wurde, mit demselben Client-Token und denselben Parametern erneut versuchen, ist die Wiederholung erfolgreich, ohne dass weitere Aktionen ausgeführt werden. Wenn Sie eine erfolgreiche Anfrage mit demselben Client-Token wiederholen, aber einer oder mehrere der Parameter anders sind als die Region oder Availability Zone, schlägt die Wiederholung mit einem Fehler fehl. `IdempotentParameterMismatch`
**Ich bin impotent, wenn ein Client-Token verwendet wird**
+ AllocateHosts
+ AllocateIpamPoolCidr
+ AssociateClientVpnTargetNetwork
+ AssociateIpamResourceDiscovery
+ AttachVerifiedAccessTrustProvider
+ AuthorizeClientVpnIngress
+ CopyFpgaImage
+ CopyImage
+ CreateCapacityReservation
+ CreateCapacityReservationFleet
+ CreateClientVpnEndpoint
+ CreateClientVpnRoute
+ CreateEgressOnlyInternetGateway
+ CreateFleet
+ CreateFlowLogs
+ CreateFpgaImage
+ CreateInstanceConnectEndpoint
+ CreateIpam
+ CreateIpamPool
+ CreateIpamResourceDiscovery
+ CreateIpamScope
+ CreateLaunchTemplate
+ CreateLaunchTemplateVersion
+ CreateManagedPrefixList
+ CreateNatGateway
+ CreateNetworkAcl
+ CreateNetworkInsightsAccessScope
+ CreateNetworkInsightsPath
+ CreateNetworkInterface
+ CreateReplaceRootVolumeTask
+ CreateReservedInstancesListing
+ CreateRouteTable
+ CreateTrafficMirrorFilter
+ CreateTrafficMirrorFilterRule
+ CreateTrafficMirrorSession
+ CreateTrafficMirrorTarget
+ CreateVerifiedAccessEndpoint
+ CreateVerifiedAccessGroup
+ CreateVerifiedAccessInstance
+ CreateVerifiedAccessTrustProvider
+ CreateVolume
+ CreateVpcEndpoint
+ CreateVpcEndpointConnectionNotification
+ CreateVpcEndpointServiceConfiguration
+ DeleteVerifiedAccessEndpoint
+ DeleteVerifiedAccessGroup
+ DeleteVerifiedAccessInstance
+ DeleteVerifiedAccessTrustProvider
+ DetachVerifiedAccessTrustProvider
+ ExportImage
+ ImportImage
+ ImportSnapshot
+ ModifyInstanceCreditSpecification
+ ModifyLaunchTemplate
+ ModifyReservedInstances
+ ModifyVerifiedAccessEndpoint
+ ModifyVerifiedAccessEndpointPolicy
+ ModifyVerifiedAccessGroup
+ ModifyVerifiedAccessGroupPolicy
+ ModifyVerifiedAccessInstance
+ ModifyVerifiedAccessInstanceLoggingConfiguration
+ ModifyVerifiedAccessTrustProvider
+ ProvisionIpamPoolCidr
+ PurchaseHostReservation
+ RequestSpotFleet
+ RequestSpotInstances
+ RunInstances
+ StartNetworkInsightsAccessScopeAnalysis
+ StartNetworkInsightsAnalysis
**Arten von Idempotenz**
+ Regional — Anfragen sind in jeder Region idempotent. Sie können jedoch dieselbe Anfrage, einschließlich desselben Client-Tokens, in einer anderen Region verwenden.
+ Zonal — Anfragen sind in jeder Availability Zone in einer Region idempotent. Wenn Sie beispielsweise dasselbe Client-Token in zwei Aufrufen in derselben Region angeben, sind die Aufrufe erfolgreich, wenn sie unterschiedliche Werte für den Parameter angeben. **AllocateHosts** **AvailabilityZone**
## RunInstances Idempotenz
Die [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)API-Aktion verwendet sowohl regionale als auch zonale Idempotenz.
Die Art der verwendeten Idempotenz hängt davon ab, wie Sie die Availability Zone in Ihrer API-Anfrage angeben. RunInstances Die Anfrage verwendet in den folgenden **Fällen zonale Idempotenz**:
+ **Wenn Sie mithilfe des **AvailabilityZone**Parameters im Datentyp Placement explizit eine Availability Zone angeben**
+ Wenn Sie mithilfe des Parameters implizit eine Availability Zone angeben **SubnetId**
Wenn Sie keine Availability Zone explizit oder implizit angeben, verwendet die Anfrage **regionale** Idempotenz.
### Zonale Idempotenz
Die zonale Idempotenz stellt sicher, dass eine RunInstances API-Anfrage in jeder Availability Zone in einer Region idempotent ist. Dadurch wird sichergestellt, dass eine Anfrage mit demselben Client-Token innerhalb jeder Availability Zone in einer Region nur einmal abgeschlossen werden kann. Dasselbe Client-Token kann jedoch verwendet werden, um Instances in anderen Availability Zones in der Region zu starten.
Wenn Sie beispielsweise eine idempotente Anfrage senden, um eine Instance in der `us-east-1a` Availability Zone zu starten, und dann dasselbe Client-Token in einer Anfrage in der `us-east-1b` Availability Zone verwenden, starten wir Instances in jeder dieser Availability Zones. Wenn einer oder mehrere der Parameter unterschiedlich sind, kehren nachfolgende Wiederholungen mit demselben Client-Token in diesen Availability Zones entweder erfolgreich zurück, ohne dass weitere Aktionen ausgeführt werden, oder schlagen mit einem Fehler fehl. `IdempotentParameterMismatch`
### Regionale Idempotenz
Regionale Idempotenz stellt sicher, dass eine RunInstances API-Anfrage in einer Region idempotent ist. Dadurch wird sichergestellt, dass eine Anfrage mit demselben Client-Token innerhalb einer Region nur einmal abgeschlossen werden kann. Genau dieselbe Anfrage mit demselben Client-Token kann jedoch verwendet werden, um Instances in einer anderen Region zu starten.
Wenn Sie beispielsweise eine idempotente Anfrage senden, um eine Instance in der `us-east-1` Region zu starten, und dann dasselbe Client-Token in einer Anfrage in der `eu-west-1` Region verwenden, starten wir Instances in jeder dieser Regionen. Wenn einer oder mehrere der Parameter unterschiedlich sind, kehren nachfolgende Wiederholungen mit demselben Client-Token in diesen Regionen entweder erfolgreich zurück, ohne dass weitere Aktionen ausgeführt werden, oder schlagen mit einem Fehler fehl. `IdempotentParameterMismatch`
**Tipp**
Wenn eine der Availability Zones in der angeforderten Region nicht verfügbar ist, können RunInstances Anfragen, die regionale Idempotenz verwenden, fehlschlagen. Um die von der AWS Infrastruktur angebotenen Availability Zone-Funktionen nutzen zu können, empfehlen wir, beim Starten von Instances die zonale Idempotenz zu verwenden. RunInstances Anfragen, die zonale Idempotenz verwenden und auf eine verfügbare Availability Zone abzielen, sind erfolgreich, auch wenn keine andere Availability Zone in der angeforderten Region verfügbar ist.
## Beispiele
### AWS CLI Beispiele für Befehle
Um einen AWS CLI Befehl idempotent zu machen, fügen Sie die `--client-token` Option hinzu.
**Beispiel 1: Idempotenz**
Der folgende Befehl [allocate-hosts](https://docs.aws.amazon.com/cli/latest/reference/ec2/allocate-hosts.html) verwendet Idempotenz, da er ein Client-Token enthält.
```
aws ec2 allocate-hosts --instance-type m5.large --availability-zone eu-west-1a --auto-placement on --quantity 1 --client-token 550e8400-e29b-41d4-a716-446655440000
```
**Beispiel 2: Regionale Idempotenz von Run-Instances**
Der folgende Befehl [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) verwendet regionale Idempotenz, da er ein Client-Token beinhaltet, aber weder explizit noch implizit eine Availability Zone spezifiziert.
```
aws ec2 run-instances --image-id ami-b232d0db --count 1 --key-name my-key-pair --client-token 550e8400-e29b-41d4-a716-446655440000
```
**Beispiel 3: Zonale Idempotenz von Run-Instances**
Der folgende Befehl [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) verwendet zonale Idempotenz, da er ein Client-Token und eine explizit angegebene Availability Zone enthält.
```
aws ec2 run-instances --placement "AvailabilityZone=us-east-1a" --image-id ami-b232d0db --count 1 --key-name my-key-pair --client-token 550e8400-e29b-41d4-a716-446655440000
```
### Beispiele für API-Anfragen
Um eine API-Anfrage idempotent zu machen, fügen Sie den `ClientToken` Parameter hinzu.
**Beispiel 1: Idempotenz**
Die folgende [AllocateHosts](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AllocateHosts.html)API-Anfrage verwendet Idempotenz, da sie ein Client-Token enthält.
```
https://ec2.amazonaws.com/?Action=AllocateHosts
&AvailabilityZone=us-east-1b
&InstanceType=m5.large
&Quantity=1
&AutoPlacement=off
&ClientToken=550e8400-e29b-41d4-a716-446655440000
&AUTHPARAMS
```
**Beispiel 2: regionale Idempotenz RunInstances**
Die folgende [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)API-Anfrage verwendet regionale Idempotenz, da sie ein Client-Token enthält, aber weder explizit noch implizit eine Availability Zone spezifiziert.
```
https://ec2.amazonaws.com/?Action=RunInstances
&ImageId=ami-3ac33653
&MaxCount=1
&MinCount=1
&KeyName=my-key-pair
&ClientToken=550e8400-e29b-41d4-a716-446655440000
&AUTHPARAMS
```
**Beispiel 3: Zonale Idempotenz RunInstances**
Die folgende [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)API-Anfrage verwendet zonale Idempotenz, da sie ein Client-Token und eine explizit angegebene Availability Zone enthält.
```
https://ec2.amazonaws.com/?Action=RunInstances
&Placement.AvailabilityZone=us-east-1d
&ImageId=ami-3ac33653
&MaxCount=1
&MinCount=1
&KeyName=my-key-pair
&ClientToken=550e8400-e29b-41d4-a716-446655440000
&AUTHPARAMS
```
## Versuchen Sie es erneut mit Empfehlungen für idempotente Anfragen
Die folgende Tabelle zeigt einige häufig vorkommende Antworten, die Sie auf idempotente API-Anfragen erhalten könnten, und stellt Empfehlungen zu Wiederholungsversuchen bereit.
| Antwort | Empfehlung | Kommentare |
| --- | --- | --- |
| 200 (OK) | Nicht erneut versuchen | Die ursprüngliche Anfrage wurde erfolgreich abgeschlossen. Alle nachfolgenden Wiederholungsversuche werden als erfolgreich zurückgegeben. |
| [Antwortcodes der Serie 400 (Client-Fehler)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html#CommonErrors) | Nicht erneut versuchen | Es liegt eins der folgenden Probleme mit der Anfrage vor: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/ec2/latest/devguide/ec2-api-idempotency.html) Wenn die Anfrage eine Ressource umfasst, deren Status sich gerade ändert, könnte ein erneuter Anfrageversuch möglicherweise erfolgreich sein. |
| Antwortcodes der Serie 500 ([Serverfehler](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html#api-error-codes-table-server)) | Erneut versuchen | Der Fehler wird durch ein AWS serverseitiges Problem verursacht und ist im Allgemeinen vorübergehend. Wiederholen Sie die Anfrage mit einer geeigneten Backoff-Strategie. |
# Drosselung von Anfragen für die Amazon-API EC2
Amazon EC2 drosselt EC2 API-Anfragen für jedes AWS Konto pro Region. Wir tun dies, um die Leistung des Dienstes zu verbessern und eine faire Nutzung für alle EC2 Amazon-Kunden sicherzustellen. Durch die Drosselung wird sichergestellt, dass Anfragen an die EC2 Amazon-API die maximal zulässigen API-Anforderungslimits nicht überschreiten. API-Anfragen unterliegen den Anforderungsbeschränkungen, unabhängig davon, ob sie von folgenden Quellen stammen:
+ Eine Drittanbieteranwendung
+ Ein Befehlszeilentool
+ Die EC2 Amazon-Konsole
Wenn Sie ein API-Drosselungslimit überschreiten, erhalten Sie den `RequestLimitExceeded` Fehlercode.
**Topics**
+ [Wie wird die Drosselung angewendet](#throttling-how)
+ [Token-Limits anfragen](#throttling-limits-rate-based)
+ [Limits für Ressourcentokens](#throttling-limits-cost-based)
+ [Überwachen Sie die API-Drosselung](#throttling-monitor)
+ [Wiederholungen und exponentieller Backoff](#api-backoff)
+ [Anfordern einer -Limit-Erhöhung](#throttling-increase)
## Wie wird die Drosselung angewendet
Amazon EC2 verwendet den [Token-Bucket-Algorithmus](https://en.wikipedia.org/wiki/Token_bucket), 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:
**Topics**
+ [Anforderungsratenbegrenzung](#throttling-rate-based)
+ [Begrenzung der Ressourcenrate](#throttling-cost-based)
### 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-Aktion`DescribeHosts`, 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-Aktion`DescribeHosts`, 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-Aktion`DescribeHosts`, 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](#throttling-limits-rate-based).
### Begrenzung der Ressourcenrate
Einige API-Aktionen, wie z. B. `RunInstances` und`TerminateInstances`, 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](#throttling-limits-cost-based).
## Größen und Nachfüllraten für Token-Buckets anfragen
Zur Begrenzung der Anforderungsrate werden API-Aktionen in die folgenden Kategorien eingeteilt:
+ **Nicht mutierende Aktionen** — API-Aktionen, die Daten über Ressourcen abrufen. Diese Kategorie umfasst im Allgemeinen alle `Describe*` `List*``Search*`,, und `Get*` API-Aktionen wie `DescribeRouteTables``SearchTransitGatewayRoutes`, und. `GetIpamPoolCidrs` Diese API-Aktionen haben 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](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-pagination.html) oder eines Filters angefordert werden, Token aus einem kleineren Token-Bucket verwenden.](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/Using_Filtering.html#Filtering_Resources_CLI) 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` und`ModifyHosts`. `CreateCapacityReservation` Diese Aktionen haben eine niedrigere Drosselungsgrenze als API-Aktionen ohne Mutationen.
+ **Ressourcenintensive Aktionen — Mutierende API-Aktionen**, deren Ausführung am meisten Zeit in Anspruch nimmt und die meisten Ressourcen beansprucht. *Diese Aktionen haben eine noch niedrigere Drosselungsgrenze als mutierende Aktionen.* *Sie werden getrennt von anderen mutierenden Aktionen gedrosselt.*
+ **Nicht mutierende Konsolenaktionen** — Nicht mutierende API-Aktionen, die von der Amazon-Konsole angefordert werden. EC2 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 |
| --- | --- | --- | --- |
| Aktionen, die nicht mutieren | 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 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/ec2/latest/devguide/ec2-api-throttling.html) | 50 | 10 |
| Mutierende Aktionen | *Alle mutierenden API-Aktionen, bei denen es sich nicht um *ressourcenintensive oder nicht kategorisierte Aktionen* handelt.* | 50 | 5 |
| Ressourcenintensive Aktionen | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/ec2/latest/devguide/ec2-api-throttling.html) | 50 | 5 |
| Aktionen auf der Konsole, die nicht mutieren | Die`Describe*`, `List*``Search*`, und `Get*` API-Aktionen, die von der EC2 Amazon-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 EC2 Amazon-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Überwachen Sie API-Anfragen mit CloudWatch](monitor.md).
## 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 einer Instance zu informieren. Weitere Informationen finden Sie unter [Automatisieren EC2 von Amazon mithilfe EventBridge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html).
**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](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/).
Jedes AWS SDK implementiert eine automatische Wiederholungslogik. Weitere Informationen finden Sie unter [Verhalten bei Wiederholungsversuchen](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) im Referenzhandbuch *AWS SDKs und im Tools-Referenzhandbuch.*
## Anfordern einer -Limit-Erhöhung
Sie können eine Erhöhung der API-Drosselungslimits für Ihren 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` `StartInstances``StopInstances`,, und`TerminateInstances`. Geben Sie unbedingt an, welches Limit erhöht werden soll
**Um Zugriff auf diese Funktion zu beantragen**
1. [AWS Support Zentrum](https://console.aws.amazon.com/support/home#/) öffnen.
1. Wählen Sie **Create case** (Fall erstellen) aus.
1. Wählen Sie **Konto und Fakturierung** aus.
1. Wählen Sie für **Service** **die Optionen Allgemeine Informationen und Erste Schritte** aus.
1. Wählen Sie als **Kategorie** die Option **Nutzung AWS und Dienste** aus.
1. Wählen Sie **Next step: Additional information** (Nächster Schritt: Zusätzliche Informationen).
1. Geben Sie unter **Subject (Betreff)** **Request an increase in my Amazon EC2 API throttling limits** ein.
1. 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
```
1. Klicken Sie auf **Next step: Solve now or contact us** ( ()Nächster Schritt): Jetzt lösen oder Support kontaktieren).
1. Wählen Sie auf der Registerkarte **Kontakt** Ihre bevorzugte Kontaktsprache und Kontaktmethode aus.
1. Wählen Sie **Absenden** aus.
# Paginierung in der Amazon-API EC2
Wir empfehlen, beim Aufrufen von Beschreibungsaktionen, die potenziell zu einer großen Anzahl von Ergebnissen führen können, die Paginierung zu verwenden, z. B. `DescribeInstances` Durch die Paginierung werden die Anzahl der von einem Describe-Aufruf zurückgegebenen Elemente und die Zeit, die bis zur Rückgabe des Aufrufs benötigt wird, begrenzt. Wenn Sie über eine große Anzahl von Ressourcen verfügen, werden Aufrufe ohne Paginierung möglicherweise gedrosselt und es kann zu einem Timeout kommen. Daher ist die Gesamtlatenz bei paginierten Aufrufen besser als bei Aufrufen ohne Paginierung, da paginierte Aufrufe durchweg erfolgreich sind.
Weitere Informationen finden Sie unter [Pagination](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Query-Requests.html#api-pagination) in der *Amazon EC2 API-Referenz.*
## Bewährte Methoden
Wenn möglich, geben Sie IDs in Ihren Describe-Aufrufen eine Liste von Ressourcen an. Dies ist der schnellste Weg, um eine große Anzahl von Ressourcen zu beschreiben. Beachten Sie, dass Sie IDs in einem einzigen Anruf nicht mehr als 1.000 angeben sollten. Im Folgenden wird ein Beispiel gezeigt.
```
private List describeMyInstances(List ids){
if (ids == null || ids.isEmpty()) {
return ImmutableList.of();
}
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withInstanceIds(ids);
return ec2.describeInstances(request).getReservations();
}
```
Wenn Sie IDs in Ihren Beschreibungsaufrufen keine Ressource angeben können, empfehlen wir dringend, die Paginierung zu verwenden. Im Folgenden wird ein Beispiel gezeigt.
```
private List describeMyInstances(final Collection filters){
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withFilters(filters)
.withMaxResults(1000);
List reservations = new ArrayList<>();
String nextToken = null;
do {
request.setNextToken(nextToken);
final DescribeInstancesResult response = ec2.describeInstances(request);
reservations.addAll(response.getReservations());
nextToken = response.getNextToken();
} while (nextToken != null);
return reservations;
}
```
Wenn Sie einen paginierten Anruf erneut versuchen müssen, verwenden Sie [exponentielles](ec2-api-throttling.md#api-backoff) Back-off mit Jitter.
## Häufige Probleme
Im Folgenden finden Sie Beispiele für Code, der versehentlich Aufrufe ohne Paginierung durchführt.
**Example Beispiel für ein Problem: Übergabe einer leeren Ressourcenliste IDs**
Der folgende Code verwendet eine Liste von IDs. Wenn die Liste jedoch leer ist, ist das Ergebnis ein unpaginierter Aufruf.
```
private List describeMyInstances(List ids){
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withInstanceIds(ids);
return ec2.describeInstances(request).getReservations();
}
```
Um dieses Problem zu beheben, stellen Sie vor dem Aufruf zur Beschreibung sicher, dass die Liste nicht leer ist.
```
private List describeMyInstances(List ids){
if (ids == null || ids.isEmpty()) {
return ImmutableList.of();
// OR
return Lists.newArrayList();
// OR
return new ArrayList<>();
}
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withInstanceIds(ids);
return ec2.describeInstances(request).getReservations();
}
```
**Example Beispiel für ein Problem: Keine Einstellung MaxResults**
Der folgende Code überprüft und verwendet`nextToken`, legt aber nicht fest`MaxResults`.
```
private List describeMyInstances(final Collection filters){
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withFilters(filters);
List reservations = new ArrayList<>();
String nextToken = null;
do {
request.setNextToken(nextToken);
final DescribeInstancesResult response = ec2.describeInstances(request);
reservations.addAll(response.getReservations());
nextToken = response.getNextToken();
} while (nextToken != null);
return reservations;
}
```
Um dieses Problem zu beheben, fügen Sie `withMaxResults` Folgendes hinzu.
```
private List describeMyInstances(final Collection filters){
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withFilters(filters)
.withMaxResults(1000);
List reservations = new ArrayList<>();
String nextToken = null;
do {
request.setNextToken(nextToken);
final DescribeInstancesResult response = ec2.describeInstances(request);
reservations.addAll(response.getReservations());
nextToken = response.getNextToken();
} while (nextToken != null);
return reservations;
}
```