はじめに

AWS Solutions Architect Associate (SAA) の学習中に整理した Amazon DynamoDB 関連の知識をまとめました。
DynamoDB は NoSQL のサーバーレスデータベースとして、容量モードの選択、DAX によるキャッシュ、Global Tables によるマルチリージョン展開など、多角的に出題されます。

本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。

サービス概要

DynamoDB の特徴

NoSQL（Key-Value / Document）
ミリ秒レイテンシー
サーバーレス（インフラ管理不要）
水平スケール
アイテムサイズ上限: 400KB

Capacity Modes

モード	用途	課金
On-Demand	予測不能なトラフィック、急激なスパイク、新規テーブル	使った分だけ（pay-per-request）
Provisioned（Auto Scaling 付き）	予測可能なトラフィック、段階的な増加	プロビジョニング容量ベース

「急激なスパイク」には On-Demand を選びます。Auto Scaling は反応に遅延があるため、急激なスパイクには間に合わない場合があります。

DAX（DynamoDB Accelerator）

DynamoDB 専用のインメモリキャッシュ
DynamoDB API と完全互換 → コード変更が最小
ミリ秒 → マイクロ秒 に高速化
ホットパーティション問題を解消
ElastiCache Redis でも代替可能だが、実装がはるかに複雑

Global Tables

マルチリージョン、マルチライター（各リージョンで読み書き可能）
レプリケーションレイテンシー: 通常1秒未満
フルマネージド（カスタムレプリケーション不要）
Aurora Global Database との違い: マルチライター対応（Aurora は書き込みがプライマリのみ）

Deletion Protection

テーブル削除自体をブロック（予防的）
設定するだけ → 運用負荷ゼロ

Point-in-Time Recovery（PITR）

秒単位の粒度で過去35日間の任意時点に復元
継続的・自動的にバックアップ
誤書き込み・誤削除からの保護に最適

TTL（Time To Live）

アイテムに有効期限（Unix timestamp）を設定
期限切れアイテムを自動削除（追加コストなし）
データ保持ポリシーの実装に最適

DynamoDB の制約

アイテムサイズ上限 400KB（20MB のドキュメントは格納不可）
DAX なしの DynamoDB 単体はインメモリではない

試験で問われる設計パターン

キャッシュ・パフォーマンス系

DynamoDB キャッシュ → DAX

シナリオ: DynamoDB に対する読み取りが頻繁で、レスポンスタイムを改善したいです。コード変更は最小限にしたい場合、どのキャッシュサービスが最適でしょうか？

正解: DAX（DynamoDB 用）+ CloudFront（S3 用）

DAX = DynamoDB API 互換でコード変更最小
ElastiCache Redis でも可能だが実装が複雑

DynamoDB ホットパーティション + リファクタリング最小 → DAX

シナリオ: スポーツアプリで人気アスリートのページにアクセスが集中し、ホットパーティション問題が発生しています。RCU を増加しても解決しません。リファクタリングを最小限にして解決するにはどうすべきでしょうか？

正解: DynamoDB DAX

DAX はホットキーをキャッシュして負荷を分散
ElastiCache はコード変更が大きい
Global Tables はレプリケーション用（ホットパーティション対策ではない）
RCU 増加ではホットパーティション問題は解決しない

容量モード系

予測不能トラフィック + 急激なスパイク → On-Demand

シナリオ: 新しく立ち上げるサービスで、トラフィックパターンが予測できません。急激なスパイクにも対応したい場合、どの容量モードが適切でしょうか？

正解: DynamoDB On-Demand Capacity Mode

Auto Scaling は反応遅延があり、急激なスパイクに不向き
On-Demand は即座にキャパシティを割り当て
新規テーブル（パターン不明）にも On-Demand が推奨

グローバル展開系

マルチリージョン + 1秒未満の書き込み + グローバル同期 → Global Tables

シナリオ: グローバルに展開するアプリケーションで、各リージョンから1秒未満の書き込みレイテンシーが必要です。データはリージョン間で自動同期させたいです。どのサービスが最適でしょうか？

正解: DynamoDB Global Tables

マルチリージョン、マルチライター
Aurora Global DB は書き込みがプライマリリージョンのみ
RDS Cross-Region Read Replica は読み取り専用

DynamoDB グローバル HA + コスト効率 → Global Tables + Provisioned + Auto Scaling

シナリオ: DynamoDB をグローバルに展開して高可用性を確保しつつ、コスト効率も重視したいです。どの構成が最適でしょうか？

正解: Global Tables + Provisioned Capacity + Auto Scaling

Global Tables はネイティブレプリケーション
DAX はローカルキャッシュ（グローバル同期ではない）
Streams + Lambda によるカスタムレプリケーションは運用負荷が大きい

データ保護系

テーブルの誤削除防止 → Deletion Protection

シナリオ: 運用チームが誤って DynamoDB テーブルを削除してしまうリスクがあります。最も運用負荷の低い防止策はどれでしょうか？

正解: DynamoDB Deletion Protection

予防的（削除自体をブロック）
PITR は復旧手段（削除防止ではない）
Lambda による自動復旧は運用負荷が大きい

破損データの復旧 → PITR

シナリオ: アプリケーションのバグにより DynamoDB のデータが破損しました。破損前の状態に戻すにはどうすべきでしょうか？

正解: DynamoDB PITR

秒単位の粒度で過去35日間の任意時点に復元
On-Demand Backup は事前に取得している必要がある
Streams はカスタムコードが必要
Global Tables は破損データもレプリケートしてしまう

サービス選択系

NoSQL + ミリ秒レイテンシー + 水平スケール + サーバーレス → DynamoDB

シナリオ: NoSQL でミリ秒レイテンシー、水平スケール、サーバーレスという要件をすべて満たすデータベースはどれでしょうか？

正解: Amazon DynamoDB

ElastiCache = キャッシュ（メイン DB ではない）
RDS = リレーショナル（NoSQL 要件に不適）
Neptune = グラフ DB（Key-Value には不適）

ドキュメントサイズが 20MB → DynamoDB は不可

シナリオ: 20MB のドキュメントを保存する必要があります。DynamoDB は使えるでしょうか？

正解: 使えません。DynamoDB のアイテムサイズ上限は 400KB です。この場合は S3 をドキュメントストアとして使います。

おわりに

DynamoDB は「NoSQL + サーバーレス」の代表的なサービスであり、SAA でも頻出です。「急激なスパイク → On-Demand」「ホットパーティション → DAX」「マルチリージョン書き込み → Global Tables」「400KB 制限」という判断パターンを押さえておけば、ほとんどの問題に対応できます。

間違いや補足があればぜひコメントで教えてください。