

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.

# Sicherstellung der Idempotenz bei Amazon-API-Anfragen EC2
<a name="ec2-api-idempotency"></a>

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
<a name="client-tokens"></a>

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
<a name="run-instances-idempotency"></a>

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
<a name="zonal-idempotency"></a>

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
<a name="regional-idempotency"></a>

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
<a name="Run_Instance_Idempotency_CLI"></a>

### AWS CLI Beispiele für Befehle
<a name="cli-example"></a>

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
<a name="api-example"></a>

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
<a name="recommended-actions"></a>

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.  | 