AWS Certified Developer - Associate (DVA-C02) #6 Domain 1-5 AWS サービスでの開発 — SDK 開発パターン

#2 から #5 まで個別のサービスを見たなら、この記事は それらのサービスをコードで呼び出すときに共通して繰り返されるパターン です。試験は特定のサービスではなく「API を呼び出す正しい方式」を問う問題を継続的に出します。ページネーション、リトライ、冪等性、S3 アップロード、認証情報の供給がその核心です。

ページネーション #

AWS API は一度に返す結果の数に上限があります。ListObjectsV2、Query、Scan、DescribeInstances などは結果が多いと区切って返し、次のページを指すトークン を一緒に渡します。

• 応答に NextToken (または LastEvaluatedKey、IsTruncated + ContinuationToken) があれば結果がさらにあるという意味です。
• そのトークンを次のリクエストに入れて繰り返し呼び出します。
• ほとんどの SDK は ページネーター (paginator) を提供してこの繰り返しを自動化します。

試験の落とし穴: 「結果の一部しか返ってこない」というバグの原因は通常 ページネーションを処理していないこと です。最初のページだけ読んで止まったコードです。

指数バックオフとジッター #

スロットリング (ThrottlingException、ProvisionedThroughputExceededException、429、503) や一時的なエラーは 即座にリトライしてはいけません。同じ瞬間に全員がリトライすると負荷がさらに大きくなります (thundering herd)。

• 指数バックオフ (Exponential Backoff) — リトライ間隔を 1 秒、2 秒、4 秒のように指数的に増やします。
• ジッター (Jitter) — 間隔にランダム性を加えてリトライ時点を分散します。

良い知らせは AWS SDK が指数バックオフ + ジッターのリトライをデフォルトで内蔵 している点です。リトライ回数とモード (legacy/standard/adaptive) を設定で調整できます。「スロットリングにどう対応するか」の答えはほぼ常に 指数バックオフのリトライ であり、自前で実装するのではなく SDK 設定で処理するのが推奨です。

冪等性 #

#2・#5 で見たとおり、非同期・キューベースの配信は 同じリクエストを複数回配信 しうります (at-least-once)。副作用がある作業は冪等にする必要があります。

• 冪等性キー — クライアントがリクエストごとに一意なキー (例: 注文 ID、UUID) を付与し、サーバーはそのキーで重複を識別します。
• 条件付き書き込みで実装 — DynamoDB の attribute_not_exists 条件で「初めて見るキーのときだけ処理」を強制します。
• 一部の AWS API は ClientRequestToken のような冪等性トークンのパラメータを直接サポートします。

S3 開発パターン #

マルチパートアップロード #

大きなオブジェクト (推奨: 100MB 以上、必須: 5GB 超) は マルチパートアップロード で分割してアップロードします。

• パートを 並列アップロード して速度を上げ、失敗したパートだけ再送します。
• 不完全なマルチパートアップロードはストレージコストを発生させるので、ライフサイクルルールで未完了アップロードを整理 するのが推奨です。

presigned URL #

サーバーが一時的な署名付き URL を発行して、クライアントが AWS 認証情報なしで 決まった時間だけ S3 に直接アップロード/ダウンロードできるようにします。

• モバイル・Web クライアントに IAM キーを配布せずに S3 アクセスを与える標準的な方法です。
• URL は発行した主体の権限と有効期限を持ちます。

「ブラウザから S3 に直接大きなファイルをアップロードする必要がある。サーバーを経由せずに。」の答えは presigned URL です。

S3 整合性 #

S3 は現在、新規オブジェクトの PUT と上書き・削除のすべてに強い読み込み後書き込み整合性 を提供します (以前の結果整合性モデルはもはや該当しません)。ただし同じキーを同時に書く場合は最後の書き込みが勝ちます。

SDK の認証情報供給チェーン #

SDK は認証情報を 決まった優先順位 で探します。試験は「コードにキーをハードコードせずにどう認証情報を供給するか」を問います。

1. コードに明示的に渡した認証情報
2. 環境変数 (AWS_ACCESS_KEY_ID など)
3. 共有認証情報ファイル (~/.aws/credentials)
4. IAM Role (EC2 インスタンスプロファイル、ECS タスクロール、Lambda 実行ロール)

本番環境での推奨は IAM Role です。EC2・ECS・Lambda では Role を付けると SDK が一時的な認証情報を自動で取得するので、キーを保存する必要がありません。「EC2 のコードが S3 にアクセスする」の答えが常に Role である理由です。

その他の試験ポイント #

• リージョン・エンドポイント — SDK クライアントはリージョンを指定する必要があります。誤ったリージョンはよくあるバグです。
• CLI --dry-run — 権限だけ確認して実際の実行はしません。
• エラー応答のリクエスト ID — サポート問い合わせ・デバッグ時に x-amz-request-id を添付します。

試験の出題パターン #

• 「リスト API の結果が一部しか来ない。」 → ページネーション未処理。
• 「スロットリングにどう対応するか。」 → 指数バックオフ + ジッター (SDK のデフォルトリトライ)。
• 「キューのメッセージが重複配信されて重複処理される。」 → 冪等性キー + 条件付き書き込み。
• 「ブラウザから S3 に直接アップロード、キー配布なしで。」 → presigned URL。
• 「5GB を超えるファイルを安定してアップロード。」 → マルチパートアップロード。
• 「EC2 のコードにアクセスキーをどう渡すか。」 → IAM Role (保存しない)。
• 「400 InvalidRequest が繰り返される。」 → リトライではなくリクエスト・権限を修正 (4xx はリトライ無意味)。

まとめ #

この記事の要点:

• ページネーション — トークンをたどって繰り返す。最初のページだけ読むコードはバグ
• 指数バックオフ + ジッター — スロットリング/5xx 対応。SDK がデフォルトで内蔵、4xx はリトライ無意味
• 冪等性キー + 条件付き書き込み で at-least-once の重複を防御
• S3 — 大きなファイルは マルチパート、クライアントの直接アクセスは presigned URL
• 認証情報供給チェーン — 本番はキー保存なしの IAM Role

次へ — Domain 2-1 認証と認可 #

開発ドメインを終えました。次は 26% を占めるセキュリティです。#7 認証と認可 では、IAM Role をコード視点で見直し、Cognito User Pool と Identity Pool の役割分担、STS の一時的な認証情報とフェデレーションを見ていきます。