変更要約: in-scopeサービス網羅(軸B): s1(CloudWatch)にAthena/OpenSearch Serviceによる大規模ログ分析の定義・役割・選択基準を追記。
5.3パフォーマンスとコストの最適化
キャッシュ（ElastiCache/DAX/CloudFront）、Lambda のチューニング（メモリ/同時実行/コールドスタート対策）、効率的なデータアクセス（Query/リトライ＋指数バックオフ/ページング）といった最適化手法を理解します。
計測して問題を見つけたら、次は速く・安くします。キャッシュ・コンピュートのチューニング・効率的なデータアクセスが定番の打ち手です。
5.3.1最適化の打ち手
- キャッシュ：ElastiCache/DAX（DynamoDB 前段）や CloudFront（エッジ）で遅延と DB 負荷を削減。
- Lambda のチューニング：メモリ調整で CPU を確保、プロビジョンド同時実行でコールドスタートを抑制。
- 効率的なデータアクセス：Scan ではなく Query、スロットリングには指数バックオフ付きリトライ、大量結果はページング。
「読み取り高速化＝キャッシュ（CloudFront/ElastiCache/DAX）」「コールドスタート対策＝プロビジョンド同時実行」「スロットリング(429/ProvisionedThroughputExceeded)＝指数バックオフでリトライ」「Scan を避け Query」 は DVA で頻出です。
最適化は「計測 → ボトルネック特定 → 打ち手」の順で進めます。読み取りが重いなら キャッシュ で DB 負荷と遅延を下げます。静的コンテンツや API レスポンスは CloudFront（エッジ）、汎用のインメモリは ElastiCache（Redis/Memcached）、DynamoDB 専用なら DAX でマイクロ秒級の読み取りにできます。Lambda はメモリを増やすと比例して CPU も増えるため、メモリ調整が実質的なチューニングになり、適正値は Lambda Power Tuning で探れます。初回の遅延（コールドスタート）は プロビジョンド同時実行 で温めて抑制し、同時実行数は 予約済み同時実行 で上限を管理します。DynamoDB では全件走査の Scan を避けて Query（または GSI）にし、必要な属性だけ射影してコストを下げます。スロットリング（429 / ProvisionedThroughputExceeded）には 指数バックオフ＋ジッター付きリトライ で対応し、大量結果は ページング で分割取得します。
| 課題 | 打ち手 |
|---|---|
| 読み取りが遅い/DB 負荷が高い | キャッシュ（CloudFront/ElastiCache/DAX） |
| Lambda の初回遅延 | プロビジョンド同時実行 |
| DynamoDB のスロットリング | 指数バックオフ＋ジッターでリトライ |
| 全件走査が重い | Scan を避け Query/GSI |
シナリオ：人気商品ページの DynamoDB 読み取りがスロットリング。 前段に DAX を入れて読み取りをマイクロ秒級にしDB 負荷を削減。アクセスは Scan ではなく Query（パーティションキー指定）に直し、SDK の 指数バックオフ＋ジッターでスパイクを吸収。さらに静的アセットは CloudFront に載せてオリジン負荷も下げます。
Q. DynamoDB をマイクロ秒級に？ DAX。Q. Lambda の CPU を増やすには？ メモリを増やす（比例）。Q. コールドスタート対策は？ プロビジョンド同時実行。Q. スロットリングは？ 指数バックオフ＋ジッターでリトライ。Q. Scan と Query は？ 可能な限り Query/GSI。
AWS SDK は既定で指数バックオフ付きリトライを行います。スロットリングが続く場合はキャパシティ設計やアクセスパターン（キー設計）を見直します。
5.3.2この節のまとめ
- キャッシュ／Lambda チューニング／効率的なデータアクセスで最適化
- コールドスタート＝プロビジョンド同時実行、スロットリング＝指数バックオフ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. DynamoDB の読み取りをマイクロ秒級まで高速化したい。最も適したキャッシュはどれですか？
Q2. Lambda のコールドスタートによる初回遅延を抑えたい。最も適した方法はどれですか？
Q3. DynamoDB のスロットリング（ProvisionedThroughputExceeded）に対するアプリ側の正しい対処はどれですか？