AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

正解

A. AWS KMS への API 呼び出しレートを下げ、指数バックオフとリトライのロジックを実装する

AWS KMS には API ごとに1秒あたりのリクエストレートクォータがあり、これを超えると ThrottlingException が返る。AWS がスロットリング時の対処として公式に推奨しているのが、呼び出しレートの抑制と、指数バックオフ＋ジッターを伴うリトライの実装。
即座に等間隔でリトライすると輻輳がさらに悪化するが、間隔を指数的に広げることで一時的なスロットリングを吸収し、処理を失敗させずに完了できる。
AWS SDK にも標準のリトライ機構があり、設定で強化できる。正解の1つ。

正解

B. AWS Encryption SDK のデータキーキャッシング機能を利用し、AWS KMS への呼び出し回数を削減する

AWS Encryption SDK のデータキーキャッシングは、GenerateDataKey で取得したデータキーを一定時間・一定メッセージ数・一定バイト数の範囲でローカルに再利用する仕組み。
これにより暗号化のたびに KMS を呼び出す必要がなくなり、KMS への API 呼び出し回数を桁違いに削減できる。エンベロープ暗号化の考え方そのもので、スロットリングの根本原因（呼び出し回数の多さ）を直接取り除く。
キャッシュの上限（有効期間・使用回数）を設定してセキュリティとのバランスを取れる点も実務的。正解の1つ。

C. AWS CloudTrail のログを Amazon CloudWatch Logs に送信し、KMS 呼び出しの傾向を可視化する

CloudTrail のログを CloudWatch Logs に送れば、どの API がどれだけ呼ばれているかを可視化・分析でき、原因調査には役立つ。
しかしそれは現状を観測しているだけであり、KMS への呼び出し回数もレートも1件たりとも減らない。
ThrottlingException の発生を防ぐ・解消する直接の対策ではないため、「最も効果的な解決策」を問う本問では誤り。

D. Lambda 関数に割り当てる同時実行数の上限を引き上げ、処理スループットを向上させる

Lambda の同時実行数を引き上げると、同時に KMS を呼び出す実行環境が増えるため、単位時間あたりのリクエストレートはさらに上昇する。
結果として ThrottlingException は減るどころか悪化する。スループット不足ではなく KMS 側のレートクォータ超過が原因である点を取り違えた選択肢。
典型的な「症状と逆向きの対処」であり、明確な誤り。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
KMS が ThrottlingException を返している	原因はKMS の API リクエストレートクォータ超過。対策は「呼び出しを減らす」か「うまく再試行する」の2方向 →選択肢（A・B）は候補
スロットリング発生時の AWS 推奨の作法	指数バックオフ＋リトライで一時的なスロットリングを吸収する →選択肢（A）が正解
呼び出し回数そのものを根本的に減らしたい	AWS Encryption SDK のデータキーキャッシングでデータキーを再利用し、GenerateDataKey の回数を削減 →選択肢（B）が正解
「問題を解決する」対応であること（観測ではなく解消）	CloudTrail の可視化は調査には有用だが、呼び出し回数は減らない →選択肢（C）を消す
同時実行数を増やせばスループットは上がるか	並列度を上げるとKMS への同時呼び出しが増えてスロットリングが悪化する →選択肢（D）を消す

ひっかけポイント

• 選択肢 D の「同時実行数を引き上げてスループット向上」は Lambda 問題の常套句だが、本問ではボトルネックが Lambda ではなく KMS 側のレートクォータ。増やすほど悪化する逆効果の対処
• 選択肢 C の CloudTrail → CloudWatch Logs は「正しいこと」を言っているため選びたくなるが、可視化＝解決ではない。設問が「解決するために取るべき対応」である点を読む
• データキーキャッシングはAWS Encryption SDK の機能であって、KMS 本体の設定ではない。「キャッシュでコールを減らす＝エンベロープ暗号化」の発想を押さえる
• キャッシングは同じデータキーを再利用する以上、セキュリティとのトレードオフがある。有効期間・使用回数・バイト数の上限を設定して制御する点まで問われることがある

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「スロットリングではなく、大量データを直接 KMS で暗号化しようとして失敗している（4KB 超）」	エンベロープ暗号化（GenerateDataKey でデータキーを取得しローカルで暗号化）が正解軸に。
「レートクォータ自体を引き上げたい」	Service Quotas からの引き上げ申請が選択肢に登場する（ただし設計改善が先）。
「キーのローテーションや管理の運用負荷を下げたい」	KMS の自動キーローテーションが論点に変わる。
「DynamoDB や S3 に保存するデータを暗号化したい（アプリ側の呼び出しを増やしたくない）」	サービス側の保管時暗号化（SSE-KMS など）の利用が正解軸に。
「Lambda が DynamoDB や S3 でスロットリングしている」	対象サービスは変わっても指数バックオフ＋リトライ、呼び出し削減（キャッシュ・バッチ化）という解法の型は同じ。

関連サービスの解説

AWS Key Management Service (AWS KMS)