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.
# Das SDKs konfigurieren
In der AWS SDK für Go V2 können Sie allgemeine Einstellungen für Service-Clients konfigurieren, z. B. die Logger-, Log Level- und Wiederholungskonfiguration. Die meisten Einstellungen sind optional. Für jeden Service-Client müssen Sie jedoch eine AWS Region und Ihre Anmeldeinformationen angeben. Das SDK verwendet diese Werte, um Anfragen an die richtige Region zu senden und Anfragen mit den richtigen Anmeldeinformationen zu signieren. Sie können diese Werte programmgesteuert im Code oder über die Ausführungsumgebung angeben.
## AWS Gemeinsam genutzte Konfigurationsdateien werden geladen
Es gibt eine Reihe von Möglichkeiten, einen Service-API-Client zu initialisieren, aber das folgende Muster wird Benutzern am häufigsten empfohlen.
Verwenden Sie den folgenden Code, um das SDK für die Verwendung der AWS gemeinsam genutzten Konfigurationsdateien zu konfigurieren:
```
import (
"context"
"log"
"github.com/aws/aws-sdk-go-v2/config"
)
// ...
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
log.Fatalf("failed to load configuration, %v", err)
}
```
`config.LoadDefaultConfig(context.TODO())`erstellt mithilfe der AWS gemeinsam genutzten [Konfigurationsquellen eine AWS.Config](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#Config). Dazu gehören die Konfiguration eines Anmeldeinformationsanbieters, die Konfiguration der AWS Region und das Laden der dienstspezifischen Konfiguration. Dienstclients können mithilfe der geladenen Datei erstellt werden`aws.Config`, wodurch ein konsistentes Muster für die Erstellung von Clients bereitgestellt wird.
Weitere Informationen zu AWS gemeinsam genutzten Konfigurationsdateien finden Sie unter [Konfiguration](https://docs.aws.amazon.com/sdkref/latest/guide/creds-config-files.html) im Referenzhandbuch AWS SDKs und im Tools-Referenzhandbuch.
## Angabe der AWS Region
Wenn Sie die Region angeben, geben Sie an, wohin Anfragen gesendet werden sollen, z. B. `us-west-2` oder`us-east-2`. Eine Liste der Regionen für jeden Dienst finden Sie unter [Dienstendpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) in der Allgemeine Amazon Web Services-Referenz.
Das SDK hat keine Standardregion. Um eine Region anzugeben:
+ Setzen Sie die `AWS_REGION` Umgebungsvariable auf die Standardregion.
+ Stellen Sie die Region explizit mit [config ein. WithRegion](https://github.com/aws/aws-sdk-go-v2/blob/config/v0.2.2/config/provider.go#L127)als Argument für `config.LoadDefaultConfig` beim Laden der Konfiguration.
RÜCKBLICK: Wenn Sie eine Region mit all diesen Techniken festlegen, verwendet das SDK die Region, die Sie explizit angegeben haben.
### Region mit Umgebungsvariable konfigurieren
#### Linux, macOS oder Unix
```
export AWS_REGION=us-west-2
```
#### Windows
```
set AWS_REGION=us-west-2
```
### Region programmgesteuert angeben
```
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRegion("us-west-2"))
```
## Festlegen von Anmeldeinformationen
AWS SDK für Go Für das Signieren von Anfragen sind Anmeldeinformationen (ein Zugriffsschlüssel und ein geheimer Zugriffsschlüssel) erforderlich. AWS Sie können Ihre Anmeldeinformationen je nach Ihrem speziellen Anwendungsfall an verschiedenen Stellen angeben. Informationen zum Abrufen von Anmeldeinformationen finden Sie unter[Fangen Sie an mit AWS SDK für Go](getting-started.md).
Wenn Sie eine `aws.Config` Instanz mithilfe initialisieren`config.LoadDefaultConfig`, verwendet das SDK seine standardmäßige Anmeldeinformationskette, um Anmeldeinformationen zu finden AWS . Diese standardmäßige Anmeldeinformationskette sucht in der folgenden Reihenfolge nach Anmeldeinformationen:
1. Umgebungsvariablen.
1. Statische Anmeldeinformationen (`AWS_ACCESS_KEY_ID`,`AWS_SECRET_ACCESS_KEY`,`AWS_SESSION_TOKEN`)
1. Web-Identitätstoken (`AWS_WEB_IDENTITY_TOKEN_FILE`)
1. Gemeinsam genutzte Konfigurationsdateien.
1. SDK verwendet standardmäßig den Ordner `credentials` Datei unter dem `.aws` Ordner, der sich im Home-Ordner auf Ihrem Computer befindet.
1. SDK verwendet standardmäßig den Ordner `config` File unter dem `.aws` Ordner, der sich im Home-Ordner auf Ihrem Computer befindet.
1. Wenn Ihre Anwendung eine Amazon ECS-Aufgabendefinition oder einen RunTask API-Vorgang verwendet, IAM-Rolle für Aufgaben.
1. Wenn Ihre Anwendung auf einer Amazon EC2-Instance ausgeführt wird, IAM-Rolle für Amazon EC2.
Das SDK erkennt und verwendet die integrierten Anbieter automatisch, ohne dass manuelle Konfigurationen erforderlich sind. Wenn Sie beispielsweise IAM-Rollen für Amazon EC2 EC2-Instances verwenden, verwenden Ihre Anwendungen automatisch die Anmeldeinformationen der Instance. Sie müssen die Anmeldeinformationen in Ihrer Anwendung nicht manuell konfigurieren.
Als bewährte Methode AWS empfiehlt es sich, die Anmeldeinformationen in der folgenden Reihenfolge anzugeben:
1. Verwenden Sie IAM-Rollen für Aufgaben, wenn Ihre Anwendung eine Amazon ECS-Aufgabendefinition oder einen RunTask API-Vorgang verwendet.
1. Verwenden Sie IAM-Rollen für Amazon EC2 (wenn Ihre Anwendung auf einer Amazon EC2 EC2-Instance läuft).
IAM-Rollen stellen Anwendungen auf der Instance temporäre Sicherheitsanmeldedaten zur Verfügung, um Aufrufe zu tätigen. AWS IAM-Rollen bieten eine einfache Möglichkeit, Anmeldeinformationen auf mehreren Amazon EC2 EC2-Instances zu verteilen und zu verwalten.
1. Verwenden Sie gemeinsam genutzte Anmeldeinformationen oder Konfigurationsdateien.
Die Anmeldeinformationen und Konfigurationsdateien werden von anderen AWS SDKs und gemeinsam genutzt AWS CLI. Aus Sicherheitsgründen empfehlen wir, die Anmeldeinformationsdatei für die Festlegung sensibler Werte wie Zugriffsschlüssel IDs und geheime Schlüssel zu verwenden. Hier sind die [Formatierungsanforderungen](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html) für jede dieser Dateien.
1. Umgebungsvariablen verwenden.
Das Setzen von Umgebungsvariablen ist nützlich, wenn Sie Entwicklungsarbeiten auf einem anderen Computer als einer Amazon EC2 EC2-Instance durchführen.
### IAM-Rollen für Aufgaben
Wenn Ihre Anwendung eine Amazon ECS-Aufgabendefinition oder einen `RunTask` Vorgang verwendet, verwenden Sie [IAM-Rollen für Aufgaben](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html), um eine IAM-Rolle anzugeben, die von den Containern in einer Aufgabe verwendet werden kann.
### IAM-Rollen für Amazon EC2 EC2-Instances
Wenn Sie Ihre Anwendung auf einer Amazon EC2 EC2-Instance ausführen, verwenden Sie die [IAM-Rolle](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) der Instance, um temporäre Sicherheitsanmeldeinformationen für Aufrufe abzurufen. AWS
Wenn Sie Ihre Instance für die Verwendung von IAM-Rollen konfiguriert haben, verwendet das SDK diese Anmeldeinformationen automatisch für Ihre Anwendung. Sie müssen diese Anmeldeinformationen nicht manuell angeben.
### Gemeinsame Anmeldeinformationen und Konfiguration
Die gemeinsamen Anmeldeinformationen und Konfigurationsdateien können verwendet werden, um gemeinsame Konfigurationen AWS SDKs und andere Tools gemeinsam zu nutzen. Wenn Sie für unterschiedliche Tools und Anwendungen verschiedene Anmeldeinformationen verwenden, können Sie mithilfe von *Profilen* mehrere Zugriffsschlüssel innerhalb ein und derselben Konfigurationsdatei konfigurieren.
Sie können mehrere Speicherorte für Anmelde- oder Konfigurationsdateien angeben. Standardmäßig lädt das SDK Dateien`config.LoadOptions`, die an den in der [Festlegen von Anmeldeinformationen](#specifying-credentials) genannten Standardspeicherorten gespeichert sind.
```
import (
"context"
"github.com/aws/aws-sdk-go-v2/config"
)
// ...
cfg , err := config.LoadDefaultConfig(context.TODO(),
config.WithSharedCredentialsFiles(
[]string{"test/credentials", "data/credentials"},
),
config.WithSharedConfigFiles(
[]string{"test/config", "data/config"},
)
)
```
Wenn Sie mit gemeinsam genutzten Anmeldeinformationen und Konfigurationsdateien arbeiten und doppelte Profile angegeben werden, werden diese zusammengeführt, um ein Profil aufzulösen. Im Falle eines Zusammenführungskonflikts
1. Wenn in derselben credentials/config Datei doppelte Profile angegeben werden, haben die im letzteren Profil angegebenen Profileigenschaften Vorrang.
1. Wenn doppelte Profile entweder für mehrere Anmeldeinformationsdateien oder für mehrere Konfigurationsdateien angegeben werden, werden die Profileigenschaften gemäß der Reihenfolge der Dateieingabe in die `config.LoadOptions` aufgelöst. Die Profileigenschaften in den letztgenannten Dateien haben Vorrang.
1. Wenn ein Profil sowohl in der Anmeldeinformationsdatei als auch in der Konfigurationsdatei vorhanden ist, haben die Eigenschaften der Anmeldeinformationsdatei Vorrang.
Bei Bedarf können Sie die Schritte `LogConfigurationWarnings` zur Profilauflösung aktivieren `config.LoadOptions` und protokollieren.
#### Die Datei mit den Anmeldeinformationen wird erstellt
Wenn Sie keine gemeinsame Anmeldeinformationsdatei (`.aws/credentials`) haben, können Sie einen beliebigen Texteditor verwenden, um eine Datei in Ihrem Home-Verzeichnis zu erstellen. Fügen Sie Ihrer Anmeldeinformationsdatei den folgenden Inhalt hinzu ** und ** ersetzen Sie dabei Ihre Anmeldeinformationen.
```
[default]
aws_access_key_id =
aws_secret_access_key =
```
In der `[default]` Überschrift werden die Anmeldeinformationen für das Standardprofil definiert, die das SDK verwendet, sofern Sie es nicht für die Verwendung eines anderen Profils konfigurieren.
Sie können auch temporäre Sicherheitsanmeldedaten verwenden, indem Sie die Sitzungstoken zu Ihrem Profil hinzufügen, wie im folgenden Beispiel gezeigt:
```
[temp]
aws_access_key_id =
aws_secret_access_key =
aws_session_token =
```
Der Abschnittsname für ein nicht standardmäßiges Profil in einer Anmeldeinformationsdatei darf nicht mit dem Wort `profile` beginnen. Weitere Informationen finden Sie im [AWS SDKs Referenzhandbuch zu Tools.](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html#file-format-creds)
#### Die Config erstellen
Wenn Sie keine gemeinsame Anmeldeinformationsdatei (`.aws/config`) haben, können Sie einen beliebigen Texteditor verwenden, um eine Datei in Ihrem Home-Verzeichnis zu erstellen. Fügen Sie Ihrer Konfigurationsdatei den folgenden Inhalt hinzu und ** ersetzen Sie ihn durch die gewünschte Region.
```
[default]
region =
```
Die `[default]` Überschrift definiert die Konfiguration für das Standardprofil, das das SDK verwendet, sofern Sie es nicht für die Verwendung eines anderen Profils konfigurieren.
Sie können benannte Profile verwenden, wie im folgenden Beispiel gezeigt:
```
[profile named-profile]
region =
```
Der Abschnittsname für ein nicht standardmäßiges Profil in einer Konfigurationsdatei muss immer mit dem Wort beginnen`profile`, gefolgt vom beabsichtigten Profilnamen. Weitere Informationen finden Sie im Referenzhandbuch [AWS SDKs und im Tools-Referenzhandbuch.](https://docs.aws.amazon.com/credref/latest/refdocs/file-format.html#file-format-config)
#### Profile angeben
Sie können mehrere Zugriffsschlüssel in dieselbe Konfigurationsdatei aufnehmen, indem Sie jeden Satz von Zugriffsschlüsseln einem Profil zuordnen. In Ihrer Anmeldeinformationsdatei können Sie beispielsweise mehrere Profile wie folgt deklarieren.
```
[default]
aws_access_key_id =
aws_secret_access_key =
[test-account]
aws_access_key_id =
aws_secret_access_key =
[prod-account]
; work profile
aws_access_key_id =
aws_secret_access_key =
```
Standardmäßig prüft das SDK die Umgebungsvariable `AWS_PROFILE`, um zu bestimmen, welches Profil verwendet werden soll. Wenn keine `AWS_PROFILE` Variable festgelegt ist, verwendet das SDK das `default` Profil.
Manchmal möchten Sie vielleicht ein anderes Profil für Ihre Anwendung verwenden. Sie möchten beispielsweise die `test-account` Anmeldeinformationen mit Ihrer `myapp` Anwendung verwenden. Sie können dieses Profil mit dem folgenden Befehl verwenden:
```
$ AWS_PROFILE=test-account myapp
```
Sie können das SDK auch anweisen, ein Profil auszuwählen`config.LoadDefaultConfig`, indem Sie es entweder `os.Setenv("AWS_PROFILE", "test-account")` vor dem Aufruf aufrufen oder indem Sie ein explizites Profil als Argument übergeben, wie im folgenden Beispiel gezeigt:
```
cfg, err := config.LoadDefaultConfig(context.TODO(),
config.WithSharedConfigProfile("test-account"))
```
**Anmerkung**
Wenn Sie Anmeldeinformationen in Umgebungsvariablen angeben, verwendet das SDK immer diese Anmeldeinformationen, unabhängig davon, welches Profil Sie angeben.
### Umgebungsvariablen
Standardmäßig erkennt das SDK die in Ihrer Umgebung festgelegten AWS Anmeldeinformationen und verwendet sie zum Signieren von Anfragen AWS. Auf diese Weise müssen Sie die Anmeldeinformationen in Ihren Anwendungen nicht verwalten.
Das SDK sucht in den folgenden Umgebungsvariablen nach Anmeldeinformationen:
+ `AWS_ACCESS_KEY_ID`
+ `AWS_SECRET_ACCESS_KEY`
+ `AWS_SESSION_TOKEN` (optional)
Die folgenden Beispiele zeigen, wie Sie die Umgebungsvariablen konfigurieren.
#### Linux, OS X oder Unix
```
$ export AWS_ACCESS_KEY_ID=YOUR_AKID
$ export AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY
$ export AWS_SESSION_TOKEN=TOKEN
```
#### Windows
```
> set AWS_ACCESS_KEY_ID=YOUR_AKID
> set AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY
> set AWS_SESSION_TOKEN=TOKEN
```
### Geben Sie Anmeldeinformationen programmgesteuert an
`config.LoadDefaultConfig`[ermöglicht es Ihnen, eine explizite AWS anzugeben. CredentialProvider](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#CredentialsProvider)beim Laden der gemeinsam genutzten Konfigurationsquellen. Verwenden Sie [config, um beim Laden der gemeinsam genutzten Konfiguration einen expliziten Anbieter für Anmeldeinformationen zu übergeben. WithCredentialsProvider](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/config#WithCredentialsProvider). Wenn beispielsweise `customProvider` auf eine `aws.CredentialProvider` Implementierungsinstanz verwiesen wird, kann sie beim Laden der Konfiguration wie folgt übergeben werden:
```
cfg, err := config.LoadDefaultConfig(context.TODO(),
config.WithCredentialsProvider(customProvider))
```
Wenn Sie wie in diesem Beispiel explizit Anmeldeinformationen angeben, verwendet das SDK nur diese Anmeldeinformationen.
**Anmerkung**
Alle Anmeldeinformationsanbieter, die an übergeben oder von zurückgegeben wurden, `LoadDefaultConfig` werden [CredentialsCache](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#CredentialsCache)automatisch in eine eingebunden. Dies ermöglicht das Zwischenspeichern und die Rotation von Anmeldeinformationen, wodurch Parallelität gewährleistet ist. Wenn Sie einen Anbieter explizit `aws.Config` direkt konfigurieren, müssen Sie den Anbieter auch explizit mit diesem Typ umschließen, indem Sie. [NewCredentialsCache](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#NewCredentialsCache)
#### Statische Anmeldeinformationen
Sie können Anmeldeinformationen in Ihrer Anwendung fest codieren, indem Sie die [Anmeldeinformationen verwenden. NewStaticCredentialsProvider](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials#NewStaticCredentialsProvider)Anmeldeinformationsanbieter, um die zu verwendenden Zugriffsschlüssel explizit festzulegen. Beispiel:
```
cfg, err := config.LoadDefaultConfig(context.TODO(),
config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider("AKID", "SECRET_KEY", "TOKEN")),
)
```
**Warnung**
Betten Sie keine Anmeldeinformationen in eine Anwendung ein. Verwenden Sie diese Methode nur zu Testzwecken.
#### Anmeldeinformationen für Single Sign-On
Das SDK bietet einen Anbieter für Anmeldeinformationen zum Abrufen temporärer AWS Anmeldeinformationen mithilfe von. AWS IAM Identity Center Mit dem AWS CLI authentifizieren Sie sich beim AWS Zugriffsportal und autorisieren den Zugriff auf temporäre Anmeldeinformationen. AWS Anschließend konfigurieren Sie Ihre Anwendung so, dass das Single Sign-On (SSO) -Profil geladen wird, und das SDK verwendet Ihre SSO-Anmeldeinformationen, um temporäre AWS Anmeldeinformationen abzurufen, die bei Ablauf automatisch erneuert werden. Wenn Ihre SSO-Anmeldeinformationen ablaufen, müssen Sie sie ausdrücklich erneuern, indem Sie sich erneut mit dem bei Ihrem IAM Identity Center-Konto anmelden. AWS CLI
Sie können beispielsweise ein Profil erstellen`dev-profile`, dieses Profil mit dem authentifizieren und autorisieren und Ihre Anwendung wie unten gezeigt konfigurieren. AWS CLI
1. Erstellen Sie zuerst das und `profile` `sso-session`
```
[profile dev-profile]
sso_session = dev-session
sso_account_id = 012345678901
sso_role_name = Developer
region = us-east-1
[sso-session dev-session]
sso_region = us-west-2
sso_start_url = https://company-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:access
```
1. Melden Sie sich mit dem AWS CLI an, um das SSO-Profil zu authentifizieren und zu autorisieren.
```
$ aws --profile dev-profile sso login
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:
https://device.sso.us-west-2.amazonaws.com/
Then enter the code:
ABCD-EFGH
Successully logged into Start URL: https://company-sso-portal.awsapps.com/start
```
1. Als Nächstes konfigurieren Sie Ihre Anwendung so, dass sie das SSO-Profil verwendet.
```
import "github.com/aws/aws-sdk-go-v2/config"
// ...
cfg, err := config.LoadDefaultConfig(
context.Background(),
config.WithSharedConfigProfile("dev-profile"),
)
if err != nil {
return err
}
```
Weitere Informationen zur Konfiguration von SSO-Profilen und zur Authentifizierung mithilfe des AWS CLI finden Sie unter [Konfiguration der AWS CLI zu AWS IAM Identity Center verwendenden](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) Profile im AWS CLI Benutzerhandbuch. [Weitere Informationen zur programmgesteuerten Erstellung des SSO-Anmeldeinformationsanbieters finden Sie in der Referenzdokumentation zur ssocreds-API.](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials/ssocreds)
#### Anmeldeinformationen
Sie können Ihre vorhandenen Anmeldedaten für die AWS Management Console für den programmgesteuerten Zugriff AWS auf Dienste verwenden. AWS Generiert nach einem browserbasierten Authentifizierungsablauf temporäre Anmeldeinformationen, die in allen lokalen Entwicklungstools wie der AWS CLI AWS -Tools für PowerShell und AWS SDKs funktionieren. Diese Funktion vereinfacht die Konfiguration und Verwaltung von AWS CLI-Anmeldeinformationen, insbesondere wenn Sie die interaktive Authentifizierung der Verwaltung von langfristigen Zugriffsschlüsseln vorziehen.
1. Initiieren Sie den Anmeldevorgang mit der AWS CLI und folgen Sie den Anweisungen des Browsers. In diesem Beispiel speichern wir die Anmeldesitzung in einem neuen Profil**dev-profile**, dies ist jedoch optional.
```
$ aws --profile dev-profile login
```
1. (Optional) Überprüfen Sie Ihre AWS gemeinsam genutzte Konfigurationsdatei, um sicherzustellen, dass die Sitzung eingerichtet wurde.
```
[profile dev-profile]
login_session = arn:aws:sts::account id>:role
```
1. Als Nächstes konfigurieren Sie Ihre Anwendung so, dass sie das Anmeldeprofil verwendet.
```
import "github.com/aws/aws-sdk-go-v2/config"
// ...
cfg, err := config.LoadDefaultConfig(
context.Background(),
// only necessary if login session is saved to a non-default profile
config.WithSharedConfigProfile("dev-profile"),
)
if err != nil {
return err
}
```
Weitere Informationen zur Konfiguration von Anmeldeprofilen und zur Authentifizierung mit der AWS CLI finden Sie unter [Anmeldung für die AWS lokale Entwicklung mit Konsolenanmeldedaten](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sign-in.html).
#### Andere Anbieter von Anmeldeinformationen
Das SDK bietet andere Methoden zum Abrufen von Anmeldeinformationen im Modul für [Anmeldeinformationen](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials). Sie können beispielsweise temporäre Sicherheitsanmeldedaten aus AWS -Security-Token-Service oder Anmeldeinformationen aus einem verschlüsselten Speicher abrufen.
**Verfügbare Anbieter von Anmeldeinformationen**:
+ [ec2rolecreds](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials/ec2rolecreds) — Rufen Sie Anmeldeinformationen von Amazon EC2-Instance-Rollen über Amazon EC2 IMDS ab.
+ [endpointcreds — Ruft Anmeldeinformationen von einem beliebigen HTTP-Endpunkt ab](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials/endpointcreds).
+ [processcreds](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials/processcreds) — Ruft Anmeldeinformationen von einem externen Prozess ab, der von der Shell der Host-Umgebung aufgerufen wird.
+ [stscreds](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials/stscreds) — Ruft Anmeldeinformationen ab von AWS STS
# Authentifizierung konfigurieren
Der AWS SDK für Go bietet die Möglichkeit, den Dienst für das Authentifizierungsverhalten zu konfigurieren. In den meisten Fällen ist die Standardkonfiguration ausreichend, aber die Konfiguration der benutzerdefinierten Authentifizierung ermöglicht zusätzliche Funktionen, wie z. B. die Verwendung von Servicefunktionen vor der Veröffentlichung.
## Definitionen
Dieser Abschnitt enthält eine allgemeine Beschreibung der Authentifizierungskomponenten in der. AWS SDK für Go
### AuthScheme
An [AuthScheme](https://pkg.go.dev/github.com/aws/smithy-go/transport/http#AuthScheme)ist die Schnittstelle, die den Workflow definiert, über den das SDK eine Anruferidentität abruft und sie an eine Betriebsanforderung anhängt.
Ein Authentifizierungsschema verwendet die folgenden Komponenten, die weiter unten ausführlich beschrieben werden:
+ Eine eindeutige ID, die das Schema identifiziert
+ Ein Identity Resolver, der eine beim Signieren verwendete Anruferidentität zurückgibt (z. B. Ihre AWS Anmeldeinformationen)
+ Ein Unterzeichner, der die Identität des Anrufers tatsächlich in die Transportanfrage des Vorgangs einfügt (z. B. den HTTP-Header) `Authorization`
Jede Service-Client-Option enthält ein `AuthSchemes` Feld, das standardmäßig mit der Liste der von diesem Dienst unterstützten Authentifizierungsschemata gefüllt ist.
### AuthSchemeResolver
Jede Service-Client-Option enthält ein `AuthSchemeResolver` Feld. Diese pro Dienst definierte Schnittstelle ist die API, die vom SDK aufgerufen wird, um die möglichen Authentifizierungsoptionen für jeden Vorgang zu ermitteln.
**Wichtig**
Der Auth-Schema-Resolver schreibt NICHT vor, welches Authentifizierungsschema verwendet wird. [Er gibt eine Liste von Schemata zurück, die verwendet werden *können* („Optionen“). Das endgültige Schema wird durch einen festen Algorithmus ausgewählt, der hier beschrieben wird.](#auth-scheme-resolution-workflow)
### Option
Eine [Option](https://pkg.go.dev/github.com/aws/smithy-go/auth#Option), die von einem Aufruf von zurückgegeben wird`ResolverAuthSchemes`, stellt eine mögliche Authentifizierungsoption dar.
Eine Option besteht aus drei Informationssätzen:
+ Eine ID, die das mögliche Schema darstellt
+ Ein undurchsichtiger Satz von Eigenschaften, der dem Identity Resolver des Schemas zur Verfügung gestellt werden soll
+ Ein undurchsichtiger Satz von Eigenschaften, der dem Unterzeichner des Schemas zur Verfügung gestellt werden soll
#### Ein Hinweis zu Eigenschaften
In 99% der Anwendungsfälle müssen sich Anrufer keine Gedanken über die undurchsichtigen Eigenschaften bei der Identitätsauflösung und beim Signieren machen. Das SDK ruft die erforderlichen Eigenschaften für jedes Schema ab und übergibt sie an die stark typisierten Schnittstellen, die im SDK verfügbar sind. [Beispielsweise codiert der standardmäßige Auth Resolver für Dienste die Option Sigv4 so, dass sie über Unterzeichnereigenschaften für den Signaturnamen und die Region verfügt, deren Werte an die vom Client konfigurierte Version v4 übergeben werden. HTTPSigner](https://pkg.go.dev/github.com/aws/smithy-go/auth#Option)Implementierung, wenn SigV4 ausgewählt ist.
### Identität
Eine [Identität](https://pkg.go.dev/github.com/aws/smithy-go/auth#Identity) ist eine abstrakte Darstellung dessen, wer der SDK-Aufrufer ist.
Der im SDK am häufigsten verwendete Identitätstyp ist eine Reihe von`aws.Credentials`. In den meisten Anwendungsfällen muss sich der Aufrufer nicht mit `Identity` einer Abstraktion befassen und kann direkt mit den konkreten Typen arbeiten.
**Anmerkung**
Um die Abwärtskompatibilität zu wahren und API-Verwirrung zu vermeiden, erfüllt der AWS SDK-spezifische Identitätstyp die Schnittstelle `aws.Credentials` nicht direkt. `Identity` Diese Zuordnung wird intern abgewickelt.
### IdentityResolver
[IdentityResolver](https://pkg.go.dev/github.com/aws/smithy-go/auth#IdentityResolver)ist die Schnittstelle, über die ein abgerufen `Identity` wird.
[Konkrete Versionen von `IdentityResolver` existieren im SDK in stark typisierter Form (z. B. aws. CredentialsProvider](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#CredentialsProvider)), das SDK verarbeitet diese Zuordnung intern.
Ein Aufrufer muss die `IdentityResolver` Schnittstelle nur direkt implementieren, wenn er ein externes Authentifizierungsschema definiert.
### Signer
Der [Unterzeichner](https://pkg.go.dev/github.com/aws/smithy-go/transport/http#Signer) ist die Schnittstelle, über die eine Anfrage um den abgerufenen Anrufer ergänzt wird. `Identity`
[Konkrete Versionen von `Signer` existieren im SDK in stark typisierter Form (z. B. v4). HTTPSigner](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/signer/v4#HTTPSigner)), das SDK verarbeitet diese Zuordnung intern.
Ein Aufrufer muss die `Signer` Schnittstelle nur direkt implementieren, wenn er ein externes Authentifizierungsschema definiert.
### AuthResolverParameters
Jeder Dienst benötigt einen bestimmten Satz von Eingaben, die an seine Auflösungsfunktion übergeben werden, die in jedem Servicepaket als definiert ist. `AuthResolverParameters`
Die Basis-Resolverparameter lauten wie folgt:
| Name | Typ | description |
| --- | --- | --- |
| Operation | string | Der Name der Operation, die aufgerufen wird. |
| Region | string | Die AWS Region des Kunden. Nur für Dienste vorhanden, die SigV4 [A] verwenden. |
Wenn Sie Ihren eigenen Resolver implementieren, sollten Sie niemals eine eigene Instanz seiner Parameter erstellen müssen. Das SDK bezieht diese Werte pro Anfrage und leitet sie an Ihre Implementierung weiter.
## Arbeitsablauf zur Auflösung des Authentifizierungsschemas
Wenn Sie einen AWS Dienstvorgang über das SDK aufrufen, erfolgt die folgende Abfolge von Aktionen, nachdem die Anforderung serialisiert wurde:
1. Das SDK ruft die `AuthSchemeResolver.ResolveAuthSchemes()` API des Clients auf und bezieht die Eingabeparameter nach Bedarf, um eine Liste möglicher [Optionen](https://pkg.go.dev/github.com/aws/smithy-go/auth#Option) für den Vorgang zu erhalten.
1. Das SDK durchläuft diese Liste und wählt das erste Schema aus, das die folgenden Bedingungen erfüllt.
+ Ein Schema mit übereinstimmender ID ist in der eigenen Liste des Kunden vorhanden `AuthSchemes`
+ Der Identity Resolver des Schemas existiert in den Optionen des Clients (ist nicht vorhanden`nil`) (wird über die `GetIdentityResolver` Methode des Schemas überprüft, die Zuordnung zu den oben beschriebenen konkreten Identity-Resolver-Typen erfolgt intern) (1)
1. Unter der Annahme, dass ein praktikables Schema ausgewählt wurde, ruft das SDK seine `GetIdentityResolver()` API auf, um die Identität des Aufrufers abzurufen. Beispielsweise wird das integrierte SigV4-Authentifizierungsschema intern dem Anbieter des Kunden zugeordnet. `Credentials`
1. Das SDK ruft den Identity Resolver auf `GetIdentity()` (z. B. `aws.CredentialProvider.Retrieve()` für Sigv4).
1. Das SDK ruft die Endpunkt-Resolver `ResolveEndpoint()` auf, um den Endpunkt für die Anfrage zu finden. Der Endpunkt kann zusätzliche Metadaten enthalten, die den Signaturprozess beeinflussen (z. B. einen eindeutigen Signaturnamen für S3 Object Lambda).
1. Das SDK ruft die `Signer()` API des Authentifizierungsschemas auf, um den Unterzeichner abzurufen, und verwendet seine `SignRequest()` API, um die Anfrage mit der zuvor abgerufenen Anruferidentität zu signieren.
(1) Wenn das SDK auf die anonyme Option (ID`smithy.api#noAuth`) in der Liste stößt, wird sie automatisch ausgewählt, da es keinen entsprechenden Identity Resolver gibt.
## Wird nativ unterstützt `AuthScheme`
Die folgenden Authentifizierungsschemata werden nativ unterstützt von. AWS SDK für Go
| Name | Schema-ID | Identitätsauflöser | Signer | Hinweise |
| --- | --- | --- | --- | --- |
| [SigV4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) | aws.auth\$1sigv4 | [aws. CredentialsProvider](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#Credentials) | [v4. HTTPSigner](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/signer/v4#Signer) | Die aktuelle Standardeinstellung für die meisten AWS Serviceoperationen. |
| SigV4a | aws.auth\$1sigv4a | war. CredentialsProvider | – | Die Verwendung von SigV4a ist derzeit begrenzt, die Signer-Implementierung ist intern. In dieser [Ankündigung](https://github.com/aws/aws-sdk-go-v2/discussions/2812) finden Sie ein neues Opt-In-Modul aws-http-auth, das allgemeine Verwendungszwecke APIs für das Signieren von HTTP-Anfragen aufzeigt. |
| SIGV4Express | com.amazonaws.s3\$1sigv4express | [s3. ExpressCredentialsProvider](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/s3#ExpressCredentialsProvider) | v4. HTTPSigner | Wird für [Express One Zone](https://aws.amazon.com/s3/storage-classes/express-one-zone/) verwendet. |
| HTTP-Träger | smithy.api\$1httpBearerAuth | [Schmiedeträger. TokenProvider](https://pkg.go.dev/github.com/aws/smithy-go/auth/bearer#TokenProvider) | [Smithy Bearer.Signer](https://pkg.go.dev/github.com/aws/smithy-go/auth/bearer#Signer) | [Wird von Codecatalyst verwendet.](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/codecatalyst) |
| Anonym | smithy.api\$1noAuth | – | – | Keine Authentifizierung — Es ist keine Identität erforderlich, und die Anfrage ist nicht signiert oder authentifiziert. |
### Konfiguration der Identität
AWS SDK für Go In werden die Identitätskomponenten eines Authentifizierungsschemas im SDK-Client `Options` konfiguriert. Das SDK nimmt die Werte für diese Komponenten automatisch auf und verwendet sie für das Schema, das es auswählt, wenn eine Operation aufgerufen wird.
**Anmerkung**
Aus Gründen der Abwärtskompatibilität erlaubt das SDK implizit die Verwendung des anonymen Authentifizierungsschemas, wenn keine Identitätsauflösungen konfiguriert sind. Dies kann manuell erreicht werden, indem alle Identitätsauflösungen auf dem Computer eines Clients eingerichtet werden `nil` (der Sigv4-Identitätsauflöser kann auch auf eingestellt werden). `Options` `aws.AnonymousCredentials{}`
### Konfiguration des Unterzeichners
In AWS SDK für Go werden die Unterzeichnerkomponenten eines Authentifizierungsschemas im SDK-Client konfiguriert. `Options` Das SDK nimmt die Werte für diese Komponenten automatisch auf und verwendet sie für das Schema, das es auswählt, wenn eine Operation aufgerufen wird. Es ist keine zusätzliche Konfiguration erforderlich.
#### Benutzerdefiniertes Authentifizierungsschema
Um ein benutzerdefiniertes Authentifizierungsschema zu definieren und es für die Verwendung zu konfigurieren, muss der Aufrufer Folgendes tun:
1. Definieren Sie eine Implementierung [AuthScheme](https://pkg.go.dev/github.com/aws/smithy-go/transport/http#AuthScheme)
1. Registrieren Sie das Schema in der `AuthSchemes` Liste des SDK-Clients
1. Instrumentieren Sie die SDK-Clients`AuthSchemeResolver`, um gegebenenfalls eine Authentifizierung `Option` mit der ID des Schemas zurückzugeben
**Warnung**
Die folgenden Dienste haben ein einzigartiges oder benutzerdefiniertes Authentifizierungsverhalten. Wir empfehlen Ihnen, an die Standardimplementierung zu delegieren und einen entsprechenden Wrapping vorzunehmen, falls Sie ein benutzerdefiniertes Authentifizierungsverhalten benötigen:
| Service | Hinweise |
| --- | --- |
| S3 | Bedingte Verwendung von SigV4a und SigV4Express, abhängig von der Operationseingabe. |
| EventBridge | Bedingte Verwendung von SigV4a, abhängig von der Betriebseingabe. |
| Cognito | Bestimmte Operationen sind nur anonym. |
| SSO | Bestimmte Operationen sind nur anonym. |
| STS | Bestimmte Operationen sind nur anonym. |
# Client-Endpunkte konfigurieren
**Warnung**
Die Auflösung von Endpunkten ist ein SDK-Thema für Fortgeschrittene. Wenn Sie diese Einstellungen ändern, riskieren Sie, dass Ihr Code beschädigt wird. Die Standardeinstellungen sollten für die meisten Benutzer in Produktionsumgebungen gelten.
Das AWS SDK für Go bietet die Möglichkeit, einen benutzerdefinierten Endpunkt zu konfigurieren, der für einen Dienst verwendet werden soll. In den meisten Fällen reicht die Standardkonfiguration aus. Die Konfiguration benutzerdefinierter Endpunkte ermöglicht zusätzliches Verhalten, z. B. die Arbeit mit Vorabversionen eines Dienstes.
## Anpassung
Es gibt zwei „Versionen“ der Konfiguration für die Endpunktauflösung im SDK.
+ v2, veröffentlicht im dritten Quartal 2023, konfiguriert über:
+ `EndpointResolverV2`
+ `BaseEndpoint`
+ v1, zusammen mit dem SDK veröffentlicht, konfiguriert über:
+ `EndpointResolver`
Wir empfehlen Benutzern von Version 1 Endpoint Resolution, auf Version 2 zu migrieren, um Zugriff auf neuere endpunktbezogene Servicefunktionen zu erhalten.
## V2: \$1 `EndpointResolverV2` `BaseEndpoint`
In Auflösung v2 `EndpointResolverV2` ist dies der endgültige Mechanismus, durch den die Endpunktauflösung erfolgt. Die `ResolveEndpoint` Methode des Resolvers wird als Teil des Workflows für jede Anfrage aufgerufen, die Sie im SDK stellen. Der vom Resolver `Endpoint` zurückgegebene Hostname wird **unverändert** verwendet, wenn die Anfrage gestellt wird (Operations-Serializer können jedoch weiterhin an den HTTP-Pfad angehängt werden).
Auflösung v2 beinhaltet eine zusätzliche Konfiguration auf Client-Ebene, die verwendet wird`BaseEndpoint`, um einen „Basis“ -Hostnamen für die Instanz Ihres Dienstes anzugeben. Der hier festgelegte Wert ist nicht definitiv — er wird letztendlich als Parameter an den Client übergeben, `EndpointResolverV2` wenn die endgültige Auflösung erfolgt (weitere Informationen `EndpointResolverV2` zu den Parametern finden Sie weiter). Die Resolver-Implementierung hat dann die Möglichkeit, diesen Wert zu überprüfen und möglicherweise zu ändern, um den endgültigen Endpunkt zu bestimmen.
Wenn Sie beispielsweise eine `GetObject` S3-Anfrage für einen bestimmten Bucket mit einem Client ausführen, für den Sie einen angegeben haben`BaseEndpoint`, fügt der Standard-Resolver den Bucket in den Hostnamen ein, sofern er mit virtuellen Hosts kompatibel ist (vorausgesetzt, Sie haben das virtuelle Hosting nicht in der Client-Konfiguration deaktiviert).
In der Praxis `BaseEndpoint` wird er höchstwahrscheinlich verwendet, um Ihren Kunden auf eine Entwicklungs- oder Vorschauinstanz eines Dienstes hinzuweisen.
### `EndpointResolverV2`-Parameter
Jeder Dienst benötigt einen bestimmten Satz von Eingaben, die an seine Auflösungsfunktion übergeben werden, die in jedem Servicepaket als definiert ist`EndpointParameters`.
Jeder Dienst umfasst die folgenden Basisparameter, die verwendet werden, um die allgemeine Endpunktauflösung innerhalb von Diensten zu erleichtern AWS:
| Name | type | description |
| --- | --- | --- |
| Region | string | Die AWS Region des Kunden |
| Endpoint | string | Der BaseEndpoint in der Client-Konfiguration festgelegte Wert |
| UseFips | bool | Ob FIPS-Endpunkte in der Client-Konfiguration aktiviert sind |
| UseDualStack | bool | Ob Dual-Stack-Endpunkte in der Client-Konfiguration aktiviert sind |
Dienste können zusätzliche Parameter angeben, die für die Auflösung erforderlich sind. Beispielsweise `EndpointParameters` enthalten S3-Dateien den Bucket-Namen sowie mehrere S3-spezifische Funktionseinstellungen, z. B. ob die virtuelle Host-Adressierung aktiviert ist.
Wenn Sie Ihre eigene Instanz implementieren`EndpointResolverV2`, sollten Sie niemals Ihre eigene Instanz von erstellen müssen. `EndpointParameters` Das SDK bezieht die Werte pro Anfrage und leitet sie an Ihre Implementierung weiter.
### Ein Hinweis zu Amazon S3
Amazon S3 ist ein komplexer Service, bei dem viele seiner Funktionen durch komplexe Endpunktanpassungen wie virtuelles Bucket-Hosting, S3 MRAP und mehr modelliert wurden.
Aus diesem Grund empfehlen wir, die `EndpointResolverV2` Implementierung in Ihrem S3-Client nicht zu ersetzen. Wenn Sie das Auflösungsverhalten erweitern müssen, indem Sie beispielsweise Anfragen an einen lokalen Entwicklungsstapel mit zusätzlichen Überlegungen zu Endpunkten senden, empfehlen wir, die Standardimplementierung so zu verpacken, dass sie als Fallback an den Standard zurückdelegiert (siehe Beispiele unten).
### Beispiele
#### Mit `BaseEndpoint`
Der folgende Codeausschnitt zeigt, wie Sie Ihren S3-Client auf eine lokale Instanz eines Dienstes verweisen, der in diesem Beispiel auf dem Loopback-Gerät an Port 8080 gehostet wird.
```
client := s3.NewFromConfig(cfg, func (o *svc.Options) {
o.BaseEndpoint = aws.String("https://localhost:8080/")
})
```
#### Mit `EndpointResolverV2`
Der folgende Codeausschnitt zeigt, wie Sie mithilfe von benutzerdefiniertem Verhalten in die Endpunktauflösung von S3 einfügen. `EndpointResolverV2`
```
import (
"context"
"net/url"
"github.com/aws/aws-sdk-go-v2/service/s3"
smithyendpoints "github.com/aws/smithy-go/endpoints"
)
type resolverV2 struct {
// you could inject additional application context here as well
}
func (*resolverV2) ResolveEndpoint(ctx context.Context, params s3.EndpointParameters) (
smithyendpoints.Endpoint, error,
) {
if /* input params or caller context indicate we must route somewhere */ {
u, err := url.Parse("https://custom.service.endpoint/")
if err != nil {
return smithyendpoints.Endpoint{}, err
}
return smithyendpoints.Endpoint{
URI: *u,
}, nil
}
// delegate back to the default v2 resolver otherwise
return s3.NewDefaultEndpointResolverV2().ResolveEndpoint(ctx, params)
}
func main() {
// load config...
client := s3.NewFromConfig(cfg, func (o *s3.Options) {
o.EndpointResolverV2 = &resolverV2{
// ...
}
})
}
```
#### Mit beiden
Das folgende Beispielprogramm demonstriert die Interaktion zwischen `BaseEndpoint` und`EndpointResolverV2`. **Dies ist ein Anwendungsfall für Fortgeschrittene:**
```
import (
"context"
"fmt"
"log"
"net/url"
"github.com/aws/aws-sdk-go-v2"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/service/s3"
smithyendpoints "github.com/aws/smithy-go/endpoints"
)
type resolverV2 struct {}
func (*resolverV2) ResolveEndpoint(ctx context.Context, params s3.EndpointParameters) (
smithyendpoints.Endpoint, error,
) {
// s3.Options.BaseEndpoint is accessible here:
fmt.Printf("The endpoint provided in config is %s\n", *params.Endpoint)
// fallback to default
return s3.NewDefaultEndpointResolverV2().ResolveEndpoint(ctx, params)
}
func main() {
cfg, err := config.LoadDefaultConfig(context.Background())
if (err != nil) {
log.Fatal(err)
}
client := s3.NewFromConfig(cfg, func (o *s3.Options) {
o.BaseEndpoint = aws.String("https://endpoint.dev/")
o.EndpointResolverV2 = &resolverV2{}
})
// ignore the output, this is just for demonstration
client.ListBuckets(context.Background(), nil)
}
```
Wenn das obige Programm ausgeführt wird, gibt es Folgendes aus:
```
The endpoint provided in config is https://endpoint.dev/
```
## V1: `EndpointResolver`
**Warnung**
Die Endpunktauflösung v1 wird aus Gründen der Abwärtskompatibilität beibehalten und ist vom modernen Verhalten in Endpunktauflösung v2 isoliert. Es wird nur verwendet, wenn das `EndpointResolver` Feld vom Anrufer festgelegt wurde.
Die Verwendung von Version 1 wird Sie höchstwahrscheinlich daran hindern, auf endpunktbezogene Servicefunktionen zuzugreifen, die mit oder nach der Veröffentlichung der v2-Auflösung eingeführt wurden. Anweisungen zum Upgrade finden Sie unter „Migration“.
A [EndpointResolver](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#EndpointResolver)kann so konfiguriert werden, dass es eine benutzerdefinierte Logik zur Endpunktauflösung für Service-Clients bereitstellt. Sie können einen benutzerdefinierten Endpunktresolver verwenden, um die Endpunktauflösungslogik eines Dienstes für alle Endpunkte oder nur für einen bestimmten regionalen Endpunkt zu überschreiben. Ein benutzerdefinierter Endpunktresolver kann die Endpunktauflösungslogik des Dienstes als Fallback auslösen, falls ein benutzerdefinierter Resolver einen angeforderten Endpunkt nicht auflösen möchte. [EndpointResolverWithOptionsFunc](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#EndpointResolverWithOptionsFunc)kann verwendet werden, um Funktionen einfach so zu verpacken, dass sie der Schnittstelle entsprechen. `EndpointResolverWithOptions`
A `EndpointResolver` kann einfach konfiguriert werden, indem der mit einem Wrapped [WithEndpointResolverWithOptions](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/config#WithEndpointResolverWithOptions)an umschlossene Resolver übergeben wird. Dadurch ist es möglich [LoadDefaultConfig](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/config#LoadDefaultConfig), Endpunkte beim Laden von Zugangsdaten zu überschreiben und das Ergebnis `aws.Config` mit Ihrem benutzerdefinierten Endpoint-Resolver zu konfigurieren.
Der Endpunkt-Resolver erhält den Dienst und die Region als Zeichenfolge, sodass der Resolver sein Verhalten dynamisch steuern kann. Jedes Service-Client-Paket hat eine exportierte `ServiceID` Konstante, anhand derer ermittelt werden kann, welcher Service-Client Ihren Endpoint-Resolver aufruft.
Ein Endpoint-Resolver kann den [EndpointNotFoundError](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#EndpointNotFoundError)Sentinel-Fehlerwert verwenden, um eine Fallback-Auflösung auf die Standardauflösungslogik des Service Clients auszulösen. Auf diese Weise können Sie einen oder mehrere Endpunkte nahtlos überschreiben, ohne sich mit der Fallback-Logik befassen zu müssen.
Wenn Ihre Endpoint Resolver-Implementierung einen anderen Fehler als zurückgibt`EndpointNotFoundError`, wird die Endpunktauflösung beendet und der Dienstvorgang gibt einen Fehler an Ihre Anwendung zurück.
### Beispiele
#### Mit Fallback
Der folgende Codeausschnitt zeigt, wie ein einzelner Dienstendpunkt für DynamoDB mit Fallback-Verhalten für andere Endpunkte überschrieben werden kann:
```
customResolver := aws.EndpointResolverWithOptionsFunc(func(service, region string, options ...interface{}) (aws.Endpoint, error) {
if service == dynamodb.ServiceID && region == "us-west-2" {
return aws.Endpoint{
PartitionID: "aws",
URL: "https://test.us-west-2.amazonaws.com",
SigningRegion: "us-west-2",
}, nil
}
// returning EndpointNotFoundError will allow the service to fallback to it's default resolution
return aws.Endpoint{}, &aws.EndpointNotFoundError{}
})
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithEndpointResolverWithOptions(customResolver))
```
#### Ohne Fallback
Der folgende Codeausschnitt zeigt, wie ein einzelner Dienstendpunkt für DynamoDB ohne Fallback-Verhalten für andere Endpunkte außer Kraft gesetzt werden kann:
```
customResolver := aws.EndpointResolverWithOptionsFunc(func(service, region string, options ...interface{}) (aws.Endpoint, error) {
if service == dynamodb.ServiceID && region == "us-west-2" {
return aws.Endpoint{
PartitionID: "aws",
URL: "https://test.us-west-2.amazonaws.com",
SigningRegion: "us-west-2",
}, nil
}
return aws.Endpoint{}, fmt.Errorf("unknown endpoint requested")
})
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithEndpointResolverWithOptions(customResolver))
```
### Unveränderliche Endpunkte
**Warnung**
Das Festlegen eines Endpunkts als unveränderlich kann dazu führen, dass einige Service-Client-Funktionen nicht ordnungsgemäß funktionieren, was zu undefiniertem Verhalten führen kann. Bei der Definition eines Endpunkts als unveränderlich ist Vorsicht geboten.
Einige Service-Clients, wie Amazon S3, können den vom Resolver zurückgegebenen Endpunkt für bestimmte Servicevorgänge ändern. Amazon S3 verarbeitet beispielsweise die [virtuelle Bucket-Adressierung](https://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html) automatisch, indem der aufgelöste Endpunkt mutiert wird. Sie können verhindern, dass das SDK Ihre benutzerdefinierten Endpunkte mutiert, indem Sie auf einstellen. [HostnameImmutable](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#Endpoint.HostnameImmutable)`true` Beispiel:
```
customResolver := aws.EndpointResolverWithOptionsFunc(func(service, region string, options ...interface{}) (aws.Endpoint, error) {
if service == dynamodb.ServiceID && region == "us-west-2" {
return aws.Endpoint{
PartitionID: "aws",
URL: "https://test.us-west-2.amazonaws.com",
SigningRegion: "us-west-2",
HostnameImmutable: true,
}, nil
}
return aws.Endpoint{}, fmt.Errorf("unknown endpoint requested")
})
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithEndpointResolverWithOptions(customResolver))
```
## Migration
Bei der Migration von Version 1 zu Version 2 der Endpunktauflösung gelten die folgenden allgemeinen Prinzipien:
+ Die Rückgabe eines [Endpunkts](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#Endpoint) mit der [HostnameImmutable](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#Endpoint.HostnameImmutable)Einstellung auf `false` entspricht in etwa der Einstellung `BaseEndpoint` auf die ursprünglich von Version 1 zurückgegebene URL und der Beibehaltung `EndpointResolverV2` der Standardeinstellung.
+ Die Rückgabe eines Endpunkts mit HostnameImmutable set to `true` entspricht in etwa der Implementierung eines`EndpointResolverV2`, das die ursprünglich zurückgegebene URL von v1 zurückgibt.
+ Die primäre Ausnahme bilden Operationen mit modellierten Endpunktpräfixen. Ein Hinweis dazu finden Sie weiter unten.
Beispiele für diese Fälle sind unten aufgeführt.
**Warnung**
Unveränderliche V1-Endpunkte und V2-Auflösung sind im Verhalten nicht gleichwertig. Beispielsweise würden Signaturüberschreibungen für benutzerdefinierte Funktionen wie S3 Object Lambda immer noch für unveränderliche Endpunkte festgelegt, die über v1-Code zurückgegeben werden, aber dasselbe gilt nicht für v2.
### Hinweis zu Host-Präfixen
Einige Operationen werden mit Host-Präfixen modelliert, die dem aufgelösten Endpunkt vorangestellt werden. Dieses Verhalten muss zusammen mit der Ausgabe von ResolveEndpoint V2 funktionieren, weshalb das Hostpräfix weiterhin auf dieses Ergebnis angewendet wird.
Sie können das Endpunkt-Host-Präfix manuell deaktivieren, indem Sie eine Middleware anwenden. Weitere Informationen finden Sie im Abschnitt mit den Beispielen.
### Beispiele
#### Veränderbarer Endpunkt
Das folgende Codebeispiel zeigt, wie ein einfacher v1-Endpoint-Resolver migriert wird, der einen modifizierbaren Endpunkt zurückgibt:
```
// v1
client := svc.NewFromConfig(cfg, func (o *svc.Options) {
o.EndpointResolver = svc.EndpointResolverFromURL("https://custom.endpoint.api/")
})
// v2
client := svc.NewFromConfig(cfg, func (o *svc.Options) {
// the value of BaseEndpoint is passed to the default EndpointResolverV2
// implementation, which will handle routing for features such as S3 accelerate,
// MRAP, etc.
o.BaseEndpoint = aws.String("https://custom.endpoint.api/")
})
```
#### Unveränderlicher Endpunkt
```
// v1
client := svc.NewFromConfig(cfg, func (o *svc.Options) {
o.EndpointResolver = svc.EndpointResolverFromURL("https://custom.endpoint.api/", func (e *aws.Endpoint) {
e.HostnameImmutable = true
})
})
// v2
import (
smithyendpoints "github.com/aws/smithy-go/endpoints"
)
type staticResolver struct {}
func (*staticResolver) ResolveEndpoint(ctx context.Context, params svc.EndpointParameters) (
smithyendpoints.Endpoint, error,
) {
// This value will be used as-is when making the request.
u, err := url.Parse("https://custom.endpoint.api/")
if err != nil {
return smithyendpoints.Endpoint{}, err
}
return smithyendpoints.Endpoint{
URI: *u,
}, nil
}
client := svc.NewFromConfig(cfg, func (o *svc.Options) {
o.EndpointResolverV2 = &staticResolver{}
})
```
#### Hostpräfix deaktivieren
```
import (
"context"
"fmt"
"net/url"
"github.com/aws/aws-sdk-go-v2/aws"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/service/"
smithyendpoints "github.com/aws/smithy-go/endpoints"
"github.com/aws/smithy-go/middleware"
smithyhttp "github.com/aws/smithy-go/transport/http"
)
// disableEndpointPrefix applies the flag that will prevent any
// operation-specific host prefix from being applied
type disableEndpointPrefix struct{}
func (disableEndpointPrefix) ID() string { return "disableEndpointPrefix" }
func (disableEndpointPrefix) HandleInitialize(
ctx context.Context, in middleware.InitializeInput, next middleware.InitializeHandler,
) (middleware.InitializeOutput, middleware.Metadata, error) {
ctx = smithyhttp.SetHostnameImmutable(ctx, true)
return next.HandleInitialize(ctx, in)
}
func addDisableEndpointPrefix(o *.Options) {
o.APIOptions = append(o.APIOptions, (func(stack *middleware.Stack) error {
return stack.Initialize.Add(disableEndpointPrefix{}, middleware.After)
}))
}
type staticResolver struct{}
func (staticResolver) ResolveEndpoint(ctx context.Context, params .EndpointParameters) (
smithyendpoints.Endpoint, error,
) {
u, err := url.Parse("https://custom.endpoint.api/")
if err != nil {
return smithyendpoints.Endpoint{}, err
}
return smithyendpoints.Endpoint{URI: *u}, nil
}
func main() {
cfg, err := config.LoadDefaultConfig(context.Background())
if err != nil {
panic(err)
}
svc := .NewFromConfig(cfg, func(o *.Options) {
o.EndpointResolverV2 = staticResolver{}
})
_, err = svc.(context.Background(), &.{ /* ... */ },
addDisableEndpointPrefix)
if err != nil {
panic(err)
}
}
```
# Passen Sie den HTTP-Client an
Der AWS SDK für Go verwendet einen Standard-HTTP-Client mit Standardkonfigurationswerten. Sie können zwar einige dieser Konfigurationswerte ändern, aber der Standard-HTTP-Client und -Transport sind nicht ausreichend für Kunden konfiguriert, die den AWS SDK für Go in einer Umgebung mit hohem Durchsatz und niedrigen Latenzanforderungen verwenden. Weitere Informationen finden Sie im, [Häufig gestellte Fragen](faq-gosdk.md) da die Konfigurationsempfehlungen je nach Arbeitslast variieren. In diesem Abschnitt wird beschrieben, wie Sie einen benutzerdefinierten HTTP-Client konfigurieren und diesen Client zum Erstellen von AWS SDK für Go Aufrufen verwenden.
Um Ihnen bei der Erstellung eines benutzerdefinierten HTTP-Clients zu helfen, wird in diesem Abschnitt beschrieben, wie Sie benutzerdefinierte Einstellungen konfigurieren und diesen Client mit einem AWS SDK für Go Service-Client verwenden. [NewBuildableClient](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/transport/http#NewBuildableClient)
Lassen Sie uns definieren, was wir anpassen möchten.
## Überschreiben beim Laden der Konfiguration
Beim Aufrufen können benutzerdefinierte HTTP-Clients bereitgestellt werden, [LoadDefaultConfig](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/config#LoadDefaultConfig)indem der Client [mit With umschlossen HTTPClient](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/config#WithHTTP) und der resultierende Wert an `LoadDefaultConfig` übergeben wird. Um zum Beispiel `customClient` als unseren Client zu übergeben:
```
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithHTTPClient(customClient))
```
## Zeitüberschreitung
Das `BuildableHTTPClient` kann mit einem Timeout-Limit für Anfragen konfiguriert werden. Dieses Timeout beinhaltet die Zeit, um eine Verbindung herzustellen, etwaige Weiterleitungen zu verarbeiten und den gesamten Antworttext zu lesen. Um beispielsweise das Client-Timeout zu ändern:
```
import "github.com/aws/aws-sdk-go-v2/aws/transport/http"
// ...
httpClient := http.NewBuildableClient().WithTimeout(time.Second*5)
```
## Dialer
Der `BuildableHTTPClient` bietet eine Builder-Mechanik zum Erstellen von Clients mit modifizierten [Dialer-Optionen](https://golang.org/pkg/net/#Dialer). Das folgende Beispiel zeigt, wie die Einstellungen eines Clients `Dialer` konfiguriert werden.
```
import awshttp "github.com/aws/aws-sdk-go-v2/aws/transport/http"
import "net"
// ...
httpClient := awshttp.NewBuildableClient().WithDialerOptions(func(d *net.Dialer) {
d.KeepAlive = -1
d.Timeout = time.Millisecond*500
})
```
### Einstellungen
#### Dialer. KeepAlive
Diese Einstellung stellt den Keep-Alive-Zeitraum für eine aktive Netzwerkverbindung dar.
Auf einen negativen Wert setzen, um Keep-Alives zu deaktivieren.
Auf **0** setzen, um Keep-Alives zu aktivieren, sofern sie vom Protokoll und vom Betriebssystem unterstützt werden.
Netzwerkprotokolle oder Betriebssysteme, die Keep-Alives nicht unterstützen, ignorieren dieses Feld. Standardmäßig aktiviert TCP Keep Alive.
Weitere Informationen finden Sie [unter https://golang. org/pkg/net/\$1Dialer. KeepAlive](https://golang.org/pkg/net/#Dialer.KeepAlive)
`KeepAlive`Als **Time.Duration** festlegen.
#### Dialer.Timeout
Diese Einstellung gibt an, wie lange ein Dial maximal darauf wartet, dass eine Verbindung hergestellt wird.
Die Standardeinstellung ist 30 Sekunden.
Weitere Informationen finden Sie [unter https://golang. org/pkg/net/\$1Dialer .Timeout](https://golang.org/pkg/net/#Dialer.Timeout)
`Timeout`**Als Time.Duration festlegen.**
## Transport
[Das `BuildableHTTPClient` bietet eine Builder-Mechanik zum Erstellen von Clients mit modifizierten Transportoptionen.](https://golang.org/pkg/net/http#Transport)
### Einen Proxy konfigurieren
Wenn Sie keine direkte Verbindung zum Internet herstellen können, können Sie von GO unterstützte Umgebungsvariablen (`HTTP_PROXY`/`HTTPS_PROXY`) verwenden oder einen benutzerdefinierten HTTP-Client erstellen, um Ihren Proxy zu konfigurieren. Im folgenden Beispiel wird der Client so konfiguriert, dass er `PROXY_URL` als Proxy-Endpunkt verwendet wird:
```
import awshttp "github.com/aws/aws-sdk-go-v2/aws/transport/http"
import "net/http"
// ...
httpClient := awshttp.NewBuildableClient().WithTransportOptions(func(tr *http.Transport) {
proxyURL, err := url.Parse("PROXY_URL")
if err != nil {
log.Fatal(err)
}
tr.Proxy = http.ProxyURL(proxyURL)
})
```
### Andere Einstellungen
Im Folgenden finden Sie einige andere `Transport` Einstellungen, die geändert werden können, um den HTTP-Client zu optimieren. Alle zusätzlichen Einstellungen, die hier nicht beschrieben werden, finden Sie in der Dokumentation zum [Transporttyp](https://golang.org/pkg/net/http/#Transport). Diese Einstellungen können wie im folgenden Beispiel gezeigt angewendet werden:
```
import awshttp "github.com/aws/aws-sdk-go-v2/aws/transport/http"
import "net/http"
// ...
httpClient := awshttp.NewBuildableClient().WithTransportOptions(func(tr *http.Transport) {
tr.ExpectContinueTimeout = 0
tr.MaxIdleConns = 10
})
```
#### Verkehr. ExpectContinueTimeout
Wenn die Anfrage einen „Expect: 100-continue“ -Header hat, stellt diese Einstellung die maximale Wartezeit auf die ersten Antwortheader eines Servers dar, nachdem die Anforderungsheader vollständig geschrieben wurden. Diese Zeit beinhaltet nicht die Zeit zum Senden des Anforderungsheaders. Der HTTP-Client sendet seine Nutzdaten, nachdem dieser Timeout abgelaufen ist.
Standard 1 Sekunde.
Setzen Sie den Wert auf **0**, um kein Timeout zu vermeiden, und senden Sie die Payload der Anfrage ohne Wartezeit. Ein Anwendungsfall ist, wenn Sie auf Probleme mit Proxys oder Drittanbieterdiensten stoßen, die eine Sitzung durchführen, die der Verwendung von Amazon S3 in der später gezeigten Funktion ähnelt.
[Weitere Informationen finden Sie unter https://golang. org/pkg/net/http/\$1Transport. ExpectContinueTimeout](https://golang.org/pkg/net/http/#Transport.ExpectContinueTimeout)
`ExpectContinue`Als **Time.Duration** festlegen.
#### Verkehr. IdleConnTimeout
Diese Einstellung stellt die maximale Zeit dar, um eine inaktive Netzwerkverbindung zwischen HTTP-Anfragen aufrechtzuerhalten.
Auf **0 gesetzt, wenn** kein Limit angegeben wird.
Weitere Informationen finden Sie [unter https://golang. org/pkg/net/http/\$1Transport. IdleConnTimeout](https://golang.org/pkg/net/http/#Transport.IdleConnTimeout)
`IdleConnTimeout`Als **Time.Duration** festlegen.
#### Verkehr. MaxIdleConns
Diese Einstellung stellt die maximale Anzahl inaktiver Verbindungen (Keep-Alive) auf allen Hosts dar. Ein Anwendungsfall für die Erhöhung dieses Werts ist, wenn Sie in kurzer Zeit viele Verbindungen von denselben Clients sehen
**0** bedeutet kein Limit.
Weitere Informationen finden Sie [unter https://golang. org/pkg/net/http/\$1Transport. MaxIdleConns](https://golang.org/pkg/net/http/#Transport.MaxIdleConns)
`MaxIdleConns`Als **int** setzen.
#### Verkehr. MaxIdleConnsPerHost
Diese Einstellung stellt die maximale Anzahl inaktiver Verbindungen (Keep-Alive) dar, die pro Host beibehalten werden können. Ein Anwendungsfall für die Erhöhung dieses Werts ist, wenn Sie innerhalb eines kurzen Zeitraums viele Verbindungen von denselben Clients sehen
Die Standardeinstellung sind zwei inaktive Verbindungen pro Host.
Auf **0** setzen, um DefaultMaxIdleConnsPerHost (2) zu verwenden.
Weitere Informationen finden Sie [unter https://golang. org/pkg/net/http/\$1Transport. MaxIdleConnsPerHost](https://golang.org/pkg/net/http/#Transport.MaxIdleConnsPerHost)
`MaxIdleConnsPerHost`Als **int** setzen.
#### Verkehr. ResponseHeaderTimeout
Diese Einstellung stellt die maximale Wartezeit dar, bis ein Client den Antwortheader gelesen hat.
Wenn der Client den Header der Antwort innerhalb dieser Dauer nicht lesen kann, schlägt die Anforderung mit einem Timeout-Fehler fehl.
Seien Sie vorsichtig bei der Einstellung dieses Werts, wenn Sie Lambda-Funktionen mit langer Laufzeit verwenden, da der Vorgang keine Antwortheader zurückgibt, bis die Lambda-Funktion abgeschlossen ist oder das Timeout abgelaufen ist. Sie können diese Option jedoch weiterhin mit der API-Operation \$1\$1 \$1\$1 verwenden. InvokeAsync
Die Standardeinstellung ist kein Timeout. Warte ewig.
Weitere Informationen finden Sie unter [https://golang. org/pkg/net/http/\$1Transport. ResponseHeaderTimeout](https://golang.org/pkg/net/http/#Transport.ResponseHeaderTimeout)
`ResponseHeaderTimeout`Als **Time.Duration** festlegen.
#### Verkehr. TLSHandshakeAuszeit
Diese Einstellung stellt die maximale Wartezeit bis zum Abschluss eines TLS-Handshakes dar.
Der Standardwert beträgt 10 Sekunden.
Null bedeutet kein Timeout.
Weitere Informationen finden Sie unter [https://golang. org/pkg/net/http/\$1Transport. TLSHandshakeAuszeit](https://golang.org/pkg/net/http/#Transport.TLSHandshakeTimeout)
`TLSHandshakeTimeout`Als **Time.Duration** festlegen.
# HTTP-Interzeptoren
Sie können Interzeptoren verwenden, um sich in die Ausführung von API-Anfragen und -Antworten einzuklinken. Interzeptoren sind offene Mechanismen, bei denen das SDK Code aufruft, den Sie schreiben, um Verhalten in den Lebenszyklus einzufügen. request/response Auf diese Weise können Sie eine In-Flight-Anfrage ändern, die Anforderungsverarbeitung debuggen, Ausnahmen anzeigen und vieles mehr.
## Interzeptoren im Vergleich zu Middleware
Die AWS SDK für Go Version 2 bietet sowohl Interzeptoren als auch Middleware zur Anpassung der Anforderungsverarbeitung. Beide dienen zwar ähnlichen Zwecken, sind jedoch für unterschiedliche Zielgruppen und Anwendungsfälle konzipiert:
+ **Interceptors** wurden für SDK-Benutzer entwickelt, die die request/response Verarbeitung mit einer einfachen, HTTP-orientierten API anpassen möchten. Sie bieten spezifische Anknüpfungspunkte im Anforderungslebenszyklus und arbeiten direkt mit HTTP-Anfragen und -Antworten.
+ **Middleware** ist ein fortschrittlicheres, transportunabhängiges System, das hauptsächlich intern vom SDK verwendet wird. Middleware ist zwar leistungsstark, erfordert jedoch tiefere Kenntnisse der internen Funktionen des SDK und beinhaltet komplexere Schnittstellen.
Hauptvorteile von Interceptoren gegenüber Middleware für allgemeine Anwendungsfälle:
+ **HTTP-orientiert**: Interceptoren arbeiten direkt mit HTTP-Anfragen und -Antworten, wodurch die für Middleware erforderliche Überprüfung des Transporttyps entfällt.
+ **Einfachere Schnittstellen**: Jeder Interceptor-Hook hat eine spezifische, fokussierte Schnittstelle und nicht das generische Middleware-Muster.
+ **Klareres Ausführungsmodell**: Interceptoren werden an genau definierten Punkten im Anforderungszyklus ausgeführt, ohne dass Kenntnisse über die Reihenfolge der Middleware-Stacks erforderlich sind.
**Anmerkung**
Interceptors bauen auf dem vorhandenen Middleware-System auf, sodass beide in derselben Anwendung koexistieren können. Middleware ist weiterhin für fortgeschrittene Anwendungsfälle verfügbar, die transportunabhängiges Verhalten oder komplexe Stack-Manipulation erfordern.
## Verfügbare Interceptor-Hooks
Die AWS SDK für Go Version 2 bietet Interceptor-Hooks in verschiedenen Phasen des Anforderungslebenszyklus. Jeder Hook entspricht einer bestimmten Schnittstelle, die Sie implementieren können:
+ `BeforeExecution`- Erster Hook, der während der Ausführung des Vorgangs aufgerufen wird
+ `BeforeSerialization`— Bevor die Eingabenachricht in eine Transportanforderung serialisiert wird
+ `AfterSerialization`- Nachdem die Eingabenachricht in die Transportanfrage serialisiert wurde
+ `BeforeRetryLoop`- Vor dem Eintritt in die Wiederholungsschleife
+ `BeforeAttempt`- Erster Hook, der innerhalb der Wiederholungsschleife aufgerufen wird
+ `BeforeSigning`- Bevor die Transportanfrage signiert wird
+ `AfterSigning`- Nachdem die Transportanfrage unterschrieben wurde
+ `BeforeTransmit`- Bevor die Transportanfrage gesendet wird
+ `AfterTransmit`- Nach Erhalt der Transportantwort
+ `BeforeDeserialization`- Bevor die Transportantwort deserialisiert wird
+ `AfterDeserialization`- Nach dem Demarshalling der Transportreaktion
+ `AfterAttempt`- Letzter Hook, der innerhalb der Wiederholungsschleife aufgerufen wurde
+ `AfterExecution`- Letzter Hook, der während der Ausführung der Operation aufgerufen wurde
Sie können mehrere Schnittstellen in einem einzigen Interceptor implementieren, um sich in mehrere Phasen des Anforderungslebenszyklus einzuklinken.
## Registrierung des Interceptors
Sie registrieren Interzeptoren, wenn Sie einen Service-Client erstellen oder wenn Sie die Konfiguration für einen bestimmten Vorgang überschreiben. Die Registrierung unterscheidet sich je nachdem, ob Sie möchten, dass der Interceptor für alle Operationen Ihres Clients oder nur für bestimmte Operationen gilt.
Interzeptoren werden über eine Interceptor-Registry verwaltet, die Methoden zum Hinzufügen und Entfernen von Interzeptoren bereitstellt. Das folgende Beispiel zeigt einen einfachen Interceptor, der ausgehenden Anfragen vor dem Signiervorgang einen AWS X-Ray Trace-ID-Header hinzufügt:
```
type recursionDetection struct{}
func (recursionDetection) BeforeSigning(ctx context.Context, in *smithyhttp.InterceptorContext) error {
if traceID := os.Getenv("_X_AMZN_TRACE_ID"); traceID != "" {
in.Request.Header.Set("X-Amzn-Trace-Id", traceID)
}
return nil
}
// use it on the client
svc := s3.NewFromConfig(cfg, func(o *s3.Options) {
o.Interceptors.AddBeforeSigning(recursionDetection{})
})
```
Die Interceptor-Registry wird zu den Client-Optionen hinzugefügt, wodurch die Interceptor-Konfiguration pro Vorgang ermöglicht wird:
```
// ... or use it per-operation
s3.ListBuckets(context.Background(), &s3.ListBucketsInput{
}, func(o *s3.Options) {
o.Interceptors.AddBeforeSigning(recursionDetection{})
})
```
## Globale Interceptor-Konfiguration
Sie können Interzeptoren auch global registrieren, indem Sie die `config.LoadDefaultConfig` Funktion mit den entsprechenden `With*` Optionen für jeden Interzeptortyp verwenden. Dadurch wird der Interceptor auf alle AWS Service-Clients angewendet, die mit dieser Konfiguration erstellt wurden:
```
type myExecutionInterceptor struct{}
func (*myExecutionInterceptor) AfterExecution(ctx context.Context, in *smithyhttp.InterceptorContext) error {
// Add your custom logic here
return nil
}
cfg, err := config.LoadDefaultConfig(context.Background(),
config.WithAfterExecution(&myExecutionInterceptor{}))
if err != nil {
panic(err)
}
// every service client created from the above config
// will include this interceptor
svc := s3.NewFromConfig(cfg)
```
# Protokollierung
Der AWS SDK für Go verfügt über Protokollierungsfunktionen, mit denen Ihre Anwendung Debugging-Informationen zum Debuggen und Diagnostizieren von Anforderungsproblemen oder -fehlern aktivieren kann. Die [Logger-Schnittstelle](https://pkg.go.dev/github.com/aws/smithy-go/logging#Logger) und [ClientLogMode](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#ClientLogMode)sind die wichtigsten Komponenten, mit denen Sie festlegen können, wie und was von Clients protokolliert werden soll.
## Logger
Beim Erstellen einer [Config](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#Config) `Logger` wird standardmäßig so konfiguriert, dass Protokollnachrichten an den Standardfehler des Prozesses (stderr) gesendet werden. [LoadDefaultConfig](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/config#LoadDefaultConfig) [Ein benutzerdefinierter Logger, der die [Logger-Schnittstelle](https://pkg.go.dev/github.com/aws/smithy-go/logging#Logger) erfüllt, kann als Argument übergeben werden, `LoadDefaultConfig` indem er mit der Konfiguration umschlossen wird. WithLogger](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/config#WithLogger).
Zum Beispiel, um unsere Kunden so zu konfigurieren, dass sie unsere verwenden`applicationLogger`:
```
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithLogger(applicationLogger))
```
Jetzt senden Clients, die mit dem `aws.Config` Constructed konfiguriert wurden, Protokollnachrichten an`applicationLogger`.
### Kontextsensitive Logger
Eine Logger-Implementierung kann die optionale Schnittstelle implementieren. [ContextLogger](https://pkg.go.dev/github.com/aws/smithy-go/logging#ContextLogger) Bei Loggern, die diese Schnittstelle implementieren, werden ihre `WithContext` Methoden im aktuellen Kontext aufgerufen. Auf diese Weise können Ihre Protokollierungsimplementierungen eine neue Datei zurückgeben`Logger`, die zusätzliche Logging-Metadaten auf der Grundlage der im Kontext vorhandenen Werte schreiben kann.
## ClientLogMode
Standardmäßig erzeugen Service-Clients keine Protokollnachrichten. Um Clients so zu konfigurieren, dass sie Protokollnachrichten zu Debugging-Zwecken senden, verwenden Sie das [ClientLogMode](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#ClientLogMode)Mitglied on`Config`. `ClientLogMode`kann so eingestellt werden, dass Debugging-Messaging aktiviert wird für:
+ Signatur Version 4 (Sigv4) Signierung
+ Wiederholungen anfordern
+ HTTP-Anforderungen
+ HTTP-Antworten
Um beispielsweise die Protokollierung von HTTP-Anfragen und -Wiederholungen zu aktivieren:
```
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithClientLogMode(aws.LogRetries | aws.LogRequest))
```
Informationen zu [ClientLogMode](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#ClientLogMode)den verschiedenen verfügbaren Client-Protokollmodi finden Sie unter.
# Spuren und Metriken
Das AWS SDK für Go ist so konzipiert, dass es Trace-Spans und clientseitige Metriken für SDK-Operationen aufzeichnet. Standardmäßig verwenden Clients No-Op-Implementierungen sowohl für die Ablaufverfolgung als auch für die Metriken, was bedeutet, dass keine Daten gesammelt werden, es sei denn, Sie konfigurieren einen Anbieter.
Service-Clients haben zwei Konfigurationsoptionen für die Beobachtbarkeit:
+ [TracerProvider](https://pkg.go.dev/github.com/aws/smithy-go/tracing#TracerProvider)— Einstiegspunkt für die Erstellung von Tracern und die Aufzeichnung von Client-Trace-Spans.
+ [MeterProvider](https://pkg.go.dev/github.com/aws/smithy-go/metrics#MeterProvider)— Einstiegspunkt für die Erstellung von Zählern und die Aufzeichnung von kundenseitigen Metriken.
Diese APIs sind zwar von den Spezifikationen OpenTelemetry (OTel) inspiriert, werden aber unabhängig voneinander in definiert. `smithy-go` Das SDK bietet Adaptermodule, um konkrete OTel SDK-Implementierungen mit den Provider-Schnittstellen des SDK zu verbinden.
## Nachverfolgung
Verwenden Sie das [Smithyoteltracing-Adaptermodul](https://pkg.go.dev/github.com/aws/smithy-go/tracing/smithyoteltracing), um eine Verbindung zu einem Service-Client herzustellen. OTel `trace.TracerProvider`
Das folgende Beispiel zeigt, wie die Ablaufverfolgung für einen Amazon S3 S3-Client konfiguriert wird:
```
import (
"github.com/aws/aws-sdk-go-v2/service/s3"
"github.com/aws/smithy-go/tracing/smithyoteltracing"
"go.opentelemetry.io/otel/trace"
)
// provider is an OTel trace.TracerProvider that you have configured.
var provider trace.TracerProvider
svc := s3.NewFromConfig(cfg, func(o *s3.Options) {
o.TracerProvider = smithyoteltracing.Adapt(provider)
})
```
SDK-Operationen sind mit einer übergeordneten Hierarchie ausgestattet, die die wichtigsten Komponenten des Vorgangslebenszyklus abdeckt, wie z. B. die Serialisierung von Anfragen, das Signieren und die Wiederholungsschleife.
## Kennzahlen
Verwenden Sie das [Smithyotelmetrics-Adaptermodul](https://pkg.go.dev/github.com/aws/smithy-go/metrics/smithyotelmetrics), um eine Verbindung zu einem Service-Client herzustellen. OTel `metric.MeterProvider`
Das folgende Beispiel zeigt, wie Metriken für einen Amazon S3 S3-Client konfiguriert werden:
```
import (
"github.com/aws/aws-sdk-go-v2/service/s3"
"github.com/aws/smithy-go/metrics/smithyotelmetrics"
"go.opentelemetry.io/otel/metric"
)
// provider is an OTel metric.MeterProvider that you have configured.
var provider metric.MeterProvider
svc := s3.NewFromConfig(cfg, func(o *s3.Options) {
o.MeterProvider = smithyotelmetrics.Adapt(provider)
})
```
### Unterstützte Metriken
SDK-Clients sammeln die folgenden Metriken:
| Metrikname | Einheit | Typ | Description |
| --- | --- | --- | --- |
| client.call.duration | S | Histogramm | Gesamtdauer des Anrufs, einschließlich Wiederholungsversuche und Zeit zum Senden oder Empfangen von Anfrage und Antworttext. |
| client.call.attempts | \$1Versuch\$1 | MonotonicCounter | Die Anzahl der Versuche für einen einzelnen Vorgang. |
| client.call.errors | \$1Fehler\$1 | MonotonicCounter | Die Anzahl der Fehler bei einem Vorgang. |
| client.call.attempt\$1duration | S | Histogramm | Die Zeit, um eine Verbindung mit dem Dienst herzustellen, die Anfrage zu senden und den HTTP-Statuscode und die Header (einschließlich der Wartezeit in der Warteschlange auf das Senden) zurückzuholen. |
| client.call.resolve\$1endpoint\$1duration | S | Histogramm | Die Zeit, bis ein Endpunkt (Endpunktresolver, nicht DNS) für die Anfrage aufgelöst werden muss. |
| client.call.deserialization\$1duration | S | Histogramm | Die Zeit, um einen Nachrichtentext zu deserialisieren. |
| client.call.auth.signing\$1duration | S | Histogramm | Die Zeit, um eine Anfrage zu signieren. |
| client.call.auth.resolve\$1identity\$1duration | S | Histogramm | Die Zeit, um eine Identität (AWS Anmeldeinformationen, Inhaber-Token usw.) von einem Identitätsanbieter zu erwerben. |
Die folgenden Attribute (Dimensionen) sind gegebenenfalls in jeder Metrik enthalten:
+ `rpc.service`— Der Dienstname.
+ `rpc.method`— Der Name der Operation.
+ `exception.type`— Der Fehlertyp (enthalten in`client.call.errors`).
+ `auth.scheme_id`— Das Authentifizierungsschema (in authentifizierungsbezogenen Metriken enthalten).
### HTTP-Client-Metriken
Der HTTP-Client des SDK sammelt die folgenden zusätzlichen Metriken, die sich auf den zugrunde liegenden HTTP-Verbindungslebenszyklus beziehen:
| Metrikname | Einheit | Typ | Description |
| --- | --- | --- | --- |
| client.http.connections.acquire\$1duration | S | Histogramm | Die Zeit, die eine Anfrage benötigt, um eine Verbindung herzustellen. |
| client.http.connections.dns\$1lookup\$1duration | S | Histogramm | Die Zeit, die für die Durchführung einer DNS-Suche benötigt wird. |
| client.http.connections.tls\$1handshake\$1duration | S | Histogramm | Die Zeit, die für die Durchführung eines TLS-Handshakes benötigt wird. |
| client.http.connections.usage | \$1Verbindung\$1 | UpDownCounter | Der aktuelle Status der Verbindungen im Pool. Verwendet eine state Dimension mit dem Wert idle oderacquired. |
| client.http.do\$1request\$1duration | S | Histogramm | Die Gesamtzeit, die für die Ausführung der HTTP-Anfrage aufgewendet wurde. |
| client.http.time\$1to\$1first\$1byte | S | Histogramm | Die Zeit vom Senden der Anfrage bis zum Empfang des ersten Antwortbytes. |
# Wiederholversuche und Zeitüberschreitungen
AWS SDK für Go Damit können Sie das Wiederholungsverhalten von Anfragen an HTTP-Dienste konfigurieren. Standardmäßig verwenden Service-Clients [Retry.STANDARD als Standard-Wiederholungsversuch](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry#Standard). Wenn die Standardkonfiguration oder das Standardverhalten nicht Ihren Anwendungsanforderungen entspricht, können Sie die Retryer-Konfiguration anpassen oder Ihre eigene Retryer-Implementierung bereitstellen.
Das AWS SDK für Go stellt eine [AWS.Retryer-Schnittstelle](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#Retryer) bereit, die den Methodensatz definiert, der für die Implementierung einer Retry-Implementierung erforderlich ist. [Das SDK bietet zwei Implementierungen für Wiederholungen: retry.STANDARD und aws.](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry#Standard) [ NoOpRetryer](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#NoOpRetryer).
## Standardtrockner
Der [Retry.Standard Retryer](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry#Standard) ist die Standardimplementierung, die von SDK-Clients verwendet wird. `aws.Retryer` Der Standard-Retryer ist ein Retryer mit begrenzter Geschwindigkeit, einer konfigurierbaren Anzahl von Maximalversuchen und der Möglichkeit, die Rücknahme von Anfragen zu deaktivieren.
In der folgenden Tabelle sind die Standardwerte für diesen Wiederholungsversuch definiert:
| Eigenschaft | Standard |
| --- | --- |
| Max. Anzahl der Versuche | 3 |
| Maximale Back-Off-Verzögerung | 20 Sekunden |
Wenn beim Aufrufen Ihrer Anfrage ein Fehler auftritt, der wiederholt werden kann, verwendet der Standard-Wiederholungsversuch die bereitgestellte Konfiguration, um die Anfrage zu verzögern und anschließend erneut zu versuchen. Wiederholungen erhöhen die Gesamtlatenz Ihrer Anfrage, und Sie müssen den Wiederholungsversuch konfigurieren, falls die Standardkonfiguration nicht Ihren Anwendungsanforderungen entspricht.
In der Dokumentation zum [Retry-Paket](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry) finden Sie Einzelheiten dazu, welche Fehler bei der Standardimplementierung von Retryern als wiederholbar angesehen werden.
## NopRetryer
[Das war. NopRetryer](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws#NopRetryer)ist eine `aws.Retryer` Implementierung, die bereitgestellt wird, wenn Sie alle Wiederholungsversuche deaktivieren möchten. Beim Aufrufen eines Service-Client-Vorgangs erlaubt dieser Wiederholungsversuch nur, dass die Anfrage einmal versucht wird, und alle daraus resultierenden Fehler werden an die aufrufende Anwendung zurückgegeben.
## Verhalten anpassen
Das SDK stellt eine Reihe von Hilfsprogrammen bereit, die eine `aws.Retryer` Implementierung umschließen, und gibt den bereitgestellten Wiederholungsversuch mit dem gewünschten Wiederholungsverhalten zurück. Sie können den Standard-Retryer für alle Clients, pro Client oder pro Vorgang überschreiben, je nach den Anforderungen Ihrer Anwendung. Weitere Beispiele zur Vorgehensweise finden Sie in den Dokumentationsbeispielen zum [Retry-Paket](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry).
**Warnung**
Wenn Sie eine globale `aws.Retryer` Implementierung mit angeben`config.WithRetryer`, müssen Sie sicherstellen, dass Sie für `aws.Retryer` jeden Aufruf eine neue Instanz zurückgeben. Dadurch wird sichergestellt, dass Sie nicht für alle Service-Clients einen globalen Token-Bucket für Wiederholungsversuche erstellen.
### Begrenzung der maximalen Anzahl von Versuchen
Sie verwenden [Wiederholungsversuch. AddWithMaxAttempts](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry#AddWithMaxAttempts)um eine `aws.Retryer` Implementierung zu beenden und die maximale Anzahl der Versuche auf den gewünschten Wert zu setzen.
**Warnung**
Wenn Sie `retry.AddWithMaxAttempts` den Wert Null angeben, kann das SDK alle wiederholbaren Fehler erneut versuchen, bis die Anfrage erfolgreich ist oder ein Fehler zurückgegeben wird, der nicht erneut versucht werden kann. **Wenn Sie dem SDK erlauben, es unendlich oft zu wiederholen, kann dies zu unkontrollierten Arbeitslasten und überhöhten Abrechnungszyklen führen.**
```
import "context"
import "github.com/aws/aws-sdk-go-v2/aws/retry"
import "github.com/aws/aws-sdk-go-v2/config"
import "github.com/aws/aws-sdk-go-v2/service/s3"
// ...
// MaxAttempts will be infinite (will retry indefinitely)
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRetryer(func() aws.Retryer {
return retry.AddWithMaxAttempts(retry.NewStandard(), 0)
}))
if err != nil {
return err
}
client := s3.NewFromConfig(cfg)
```
Beachten Sie, dass die Instanziierung eines Wiederholungsversuchs mithilfe von Funktionsoptionen, die direkt festgelegt werden, ein leicht anderes Verhalten haben wird. MaxAttempts Genauer gesagt führt das Setzen eines Werts kleiner oder gleich Null dazu, dass der Wiederholungsversuch das standardmäßige Maximum von 3 Versuchen verwendet, anstatt es unendlich zu wiederholen:
```
import "context"
import "github.com/aws/aws-sdk-go-v2/aws/retry"
import "github.com/aws/aws-sdk-go-v2/config"
import "github.com/aws/aws-sdk-go-v2/service/s3"
// ...
// MaxAttempts will default to 3
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRetryer(func() aws.Retryer {
return retry.NewStandard(func(o *retry.StandardOptions) {
o.MaxAttempts = 0
})
}))
if err != nil {
return err
}
client := s3.NewFromConfig(cfg)
```
### Begrenzung der maximalen Back-Off-Verzögerung
Sie verwenden [Retry. AddWithMaxBackoffDelay](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry#AddWithMaxBackoffDelay)um eine `aws.Retryer` Implementierung abzuschließen und die maximale Back-Off-Verzögerung zu begrenzen, die zwischen erneuten Versuchen einer fehlgeschlagenen Anfrage auftreten kann.
Sie können beispielsweise den folgenden Code verwenden, um den standardmäßigen Client-Wiederholungsversuch mit einer gewünschten maximalen Verzögerung von fünf Sekunden zu beenden:
```
import "context"
import "time"
import "github.com/aws/aws-sdk-go-v2/aws/retry"
import "github.com/aws/aws-sdk-go-v2/config"
import "github.com/aws/aws-sdk-go-v2/service/s3"
// ...
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRetryer(func() aws.Retryer {
return retry.AddWithMaxBackoffDelay(retry.NewStandard(), time.Second*5)
}))
if err != nil {
return err
}
client := s3.NewFromConfig(cfg)
```
### Versuchen Sie es erneut mit weiteren API-Fehlercodes
Sie verwenden [Retry. AddWithErrorCodes](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry#AddWithErrorCodes)um eine `aws.Retryer` Implementierung zu verpacken und zusätzliche API-Fehlercodes einzufügen, die als wiederholbar erachtet werden sollten.
Sie können beispielsweise den folgenden Code verwenden, um den Standard-Client-Wiederholungsversuch so zu umschließen, dass die Amazon S3 `NoSuchBucketException` S3-Ausnahme als wiederholbar gilt.
```
import "context"
import "time"
import "github.com/aws/aws-sdk-go-v2/aws/retry"
import "github.com/aws/aws-sdk-go-v2/config"
import "github.com/aws/aws-sdk-go-v2/service/s3"
import "github.com/aws/aws-sdk-go-v2/service/s3/types"
// ...
cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRetryer(func() aws.Retryer {
return retry.AddWithErrorCodes(retry.NewStandard(), (*types.NoSuchBucketException)(nil).ErrorCode())
}))
if err != nil {
return err
}
client := s3.NewFromConfig(cfg)
```
### Clientseitige Ratenbegrenzung
Damit AWS SDK für Go wird ein neuer Mechanismus zur kundenseitigen Ratenbegrenzung in die Standardrichtlinie für Wiederholungsversuche aufgenommen, der dem heutigen Verhalten entspricht. SDKs [Dieses Verhalten wird durch das [RateLimiter](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry#RateLimiter)Feld in den Optionen eines Wiederholungsversuchs gesteuert.](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/retry#StandardOptions)
A RateLimiter arbeitet als Token-Bucket mit einer festgelegten Kapazität, in dem fehlgeschlagene Betriebsversuche Tokens verbrauchen. Ein erneuter Versuch, mehr Token zu verbrauchen, als verfügbar sind, führt zu einem Betriebsfehler mit einer [QuotaExceededError](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/ratelimit#QuotaExceededError).
Die Standardimplementierung ist wie folgt parametrisiert (wie man die einzelnen Einstellungen ändert):
+ eine Kapazität von 500 (stellen Sie den Wert RateLimiter on StandardOptions using ein) [NewTokenRateLimit](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/ratelimit#NewTokenRateLimit)
+ Ein durch einen Timeout verursachter Wiederholungsversuch kostet 10 Token (aktiviert) RetryTimeoutCost StandardOptions
+ Ein durch andere Fehler verursachter Wiederholungsversuch kostet 5 Token (aktiviert) RetryCost StandardOptions
+ Ein Vorgang, der beim ersten Versuch erfolgreich ist, fügt 1 Token hinzu (aktiviert) NoRetryIncrement StandardOptions
+ Operationen, die beim zweiten oder späteren Versuch erfolgreich sind, fügen keine Tokens zurück
Wenn Sie feststellen, dass das Standardverhalten nicht den Anforderungen Ihrer Anwendung entspricht, können Sie es mit [RateLimit.NONE](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/aws/ratelimit#pkg-variables) deaktivieren.
#### Beispiel: modifizierter Ratenbegrenzer
```
import (
"context"
"github.com/aws/aws-sdk-go-v2/aws"
"github.com/aws/aws-sdk-go-v2/aws/ratelimit"
"github.com/aws/aws-sdk-go-v2/aws/retry"
"github.com/aws/aws-sdk-go-v2/config"
)
// ...
cfg, err := config.LoadDefaultConfig(context.Background(), config.WithRetryer(func() aws.Retryer {
return retry.NewStandard(func(o *retry.StandardOptions) {
// Makes the rate limiter more permissive in general. These values are
// arbitrary for demonstration and may not suit your specific
// application's needs.
o.RateLimiter = ratelimit.NewTokenRateLimit(1000)
o.RetryCost = 1
o.RetryTimeoutCost = 3
o.NoRetryIncrement = 10
})
}))
```
#### Beispiel: Keine Ratenbegrenzung mit RateLimit.None
```
import (
"context"
"github.com/aws/aws-sdk-go-v2/aws"
"github.com/aws/aws-sdk-go-v2/aws/ratelimit"
"github.com/aws/aws-sdk-go-v2/aws/retry"
"github.com/aws/aws-sdk-go-v2/config"
)
// ...
cfg, err := config.LoadDefaultConfig(context.Background(), config.WithRetryer(func() aws.Retryer {
return retry.NewStandard(func(o *retry.StandardOptions) {
o.RateLimiter = ratelimit.None
})
}))
```
## Timeouts
Sie verwenden das [Kontextpaket](https://golang.org/pkg/context/), um beim Aufrufen eines Service-Client-Vorgangs Timeouts oder Deadlines festzulegen. [Verwenden Sie den Kontext. WithDeadline](https://golang.org/pkg/context/#WithDeadline)um den Kontext Ihrer Anwendungen zu verschließen und eine Frist bis zu einem bestimmten Zeitpunkt festzulegen, bis zu dem der aufgerufene Vorgang abgeschlossen sein muss. [Um ein Timeout nach einem bestimmten `time.Duration` Nutzungskontext festzulegen. WithTimeout](https://golang.org/pkg/context/#WithTimeout). Das SDK übergibt die bereitgestellten Daten `context.Context` an den HTTP-Transportclient, wenn eine Service-API aufgerufen wird. Wenn der an das SDK übergebene Kontext beim Aufrufen des Vorgangs storniert wird oder abgebrochen wird, wiederholt das SDK die Anfrage nicht weiter und kehrt zur aufrufenden Anwendung zurück. In Fällen, in denen der dem SDK bereitgestellte Kontext storniert wurde, müssen Sie die Kontextstornierung in Ihrer Anwendung entsprechend handhaben.
### Ein Timeout festlegen
Das folgende Beispiel zeigt, wie ein Timeout für einen Service-Client-Vorgang festgelegt wird.
```
import "context"
import "time"
// ...
ctx := context.TODO() // or appropriate context.Context value for your application
client := s3.NewFromConfig(cfg)
// create a new context from the previous ctx with a timeout, e.g. 5 seconds
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()
resp, err := client.GetObject(ctx, &s3.GetObjectInput{
// input parameters
})
if err != nil {
// handle error
}
```