2026-08-27（木）RDS (Aurora), S3 (Glacier)

1. 【この範囲の全体像】

本範囲は、高可用で極めて高いスケーラビリティを持つフルマネージドNoSQLデータベースサービスである Amazon DynamoDB のアーキテクチャと機能特性を学ぶエリアです [p.143]。

（※書籍の構成上、第5章5-4（p.143-148）の該当テーマは「DynamoDB」となります [p.143]。

RDSやGlacierは5-1・5-2および4-4に該当します [p.103, p.126, p.129]。

）試験では、突発的なアクセス集中下でも「ミリ秒未満の超低遅延」や「無限の水平スケーラビリティ」を維持しつつ、コスト効率良くデータストアを設計・運用する能力が厳格に問われます [p.143]。

2. 【重要キーワード・サービス一覧】

キーワード	説明
Amazon DynamoDB [p.143]	ミリ秒単位の応答性能を持ち、自動的に3つのAZへデータを同期複製することで単一障害点（SPOF）を排除したフルマネージドNoSQLデータベースサービス [p.143]。
RCU (Read Capacity Unit) / WCU (Write Capacity Unit) [p.144]	DynamoDBの読み書き性能を規定するスループットキャパシティ [p.144]。1RCUは「4KBの項目に対し秒間1回の強い一貫性読み取り（または秒間2回の結果整合性読み取り）」[p.144]、1WCUは「1KBの項目に対し秒間1回の書き込み」と定義されます [p.144]。
結果整合性のある読み取り (Eventually Consistent Read) vs 強い一貫性のある読み取り (Strongly Consistent Read) [p.144, p.147]	デフォルトは結果整合性（秒間2回/RCU）[p.144]。直前の書き込み内容を即座に確実に反映した最新データを読み出したい場合は「強い一貫性のある読み取り」をオプション指定しますが、消費RCUは2倍（秒間1回/RCU）になります [p.144, p.147]。
プライマリーキー（パーティションキー / ソートキー） [p.145]	データを一意に特定するための属性 [p.145]。単一の「パーティションキー（ハッシュキー）」のみで構成する形式と、「パーティションキー＋ソートキー（レンジキー）」を組み合わせる複合キー形式の2種類があります [p.145]。
LSI (ローカルセカンダリインデックス) [p.145]	テーブルと同じパーティションキーを使用しつつ、異なるソートキーを定義するインデックス [p.145]。テーブル作成時にのみ定義可能で、テーブル本体のRCU/WCUキャパシティを共有・消費します [p.145]。
GSI (グローバルセカンダリインデックス) [p.145]	テーブルとは異なるパーティションキーおよびソートキーを自由に定義できるインデックス [p.145]。テーブル作成後であってもいつでも自由に追加・削除が可能で、テーブル本体とは完全に分離された独自のキャパシティユニットを割り当てて消費します [p.145]。
Time to Live (TTL) [p.146]	データの有効期限を設定し、期限を過ぎた項目を最大48時間以内に自動消去する機能 [p.146]。この自動削除処理は、テーブルに割り当てられたWCUスループット容量を一切消費しないため、コスト効率に極めて優れます [p.146]。
DynamoDB Streams [p.146]	テーブルに対する追加・更新・削除の変更履歴を直近24時間保持する機能 [p.146]。これを有効化することで、データの変更イベントをリアルタイムに検知し、AWS Lambdaなどを起動して非同期のイベント駆動処理を実行できます [p.78, p.146]。
DAX (DynamoDB Accelerator) [p.147]	DynamoDBの直前にインラインで配置する、API互換のフルマネージドな専用インメモリキャッシュクラスター [p.147]。読み取りレスポンスをミリ秒から「マイクロ秒単位」へと劇的に高速化し、テーブル側のRCU消費を大幅に抑制してコスト最適化に貢献します [p.147]。

3. 【試験で問われる比較ポイント】

① セカンダリインデックスの決定的な違い：LSI vs GSI [p.145]

比較項目	LSI (ローカルセカンダリインデックス) [p.145]	GSI (グローバルセカンダリインデックス) [p.145]
パーティションキー	テーブルと全く同じものでなければならない [p.145]。	テーブルとは異なる別の属性を指定可能 [p.145]。
ソートキー	テーブルと異なる任意の属性を指定可能 [p.145]。	テーブルと異なる任意の属性を指定可能 [p.145]。
作成タイミング	テーブル作成時のみ（後からの追加は絶対に不可） [p.145]。	テーブル作成後、運用中のいつでも追加・削除が可能 [p.145]。
キャパシティ（RCU/WCU）	テーブル本体にプロビジョニングされたキャパシティを共有消費する [p.145]。	テーブル本体とは完全に別個のキャパシティを指定し、独自に消費する [p.145]。
決定的な選定シグナル	「同一のユーザーID（同一パーティション）内で、別の属性（例：登録日時順）に沿って高速に検索を絞り込みたい（かつ初期設計時点で確定している）」	「テーブルとは全く異なるキー（例：注文IDではなく商品コードなど）を基準にして、テーブル全体を横断的にクエリしたい」

② 読み取り一貫性モデルの選択：結果整合性 vs 強い一貫性 [p.144, p.147]

比較項目	結果整合性のある読み取り (Eventually Consistent) [p.144]	強い一貫性のある読み取り (Strongly Consistent) [p.147]
データのリアルタイム性	直前の書き込み内容が即座に反映されない可能性がある（通常1秒未満で同期完了する） [p.144]。	直前の書き込み内容が100%即座に反映された最新データを確実に返却する [p.147]。
**消費キャパシティ (RCU) [p.144]	1 RCU あたり秒間 2 回の読み取り（コスト半分） [p.144]。	1 RCU あたり秒間 1 回の読み取り（コスト2倍を消費） [p.144]。
最大オブジェクトサイズ	4 KB / 1回 [p.144]	4 KB / 1回 [p.144]
決定的な選定シグナル	「最新の書き込みデータが数ミリ秒〜数秒遅れて反映されても許容できる（例：SNSの投稿タイムライン、ゲームのスコアボードなど）」	「ミリ秒の不整合も許されず、常に最新の状態を参照する必要がある（例：オンラインバンキングの残高照会、製品の在庫数チェックなど）」

4. 【ひっかけ注意ポイント】

ひっかけ①：本番運用中に、新しい検索ソート要件の追加に対して「LSI（ローカルセカンダリインデックス）」を新規作成する罠 [p.145]
- 罠パターン：「既存の注文管理DynamoDBテーブルに対して、顧客の要望により、特定の購入日順で注文履歴を高速にソート検索できるようにする必要が生じた。システムのダウンタイムを避けるため、既存テーブルにLSIを新規でアタッチしてクエリを最適化した。」
- なぜ間違いか：LSIはテーブルの作成時（Create Table）にしかアタッチすることができません [p.145]。すでに本番稼働しているテーブルに対して、後からLSIを動的に追加・作成することは物理的な仕様上、絶対に不可能です [p.145]。
- ベストプラクティス：既存稼働テーブルにインデックスを動的追加・再設計する場合は、いつでも自由に作成・削除がサポートされている GSI（グローバルセカンダリインデックス） をデプロイして適合させるのが正しい設計です [p.145]。
ひっかけ②：強い一貫性のある読み取り（Consistent Read）を無計画に有効化し、予期せぬRCU枯渇（スロットリングエラー）を招く罠 [p.144, p.147]
- 罠パターン：「データの整合性を最大限に高めるため、すべての読み取りクエリ（GetItem / Query）に対し一律で『強い一貫性のある読み取り（ConsistentRead=true）』を構成して動作させた。これにより、追加のキャパシティ消費を発生させることなく最もセキュアに整合性を担保できる。」
- なぜ間違いか：強い一貫性のある読み取りは、結果整合性のある読み取りと比較して、物理的な読み取りスループット能力を「 2倍（コストが2倍） 」消費します [p.144]。同じ読み取りリクエスト回数であっても、RCUの消費スピードが2倍に跳ね上がるため、容量制限に達してシステム全体が「スロットリング（プロビジョンドスループット超過エラー）」を引き起こし、アプリケーションがクラッシュします。
- ベストプラクティス：リアルタイム性が必要ない読み取り箇所（大部分の参照処理）はデフォルトの 結果整合性のある読み取り のまま運用し、口座残高や在庫チェックなどの本当にミリ秒の一貫性が要求されるクリティカルなAPIにのみ、明示的に強い一貫性オプションを指定する設計でスループットコストを最適化します [p.144, p.147]。
ひっかけ③：DynamoDBテーブルに対するミリ秒から「マイクロ秒」への更なる高速化要件に、安易に「Amazon ElastiCache」を前段構築する罠 [p.147, p.149]
- 罠パターン：「モバイルゲームのセッションデータへの極限のアクセス応答速度を求めるため、DynamoDBテーブルの前段に汎用的なキャッシュサービスである Amazon ElastiCache（Redis / Memcached）クラスターを構築し、アプリケーションからキャッシュ制御を行うプログラムコードを独自に自作・記述した。」
- なぜ間違いか：間違いではないものの、ElastiCacheを導入すると、キャッシュデータの同期処理や無効化処理、接続切断時の再試行ロジックなどの複雑なロジックをアプリケーションのプログラムコード側に利用者が「自前で自律開発・保守」しなければならず、運用・開発オーバーヘッドが著しく増大します [p.149]。
- ベストプラクティス：DynamoDBに完全に最適化され、シームレスなAPI互換を持つ専用インメモリキャッシュである Amazon DynamoDB Accelerator (DAX) を配置します [p.147]。DAXであれば、既存のアプリケーションコード（DynamoDB API）を書き換えることなく、接続先エンドポイントをDAXに切り替えるだけで、読み取りレイテンシーをミリ秒単位から「マイクロ秒単位」へ容易に引き下げ、RCU消費も自動で劇的に削減できます [p.147]。