目次
1. 結論
DAX（DynamoDB Accelerator）は、「DynamoDB専用の加速装置」です。通常のDynamoDBはミリ秒単位の応答ですが、DAXを挟むことでマイクロ秒（ミリ秒の1000分の1）単位まで高速化できます。最大の特徴は「透過的」であることで、アプリケーション側のDB操作ロジックを大きく書き換えることなく導入できる点にあります。
2. SAAで出やすいポイント
- 圧倒的な低レイテンシー: 「ミリ秒ではなくマイクロ秒」というキーワードが出たらDAXを疑う。
- 読み取り負荷の軽減: 頻繁にアクセスされるデータ（ホットキー）への負荷をキャッシュで吸収し、DynamoDBのRCU（読み取りキャパシティ）を節約できる。
- 透過的（Transparent）: 既存のDynamoDB APIと互換性があるため、SDKをDAX用に切り替えるだけでキャッシュを利用できる。
- 書き込みスルー（Write-Through）: DAXに書き込むと、自動的にDynamoDBにも反映されるため、キャッシュと本体の整合性が保たれやすい。
3. キーワードでの判断
| 問題文のキーワード | 疑うべきサービス/機能 | 判断理由 |
|---|---|---|
| 「DynamoDBの読み取りをマイクロ秒にしたい」 | DAX | 専用の超高速キャッシュ |
| 「DynamoDBのホットキーによるスロットリングを解消」 | DAX | 特定データへの集中アクセスを吸収 |
| 「アプリケーションコードの変更を最小限にキャッシュ導入」 | DAX | 透過的キャッシュの特性 |
4. ひっかけポイント
- ElastiCacheとの使い分け:
- DAX: DynamoDBのみ。アプリの書き換えが少ない。マイクロ秒。
- ElastiCache: RDSやS3など何でも。アプリ側でキャッシュロジックの実装が必要。ミリ秒。
- コスト: DAXクラスター自体の稼働費用がかかるため、RCUを増やすのとどちらが安いか検討が必要（SAAでは性能要件が優先されることが多い）。
5. 覚え方
- 「DynamoDBの専用ブースター」。
- DynamoDBというスポーツカーに、さらにターボ（DAX）を付けるイメージ。
6. 関連サービス
| サービス名 | 関連する理由 |
|---|---|
| DynamoDB | DAXが加速させる対象のNoSQLデータベース。 |
| VPC | DAXはVPC内で動作するため、ネットワーク構成の考慮が必要。 |
| IAM | DAXクラスターへのアクセス権限管理に使用する。 |
7. Obsidian管理メモ
- 復習ポイント: 「強い整合性のある読み取り（Strongly Consistent Reads）」をDAX経由で行うと、キャッシュを飛ばしてDynamoDB本体に行くため、レイテンシーは改善しない点に注意。
- 関連ノート: DynamoDBの高度な設計
8. HTMLファイル名
amazon-dynamodb-accelerator-dax-guide.html
