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.
# Konfiguration von Service-Clients im AWS SDK für Rust
Für den programmgesteuerten Zugriff AWS-Services verwendet das AWS SDK für Rust jeweils eine Client-Struktur. AWS-Service Wenn Ihre Anwendung beispielsweise auf Amazon zugreifen muss EC2, erstellt Ihre Anwendung eine EC2 Amazon-Client-Struktur als Schnittstelle zu diesem Service. Anschließend verwenden Sie den Service-Client, um Anfragen an diesen zu stellen AWS-Service.
Um eine Anfrage an einen zu stellen AWS-Service, müssen Sie zunächst einen Service-Client erstellen. Für jeden Code, den AWS-Service Sie verwenden, gibt es eine eigene Kiste und einen eigenen Typ für die Interaktion mit ihm. Der Client stellt für jeden API-Vorgang, der vom Dienst verfügbar gemacht wird, eine Methode zur Verfügung.
Es gibt viele alternative Möglichkeiten, das SDK-Verhalten zu konfigurieren, aber letztendlich hat alles mit dem Verhalten von Service-Clients zu tun. Jede Konfiguration hat keine Wirkung, bis ein aus ihnen erstellter Service-Client verwendet wird.
Sie müssen festlegen, wie sich Ihr Code authentifiziert AWS , wenn Sie mit AWS-Services entwickeln. Sie müssen auch festlegen, was AWS-Region Sie verwenden möchten.
Das [AWS SDKs Referenzhandbuch für Tools](https://docs.aws.amazon.com/sdkref/latest/guide/) enthält außerdem Einstellungen, Funktionen und andere grundlegende Konzepte, die in vielen der AWS SDKs Tools üblich sind.
**Topics**
+ [Client-Konfiguration extern](config-external.md)
+ [Client-Konfiguration im Code](config-code.md)
+ [AWS-Region](region.md)
+ [Anbieter von Anmeldeinformationen](credproviders.md)
+ [Verhaltensversionen](behavior-versions.md)
+ [Erneute Versuche](retries.md)
+ [Timeouts](timeouts.md)
+ [Beobachtbarkeit](observability.md)
+ [Client-Endpunkte](endpoints.md)
+ [Überschreiben einer Betriebskonfiguration](peroperation.md)
+ [HTTP](http.md)
+ [Interzeptoren](interceptors.md)
# Externes Konfigurieren von AWS SDK für Rust Service-Clients
Viele Konfigurationseinstellungen können außerhalb Ihres Codes bearbeitet werden. Wenn die Konfiguration extern vorgenommen wird, wird die Konfiguration auf alle Ihre Anwendungen angewendet. Die meisten Konfigurationseinstellungen können entweder als Umgebungsvariablen oder in einer separaten gemeinsam genutzten AWS `config` Datei festgelegt werden. Die gemeinsam genutzte `config` Datei kann separate Einstellungssätze, sogenannte Profile, enthalten, um unterschiedliche Konfigurationen für verschiedene Umgebungen oder Tests bereitzustellen.
Umgebungsvariablen und gemeinsam genutzte `config` Dateieinstellungen sind standardisiert und werden von allen AWS SDKs Tools gemeinsam genutzt, um konsistente Funktionen in verschiedenen Programmiersprachen und Anwendungen zu unterstützen.
Weitere Informationen zur Konfiguration Ihrer Anwendung mit diesen *Methoden AWS SDKs sowie Einzelheiten zu den einzelnen SDK-übergreifenden Einstellungen finden Sie im Referenzhandbuch* und im Tools-Referenzhandbuch. Alle Einstellungen, die das SDK anhand der Umgebungsvariablen oder Konfigurationsdateien auflösen kann, finden Sie in der [Einstellungsreferenz im Referenzhandbuch AWS](https://docs.aws.amazon.com/sdkref/latest/guide/settings-reference.html) *SDKs und im Tools-Referenzhandbuch.*
Um eine Anfrage an zu stellen AWS-Service, instanziieren Sie zunächst einen Client für diesen Dienst. Sie können allgemeine Einstellungen für Service-Clients wie Timeouts und den HTTP-Client konfigurieren und die Konfiguration erneut versuchen.
Jeder Dienstclient benötigt einen Anmeldeinformationsanbieter AWS-Region und einen Anmeldeinformationsanbieter. Das SDK verwendet diese Werte, um Anfragen an die richtige Region für Ihre Ressourcen zu senden und Anfragen mit den richtigen Anmeldeinformationen zu signieren. Sie können diese Werte programmgesteuert im Code angeben oder sie automatisch aus der Umgebung laden lassen.
Das SDK verfügt über eine Reihe von Stellen (oder Quellen), die überprüft werden, um einen Wert für Konfigurationseinstellungen zu finden.
1. Jede explizite Einstellung, die im Code oder auf einem Service-Client selbst festgelegt ist, hat Vorrang vor allen anderen Einstellungen.
1. Umgebungsvariablen
+ Einzelheiten zum Setzen von Umgebungsvariablen finden Sie unter [Umgebungsvariablen](https://docs.aws.amazon.com/sdkref/latest/guide/environment-variables.html) im Referenzhandbuch *AWS SDKs und im Tools-Referenzhandbuch.*
+ Beachten Sie, dass Sie Umgebungsvariablen für eine Shell auf verschiedenen Gültigkeitsebenen konfigurieren können: systemweit, benutzerweit und für eine bestimmte Terminalsitzung.
1. Geteilte Dateien und Dateien `config` `credentials`
+ Einzelheiten zum Einrichten dieser Dateien finden Sie im *Referenzhandbuch „[Gemeinsam genutzte `config``credentials` Dateien](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html)“AWS SDKs und „Tools*“.
1. Jeder Standardwert, der vom SDK-Quellcode selbst bereitgestellt wird, wird zuletzt verwendet.
+ Für einige Eigenschaften, z. B. Region, gibt es keine Standardeinstellung. Sie müssen sie entweder explizit im Code, in einer Umgebungseinstellung oder in der gemeinsam genutzten `config` Datei angeben. Wenn das SDK die erforderliche Konfiguration nicht auflösen kann, können API-Anfragen zur Laufzeit fehlschlagen.
# AWS SDK für Rust-Serviceclients im Code konfigurieren
Wenn die Konfiguration direkt im Code abgewickelt wird, ist der Konfigurationsbereich auf die Anwendung beschränkt, die diesen Code verwendet. Innerhalb dieser Anwendung gibt es Optionen für die globale Konfiguration aller Service-Clients, die Konfiguration für alle Clients eines bestimmten AWS-Service Typs oder die Konfiguration für eine bestimmte Service-Client-Instanz.
Um eine Anfrage an zu stellen AWS-Service, instanziieren Sie zunächst einen Client für diesen Dienst. Sie können allgemeine Einstellungen für Service-Clients wie Timeouts und den HTTP-Client konfigurieren und die Konfiguration erneut versuchen.
Jeder Dienstclient benötigt einen AWS-Region und einen Anmeldeinformationsanbieter. Das SDK verwendet diese Werte, um Anfragen an die richtige Region für Ihre Ressourcen zu senden und Anfragen mit den richtigen Anmeldeinformationen zu signieren. Sie können diese Werte programmgesteuert im Code angeben oder sie automatisch aus der Umgebung laden lassen.
**Anmerkung**
Die Erstellung von Service-Clients kann teuer sein und sie sind in der Regel für die gemeinsame Nutzung vorgesehen. Um dies zu erleichtern, werden alle `Client` Strukturen implementiert`Clone`.
## Konfigurieren Sie einen Client aus der Umgebung
Verwenden Sie statische Methoden aus der Kiste, um einen Client mit einer Konfiguration aus der `aws-config` Umgebung zu erstellen:
```
let config = aws_config::defaults(BehaviorVersion::latest())
.load()
.await;
let s3 = aws_sdk_s3::Client::new(&config);
```
Das Erstellen eines Clients auf diese Weise ist nützlich, wenn er auf Amazon Elastic Compute Cloud oder in einem anderen Kontext ausgeführt wird AWS Lambda, in dem die Konfiguration eines Service-Clients direkt in der Umgebung verfügbar ist. Dies entkoppelt Ihren Code von der Umgebung, in der er ausgeführt wird, und macht es einfacher, Ihre Anwendung für mehrere bereitzustellen, AWS-Regionen ohne den Code zu ändern.
Sie können bestimmte Eigenschaften explizit überschreiben. Die explizite Konfiguration hat Vorrang vor der Konfiguration, die in der Ausführungsumgebung aufgelöst wurde. Das folgende Beispiel lädt die Konfiguration aus der Umgebung, überschreibt jedoch ausdrücklich: AWS-Region
```
let config = aws_config::defaults(BehaviorVersion::latest())
.region("us-east-1")
.load()
.await;
let s3 = aws_sdk_s3::Client::new(&config);
```
**Anmerkung**
Nicht alle Konfigurationswerte stammen zum Zeitpunkt der Erstellung vom Client. Auf Einstellungen im Zusammenhang mit Anmeldeinformationen, wie z. B. temporäre Zugriffsschlüssel und die IAM Identity Center-Konfiguration, wird über die Ebene des Anmeldeinformationsanbieters zugegriffen, wenn der Client für eine Anfrage verwendet wird.
Der in den vorherigen Beispielen `BehaviorVersion::latest()` gezeigte Code gibt die Version des SDK an, die standardmäßig verwendet werden soll. `BehaviorVersion::latest()`ist für die meisten Fälle geeignet. Details hierzu finden Sie unter [Verwenden von Verhaltensversionen in der AWS SDK für Rust](behavior-versions.md).
## Verwenden Sie das Builder-Muster für dienstspezifische Einstellungen
Es gibt einige Optionen, die nur für einen bestimmten Service-Client-Typ konfiguriert werden können. In den meisten Fällen möchten Sie jedoch immer noch den Großteil der Konfiguration aus der Umgebung laden und dann die zusätzlichen Optionen speziell hinzufügen. Das Builder-Muster ist ein gängiges Muster innerhalb der AWS SDK für Rust Crates. Sie laden zuerst die allgemeine Konfiguration mit und verwenden dann die `from` Methode`aws_config::defaults`, um diese Konfiguration in den Builder für den Dienst zu laden, mit dem Sie arbeiten. Anschließend können Sie beliebige eindeutige Konfigurationswerte für diesen Dienst festlegen und aufrufen`build`. Schließlich wird der Client anhand dieser modifizierten Konfiguration erstellt.
```
// Call a static method on aws-config that sources default config values.
let config = aws_config::defaults(BehaviorVersion::latest())
.load()
.await;
// Use the Builder for S3 to create service-specific config from the default config.
let s3_config = aws_sdk_s3::config::Builder::from(&config)
.accelerate(true) // Set an S3-only configuration option
.build();
// Create the client.
let s3 = aws_sdk_s3::Client::from_conf(s3_config);
```
Eine Möglichkeit, zusätzliche Methoden zu finden, die für einen bestimmten Typ von Service-Client verfügbar sind, besteht darin, die API-Dokumentation zu verwenden, z. B. für [https://docs.rs/aws-sdk-s3/latest/aws_sdk_s3/config/struct.Builder.html](https://docs.rs/aws-sdk-s3/latest/aws_sdk_s3/config/struct.Builder.html).
## Erweiterte explizite Client-Konfiguration
Um einen Service-Client mit bestimmten Werten zu konfigurieren, anstatt eine Konfiguration aus der Umgebung zu laden, können Sie diese im Client `Config` Builder angeben, wie im Folgenden gezeigt:
```
let conf = aws_sdk_s3::Config::builder()
.region("us-east-1")
.endpoint_resolver(my_endpoint_resolver)
.build();
let s3 = aws_sdk_s3::Client::from_conf(conf);
```
Wenn Sie eine Dienstkonfiguration mit erstellen`aws_sdk_s3::Config::builder()`, *wird keine Standardkonfiguration geladen*. Standardwerte werden nur geladen, wenn eine Konfiguration erstellt wird, die auf `aws_config::defaults` basiert.
Es gibt einige Optionen, die nur für einen bestimmten Service-Client-Typ konfiguriert werden können. Das vorherige Beispiel zeigt ein Beispiel dafür, indem die `endpoint_resolver` Funktion auf einem Amazon S3 S3-Client verwendet wird.
# Einstellung der AWS-Region für die AWS SDK für Rust
Sie können auf diejenigen zugreifen AWS-Services , die in einem bestimmten geografischen Gebiet tätig sind, indem Sie AWS-Regionen Dies kann sowohl aus Gründen der Redundanz als auch dafür nützlich sein, dass Ihre Daten und Anwendungen in der Nähe ausgeführt werden, wo Sie und Ihre Benutzer darauf zugreifen. Weitere Informationen zur Verwendung von Regionen finden Sie [AWS-Region](https://docs.aws.amazon.com/sdkref/latest/guide/feature-region.html)im Referenzhandbuch *AWS SDKs und im Tools-Referenzhandbuch.*
**Wichtig**
Die meisten Ressourcen befinden sich in einer bestimmten Region, AWS-Region und Sie müssen die richtige Region für die Ressource angeben, wenn Sie das SDK verwenden.
Sie müssen einen Standard AWS-Region für das SDK für Rust festlegen, das für AWS Anfragen verwendet werden soll. Dieser Standard wird für alle Aufrufe von SDK-Servicemethoden verwendet, die nicht mit einer Region angegeben sind.
Beispiele dafür, wie Sie die Standardregion mithilfe der gemeinsam genutzten AWS `config` Datei- oder Umgebungsvariablen festlegen, finden Sie [AWS-Region](https://docs.aws.amazon.com/sdkref/latest/guide/feature-region.html)im Referenzhandbuch *AWS SDKs und im Tools-Referenzhandbuch*.
## AWS-Region Anbieterkette
Der folgende Suchvorgang wird verwendet, wenn die Konfiguration eines Service-Clients aus der Ausführungsumgebung geladen wird. Der erste Wert, den das SDK feststellt, wird in der Konfiguration des Clients verwendet. Weitere Informationen zum Erstellen von Service-Clients finden Sie unter[Konfigurieren Sie einen Client aus der Umgebung](config-code.md#configure-a-client-from-the-environment).
1. Jede explizite Region, die programmgesteuert festgelegt wurde.
1. Die Umgebungsvariable `AWS_REGION` wird geprüft.
+ Wenn Sie den AWS Lambda Dienst verwenden, wird diese Umgebungsvariable automatisch vom AWS Lambda Container festgelegt.
1. Die `region` Eigenschaft in der gemeinsam genutzten AWS `config` Datei wird überprüft.
+ Die `AWS_CONFIG_FILE` Umgebungsvariable kann verwendet werden, um den Speicherort der gemeinsam genutzten `config` Datei zu ändern. Weitere Informationen darüber, wo diese Datei gespeichert wird, finden Sie unter [Speicherort der gemeinsam genutzten `credentials` Dateien `config` und Dateien](https://docs.aws.amazon.com/sdkref/latest/guide/file-location.html) im *AWS SDKs Referenzhandbuch zu Tools*.
+ Die `AWS_PROFILE` Umgebungsvariable kann verwendet werden, um ein benanntes Profil anstelle des Standardprofils auszuwählen. Weitere Informationen zur Konfiguration verschiedener Profile finden Sie unter [Geteilte Profile `config` und `credentials` Dateien](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html) im *AWS SDKs Referenzhandbuch zu Tools*.
1. Das SDK versucht, den Amazon EC2 Instance Metadata Service zu verwenden, um die Region der aktuell laufenden Amazon EC2 EC2-Instance zu ermitteln.
+ Die AWS SDK für Rust einzige Unterstützung. IMDSv2
Das `RegionProviderChain` wird automatisch ohne zusätzlichen Code verwendet, wenn eine Basiskonfiguration für die Verwendung mit einem Service-Client erstellt wird:
```
let config = aws_config::defaults(BehaviorVersion::latest())
.load()
.await;
```
## Einstellen des AWS-Region In-Codes
### Explizites Einstellen der Region im Code
Verwenden Sie es `Region::new()` direkt in Ihrer Konfiguration, wenn Sie die Region explizit festlegen möchten.
Die Region Provider Chain wird nicht verwendet — sie überprüft nicht die Umgebung, die gemeinsam genutzte `config` Datei oder den Amazon EC2 Instance Metadata Service.
```
use aws_config::{defaults, BehaviorVersion};
use aws_sdk_s3::config::Region;
#[tokio::main]
async fn main() {
let config = defaults(BehaviorVersion::latest())
.region(Region::new("us-west-2"))
.load()
.await;
println!("Using Region: {}", config.region().unwrap());
}
```
Stellen Sie sicher, dass Sie eine gültige Zeichenfolge für eingeben AWS-Region. Der angegebene Wert ist nicht validiert.
### Anpassen der `RegionProviderChain`
Verwenden Sie den[AWS-Region Anbieterkette](#region-provider-chain), wenn Sie eine Region bedingt einfügen, sie überschreiben oder die Auflösungskette anpassen möchten.
```
use aws_config::{defaults, BehaviorVersion};
use aws_config::meta::region::RegionProviderChain;
use aws_sdk_s3::config::Region;
use std::env;
#[tokio::main]
async fn main() {
let region_provider = RegionProviderChain::first_try(env::var("CUSTOM_REGION").ok().map(Region::new))
.or_default_provider()
.or_else(Region::new("us-east-2"));
let config = aws_config::defaults(BehaviorVersion::latest())
.region(region_provider)
.load()
.await;
println!("Using Region: {}", config.region().unwrap());
}
```
Die vorherige Konfiguration wird:
1. Prüfen Sie zunächst, ob in der `CUSTOM_REGION` Umgebungsvariablen eine Zeichenfolge festgelegt ist.
1. Wenn das nicht verfügbar ist, greifen Sie auf die standardmäßige Anbieterkette der Region zurück.
1. Wenn das fehlschlägt, verwenden Sie „us-east-2" als letzten Fallback.
# Verwenden des AWS SDK für Rust-Anmeldeinformationsanbieter
Alle Anfragen an AWS müssen kryptografisch signiert werden, wobei die Anmeldeinformationen verwendet werden müssen, die von ausgestellt wurden. AWS Zur Laufzeit ruft das SDK Konfigurationswerte für Anmeldeinformationen ab, indem es mehrere Speicherorte überprüft.
Wenn die abgerufene Konfiguration [Einstellungen für den AWS IAM Identity Center Single Sign-On-Zugriff](credentials.md) enthält, ruft das SDK zusammen mit dem IAM Identity Center temporäre Anmeldeinformationen ab, an die es Anfragen sendet. AWS-Services
Wenn die abgerufene Konfiguration [temporäre Anmeldeinformationen](https://docs.aws.amazon.com/sdkref/latest/guide/access-temp-idc.html) enthält, verwendet das SDK diese, um Aufrufe zu tätigen AWS-Service . Temporäre Anmeldeinformationen bestehen aus Zugriffsschlüsseln und einem Sitzungstoken.
Die Authentifizierung mit AWS kann außerhalb Ihrer Codebasis erfolgen. Viele Authentifizierungsmethoden können vom SDK mithilfe der Credential Provider-Kette automatisch erkannt, verwendet und aktualisiert werden.
Anleitungen zu den ersten Schritten mit der AWS Authentifizierung für Ihr Projekt finden Sie unter [Authentifizierung und Zugriff](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) im *AWS SDKs Referenzhandbuch zu Tools.*
## Die Kette der Anbieter von Anmeldeinformationen
Wenn Sie bei der Erstellung eines Clients nicht explizit einen Anbieter für Anmeldeinformationen angeben, verwendet das SDK für Rust eine Kette von Anbietern von Anmeldeinformationen, die eine Reihe von Stellen überprüft, an denen Sie Anmeldeinformationen angeben können. Sobald das SDK Anmeldeinformationen an einem dieser Orte findet, wird die Suche beendet. Einzelheiten zur Erstellung von Clients finden Sie unter[AWS SDK für Rust-Serviceclients im Code konfigurieren](config-code.md).
Im folgenden Beispiel wird kein Anbieter für Anmeldeinformationen im Code angegeben. Das SDK verwendet die Anmeldeinformationsanbieterkette, um die Authentifizierung zu erkennen, die in der Hostumgebung eingerichtet wurde, und verwendet diese Authentifizierung für Aufrufe von. AWS-Services
```
let config = aws_config::defaults(BehaviorVersion::latest()).load().await;
let s3 = aws_sdk_s3::Client::new(&config);
```
### Reihenfolge beim Abrufen der Anmeldeinformationen
Die Anmeldeinformationsanbieterkette sucht anhand der folgenden vordefinierten Reihenfolge nach Anmeldeinformationen:
1. **Greifen Sie auf wichtige Umgebungsvariablen zu**
Das SDK versucht, Anmeldeinformationen aus den `AWS_ACCESS_KEY_ID` `AWS_SESSION_TOKEN` Umgebungsvariablen und zu laden. `AWS_SECRET_ACCESS_KEY`
1. **Die geteilten `credentials` Dateien AWS `config` und**
Das SDK versucht, Anmeldeinformationen aus dem `[default]` Profil in die gemeinsam genutzten `credentials` Dateien AWS `config` und Dateien zu laden. Sie können die `AWS_PROFILE` Umgebungsvariable verwenden, um ein benanntes Profil auszuwählen, das das SDK laden und nicht verwenden soll`[default]`. Die `credentials` Dateien `config` und werden von verschiedenen AWS SDKs AND-Tools gemeinsam genutzt. Weitere Informationen zu diesen Dateien finden Sie unter [Gemeinsam genutzte `credentials` Dateien `config` und Dateien](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html) im *AWS SDKs Referenzhandbuch für Tools*. Weitere Informationen zu standardisierten Anbietern, die Sie in einem Profil angeben können, finden Sie unter [AWS SDKs Tools für standardisierte Anbieter von Anmeldeinformationen](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html).
1. **AWS STS Web-Identität**
Beim Erstellen von mobilen Anwendungen oder clientbasierten Webanwendungen, für die Zugriff erforderlich ist AWS, gibt AWS -Security-Token-Service (AWS STS) einen Satz temporärer Sicherheitsanmeldedaten für Verbundbenutzer zurück, die über einen Public Identity Provider (IdP) authentifiziert wurden.
+ Wenn Sie dies in einem Profil angeben, versucht das SDK oder das Tool, temporäre Anmeldeinformationen mithilfe der API-Methode abzurufen. AWS STS `AssumeRoleWithWebIdentity` Einzelheiten zu dieser Methode finden Sie [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)in der *AWS -Security-Token-Service API-Referenz*.
+ Anleitungen zur Konfiguration dieses Anbieters finden Sie unter [Federate with Web Identity oder OpenID Connect](https://docs.aws.amazon.com/sdkref/latest/guide/access-assume-role.html#webidentity) im *AWS SDKs und Tools Reference Guide.*
+ Einzelheiten zu den SDK-Konfigurationseigenschaften für diesen Anbieter finden Sie unter Assume [role Credential Provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-assume-role-credentials.html) im Referenzhandbuch *AWS SDKs und im Tools-Referenzhandbuch*.
1. **Anmeldeinformationen für Amazon ECS- und Amazon EKS-Container**
Ihren Amazon Elastic Container Service-Aufgaben und Kubernetes-Servicekonten kann eine IAM-Rolle zugewiesen werden. Die in der IAM-Rolle gewährten Berechtigungen werden von den Containern übernommen, die in der Aufgabe oder den Containern des Pods ausgeführt werden. Diese Rolle ermöglicht es Ihrem SDK für Rust-Anwendungscode (auf dem Container), andere AWS-Services zu verwenden.
Das SDK versucht, Anmeldeinformationen aus den `AWS_CONTAINER_CREDENTIALS_FULL_URI` Umgebungsvariablen `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` oder abzurufen, die automatisch von Amazon ECS und Amazon EKS festgelegt werden können.
+ Einzelheiten zur Einrichtung dieser Rolle für Amazon ECS finden Sie unter [Amazon ECS-Aufgaben-IAM-Rolle](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) im *Amazon Elastic Container Service Developer Guide*.
+ Informationen zur Einrichtung von Amazon EKS finden Sie unter [Einrichten des Amazon EKS Pod Identity Agent](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) im **Amazon EKS-Benutzerhandbuch**.
+ Einzelheiten zu den SDK-Konfigurationseigenschaften für diesen Anbieter finden Sie unter [Container Credential Provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-container-credentials.html) im *AWS SDKs und Tools Reference Guide.*
1. **Amazon EC2 EC2-Instance-Metadatenservice**
Erstellen Sie eine IAM-Rolle und fügen Sie sie Ihrer Instance hinzu. Die SDK for Rust-Anwendung auf der Instanz versucht, die von der Rolle bereitgestellten Anmeldeinformationen aus den Instanz-Metadaten abzurufen.
+ Das SDK für Rust unterstützt nur [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html).
+ Einzelheiten zur Einrichtung dieser Rolle und zur Verwendung von Metadaten, zu den [IAM-Rollen für Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) und [Arbeiten mit Instance-Metadaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) finden Sie im *Amazon EC2 EC2-Benutzerhandbuch*.
+ *Einzelheiten zu den SDK-Konfigurationseigenschaften für diesen Anbieter finden Sie unter [IMDS-Anmeldeinformationsanbieter](https://docs.aws.amazon.com/sdkref/latest/guide/feature-imds-credentials.html) im Referenzhandbuch und im Tools-Referenzhandbuch.AWS SDKs *
1. Wenn die Anmeldeinformationen zu diesem Zeitpunkt immer noch nicht gelöst sind, ist der Vorgang panics fehlerhaft.
Einzelheiten zu den Konfigurationseinstellungen des AWS Anmeldeinformationsanbieters finden Sie unter [Standardisierte Anmeldeinformationsanbieter](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html) in der *Einstellungsreferenz* des *AWS SDKs und im Tools-Referenzhandbuch.*
## Anbieter expliziter Anmeldeinformationen
Anstatt sich bei der Erkennung Ihrer Authentifizierungsmethode auf die Kette der Anmeldeinformationsanbieter zu verlassen, können Sie einen bestimmten Anmeldeinformationsanbieter angeben, den das SDK verwenden soll. Wenn Sie Ihre allgemeine Konfiguration mit laden`aws_config::defaults`, können Sie einen benutzerdefinierten Anbieter für Anmeldeinformationen angeben, wie im Folgenden dargestellt:
```
let config = aws_config::defaults(BehaviorVersion::latest())
.credentials_provider(MyCredentialsProvider::new())
.load()
.await;
```
Sie können Ihren eigenen Anbieter für Anmeldeinformationen implementieren, indem Sie das [https://docs.rs/aws-credential-types/latest/aws_credential_types/provider/trait.ProvideCredentials.html](https://docs.rs/aws-credential-types/latest/aws_credential_types/provider/trait.ProvideCredentials.html)Merkmal implementieren.
## Zwischenspeichern von Identitäten
Das SDK speichert Anmeldeinformationen und andere Identitätstypen wie SSO-Token im Cache. Standardmäßig verwendet das SDK eine Lazy-Cache-Implementierung, die Anmeldeinformationen bei der ersten Anfrage lädt, zwischenspeichert und dann versucht, sie bei einer weiteren Anfrage zu aktualisieren, wenn sie fast ablaufen. Clients, die auf derselben Grundlage erstellt wurden, teilen `SdkConfig` sich eine. [https://docs.rs/aws-smithy-runtime/latest/aws_smithy_runtime/client/identity/struct.IdentityCache.html](https://docs.rs/aws-smithy-runtime/latest/aws_smithy_runtime/client/identity/struct.IdentityCache.html)
# Verwenden von Verhaltensversionen in der AWS SDK für Rust
AWS SDK für Rust Entwickler erwarten das robuste und vorhersehbare Verhalten, das die Sprache und ihre wichtigsten Bibliotheken bieten, und verlassen sich darauf. Um Entwicklern, die das SDK für Rust verwenden, dabei zu helfen, das erwartete Verhalten zu erzielen, müssen Client-Konfigurationen a enthalten`BehaviorVersion`. Das `BehaviorVersion` gibt die Version des SDK an, deren Standardwerte erwartet werden. Auf diese Weise kann sich das SDK im Laufe der Zeit weiterentwickeln und bewährte Verfahren ändern, um neuen Standards zu entsprechen und neue Funktionen zu unterstützen, ohne dass sich dies unerwartet negativ auf das Verhalten Ihrer Anwendung auswirkt.
**Warnung**
Wenn Sie versuchen, das SDK zu konfigurieren oder einen Client zu erstellen, ohne explizit a anzugeben`BehaviorVersion`, wird panic der Konstruktor dies tun.
Stellen Sie sich beispielsweise vor, dass eine neue Version des SDK mit einer neuen Standard-Wiederholungsrichtlinie veröffentlicht wird. Wenn Ihre Anwendung eine `BehaviorVersion` mit einer früheren Version des SDK übereinstimmende Version verwendet, wird diese vorherige Konfiguration anstelle der neuen Standardkonfiguration verwendet.
Jedes Mal, wenn eine neue Verhaltensversion des SDK für Rust veröffentlicht wird, `BehaviorVersion` wird die vorherige Version mit dem SDK für `deprecated` Rust-Attribut gekennzeichnet und die neue Version wird hinzugefügt. Dadurch treten bei der Kompilierung Warnungen auf, ansonsten kann der Build aber wie gewohnt fortgesetzt werden. `BehaviorVersion::latest()`wird ebenfalls aktualisiert, um das Standardverhalten der neuen Version anzuzeigen.
**Anmerkung**
Wenn Ihr Code nicht von extrem spezifischen Verhaltensmerkmalen abhängt, sollten Sie ihn `BehaviorVersion::latest()` im Code verwenden oder das Feature-Flag `behavior-version-latest` in der `Cargo.toml` Datei verwenden. Wenn Sie Code schreiben, der latenzempfindlich ist oder das Verhalten des Rust SDK optimiert, sollten Sie erwägen, ihn an eine bestimmte Hauptversion `BehaviorVersion` zu binden.
## Stellen Sie die Verhaltensversion ein `Cargo.toml`
Sie können die Verhaltensversion für das SDK und einzelne Module, z. B. `aws-sdk-s3` oder, angeben`aws-sdk-iam`, indem Sie der `Cargo.toml` Datei ein entsprechendes Feature-Flag hinzufügen. Derzeit wird nur die `latest` Version des SDK unterstützt in`Cargo.toml`:
```
[dependencies]
aws-config = { version = "1", features = ["behavior-version-latest"] }
aws-sdk-s3 = { version = "1", features = ["behavior-version-latest"] }
```
## Legen Sie die Verhaltensversion im Code fest
Ihr Code kann die Verhaltensversion nach Bedarf ändern, indem Sie sie bei der Konfiguration des SDK oder eines Clients angeben:
```
let config = aws_config::load_defaults(BehaviorVersion::v2023_11_09()).await;
```
In diesem Beispiel wird eine Konfiguration erstellt, die die Umgebung verwendet, um das SDK zu konfigurieren, aber den Wert `BehaviorVersion` auf setzt`v2023_11_09()`.
# Konfiguration von Wiederholungsversuchen im AWS SDK für Rust
Das AWS SDK für Rust bietet ein standardmäßiges Wiederholungsverhalten für Serviceanfragen und anpassbare Konfigurationsoptionen. Ruft auf, um AWS-Services gelegentlich unerwartete Ausnahmen zurückzugeben. Bestimmte Arten von Fehlern, wie Drosselungen oder vorübergehende Fehler, können erfolgreich sein, wenn der Aufruf erneut versucht wird.
Das Wiederholungsverhalten kann global mithilfe von Umgebungsvariablen oder Einstellungen in der gemeinsam genutzten Datei konfiguriert werden. AWS `config` Informationen zu diesem Ansatz finden Sie unter [Verhalten bei Wiederholungsversuchen](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) im Referenzhandbuch *AWS SDKs und im Tools-Referenzhandbuch.* Es enthält auch detaillierte Informationen zu Implementierungen von Wiederholungsstrategien und dazu, wie Sie sich für eine Strategie entscheiden können.
Alternativ können diese Optionen auch in Ihrem Code konfiguriert werden, wie in den folgenden Abschnitten gezeigt.
## Standardkonfiguration für Wiederholungsversuche
Jeder Service-Client verwendet standardmäßig die Konfiguration der `standard` Wiederholungsstrategie, die in der Struktur bereitgestellt wird. [https://docs.rs/aws-smithy-types/latest/aws_smithy_types/retry/struct.RetryConfig.html](https://docs.rs/aws-smithy-types/latest/aws_smithy_types/retry/struct.RetryConfig.html) Standardmäßig wird ein Anruf dreimal versucht (*der erste Versuch plus zwei Wiederholungen*). Darüber hinaus wird jeder Wiederholungsversuch um eine kurze, zufällige Dauer verzögert, um Wiederholungsversuche zu vermeiden. Diese Konvention ist für die meisten Anwendungsfälle geeignet, kann jedoch unter bestimmten Umständen, wie z. B. bei Systemen mit hohem Durchsatz, ungeeignet sein.
Nur einige Arten von Fehlern werden von der als wiederholbar angesehen. SDKs Beispiele für Fehler, die wiederholt werden können, sind:
+ Socket-Timeouts
+ Drosselung auf der Serviceseite
+ vorübergehende Dienstfehler wie HTTP 5XX-Antworten
Die folgenden Beispiele gelten **nicht als wiederholbar**:
+ Fehlende oder ungültige Parameter
+ Authentifizierungs-/Sicherheitsfehler
+ Ausnahmen bei Fehlkonfigurationen
Sie können die `standard` Wiederholungsstrategie anpassen, indem Sie die maximale Anzahl an Versuchen, Verzögerungen und die Backoff-Konfiguration festlegen.
## Maximale Anzahl an Versuchen
Sie können die maximale Anzahl der Versuche in Ihrem Code anpassen, indem Sie eine Änderung [https://docs.rs/aws-smithy-types/latest/aws_smithy_types/retry/struct.RetryConfig.html](https://docs.rs/aws-smithy-types/latest/aws_smithy_types/retry/struct.RetryConfig.html)an Ihrem Code angeben`aws_config::defaults`:
```
const CUSTOM_MAX_ATTEMPTS: u32 = 5;
let retry_config = RetryConfig::standard()
// Set max attempts. When max_attempts is 1, there are no retries.
// This value MUST be greater than zero.
// Defaults to 3.
.with_max_attempts(CUSTOM_MAX_ATTEMPTS);
let config = aws_config::defaults(BehaviorVersion::latest())
.retry_config(retry_config)
.load()
.await;
```
## Verzögerungen und Rückschläge
Wenn ein erneuter Versuch erforderlich ist, wartet die standardmäßige Wiederholungsstrategie, bevor sie den nächsten Versuch durchführt. Die Verzögerung beim ersten Versuch ist gering, nimmt aber bei späteren Wiederholungen exponentiell zu. Die maximale Verzögerung ist begrenzt, sodass sie nicht zu groß wird.
Zufälliger Jitter wird auf die Verzögerungen zwischen allen Versuchen angewendet. Der Jitter trägt dazu bei, die Auswirkungen großer Flotten zu mildern, die zu erneuten Stürmen führen können. *Eine eingehendere Erläuterung zu exponentiellem Backoff und Jitter finden Sie unter [Exponentieller](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) Rückfluss und Jitter im Architektur-Blog.AWS *
Sie können die Verzögerungseinstellungen in Ihrem Code anpassen, indem Sie eine Änderung an Ihrem Code angeben. [https://docs.rs/aws-smithy-types/latest/aws_smithy_types/retry/struct.RetryConfig.html](https://docs.rs/aws-smithy-types/latest/aws_smithy_types/retry/struct.RetryConfig.html)`aws_config::defaults` Der folgende Code legt die Konfiguration so fest, dass der erste Wiederholungsversuch um bis zu 100 Millisekunden verzögert wird und dass die maximale Zeitspanne zwischen jedem Wiederholungsversuch 5 Sekunden beträgt.
```
let retry_config = RetryConfig::standard()
// Defaults to 1 second.
.with_initial_backoff(Duration::from_millis(100))
// Defaults to 20 seconds.
.with_max_backoff(Duration::from_secs(5));
let config = aws_config::defaults(BehaviorVersion::latest())
.retry_config(retry_config)
.load()
.await;
```
## Adaptiver Wiederholungsmodus
Als Alternative zur Moduswiederholungsstrategie ist die `standard` `adaptive` Moduswiederholungsstrategie ein fortschrittlicher Ansatz, bei dem nach der idealen Anforderungsrate gesucht wird, um Drosselungsfehler zu minimieren.
**Anmerkung**
Adaptive Wiederholungen sind ein erweiterter Wiederholungsmodus. Die Verwendung dieser Strategie wird in der Regel nicht empfohlen. Weitere Informationen finden Sie unter [Verhalten bei Wiederholungsversuchen](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html#standardvsadaptive) im Referenzhandbuch *AWS SDKs und im Tools-Referenzhandbuch.*
Adaptive Wiederholungen umfassen alle Funktionen von Standardwiederholungen. Es fügt einen clientseitigen Ratenbegrenzer hinzu, der die Rate gedrosselter Anfragen im Vergleich zu Anfragen ohne Drosselung misst. Außerdem wird der Datenverkehr so begrenzt, dass versucht wird, innerhalb einer sicheren Bandbreite zu bleiben, sodass im Idealfall keine Drosselungsfehler auftreten.
Die Rate passt sich in Echtzeit an sich ändernde Betriebsbedingungen und Verkehrsmuster an und kann die Verkehrsrate entsprechend erhöhen oder verringern. Entscheidend ist, dass der Ratenbegrenzer erste Versuche in Szenarien mit hohem Verkehrsaufkommen verzögern kann.
Sie können die `adaptive` Wiederholungsstrategie im Code auswählen, indem Sie Folgendes angeben: [https://docs.rs/aws-smithy-types/latest/aws_smithy_types/retry/struct.RetryConfig.html](https://docs.rs/aws-smithy-types/latest/aws_smithy_types/retry/struct.RetryConfig.html)
```
let config = aws_config::defaults(BehaviorVersion::latest())
.retry_config(RetryConfig::adaptive())
.load()
.await;
```
# Timeouts im AWS SDK für Rust konfigurieren
Das AWS SDK für Rust bietet verschiedene Einstellungen für die Verwaltung von AWS-Service Anforderungs-Timeouts und blockierten Datenströmen. Diese helfen Ihrer Anwendung, sich optimal zu verhalten, wenn unerwartete Verzögerungen und Ausfälle im Netzwerk auftreten.
## API-Timeouts
Wenn es vorübergehende Probleme gibt, die dazu führen können, dass Anforderungsversuche lange dauern oder ganz fehlschlagen, ist es wichtig, Timeouts zu überprüfen und festzulegen, damit Ihre Anwendung schnell fehlschlägt und sich optimal verhält. Anfragen, die fehlschlagen, können vom SDK automatisch wiederholt werden. Es empfiehlt sich, Timeouts sowohl für den einzelnen Versuch als auch für die gesamte Anfrage festzulegen.
Das SDK für Rust bietet ein Standard-Timeout für den Verbindungsaufbau für eine Anfrage. Für das SDK ist standardmäßig keine maximale Wartezeit für den Empfang einer Antwort auf einen Anforderungsversuch oder für die gesamte Anfrage festgelegt. Die folgenden Timeout-Optionen sind verfügbar:
| Parameter | Standardwert | Description |
| --- | --- | --- |
| Verbindungs-Timeout | 3,1 Sekunden | Die maximale Wartezeit, bis eine Verbindung hergestellt werden kann, bevor der Vorgang abgebrochen wird. |
| Timeout für den Vorgang | Keine | Die maximale Wartezeit, bis eine Antwort vom SDK für Rust eingeht, einschließlich aller Wiederholungsversuche. |
| Timeout für den Versuch eines Vorgangs | Keine | Die maximale Wartezeit auf einen einzelnen HTTP-Versuch. Danach kann der API-Aufruf erneut versucht werden. |
| Timeout beim Lesen | Keine | Die maximale Wartezeit bis zum Lesen des ersten Bytes einer Antwort ab dem Zeitpunkt, an dem die Anforderung initiiert wird. |
Das folgende Beispiel zeigt die Konfiguration eines Amazon S3 S3-Clients mit benutzerdefinierten Timeout-Werten:
```
let config = aws_config::defaults(BehaviorVersion::latest())
.timeout_config(
TimeoutConfig::builder()
.operation_timeout(Duration::from_secs(5))
.operation_attempt_timeout(Duration::from_millis(1500))
.build()
)
.load()
.await;
let s3 = aws_sdk_s3::Client::new(&config);
```
Wenn Sie sowohl Vorgangs- als auch Versuchs-Timeouts zusammen verwenden, legen Sie ein festes Limit für die Gesamtzeit fest, die für alle Versuche bei Wiederholungen aufgewendet wird. Sie legen außerdem fest, dass eine einzelne HTTP-Anfrage bei einer langsamen Anfrage schnell fehlschlägt.
Als Alternative zum Festlegen dieser Timeout-Werte auf dem Service-Client für alle Operationen können Sie [sie für eine einzelne Anfrage konfigurieren oder überschreiben](peroperation.md).
**Wichtig**
Timeouts für Vorgänge und Versuche gelten nicht für Streaming-Daten, die verbraucht werden, nachdem das SDK für Rust eine Antwort zurückgegeben hat. Ein Beispiel: Wenn Daten von einem `ByteStream` Mitglied einer Antwort abgerufen werden, gibt es keine Zeitüberschreitungen bei Vorgängen.
## Der Stream-Schutz ist ins Stocken geraten
Das SDK für Rust bietet eine weitere Form von Timeout im Zusammenhang mit der Erkennung blockierter Streams. Ein blockierter Stream ist ein Upload- oder Download-Stream, der länger als eine konfigurierte Kulanzzeit keine Daten erzeugt. Dadurch wird verhindert, dass Anwendungen auf unbestimmte Zeit hängen bleiben und niemals Fortschritte machen.
Der Schutz vor blockierten Streams gibt einen Fehler zurück, wenn ein Stream länger als den akzeptablen Zeitraum inaktiv ist.
Standardmäßig aktiviert das SDK für Rust den Schutz vor blockierten Streams sowohl für Uploads als auch für Downloads und sucht nach mindestens einer Aktivität mit einer großzügigen Übergangszeit von 20 Sekunden. byte/sec
Das folgende Beispiel zeigt eine benutzerdefinierte Version`StalledStreamProtectionConfig`, die den Upload-Schutz deaktiviert und die Übergangszeit für den Fall, dass keine Aktivität stattfindet, auf 10 Sekunden ändert:
```
let config = aws_config::defaults(BehaviorVersion::latest())
.stalled_stream_protection(
StalledStreamProtectionConfig::enabled()
.upload_enabled(false)
.grace_period(Duration::from_secs(10))
.build()
)
.load()
.await;
```
**Warnung**
Der Schutz vor blockierten Streams ist eine erweiterte Konfigurationsoption. Wir empfehlen, diese Werte nur zu ändern, wenn Ihre Anwendung eine höhere Leistung benötigt oder wenn sie ein anderes Problem verursacht.
### Deaktivieren Sie den Schutz vor blockierten Streams
Das folgende Beispiel zeigt, wie der Schutz vor blockierten Streams vollständig deaktiviert werden kann:
```
let config = aws_config::defaults(BehaviorVersion::latest())
.stalled_stream_protection(StalledStreamProtectionConfig::disabled())
.load()
.await;
```
# Konfiguration von Observability-Funktionen im AWS SDK für Rust
Beobachtbarkeit ist das Ausmaß, in dem der aktuelle Zustand eines Systems aus den von ihm ausgegebenen Daten abgeleitet werden kann. Die ausgegebenen Daten werden allgemein als Telemetrie bezeichnet.
**Topics**
+ [Protokollierung](logging.md)
# Konfiguration und Verwendung der Protokollierung im AWS SDK für Rust
Das AWS SDK für Rust verwendet das [Tracing-Framework](http://tracing.rs/) für die Protokollierung. Um die Protokollierung zu aktivieren, fügen Sie die `tracing-subscriber` Kiste hinzu und initialisieren Sie sie in Ihrer Rust-Anwendung. Zu den Protokollen gehören Zeitstempel, Protokollebenen und Modulpfade, die beim Debuggen von API-Anfragen und beim SDK-Verhalten helfen. Verwenden Sie die `RUST_LOG` Umgebungsvariable, um die Ausführlichkeit der Protokolle zu kontrollieren, und filtern Sie sie bei Bedarf nach Modulen.
## Wie aktiviere ich die Protokollierung im AWS SDK für Rust
1. Fügen Sie in einer Befehlszeile für Ihr Projektverzeichnis die [Tracing-Abonnenten-Kiste](https://crates.io/crates/tracing-subscriber) als Abhängigkeit hinzu:
```
$ cargo add tracing-subscriber --features tracing-subscriber/env-filter
```
Dadurch wird die Kiste dem `[dependencies]` Abschnitt Ihrer Datei hinzugefügt. `Cargo.toml`
1. Initialisieren Sie den Abonnenten. Normalerweise erfolgt dies zu Beginn der `main` Funktion, bevor ein SDK für Rust-Operationen aufgerufen wird:
```
use aws_config::BehaviorVersion;
type BoxError = Box;
#[tokio::main]
async fn main() -> Result<(), BoxError> {
tracing_subscriber::fmt::init(); // Initialize the subscriber.
let config = aws_config::defaults(BehaviorVersion::latest())
.load()
.await;
let s3 = aws_sdk_s3::Client::new(&config);
let _resp = s3.list_buckets()
.send()
.await?;
Ok(())
}
```
1. Schalten Sie die Protokollierung mithilfe der `RUST_LOG` Umgebungsvariablen ein. Um die Anzeige von Protokollinformationen zu aktivieren, setzen Sie in einer Befehlszeile die `RUST_LOG` Umgebungsvariable auf die Ebene, auf der Sie protokollieren möchten. Im folgenden Beispiel wird die Protokollierung auf die `debug` Stufe eingestellt:
------
#### [ Linux/macOS ]
```
$ RUST_LOG=debug
```
------
#### [ Windows ]
Wenn Sie verwenden VSCode, ist das Terminalfenster häufig standardmäßig auf PowerShell eingestellt. Überprüfen Sie, welche Art von Aufforderung Sie verwenden.
```
C:\> set RUST_LOG=debug
```
------
#### [ PowerShell ]
```
PS C:\> $ENV:RUST_LOG="debug"
```
------
1. Führen Sie das Programm aus:
```
$ cargo run
```
Sie sollten zusätzliche Ausgaben in der Konsole oder im Terminalfenster sehen.
Weitere Informationen finden Sie in der `tracing-subscriber` Dokumentation unter [Filtern von Ereignissen mit Umgebungsvariablen](https://docs.rs/tracing-subscriber/0.3.18/tracing_subscriber/fmt/index.html#filtering-events-with-environment-variables).
## Interpretieren Sie die Protokollausgabe
Sobald Sie die Protokollierung aktiviert haben, indem Sie die Schritte im vorherigen Abschnitt ausgeführt haben, werden zusätzliche Protokollinformationen standardmäßig ausgedruckt.
Wenn Sie das standardmäßige Protokollausgabeformat (vom Protokollierungsmodul als „vollständig“ bezeichnet) verwenden, sehen die Informationen, die Sie in der Protokollausgabe sehen, in etwa so aus:
```
2024-06-25T16:10:12.367482Z DEBUG invoke{service=s3 operation=ListBuckets sdk_invocation_id=3434933}:try_op:try_attempt:lazy_load_identity: aws_smithy_runtime::client::identity::cache::lazy: identity cache miss occurred; added new identity (took 480.892ms) new_expiration=2024-06-25T23:07:59Z valid_for=25066.632521s partition=IdentityCachePartition(7)
2024-06-25T16:10:12.367602Z DEBUG invoke{service=s3 operation=ListBuckets sdk_invocation_id=3434933}:try_op:try_attempt: aws_smithy_runtime::client::identity::cache::lazy: loaded identity
2024-06-25T16:10:12.367643Z TRACE invoke{service=s3 operation=ListBuckets sdk_invocation_id=3434933}:try_op:try_attempt: aws_smithy_runtime::client::orchestrator::auth: resolved identity identity=Identity { data: Credentials {... }, expiration: Some(SystemTime { tv_sec: 1719356879, tv_nsec: 0 }) }
2024-06-25T16:10:12.367695Z TRACE invoke{service=s3 operation=ListBuckets sdk_invocation_id=3434933}:try_op:try_attempt: aws_smithy_runtime::client::orchestrator::auth: signing request
```
Jeder Eintrag beinhaltet Folgendes:
+ Der Zeitstempel des Protokolleintrags.
+ Die Protokollebene des Eintrags. Das ist ein Wort wie `INFO``DEBUG`, oder`TRACE`.
+ Die verschachtelte Gruppe von [Bereichen,](https://docs.rs/tracing/latest/tracing/span/index.html) aus denen der Protokolleintrag generiert wurde, getrennt durch Doppelpunkte („:“). Auf diese Weise können Sie die Quelle des Protokolleintrags identifizieren.
+ Der Rust-Modulpfad, der den Code enthält, der den Protokolleintrag generiert hat.
+ Der Text der Protokollnachricht.
Die Standardausgabeformate des Tracing-Moduls verwenden ANSI-Escape-Codes, um die Ausgabe einzufärben. Beachten Sie diese Escape-Sequenzen, wenn Sie die Ausgabe filtern oder durchsuchen.
**Anmerkung**
Was innerhalb der `sdk_invocation_id` verschachtelten Spans angezeigt wird, ist eine eindeutige ID, die vom SDK clientseitig generiert wird, um die Korrelation von Protokollnachrichten zu erleichtern. Sie hat nichts mit der Anfrage-ID zu tun, die in der Antwort von einem gefunden wurde. AWS-Service
## Optimieren Sie Ihre Protokollierungsstufen
Wenn Sie eine Kiste verwenden, die eine Umgebungsfilterung unterstützt, können Sie z. `tracing_subscriber` B. die Ausführlichkeit der Protokolle nach Modulen steuern.
Sie können für jedes Modul dieselbe Protokollierungsebene aktivieren. Im Folgenden wird die Protokollierungsebene `trace` für jedes Modul auf festgelegt:
```
$ RUST_LOG=trace cargo run
```
Sie können die Protokollierung auf Trace-Ebene für ein bestimmtes Modul aktivieren. Im folgenden Beispiel werden auf Ebene nur Logs von `aws_smithy_runtime` eintreffen`trace`.
```
$ RUST_LOG=aws_smithy_runtime=trace
```
Sie können für mehrere Module eine andere Protokollebene angeben, indem Sie sie durch Kommas trennen. Im folgenden Beispiel wird das `aws_config` Modul auf `trace` Level-Logging und das `aws_smithy_runtime` Modul auf `debug` Level-Logging gesetzt.
```
$ RUST_LOG=aws_config=trace,aws_smithy_runtime=debug cargo run
```
In der folgenden Tabelle werden einige der Module beschrieben, die Sie zum Filtern von Protokollnachrichten verwenden können:
| Präfix | Beschreibung |
| --- | --- |
| `aws_smithy_runtime` | Kabelprotokollierung von Anfragen und Antworten |
| `aws_config` | Anmeldeinformationen werden geladen |
| `aws_sigv4` | Signierung von Anfragen und kanonische Anfragen |
Eine Möglichkeit, herauszufinden, welche Module Sie in Ihre Protokollausgabe aufnehmen müssen, besteht darin, zuerst alles zu protokollieren und dann den Crate-Namen für die benötigten Informationen in der Protokollausgabe zu suchen. Dann können Sie die Umgebungsvariable entsprechend setzen und Ihr Programm erneut ausführen.
# Konfiguration von Client-Endpunkten in der AWS SDK für Rust
Wenn der AWS SDK für Rust Anruf erfolgt AWS-Service, besteht einer der ersten Schritte darin, zu bestimmen, wohin die Anfrage weitergeleitet werden soll. Dieser Vorgang wird als Endpunktauflösung bezeichnet.
Sie können die Endpunktauflösung für das SDK konfigurieren, wenn Sie einen Service-Client erstellen. Die Standardkonfiguration für die Endpunktauflösung ist normalerweise in Ordnung, aber es gibt mehrere Gründe, warum Sie die Standardkonfiguration möglicherweise ändern möchten. Zwei Beispielgründe lauten wie folgt:
+ Um Anfragen an eine Vorabversion eines Dienstes oder an eine lokale Bereitstellung eines Dienstes zu stellen.
+ Um auf bestimmte Servicefunktionen zuzugreifen, die noch nicht im SDK modelliert wurden.
**Warnung**
Die Endpunktauflösung ist ein SDK-Thema für Fortgeschrittene. Wenn Sie die Standardeinstellungen ändern, riskieren Sie, dass Ihr Code beschädigt wird. Die Standardeinstellungen gelten für die meisten Benutzer in Produktionsumgebungen.
Benutzerdefinierte Endpunkte können global festgelegt werden, sodass sie für alle Serviceanfragen verwendet werden, oder Sie können einen benutzerdefinierten Endpunkt für einen bestimmten AWS-Service Endpunkt festlegen.
Benutzerdefinierte Endpunkte können mithilfe von Umgebungsvariablen oder Einstellungen in der gemeinsam genutzten AWS `config` Datei konfiguriert werden. Informationen zu diesem Ansatz finden Sie unter [Dienstspezifische Endpunkte](https://docs.aws.amazon.com/sdkref/latest/guide/feature-ss-endpoints.html) im Referenzhandbuch *AWS SDKs und im Tools-Referenzhandbuch*. Eine vollständige Liste der Einstellungen für gemeinsam genutzte `config` Dateien und Umgebungsvariablen für alle AWS-Services finden Sie unter [Identifikatoren für](https://docs.aws.amazon.com/sdkref/latest/guide/ss-endpoints-table.html) dienstspezifische Endpunkte.
Alternativ kann diese Anpassung auch in Ihrem Code konfiguriert werden, wie in den folgenden Abschnitten gezeigt.
## Benutzerdefinierte Konfiguration
Sie können die Endpunktauflösung eines Service-Clients mit zwei Methoden anpassen, die bei der Erstellung des Clients verfügbar sind:
1. `endpoint_url(url: Into)`
1. `endpoint_resolver(resolver: impl crate::config::endpoint::ResolveEndpoint + `static)`
Sie können beide Eigenschaften festlegen. In den meisten Fällen geben Sie jedoch nur eine an. Für den allgemeinen Gebrauch `endpoint_url` wird es am häufigsten angepasst.
### Endpunkt-URL festlegen
Sie können einen Wert für festlegen`endpoint_url`, um einen „Basis-Hostnamen“ für den Dienst anzugeben. Dieser Wert ist jedoch nicht endgültig, da er als Parameter an die `ResolveEndpoint` Instanz des Clients übergeben wird. Die `ResolveEndpoint` Implementierung kann diesen Wert dann überprüfen und möglicherweise ändern, um den endgültigen Endpunkt zu bestimmen.
### Stellen Sie den Endpunkt-Resolver ein
Die `ResolveEndpoint` Implementierung eines Service-Clients bestimmt den endgültigen aufgelösten Endpunkt, den das SDK für eine bestimmte Anfrage verwendet. Ein Service-Client ruft die `resolve_endpoint` Methode für jede Anfrage auf und verwendet den vom Resolver zurückgegebenen [https://docs.rs/aws-smithy-runtime-api/latest/aws_smithy_runtime_api/client/endpoint/struct.EndpointFuture.html](https://docs.rs/aws-smithy-runtime-api/latest/aws_smithy_runtime_api/client/endpoint/struct.EndpointFuture.html)Wert ohne weitere Änderungen.
Das folgende Beispiel zeigt die Bereitstellung einer benutzerdefinierten Endpoint-Resolver-Implementierung für einen Amazon S3 S3-Client, die pro Phase einen anderen Endpunkt auflöst, z. B. Staging und Produktion:
```
use aws_sdk_s3::config::endpoint::{ResolveEndpoint, EndpointFuture, Params, Endpoint};
#[derive(Debug)]
struct StageResolver { stage: String }
impl ResolveEndpoint for StageResolver {
fn resolve_endpoint(&self, params: &Params) -> EndpointFuture<'_> {
let stage = &self.stage;
EndpointFuture::ready(Ok(Endpoint::builder().url(format!("{stage}.myservice.com")).build()))
}
}
let config = aws_config::defaults(BehaviorVersion::latest())
.load()
.await;
let resolver = StageResolver { stage: std::env::var("STAGE").unwrap() };
let s3_config = aws_sdk_s3::config::Builder::from(&config)
.endpoint_resolver(resolver)
.build();
let s3 = aws_sdk_s3::Client::from_conf(s3_config);
```
**Anmerkung**
Endpoint-Resolver und damit auch das `ResolveEndpoint` Merkmal sind für jeden Service spezifisch und können daher nur in der Service-Client-Konfiguration konfiguriert werden. Die Endpunkt-URL kann dagegen entweder mithilfe einer gemeinsamen Konfiguration (gilt für alle daraus abgeleiteten Dienste) oder für einen bestimmten Dienst konfiguriert werden.
#### ResolveEndpoint Parameter
Die `resolve_endpoint` Methode akzeptiert dienstspezifische Parameter, die Eigenschaften enthalten, die bei der Endpunktauflösung verwendet werden.
Jeder Dienst umfasst die folgenden Basiseigenschaften:
| Name | Typ | Description |
| --- | --- | --- |
| region | Zeichenfolge | Die des Kunden AWS-Region |
| endpoint | Zeichenfolge | Eine Zeichenkettendarstellung des Wertesatzes von endpointUrl |
| use\$1fips | Boolesch | Ob FIPS-Endpunkte in der Konfiguration des Clients aktiviert sind |
| use\$1dual\$1stack | Boolesch | Ob Dual-Stack-Endpunkte in der Konfiguration des Clients aktiviert sind |
AWS-Services kann zusätzliche Eigenschaften angeben, die für die Auflösung erforderlich sind. Zu den Amazon S3 [S3-Endpunktparametern](https://docs.rs/aws-sdk-s3/latest/aws_sdk_s3/config/endpoint/struct.Params.html) gehören beispielsweise der Bucket-Name und mehrere Amazon S3-spezifische Funktionseinstellungen. Die `force_path_style` Eigenschaft bestimmt beispielsweise, ob die virtuelle Host-Adressierung verwendet werden kann.
Wenn Sie Ihren eigenen Anbieter implementieren, sollten Sie keine eigene Instanz von Endpunktparametern erstellen müssen. Das SDK stellt die Eigenschaften für jede Anfrage bereit und übergibt sie an Ihre Implementierung von`resolve_endpoint`.
### Vergleichen Sie das Verwenden mit `endpoint_url` dem Verwenden `endpoint_resolver`
Es ist wichtig zu verstehen, dass die folgenden beiden Konfigurationen, die eine verwendet `endpoint_url` und die andere, die verwendet`endpoint_resolver`, NICHT zu Clients mit gleichwertigem Verhalten bei der Endpunktauflösung führen.
```
use aws_sdk_s3::config::endpoint::{ResolveEndpoint, EndpointFuture, Params, Endpoint};
#[derive(Debug, Default)]
struct CustomResolver;
impl ResolveEndpoint for CustomResolver {
fn resolve_endpoint(&self, _params: &Params) -> EndpointFuture<'_> {
EndpointFuture::ready(Ok(Endpoint::builder().url("https://endpoint.example").build()))
}
}
let config = aws_config::defaults(BehaviorVersion::latest())
.load()
.await;
// use endpoint url
aws_sdk_s3::config::Builder::from(&config)
.endpoint_url("https://endpoint.example")
.build();
// Use endpoint resolver
aws_sdk_s3::config::Builder::from(&config)
.endpoint_resolver(CustomResolver::default())
.build();
```
Der Client, der das `endpoint_url` festlegt, gibt eine *Basis-URL* an, die an den (Standard-) Anbieter übergeben wird und im Rahmen der Endpunktauflösung geändert werden kann.
Der Client, der das festlegt, `endpoint_resolver` gibt die *endgültige* URL an, die der Amazon S3 S3-Client verwendet.
## Beispiele
Benutzerdefinierte Endpunkte werden häufig zum Testen verwendet. Anstatt Anrufe an den cloudbasierten Dienst zu tätigen, werden Anrufe an einen lokal gehosteten, simulierten Dienst weitergeleitet. Zwei dieser Optionen sind:
+ [DynamoDB local](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html) — eine lokale Version des Amazon DynamoDB-Service.
+ [LocalStack](https://github.com/localstack/localstack)— ein Cloud-Service-Emulator, der in einem Container auf Ihrem lokalen Computer ausgeführt wird.
Die folgenden Beispiele veranschaulichen zwei verschiedene Möglichkeiten, einen benutzerdefinierten Endpunkt anzugeben, um diese beiden Testoptionen zu verwenden.
### DynamoDB local direkt im Code verwenden
Wie in den vorherigen Abschnitten beschrieben, können Sie `endpoint_url` direkt im Code festlegen, dass der Basisendpunkt so überschrieben wird, dass er auf den lokalen DynamoDB-Server verweist. In Ihrem Code:
```
let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
.test_credentials()
// DynamoDB run locally uses port 8000 by default.
.endpoint_url("http://localhost:8000")
.load()
.await;
let dynamodb_local_config = aws_sdk_dynamodb::config::Builder::from(&config).build();
let client = aws_sdk_dynamodb::Client::from_conf(dynamodb_local_config);
```
Das [vollständige Beispiel](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/dynamodb/src/bin/list-tables-local.rs) ist verfügbar unter GitHub.
### LocalStack Verwenden Sie die `config` Datei
Sie können [dienstspezifische Endpunkte](https://docs.aws.amazon.com/sdkref/latest/guide/feature-ss-endpoints.html) in Ihrer gemeinsam genutzten AWS `config` Datei festlegen. Das folgende Konfigurationsprofil legt fest, `endpoint_url` dass eine Verbindung zu einem Port hergestellt werden soll`localhost`. `4566` Weitere Informationen zur LocalStack Konfiguration finden Sie unter [Zugriff LocalStack über die Endpunkt-URL](https://docs.localstack.cloud/references/network-troubleshooting/endpoint-url/) auf der *LocalStackDocs-Website*.
```
[profile localstack]
region=us-east-1
endpoint_url = http://localhost:4566
```
Das SDK nimmt die Änderungen in der gemeinsam genutzten `config` Datei auf und wendet sie auf Ihre SDK-Clients an, wenn Sie das `localstack` Profil verwenden. Bei diesem Ansatz muss Ihr Code keinen Verweis auf Endpunkte enthalten und würde wie folgt aussehen:
```
// set the environment variable `AWS_PROFILE=localstack` when running
// the application to source `endpoint_url` and point the SDK at the
// localstack instance
let config = aws_config::defaults(BehaviorVersion::latest()).load().await;
let s3_config = aws_sdk_s3::config::Builder::from(&config)
.force_path_style(true)
.build();
let s3 = aws_sdk_s3::Client::from_conf(s3_config);
```
Das [vollständige Beispiel](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/localstack) ist verfügbar unter GitHub.
# Überschreiben einer einzelnen Betriebskonfiguration eines Clients im AWS SDK für Rust
Nachdem Sie [einen Service-Client erstellt](config-code.md) haben, wird die Konfiguration unveränderlich und gilt für alle nachfolgenden Operationen. Die Konfiguration kann zu diesem Zeitpunkt zwar nicht geändert werden, sie kann jedoch für jeden Vorgang außer Kraft gesetzt werden.
Für jeden Operation Builder steht eine `customize` Methode zur Verfügung, mit der `CustomizableOperation` Sie eine einzelne Kopie der vorhandenen Konfiguration überschreiben können. Die ursprüngliche Client-Konfiguration bleibt unverändert.
Das folgende Beispiel zeigt die Erstellung eines Amazon S3 S3-Clients, der zwei Operationen aufruft, von denen der zweite überschrieben wird, um an einen anderen zu senden. AWS-Region Alle Objektaufrufe von Amazon S3 verwenden die `us-east-1` Region, außer wenn der API-Aufruf explizit überschrieben wird, um das geänderte Objekt zu verwenden. `us-west-2`
```
use aws_config::{BehaviorVersion, Region};
let config = aws_config::defaults(BehaviorVersion::latest())
.region("us-east-1")
.load()
.await;
let s3 = aws_sdk_s3::Client::new(&config);
// Request will be sent to "us-east-1"
s3.list_buckets()
.send()
.await?;
// Unset fields default to using the original config value
let modified = aws_sdk_s3::Config::builder()
.region(Region::from_static("us-west-2"));
// Request will be sent to "us-west-2"
s3.list_buckets()
// Creates a CustomizableOperation
.customize()
.config_override(modified)
.send()
.await?;
```
**Anmerkung**
Das vorherige Beispiel bezieht sich auf Amazon S3, das Konzept ist jedoch für alle Operationen dasselbe. Für bestimmte Operationen sind möglicherweise zusätzliche Methoden aktiviert`CustomizeableOperation`.
Ein Beispiel für das Hinzufügen eines Interceptors, der `customize` für eine einzelne Operation verwendet wird, finden Sie unter. [Interceptor nur für eine bestimmte Operation](interceptors.md#interceptors-registration-specific)
# Konfiguration von Einstellungen auf HTTP-Ebene im AWS SDK für Rust
Das AWS SDK für Rust bietet integrierte HTTP-Funktionalität, die von den AWS-Service Clients verwendet wird, die Sie in Ihrem Code erstellen.
Standardmäßig verwendet das SDK für Rust einen HTTPS-Client`hyper`, der auf`rustls`, und basiert`aws-lc-rs`. Dieser Client sollte für die meisten Anwendungsfälle ohne zusätzliche Konfiguration gut funktionieren.
+ [https://docs.rs/hyper/latest/hyper/](https://docs.rs/hyper/latest/hyper/)ist eine HTTP-Bibliothek auf niedrigerer Ebene für Rust, die zusammen mit der verwendet werden kann, AWS SDK für Rust um API-Dienstaufrufe zu tätigen.
+ [https://github.com/rustls/rustls](https://github.com/rustls/rustls)ist eine moderne, in Rust geschriebene TLS-Bibliothek mit integrierten Optionen für kryptografische Anbieter.
+ [https://github.com/aws/aws-lc](https://github.com/aws/aws-lc)ist eine kryptografische Bibliothek für allgemeine Zwecke, die Algorithmen enthält, die für TLS und gängige Anwendungen benötigt werden.
+ [https://github.com/aws/aws-lc-rs](https://github.com/aws/aws-lc-rs)ist ein idiomatischer Wrapper rund um die Bibliothek in Rust. `aws-lc`
Die `aws-smithy-http-client` Kiste bietet einige zusätzliche Optionen und Konfigurationen, falls Sie einen anderen TLS- oder Kryptografieanbieter wählen möchten. Für fortgeschrittenere Anwendungsfälle empfehlen wir Ihnen, Ihre eigene HTTP-Client-Implementierung mitzubringen oder eine Funktionsanfrage zur Prüfung einzureichen.
## Wählen Sie einen alternativen TLS-Anbieter
Die `aws-smithy-http-client` Kiste bietet einige alternative TLS-Anbieter.
Die folgenden Anbieter sind verfügbar:
**`rustls` mit `aws-lc`**
Ein TLS-Anbieter [https://github.com/rustls/rustls](https://github.com/rustls/rustls), der auf diesem basiert und [https://github.com/aws/aws-lc-rs](https://github.com/aws/aws-lc-rs)für die Kryptografie verwendet wird.
Dies ist das standardmäßige HTTP-Verhalten für das SDK für Rust. Wenn Sie diese Option verwenden möchten, müssen Sie in Ihrem Code keine zusätzlichen Maßnahmen ergreifen.
**`s2n-tls`**
Ein TLS-Anbieter, der auf basiert [https://github.com/aws/s2n-tls](https://github.com/aws/s2n-tls).
**`rustls` mit `aws-lc-fips`**
Ein darauf [https://github.com/rustls/rustls](https://github.com/rustls/rustls)basierender TLS-Anbieter verwendet eine FIPS-konforme Version von für die Kryptografie [https://github.com/aws/aws-lc-rs](https://github.com/aws/aws-lc-rs)
**`rustls` mit `ring`**
Ein darauf basierender TLS-Anbieter für Kryptografie [https://github.com/rustls/rustls](https://github.com/rustls/rustls). [https://github.com/briansmith/ring](https://github.com/briansmith/ring)
### Voraussetzungen
Zum Erstellen wird ein C-Compiler (Clang oder GCC) verwendet `aws-lc-rs` oder `s2n-tls` benötigt. Für einige Plattformen erfordert der Build möglicherweise auch. CMake Für das Bauen mit der „FIPS“ -Funktion auf einer beliebigen Plattform ist Go erforderlich CMake . Weitere Informationen finden Sie im [AWS-Repository Libcrypto for Rust (`aws-lc-rs`)](https://github.com/aws/aws-lc-rs/blob/main/aws-lc-rs/README.md) und in den Build-Anweisungen.
### Wie verwende ich einen alternativen TLS-Anbieter
Die `aws-smithy-http-client` Kiste bietet zusätzliche TLS-Optionen. Damit Ihre AWS-Service Kunden einen anderen TLS-Anbieter verwenden können, müssen Sie die `http_client` Verwendung des Loaders aus der `aws_config` Kiste außer Kraft setzen. Der HTTP-Client wird sowohl für Anbieter als auch AWS-Services für Anbieter von Anmeldeinformationen verwendet.
Das folgende Beispiel zeigt, wie der `s2n-tls` TLS-Anbieter verwendet wird. Ein ähnlicher Ansatz funktioniert jedoch auch für andere Anbieter.
Um den Beispielcode zu kompilieren, führen Sie den folgenden Befehl aus, um Ihrem Projekt Abhängigkeiten hinzuzufügen:
```
cargo add aws-smithy-http-client -F s2n-tls
```
Beispiel-Code:
```
use aws_smithy_http_client::{tls, Builder};
#[tokio::main]
async fn main() {
let http_client = Builder::new()
.tls_provider(tls::Provider::S2nTls)
.build_https();
let sdk_config = aws_config::defaults(
aws_config::BehaviorVersion::latest()
)
.http_client(http_client)
.load()
.await;
// create client(s) using sdk_config
// e.g. aws_sdk_s3::Client::new(&sdk_config);
}
```
## FIPS-Unterstützung aktivieren
Die `aws-smithy-http-client` Kiste bietet eine Option, um eine FIPS-konforme Kryptoimplementierung zu aktivieren. Damit Ihre AWS-Service Kunden den FIPS-konformen Anbieter verwenden können, müssen Sie die Verwendung des Loaders aus der `http_client` Kiste außer Kraft setzen. `aws_config` Der HTTP-Client wird sowohl für Anbieter von Anmeldeinformationen als auch AWS-Services für Anbieter von Anmeldeinformationen verwendet.
**Anmerkung**
Die FIPS-Unterstützung erfordert zusätzliche Abhängigkeiten in Ihrer Build-Umgebung. Weitere Informationen finden Sie in den [Bauanweisungen](https://github.com/aws/aws-lc/blob/main/BUILDING.md) für die `aws-lc` Kiste.
Um den Beispielcode zu kompilieren, führen Sie den folgenden Befehl aus, um Ihrem Projekt Abhängigkeiten hinzuzufügen:
```
cargo add aws-smithy-http-client -F rustls-aws-lc-fips
```
Der folgende Beispielcode aktiviert die FIPS-Unterstützung:
```
// file: main.rs
use aws_smithy_http_client::{
tls::{self, rustls_provider::CryptoMode},
Builder,
};
#[tokio::main]
async fn main() {
let http_client = Builder::new()
.tls_provider(tls::Provider::Rustls(CryptoMode::AwsLcFips))
.build_https();
let sdk_config = aws_config::defaults(
aws_config::BehaviorVersion::latest()
)
.http_client(http_client)
.load()
.await;
// create client(s) using sdk_config
// e.g. aws_sdk_s3::Client::new(&sdk_config);
}
```
## Priorisierung des Schlüsselaustauschs nach dem Quantum-Verfahren
Der Standard-TLS-Anbieter basiert auf der `rustls` Verwendung`aws-lc-rs`, der den Algorithmus für den Schlüsselaustausch `X25519MLKEM768` nach dem Quantenaustausch unterstützt. Um `X25519MLKEM768` den Algorithmus mit der höchsten Priorität zu erstellen, müssen Sie das `rustls` Paket zu Ihrer Kiste hinzufügen und das `prefer-post-quantum` Feature-Flag aktivieren. Andernfalls ist es verfügbar, hat aber nicht die höchste Priorität. Weitere Informationen finden Sie in der `rustls` [Dokumentation](https://docs.rs/rustls/0.23.23/rustls/manual/_05_defaults/index.html#about-the-post-quantum-secure-key-exchange-x25519mlkem768).
**Anmerkung**
Dies wird in einer future Version die Standardeinstellung sein.
## Den DNS-Resolver überschreiben
Der Standard-DNS-Resolver kann außer Kraft gesetzt werden, indem der HTTP-Client manuell konfiguriert wird.
Um den Beispielcode zu kompilieren, führen Sie die folgenden Befehle aus, um Ihrem Projekt Abhängigkeiten hinzuzufügen:
```
cargo add aws-smithy-http-client -F rustls-aws-lc
cargo add aws-smithy-runtime-api -F client
```
Der folgende Beispielcode überschreibt den DNS-Resolver:
```
use aws_smithy_http_client::{
tls::{self, rustls_provider::CryptoMode},
Builder
};
use aws_smithy_runtime_api::client::dns::{DnsFuture, ResolveDns};
use std::net::{IpAddr, Ipv4Addr};
/// A DNS resolver that returns a static IP address (127.0.0.1)
#[derive(Debug, Clone)]
struct StaticResolver;
impl ResolveDns for StaticResolver {
fn resolve_dns<'a>(&'a self, _name: &'a str) -> DnsFuture<'a> {
DnsFuture::ready(Ok(vec![IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1))]))
}
}
#[tokio::main]
async fn main() {
let http_client = Builder::new()
.tls_provider(tls::Provider::Rustls(CryptoMode::AwsLc))
.build_with_resolver(StaticResolver);
let sdk_config = aws_config::defaults(
aws_config::BehaviorVersion::latest()
)
.http_client(http_client)
.load()
.await;
// create client(s) using sdk_config
// e.g. aws_sdk_s3::Client::new(&sdk_config);
}
```
**Anmerkung**
Standardmäßig speichert Amazon Linux 2023 (AL2023) DNS nicht auf Betriebssystemebene.
## Anpassen von Root-CA-Zertifikaten
Standardmäßig lädt der TLS-Anbieter die systemeigenen Stammzertifikate für die angegebene Plattform. Um dieses Verhalten beim Laden eines benutzerdefinierten CA-Bundles anzupassen, können Sie ein `TlsContext` mit Ihrem eigenen konfigurieren`TrustStore`.
Um den Beispielcode zu kompilieren, führen Sie die folgenden Befehle aus, um Ihrem Projekt Abhängigkeiten hinzuzufügen:
```
cargo add aws-smithy-http-client -F rustls-aws-lc
```
Das folgende Beispiel verwendet `rustls` with`aws-lc`, funktioniert aber auch für jeden unterstützten TLS-Anbieter:
```
use aws_smithy_http_client::{
tls::{self, rustls_provider::CryptoMode},
Builder
};
use std::fs;
/// read the PEM encoded root CA (bundle) and return a custom TLS context
fn tls_context_from_pem(filename: &str) -> tls::TlsContext {
let pem_contents = fs::read(filename).unwrap();
// Create a new empty trust store (this will not load platform native certificates)
let trust_store = tls::TrustStore::empty()
.with_pem_certificate(pem_contents.as_slice());
tls::TlsContext::builder()
.with_trust_store(trust_store)
.build()
.expect("valid TLS config")
}
#[tokio::main]
async fn main() {
let http_client = Builder::new()
.tls_provider(tls::Provider::Rustls(CryptoMode::AwsLc))
.tls_context(tls_context_from_pem("my-custom-ca.pem"))
.build_https();
let sdk_config = aws_config::defaults(
aws_config::BehaviorVersion::latest()
)
.http_client(http_client)
.load()
.await;
// create client(s) using sdk_config
// e.g. aws_sdk_s3::Client::new(&sdk_config);
}
```
# Konfiguration von Interceptoren im AWS SDK für Rust
Sie können Interzeptoren verwenden, um sich an der Ausführung von API-Anfragen und -Antworten zu orientieren. 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, Fehler anzeigen und vieles mehr.
Das folgende Beispiel zeigt einen einfachen Interceptor, der allen ausgehenden Anfragen einen zusätzlichen Header hinzufügt, bevor die Wiederholungsschleife aufgerufen wird:
```
use std::borrow::Cow;
use aws_smithy_runtime_api::client::interceptors::{
Intercept,
context::BeforeTransmitInterceptorContextMut,
};
use aws_smithy_runtime_api::client::runtime_components::RuntimeComponents;
use aws_smithy_types::config_bag::ConfigBag;
use aws_smithy_runtime_api::box_error::BoxError;
#[derive(Debug)]
struct AddHeaderInterceptor {
key: Cow<'static, str>,
value: Cow<'static, str>,
}
impl AddHeaderInterceptor {
fn new(key: &'static str, value: &'static str) -> Self {
Self {
key: Cow::Borrowed(key),
value: Cow::Borrowed(value),
}
}
}
impl Intercept for AddHeaderInterceptor {
fn name(&self) -> &'static str {
"AddHeader"
}
fn modify_before_retry_loop(
&self,
context: &mut BeforeTransmitInterceptorContextMut<'_>,
_runtime_components: &RuntimeComponents,
_cfg: &mut ConfigBag,
) -> Result<(), BoxError> {
let headers = context.request_mut().headers_mut();
headers.insert(self.key.clone(), self.value.clone());
Ok(())
}
}
```
[Weitere Informationen und die verfügbaren Interceptor-Hooks finden Sie im Trait Intercept.](https://docs.rs/aws-smithy-runtime-api/latest/aws_smithy_runtime_api/client/interceptors/trait.Intercept.html)
## 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 ist unterschiedlich, je nachdem, ob Sie möchten, dass der Interceptor für alle Operationen Ihres Clients oder nur für bestimmte Operationen gilt.
### Interceptor für alle Operationen auf einem Service-Client
Um einen Interceptor für den gesamten Client zu registrieren, fügen Sie den Interceptor mithilfe des Musters hinzu. `Builder`
```
let config = aws_config::defaults(BehaviorVersion::latest())
.load()
.await;
// All service operations invoked using 's3' will have the header added.
let s3_conf = aws_sdk_s3::config::Builder::from(&config)
.interceptor(AddHeaderInterceptor::new("x-foo-version", "2.7"))
.build();
let s3 = aws_sdk_s3::Client::from_conf(s3_conf);
```
### Interceptor nur für eine bestimmte Operation
Um einen Interceptor nur für einen einzigen Vorgang zu registrieren, verwenden Sie die Erweiterung. `customize` Mit dieser Methode können Sie Ihre Service-Client-Konfigurationen auf der Ebene der einzelnen Operationen überschreiben. Weitere Informationen zu anpassbaren Vorgängen finden Sie unter[Überschreiben einer einzelnen Betriebskonfiguration eines Clients im AWS SDK für Rust](peroperation.md).
```
// Only the list_buckets operation will have the header added.
s3.list_buckets()
.customize()
.interceptor(AddHeaderInterceptor::new("x-bar-version", "3.7"))
.send()
.await?;
```