翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 再試行動作
<a name="feature-retry-behavior"></a>

**重要**  
このページで説明されている動作では、デフォルトの動作になるまでオプトインする必要があります。環境`AWS_NEW_RETRIES_2026=true`内で を設定します。この設定がない場合、SDK は 2026 年以前の再試行動作を使用します。これはバックオフタイミング、再試行クォータコスト、サービス固有のデフォルトが異なります。詳細については、[お知らせブログ記事](https://aws.amazon.com/blogs/developer/announcing-updated-retry-behavior-for-aws-sdks-and-tools/)を参照してください。

一時的なエラーまたはスロットリングが原因で へのリクエストが AWS のサービス 失敗した場合、SDK は自動的にリクエストを再試行できます。このページでは、再試行の設定方法と内部での仕組みについて説明します。
+ [再試行の設定](#configuring-retries): 再試行モードを選択し、最大試行回数を設定し、設定の優先順位を理解します。
+ [再試行の仕組み](#how-retries-work): 再試行フロー、エラー分類、バックオフ式、再試行クォータメカニズム、サービス固有の動作。

## 再試行の設定
<a name="configuring-retries"></a>

SDK が使用する再試行戦略と再試行回数を制御します。

### 再試行モードの選択
<a name="choosing-a-retry-mode"></a>

再試行モードは、リクエストが失敗した場合の SDK の動作を決定します。**標準**、ア**ダプティブ**、**レガシー**の 3 つのモードを使用できます。


|  | 標準 | アダプティブ | Legacy | 
| --- | --- | --- | --- | 
| クォータを再試行する | はい  | はい | SDK によって異なる | 
| 初期リクエストを遅らせる可能性がある | いいえ | はい | いいえ | 
| Error-type-specificバックオフ | はい  | はい | SDK によって異なる | 
| SDKs間で標準化 | はい  | はい | いいえ | 
| 推奨事項 | すべてのワークロードのデフォルト | 単一リソース、スロットリングが多い、レイテンシー耐性 | 下位互換性のみ | 

#### 標準モード (デフォルト)
<a name="standard-mode"></a>

標準モードでは、ジッターを使用したエクスポネンシャルバックオフを使用して、失敗したリクエストを再試行します。一時的なエラー (ネットワークタイムアウトなど) には短い遅延を使用し、スロットリングエラー ( など) には長い遅延を使用します`ThrottlingException`。

標準モードには、**再試行クォータ**、再試行ごとにトークンを差し引き、リクエストが成功したときにトークンを補充するトークンバケットが含まれます。使用可能なトークンを使い果たすと、SDK は再試行せずにエラーを返すため、成功する可能性が低い再試行を待つ代わりに、アプリケーションは迅速に失敗します。これにより、再試行トラフィックを減らすことで、サービスの中断をより迅速に解決できます。通常のオペレーション中、クォータは満杯のままで、効果はありません。再試行クォータは、最初のリクエストを遅延またはブロックしません。再試行のみが影響を受けます。詳細については、「[再試行クォータ (トークンバケット)](#retry-quota-token-bucket)」を参照してください。

別のモードを選択する特定の理由がない限り、標準モードを使用します。

#### アダプティブモード
<a name="adaptive-mode"></a>

アダプティブモードには、標準モードのすべてのものに加えて、**クライアント側のレートリミッター**が含まれます。レートリミッターはスロットリングレスポンスを追跡し、SDK がリクエストを送信するレートを調整します。標準モードとは異なり、アダプティブモードは、スロットリングが検出されたときに再試行だけでなく、*最初の*リクエストを遅延またはブロックする可能性があります。

レートリミッターは SDK クライアントインスタンスごとに動作します。クライアントからのすべてのリクエストは、ターゲットとする API オペレーションまたはリソースに関係なく、同じレート制限を共有します。

**アダプティブモードを使用するタイミング:**
+ クライアントは 1 つのリソース (1 つの DynamoDB テーブルなど) をターゲットとしており、頻繁なスロットリングレスポンスを想定しています。これは、1 つの API オペレーションを大量に呼び出す自動ワークフロー、バッチプロセッサ、または AI ワークロードで一般的です。
+ サービスがスロットリングを通知すると、SDK が自動的に遅くなります。

**アダプティブモードを使用しない場合:**
+ クライアントは複数のリソースにリクエストを送信するか、複数のテナントを処理します。1 つのリソースでスロットリングすると、レートリミッターは、影響を受けていないリソースへのリクエストを含め、そのクライアントからのすべてのリクエストを遅くします。
+ 最初のリクエストには予測可能なレイテンシーが必要です。

アダプティブモードは、一般的なデフォルトとしてお勧めしません。

#### レガシーモード
<a name="legacy-mode"></a>

レガシーモードは、標準モードが導入される前に各 SDK が使用した再試行動作です。標準化された再試行クォータは含まれません。一部の SDKs (Java など) には、レガシーモードで独自の再試行クォータ実装がありますが、動作は SDKs 間で一貫性がありません。標準化されたクォータがない場合、クライアントはサービスの中断中も引き続きフルレートで再試行します。これにより、成功する可能性の低いリクエストのスレッドと接続が結び付けられ、サービスの復旧を遅らせる可能性のある負荷が追加されます。

レガシーモードは SDKsによって異なります。再試行回数、バックオフタイミング、再試行可能なエラーセット、スロットリング動作は言語によって異なります。レガシーの再試行動作に依存するコードは、SDKs 間で移動すると動作が異なる場合があります。

**使用可能:** Java、Python、Ruby、PHP、C\+\+、CLI

.NET、Go、Kotlin、Rust、Swift、JavaScript **では使用できません** 

下位互換性のためにレガシーモードがあります。現在レガシーモードを使用している場合は、標準モードに切り替えます。

### 設定を再試行する
<a name="retry-settings"></a>

以下の設定は再試行動作を制御します。環境[変数](environment-variables.md)、[共有設定ファイル](file-format.md) (`~/.aws/config`)、またはコード内のクライアント設定を使用して設定できます。


| 設定 | コントロールするもの | 環境変数 | Config ファイルキー | デフォルト | 
| --- | --- | --- | --- | --- | 
| 再試行モード | 使用する再試行戦略 | AWS\_RETRY\_MODE | retry\_mode | standard | 
| 最大試行回数 | 最初のリクエストを含む合計試行回数 | AWS\_MAX\_ATTEMPTS | max\_attempts | 3 (注を参照) | 

最大試行値 は、SDK が 1 回の初回リクエストと最大 2 回の再試行を行う`3`ことを意味します。再試行を完全に無効に`1`する最大試行回数を設定します。

**注記**  
DynamoDB および DynamoDB Streams クライアント`4`は、デフォルトで最大試行回数になります。これらのサービスは、低レイテンシープロファイルに合わせて短いベースバックオフ遅延 (50 ミリ秒ではなく 25 ミリ秒) を使用します。追加の試行により、最後の再試行の最大バックオフは他の サービスに相当します。これは、前の表と同じ設定で上書きできます。

### 設定の優先順位
<a name="configuration-precedence"></a>

複数の場所で同じ設定を指定すると、SDK は、最大値から最小値まで、次の優先順位を使用して値を解決します。

1. **コード内の明示的なクライアント設定。**SDK クライアントまたはその設定オブジェクトに直接設定された値。

1. **[環境変数](environment-variables.md)。**例えば、`AWS_RETRY_MODE`、`AWS_MAX_ATTEMPTS` です。

1. **[共有設定ファイル](file-format.md)。**の `retry_mode`または `max_attempts`キー`~/.aws/config`。

1. **SDK のデフォルト。**設定の組み込みデフォルト。

これは、標準の [AWS SDK 設定の優先順位](settings-reference.md)に従います。より高いレベルで設定された値は、常により低いレベルで設定された値を上書きします。たとえば、 を環境変数`AWS_RETRY_MODE=adaptive`として設定し、 `retry_mode=standard`で を設定すると`~/.aws/config`、SDK はアダプティブモードを使用します。

### 言語固有の設定
<a name="language-specific-configuration"></a>

このページで説明されているクロス SDK 設定 (`retry_mode` および `max_attempts`) は、すべての SDKs。ただし、コードで再試行を設定するための API は言語によって異なります。カスタムバックオフ戦略、追加の再試行可能なエラー、再試行クォータの調整などの言語固有の設定オプションについては、 SDK の開発者ガイドを参照してください。

## 再試行の仕組み
<a name="how-retries-work"></a>

このセクションでは AWS SDKs が失敗したリクエストを処理する方法について説明します。再試行をトリガーするエラー、SDK が試行間隔を待機する時間、再試行を停止する時間などです。

### リクエストが失敗するとどうなるか
<a name="what-happens-when-a-request-fails"></a>

 AWS SDK を介して API コールを行うと、SDK は次のシーケンスに従います。

1. ア**[ダプティブモード](#adaptive-mode)のみ:** SDK はクライアント側のレートリミッターをチェックします。スロットリングが検出された場合、SDK はリクエストを送信する前に遅延またはブロックすることがあります。

1. SDK は AWS のサービス エンドポイントにリクエストを送信します。

1. サービスが正常なレスポンスを返した場合、SDK は結果をコードに返します。

1. リクエストが失敗した場合、SDK はエラーを*一時的*、*スロットリング*、または*再試行不可*として分類します。「[再試行されるエラー](#which-errors-are-retried)」を参照してください。

1. エラーが再試行可能でない場合、SDK はすぐにコードにエラーを返します。再試行は試行されません。

1. エラーが再試行可能な場合、SDK は最大試行回数に達したかどうかを確認します。その場合は、コードにエラーを返します。

1. SDK は をチェックします[再試行クォータ (トークンバケット)](#retry-quota-token-bucket)。トークン予算が枯渇した場合、SDK は再試行せず、コードにエラーを返します。例外: の場合[ロングポーリングオペレーション](#long-polling-operations)、SDK はエラーを返す前にバックオフ遅延を適用します。

1. SDK は、エラータイプと再試行回数に基づいてバックオフ遅延を計算します。「[SDK が待機する期間](#how-long-does-the-sdk-wait)」を参照してください。

1. SDK は計算された遅延を待機し、ステップ 2 からリクエストを再送信します。

SDK は、リクエストが成功するか、最大試行回数に達するか、再試行クォータが枯渇するか、再試行不可能なエラーが発生するまで、このループを繰り返します。プロセス全体は自動的に行われます。アプリケーションには、成功したレスポンスまたは最終エラーが表示されます。

### 再試行されるエラー
<a name="which-errors-are-retried"></a>

SDK は、失敗した各リクエストを、一時的、スロットリング、または再試行不可能な 3 つのカテゴリのいずれかに分類します。この分類は、SDK がリクエストを再試行するかどうかと、再試行するまでの待機時間を決定します。

分類は、サービスレスポンスの**エラーコード**と **HTTP ステータスコード**に基づいています。たとえば、エラーコードを持つ HTTP 400 `RequestTimeout`は一時的なものとして分類され、再試行されます。を持つ HTTP 400 `ValidationException`は再試行不可として分類され、すぐに返されます。

#### エラー分類
<a name="error-classification"></a>

**一時的なエラー**は、短い基本遅延 (50 ミリ秒) で再試行されます。


| エラーコード | 
| --- | 
| RequestTimeout | 
| RequestTimeoutException | 
| InternalError | 
| IDPCommunicationError | 
| I/O 障害 (接続リセット、DNS 解決障害、ソケットタイムアウト) | 
| (認識されたエラーコードのない HTTP 500、502、503、または 504) | 

**スロットリングエラー**は、より長い基本遅延 (1,000 ミリ秒) で再試行されます。


| エラーコード | 
| --- | 
| Throttling | 
| ThrottlingException | 
| ThrottledException | 
| RequestThrottledException | 
| TooManyRequestsException | 
| ProvisionedThroughputExceededException | 
| TransactionInProgressException | 
| LimitExceededException | 
| PriorRequestNotComplete | 
| RequestThrottled | 
| EC2ThrottledException | 
| RequestLimitExceeded | 
| SlowDown | 
| BandwidthLimitExceeded | 

**再試行不可能なエラー** (`AccessDeniedException`、、 など`ResourceNotFoundException`) `ValidationException`は、すぐにコードに返されます。

**注記**  
スロットリングエラーコードを持つ HTTP 5XX は、5XX エラーが通常一時的な場合でも、一時的なエラーではなくスロットリングエラーとして分類されます。SDK は最初にエラーコードで一致し、次に HTTP ステータスコードに戻ります。

スロットリングエラーは、レート制限のためにサービスがリクエストをアクティブに拒否したことを意味するため、SDK はサービスを再試行して容量を回復する時間を与えるまでより長く待機します。特定の遅延[SDK が待機する期間](#how-long-does-the-sdk-wait)については、「」を参照してください。

### SDK が待機する期間
<a name="how-long-does-the-sdk-wait"></a>

SDK は**、完全なジッターでエクスポネンシャルバックオフ**を使用します。平均して、各再試行は最後の再試行よりも長く待機し、ランダム化によって複数のクライアントからのリクエストが分散されます。

#### エラータイプ別の基本遅延
<a name="base-delays-by-error-type"></a>

基本遅延は、エラーが一時的かスロットリングかによって異なります。


| エラータイプ | 基本遅延 | 根拠 | 
| --- | --- | --- | 
| 推移的 (非スロットリング) | 50 ミリ秒 | 一時的なエラーは通常、ミリ秒以内に解決されます。短い基本遅延により、迅速な復旧が可能になります。 | 
| スロットリング | 1,000 ミリ秒 | サービスにはリクエストのレート制限があります。基本遅延が長くなると、容量を回復する時間がかかります。 | 

#### バックオフ式
<a name="backoff-formula"></a>

SDK は、次の式を使用して各再試行遅延を計算します。

```
delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)
```

説明は以下のとおりです。
+ `random(0, 1)` は 0 から 1 までの均一な分散値を返します
+ `base_delay` は、一時的なエラーの場合は 50 ミリ秒、スロットリングエラーの場合は 1,000 ミリ秒です。
+ `retry` は、最初の再試行 (2 回目のリクエスト全体の試行) では 0 から始まります。

最大バックオフ上限は **20 秒**です。試行回数に関係なく、個々の遅延が 20 秒を超えることはありません。

#### 実例
<a name="worked-examples"></a>

**例 1: 一時的なエラー、最大試行回数 3**


| Step | どうなるのか | Delay | 
| --- | --- | --- | 
| 試行 1 | 初期リクエスト。サービスは HTTP 503 を返します。 | (none) | 
| 試行 2 | SDK は random(0, 50 ms) を待機します。再試行は 503 で失敗します。 | 0～50 ミリ秒 (平均～25 ミリ秒) | 
| 試行 3 | SDK は random(0, 100 ms) を待機します。再試行は成功します。 | 0～100 ミリ秒 (平均～50 ミリ秒) | 

追加されたレイテンシーの合計は、両方の再試行で平均約 75 ミリ秒です。

**例 2: スロットリングエラー、最大試行回数 3**


| Step | どうなるのか | Delay | 
| --- | --- | --- | 
| 試行 1 | 初期リクエスト。サービスは 429 を返しますThrottling。 | (none) | 
| 試行 2 | SDK は random(0, 1,000 ms) を待機します。再試行は 429 を返します。 | 0～1,000 ミリ秒 (平均～500 ミリ秒) | 
| 試行 3 | SDK は random(0, 2,000 ms) を待機します。再試行は成功します。 | 0～2,000 ミリ秒 (平均～1,000 ミリ秒) | 

追加されたレイテンシーの合計は、両方の再試行で平均約 1,500 ミリ秒です。

**例 3: バックオフの上限に達した一時的なエラー**

基本遅延が 50 ミリ秒の場合、キャッピング前の計算遅延は次のようになります。


| 再試行 | 計算された最大遅延 | 上限の 20 秒後 | 
| --- | --- | --- | 
| 1 | 50 ミリ秒 | 50 ミリ秒 | 
| 2 | 100 ミリ秒 | 100 ミリ秒 | 
| 5 | 800 ミリ秒 | 800 ミリ秒 | 
| 9 | 12,800 ミリ秒 | 12,800 ミリ秒 | 
| 10 | 25,600 ミリ秒 | 20,000 ミリ秒 | 

この上限は、一時的なエラーに対して 10 回目の再試行 (11 回目の試行) で有効になります。ベースが 1,000 ミリ秒のスロットリングエラーの場合、上限は 6 回目の再試行時に有効になります。

**注記**  
デフォルトの最大試行回数は 3 回 (最初のリクエスト 1 回 \+ 再試行 2 回) で、バックオフの上限に達することはありません。この表は、デフォルト`max_attempts`を大きく超えるとどうなるかを示しています。

#### ジッターが重要な理由
<a name="why-jitter-matters"></a>

ランダム乗数は*フルジッター*と呼ばれます。これがないと、同時にエラーが発生したすべてのクライアントが同時に再試行し、再試行トラフィックのバースト (「群れの雷」問題) が発生します。フルジッターはバックオフウィンドウ全体に均等に再試行を分散するため、サービスは同期されたスパイクではなくリクエストの安定したトリクルを受け取ります。

たとえば、1,000 のクライアントがすべて同時に 503 を受け取るとします。フルジッターは、1,000 回すべてを正確に 50 ミリ秒で再試行するのではなく、最初の再試行を 50 ミリ秒のウィンドウに均等に分散します。

#### サーバー指向の再試行タイミング
<a name="server-directed-retry-timing"></a>

エラーレスポンスに `x-amz-retry-after`ヘッダー AWS のサービス を含むものもあります。ヘッダー値はミリ秒単位の遅延です。このヘッダーが存在する場合、SDK はサーバー指定の遅延を使用し、計算されたバックオフ遅延の最小値と計算されたバックオフ遅延の最大値に 5,000 ミリ秒を加えた値にクランプします。計算されたバックオフ自体は 20 秒に制限されるため、有効なサーバー指向の最大遅延は 25 秒です。サービスはジッターすることが予想されるため、SDK はこの値にジッターを適用しません。これにより、サービスが容量が利用可能になると予想されるときに正確に通信できるようになります。

### 再試行クォータ (トークンバケット)
<a name="retry-quota-token-bucket"></a>

SDK は、成功したリクエストと失敗の比率を追跡する内部トークン予算を維持します。失敗が広範囲に及ぶと、予算は枯渇し、SDK はエラーを直接返します。成功する可能性が低い再試行を待つ代わりに、アプリケーションは迅速に失敗します。これにより、再試行トラフィックも減り、サービスの中断を迅速に解決できます。

#### 再試行クォータの仕組み
<a name="how-the-retry-quota-works"></a>

トークン予算は満杯で開始されます。再試行するたびにトークンが差し引かれます。再試行が成功すると、SDK はその再試行で消費されたトークンを復元します。最初の試行でリクエストが成功すると (再試行不要）、SDK は 1 トークンを復元します。予算がゼロに達すると、SDK は再試行を停止し、コードに直接エラーを返します。


| パラメータ | 値 | 
| --- | --- | 
| 予算容量 | 500 トークン | 
| 一時的な (非スロットリング) 再試行あたりのコスト | 14 トークン | 
| スロットリング再試行あたりのコスト | 5 トークン | 
| 再試行後に成功時に復元されたトークン | 最後の再試行で消費された量 (14 または 5) | 
| 再試行せずに成功時に復元されたトークン | トークン 1 個 | 

一時的な再試行のコストが高いほど、さまざまな障害パターンが反映されます。500 代などの一時的なエラーや接続の失敗は、多くの場合、サービス全体の問題を示します。このような状況では、継続的な再試行が成功する可能性はほとんどありません。これにより、通話にレイテンシーが追加され、クライアントリソースが結び付けられ、すべてのユーザーの復旧が遅れる可能性があります。スロットリングエラーは、リクエストが成功するまでにサービスにより多くの時間が必要であることを示します。SDK は再試行の間隔を長くして、成功の可能性を向上させます。

#### がクォータブロックを再試行するタイミング
<a name="when-does-the-quota-block-retries"></a>

再試行クォータはトークンを常に追跡しますが、予算が枯渇したときにのみ再試行をブロックします。通常のオペレーションでは、ほぼすべてのリクエストが成功し、予算は満杯のままになります。クォータは再試行に観測可能な影響を与えません。

再試行が成功すると、同じリクエストで以前に失敗した再試行のコストではなく、独自のトークンコスト (14 または 5 トークン) のみが復元されます。たとえば、最初の再試行が失敗し、2 回目の再試行が成功すると、予算は 14 トークン純減します。予算は、再試行が成功せずにすべての試行を枯渇させると速くドレインしますが、リクエストが成功する前に複数回の再試行を必要とすると徐々にドレインします。

デフォルトで最大試行回数が 3 回の場合、リクエストの約 **22%** を超えると一時的な障害が持続し、スロットリングエラーの場合は約 **32%** を超えると、クォータがドレインし始めます。これらのレートを下回ると、成功したリクエストは、失敗した再試行よりも速く予算を補充します。

予算の開始バランスである 500 トークンは、短い障害バーストを吸収するバッファを提供します。エラーが短時間急増しても、バッファをドレインするのに十分な時間持続しない限り、再試行はブロックされません。

#### 実用的な影響
<a name="practical-implications"></a>
+ **低失敗率:** クォータは効果がありません。予算はキャパシティーまたはその近くにとどまります。
+ **サービスの中断中:** リクエストの割合が高いと、クォータは枯渇し、クライアントは再試行を待つ代わりにすぐにエラーを返します。これにより、クライアント側のレイテンシーが短縮され、スレッドと接続が解放され、サービスの復旧が迅速になります。
+ **復旧:** サービスが復旧し、リクエストが再び成功すると、再試行に成功するとトークンのコスト全体が復元され、最初の試行に成功すると 1 トークンが復元されます。予算は徐々に補充され、再試行は自動的に再開されます。
+ **スコープ:** トークン予算は通常、単一の SDK クライアントインスタンスにスコープされます。正確な範囲は SDK によって異なる場合があります。プロセスやホスト間では共有されません。

### サービス固有の動作
<a name="service-specific-behavior"></a>

#### DynamoDB
<a name="dynamodb"></a>

DynamoDB クライアントは、DynamoDB の低レイテンシープロファイル用に最適化されたチューニングされたデフォルトを使用します。


| 設定 | 一般的なデフォルト | DynamoDB のデフォルト | 
| --- | --- | --- | 
| 一時的な (非スロットリング) ベース遅延 | 50 ミリ秒 | 25 ミリ秒 | 
| スロットリングの基本遅延 | 1,000 ミリ秒 | 1,000 ミリ秒 | 
| 最大試行回数 | 3 | 4 | 

これらのデフォルトは、Amazon DynamoDB ストリームと DynamoDB ストリームの両方に適用されます。

#### ロングポーリングオペレーション
<a name="long-polling-operations"></a>

特定の AWS オペレーションでは、ロングポーリングが使用されます。接続を開いたままにして、作業が到着するのを待つことができます。これらのオペレーションは、特別な再試行処理を受け取ります。
+ `SQS.ReceiveMessage`
+ `SFN.GetActivityTask`
+ `SWF.PollForActivityTask`
+ `SWF.PollForDecisionTask`

**特殊な動作:** 再試行クォータが枯渇し、再試行がブロックされた場合 (「」のステップ 7[リクエストが失敗するとどうなるか](#what-happens-when-a-request-fails))、SDK はエラーをコードに返す前にバックオフ遅延を適用します。

これは、ロングポーリングオペレーションは通常、タイトループで呼び出されるため重要です。コードは を呼び出し`ReceiveMessage`、メッセージを処理し、すぐに`ReceiveMessage`再度 を呼び出します。強制バックオフがない場合、トークン予算が枯渇すると、SDK は遅延なくエラーを返すことになります。その後、ポーリングループはすぐに次のリクエストを送信し、クライアントの CPU 使用率をスパイクして、追加のトラフィックを生成します。強制バックオフ遅延はこのサイクルを中断し、障害発生時にクライアントリソースの使用状況とポーリングレートを管理できるようにします。

## AWS SDKsとツールによるサポート
<a name="feature-retry-behavior-sdk-compat"></a>

次の表に、各 SDK で更新された再試行動作の可用性を示します。最小バージョン、before-and-afterデフォルト、コード例など、SDK 固有の詳細については、GitHub 追跡の問題を参照してください。


| SDK | サポート | GitHub の追跡に関する問題 | 
| --- | --- | --- | 
| [SDK for Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/) | はい | [問題の追跡](https://github.com/aws/aws-sdk-java-v2/discussions/6984) | 
| [SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) | はい | [問題の追跡](https://github.com/boto/boto3/discussions/4789) | 
| [SDK for .NET 4.x](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/) | はい | [問題の追跡](https://github.com/aws/aws-sdk-net/issues/4411) | 
| [PowerShell V5 のツール](https://docs.aws.amazon.com/powershell/latest/userguide/) | はい | [問題の追跡](https://github.com/aws/aws-tools-for-powershell/issues/418) | 
| [SDK for JavaScript 3.x](https://docs.aws.amazon.com/sdk-for-javascript/latest/developer-guide/) | はい | [問題の追跡](https://github.com/aws/aws-sdk-js-v3/issues/8037) | 
| [SDK for PHP 3.x](https://docs.aws.amazon.com/sdk-for-php/latest/developer-guide/) | はい | [問題の追跡](https://github.com/aws/aws-sdk-php/discussions/3285) | 
| [SDK for Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin/latest/developer-guide/) | はい | [問題の追跡](https://github.com/aws/aws-sdk-kotlin/discussions/1885) | 
| [SDK for Rust](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/) | はい | [問題の追跡](https://github.com/awslabs/aws-sdk-rust/discussions/1431) | 
| [SDK for Swift](https://docs.aws.amazon.com/sdk-for-swift/latest/developer-guide/) | 「追跡の問題」を参照してください。 | [問題の追跡](https://github.com/awslabs/aws-sdk-swift/discussions/2166) | 
| [SDK for Ruby 3.x](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/) | 「追跡の問題」を参照してください。 | [問題の追跡](https://github.com/aws/aws-sdk-ruby/discussions/3390) | 
| [SDK for Go V2 (1.x)](https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/) | 「追跡の問題」を参照してください。 | [問題の追跡](https://github.com/aws/aws-sdk-go-v2/issues/3416) | 
| [SDK for C\+\+](https://docs.aws.amazon.com/sdk-for-cpp/latest/developer-guide/) | 「追跡の問題」を参照してください。 | [問題の追跡](https://github.com/aws/aws-sdk-cpp/issues/3832) | 
| [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/) v2 | 「追跡の問題」を参照してください。 | [問題の追跡](https://github.com/aws/aws-cli/discussions/10329) |