SAA DynamoDB 設計問題の頻出パターン10選｜キー設計・GSI/LSI・キャパシティ・Global Tables を要件文で即断する
AWS SAA-C03 で DynamoDB は「NoSQL を選ぶべきか」だけでなく、キー設計・インデックス（GSI/LSI）・キャパシティモード・DAX・Global Tables・Streams まで踏み込んで問われる頻出テーマ。本記事は DynamoDB 設計問題を「アクセスパターンからのキー設計／ホットパーティション回避／LSI と GSI の使い分け／オンデマンドとプロビジョンド＋Auto Scaling/DAX と ElastiCache/マルチリージョンの Global Tables/Streams によるイベント連携/TTL・PITR の運用」の頻出10パターンに分解する。各パターンで要件文のどのキーワードが正解を一意に決めるかを示す。結論は「DynamoDB 問題は機能の暗記ではなく、アクセスパターン・スケール・整合性・地理分散という4つの評価軸で解く」こと。
DynamoDB の設計問題を「NoSQL だから DynamoDB」で片づけようとすると、キー設計・GSI/LSI の使い分け・キャパシティモード・地理分散で足をすくわれる。 SAA-C03 で Amazon DynamoDB は、サーバーレスやマイクロサービスの相棒として出題比重が上がり続ける最重要データストアだ。だが問われるのは「NoSQL の一般論」ではなく、どのアクセスパターンに合わせてキーを切るのか・どのインデックスで検索するのか・スケールと整合性をどう捌くのか・複数リージョンにどう広げるのかという設計判断である。攻略の鍵は、頻出テーマを「キー設計（パーティション・複合・ホット回避）」「インデックス（LSI/GSI）」「キャパシティと性能（オンデマンド/プロビジョンド/DAX）」「地理分散と連携（Global Tables/Streams/運用）」の4系統×10パターンに畳み、要件文のキーワードから正解を一意に引く反射を作ること。本記事では、SAA 本番でそのまま選択肢を絞れる粒度で、DynamoDB 設計問題の頻出10パターンを分解する。読み終えれば、「最もスケーラブルで、要件のアクセスパターンを満たす構成はどれか」という問いに、迷わず正解を当てられるようになる。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：DynamoDB 問題は「機能」ではなく「4つの評価軸」で解く
- パターン1〜3：キー設計（パーティション・複合キー・ホット回避）
- パターン4〜5：インデックス（LSI と GSI の使い分け）
- パターン6〜7：キャパシティモードと DAX による高速化
- パターン8〜10：Global Tables・Streams・運用（TTL/PITR）
- 頻出ひっかけパターンと打ち手の整理
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：DynamoDB 問題は「機能」ではなく「4つの評価軸」で解く
SAA-C03 の DynamoDB 問題を最短で解く骨格は、**「要件文が4つの評価軸——アクセスパターン（キー設計）・スケール（キャパシティと分散）・整合性（読み取りと ACID）・地理分散（マルチリージョン）——のどれを問うているかを特定し、その軸で選択肢を振るう」**ことだ。これが本記事の結論である。
理由は明快で、DynamoDB の各機能はどれも「ある評価軸を制御するための道具」だからだ。キー設計とインデックスは「どんなクエリを高速にするか（アクセスパターン）」を、オンデマンド／プロビジョンド／DAX は「スケールとレイテンシ」を、強力な整合性読み取りとトランザクションは「整合性」を、Global Tables は「地理分散」を担う。つまり要件文のキーワードが軸を指し示し、軸が正解の機能を一意に決める構造になっている。
具体例で見よう。「ミリ秒応答で無限にスケールし、スキーマが柔軟」——これはアクセスパターンの軸だから DynamoDB を選ぶ。「パーティションキー以外の属性で検索したい」——インデックスの軸だから GSI。「読み取りが極端に多くマイクロ秒応答が要る」——レイテンシの軸だから DAX。「複数リージョンで低遅延に読み書きしたい」——地理分散の軸だから Global Tables。ここで「DynamoDB は万能だから細かい設計は不要」と考えると、キー設計やインデックスを問う設問で誤答する。軸で解く——この一点が DynamoDB 問題の攻略法だ。
2. パターン1〜3：キー設計（パーティション・複合キー・ホット回避）
DynamoDB 問題の土台は「キーをどう切るか」だ。ここを3パターンで押さえると、多くの設問が即断できる。
パターン1：アクセスパターンからキーを逆算する
DynamoDB 設計の鉄則は、**「先にデータモデルを決めてからクエリを考える」RDB とは逆で、「先にアクセスパターン（どんなクエリを何で引くか）を洗い出し、それを満たすようにキーを設計する」**ことだ。パーティションキー（PK）に指定した属性でしか高速な Query はできないため、「何で検索するか」がそのまま PK 候補になる。SAA では「このアクセスパターンに最適なキー設計は？」という形で問われる。
パターン2：単純キーと複合キー（PK＋SK）
プライマリキーには2種類ある。**単純キー（パーティションキーのみ）**は1属性で一意に決まる場合、**複合キー（パーティションキー＋ソートキー）**は「同一 PK 内を範囲・順序で絞りたい」場合に使う。
| 評価項目 | 単純キー（PKのみ） | 複合キー（PK＋SK） 推奨 |
|---|---|---|
| 一意性 | PK だけで一意 | PK＋SK の組で一意 |
| クエリ | 1件取得（GetItem） | 同一PK内をSKで範囲・並び替え |
| 向くケース | ユーザーIDで1件引く | ユーザーの注文履歴を日付順に |
| キーワード | 「IDで一意に取得」 | 「〜ごとに」「範囲」「時系列」 |
パターン3：ホットパーティション回避
「特定のキーにアクセスが集中してスロットリングされる」——これはホットパーティションの設問だ。パーティションキーはカーディナリティ（値の種類）が高く、アクセスが均等に分散する属性を選ぶのが正解になる。
3. パターン4〜5：インデックス（LSI と GSI の使い分け）
「パーティションキー以外の属性で検索したい」——この瞬間にインデックスの出番だ。SAA 最頻出の切り分けがこの2パターンである。
パターン4：GSI（グローバルセカンダリインデックス）
PK とは別の属性を新しいパーティションキー／ソートキーにして検索したいなら GSI が正解だ。GSI はテーブル作成後でも追加・削除でき、元テーブルとは独立したキャパシティを持つ。「別の属性軸でまったく違うクエリをしたい」「後から検索軸を追加したい」がキーワードになる。
パターン5：LSI（ローカルセカンダリインデックス）
同じパーティションキーのまま、別のソートキーで並べ替え・絞り込みたいなら LSI だ。LSI はテーブル作成時にしか作れず、元テーブルとキャパシティを共有する。
| 評価項目 | GSI 推奨 | LSI |
|---|---|---|
| パーティションキー | 別の属性に変えられる | 元テーブルと同じ |
| 作成タイミング | いつでも追加・削除可 | テーブル作成時のみ |
| キャパシティ | 独立（別枠） | 元テーブルと共有 |
| 整合性 | 結果整合性のみ | 強力な整合性も可 |
| キーワード | 「別の属性で検索」「後から追加」 | 「同じPKで別のソート」「強整合」 |
4. パターン6〜7：キャパシティモードと DAX による高速化
スケールとレイテンシの軸がこの2パターン。運用負荷とコストの設問にも直結する。
パターン6：オンデマンド vs プロビジョンド（＋Auto Scaling）
キャパシティモードは2択だ。トラフィックが予測不能・急変する／管理を減らしたいならオンデマンド、負荷が安定・予測可能でコストを最適化したいなら**プロビジョンド（＋Auto Scaling）**が正解になる。
| 評価項目 | オンデマンド 推奨 | プロビジョンド＋Auto Scaling |
|---|---|---|
| トラフィック | 予測不能・スパイク・新規 | 予測可能・安定 |
| 運用 | 容量管理不要 | 目標使用率を設定して自動調整 |
| コスト | 使った分だけ（単価は高め） | 安定負荷なら割安 |
| キーワード | 「予測できない」「急なスパイク」 | 「安定した負荷」「コスト最適化」 |
パターン7：DAX でマイクロ秒応答（読み取りキャッシュ）
「読み取りが極端に多く、ミリ秒でも足りずマイクロ秒応答が要る」——これは DAX（DynamoDB Accelerator） が正解だ。DAX は DynamoDB 専用のインメモリキャッシュで、アプリのコード変更を最小限にキャッシュを差し込めるのが強み。ElastiCache でも似たことはできるが、キャッシュ制御を自前実装する必要がある。
5. パターン8〜10：Global Tables・Streams・運用（TTL/PITR）
地理分散・イベント連携・運用の軸で、DynamoDB 問題の総仕上げとなる3パターンだ。
パターン8：Global Tables でマルチリージョン・低遅延
「複数リージョンのユーザーに低遅延で読み書きさせたい」「リージョン障害に備えたい」——これは Global Tables が正解だ。複数リージョンにアクティブ／アクティブでテーブルを複製し、各リージョンでローカルに読み書きできる。**「グローバルに低遅延」「マルチリージョン DR」「どのリージョンでも書き込める」**がキーワード。
パターン9：DynamoDB Streams でイベント駆動連携
「テーブルの変更（追加・更新・削除）をトリガーに後続処理をしたい」——これは DynamoDB Streams＋Lambda が正解だ。データの変更イベントを時系列で捕捉し、Lambda で集計・通知・他システム連携を非同期に実行する。「変更をトリガーに」「監査ログ」「集計テーブルの自動更新」がキーワードになる。
パターン10：TTL と PITR（自動削除・バックアップ）
運用系の細かい正解肢も押さえておく。**TTL（Time To Live）**は、各アイテムに有効期限のタイムスタンプ属性を設定し、期限切れアイテムを自動削除する機能。「セッションデータや一時データを自動で消したい」がキーワード。**PITR（Point-in-Time Recovery）**は、直近35日間の任意の秒単位に復元できる継続バックアップで、「誤削除・誤更新から復旧したい」が該当する。
6. 頻出ひっかけパターンと打ち手の整理
DynamoDB 問題は、正しい打ち手と“やりがちな誤答”が明確に対になっている。表で押さえれば本番で機械的に振るえる。
7. 次のアクション チェックリスト
DynamoDB 設計パターンを、今日からの学習に落とし込むための具体アクションをまとめる。
8. 関連記事
- SAA 試験完全ガイド｜SAA-C03 の出題範囲・難易度・3ヶ月合格戦略 — 本シリーズの上位ガイド
- SAA 試験範囲：4ドメイン詳細解説 — ドメイン1〜4の全体像
- SAA ドメイン3：高パフォーマンスアーキテクチャの設計 — DynamoDB の性能軸の上位
- SAA ドメイン2：弾力性のあるアーキテクチャの設計 — Global Tables・DR の上位
- SAA Lambda・サーバーレス設計の頻出パターン10選 — DynamoDB を相棒にする設計
- SAA S3 設計問題の頻出パターン10選 — 隣接する頻出テーマ
- SAA VPC 設計問題の頻出パターン10選 — ネットワーク設計の頻出
- Amazon DynamoDB とは？フルマネージド NoSQL の仕組みと料金 — DynamoDB の基礎
- DynamoDB のパーティションキー設計 — キー設計の詳細
- DynamoDB Streams の仕組みと活用 — 変更駆動連携の詳細
- DAX（DynamoDB Accelerator）とは？ — マイクロ秒キャッシュの詳細
- RDS と Aurora の使い分け — RDB が必要なケースの比較
9. 関連サイト
AWS 公式
- Amazon DynamoDB 開発者ガイド（公式）
- DynamoDB のデータモデリング（公式）
- セカンダリインデックスの一般的なガイドライン（公式）
- Amazon DynamoDB（サービス紹介・公式）
- AWS Certified Solutions Architect – Associate（公式）
- SAA-C03 試験ガイド（公式 PDF）