データベース
RDS、Aurora、DynamoDB、ElastiCache と専用データベース: データの種類、可用性、パフォーマンスから選びます。
- 分野弾力性のあるアーキテクチャ
- 分野高性能なアーキテクチャ
- 分野コスト最適化
- 図 15
- 出題パターン 10
- サービス 12
5 分で押さえる要点
- RDS Multi-AZ: 別の AZ に同期スタンバイを置き、同じ DNS 名のまま自動でフェイルオーバーします。スタンバイ（単一インスタンス型）は読み取りを処理しません。「可用性を高める」 → Multi-AZ、「読み取り負荷を減らす」 → リードレプリカ。この 2 つは別物です。
- リードレプリカは非同期でレプリケーションし、読み取りが可能です。同一または別リージョンに置け、独立した DB に昇格できます（RDS MySQL は最大 15 台）。重いレポートでプライマリ DB が遅くなる → リードレプリカ。別リージョンへの DR → クロスリージョンのリードレプリカを作って昇格。
- RDS の自動バックアップは 0～35 日保持され（0 は無効）、特定の時点へ復元できます。手動スナップショットは削除するまで保持されます。35 日を超えて保持したい場合は、手動スナップショットまたは AWS Backup。
- Aurora: 3 つの AZ にコピーを持つ共有ストレージが自動で拡張され（バージョンによって最大 256 TiB）、Aurora Replica は最大 15 台、レプリケーション遅延は通常 100 ms 未満です。レプリカが同じストレージを読むため、Aurora のフェイルオーバーは高速です。書き込みは writer endpoint、読み取りの分散は reader endpoint を使います。
- Aurora Global Database: 書き込み用 1 リージョン + 読み取り専用のセカンダリリージョン最大 10 個。レプリケーションは通常 1 秒未満です。低い RPO / RTO で別リージョンへ DR したい場合、またはグローバルユーザー向けに低レイテンシーで読み取りたい場合。
- Aurora Serverless v2 は需要に応じてスケールします。RDS Proxy は、多数の接続を開く Lambda / アプリケーションのために接続をプールします。Lambda が RDS の接続数を使い切る → RDS Proxy（フェイルオーバーも速くなり、IAM / Secrets Manager が使えます）。
- DynamoDB: NoSQL のキーバリューストアで、どの規模でもミリ秒台のレイテンシーです。アイテムは最大 400 KB。on-demand（リクエスト課金）または provisioned（RCU / WCU、auto scaling あり）。トラフィックが予測しにくい → on-demand。安定していて低コストにしたい → provisioned + auto scaling。
- 1 RCU = 4 KB 以下のアイテムを毎秒 1 回の強い整合性のある読み取り（結果整合性なら 2 回）。1 WCU = 1 KB 以下のアイテムを毎秒 1 回の書き込み。トランザクションは 2 倍かかります。キャパシティ計算問題: アイテムサイズは、読み取りなら 4 KB、書き込みなら 1 KB の倍数に切り上げます。
- DynamoDB のキー: パーティションキー（+ ソートキー）。GSI: まったく別のキーで、いつでも作成でき、結果整合性のみ。LSI: パーティションキーは同じでソートキーが異なり、テーブル作成時にしか作れず、最大 5 つ。別の属性で検索したい → GSI。Scan は避けます。
- DynamoDB Streams + Lambda で変更に応じた処理、Global Tables でマルチリージョンの active-active、PITR で 35 日間を秒単位で復元、TTL で期限切れアイテムを自動削除します。新規注文時にメールを送る → Streams + Lambda。複数の大陸のユーザーが同時に書き込む → Global Tables。
- キャッシュ: DynamoDB には DAX（マイクロ秒、コード修正ほぼ不要）、あらゆるデータソースには ElastiCache（Valkey / Redis OSS: レプリケーション、バックアップ、豊富なデータ構造。Memcached: シンプル、マルチスレッド、レプリケーションなし）。RDS からの繰り返し読み取りが多い → ElastiCache（cache-aside）。ランキング → Valkey / Redis の sorted set。
- 専用データベース: DocumentDB（MongoDB）、Neptune（グラフ）、Keyspaces（Cassandra）、Timestream（時系列）、Redshift（データウェアハウス、OLAP）、MemoryDB（耐久性のある Redis をプライマリ DB として使用）。試験ではデータモデルが示されることが多く、モデルに合わせて選びます。友人関係 → Neptune、時間軸の IoT データ → Timestream。
- RDS の暗号化は作成時に有効にする必要があります。暗号化されていない DB は、スナップショット → 暗号化付きでスナップショットをコピー → 復元します。リードレプリカの暗号化状態はソースと同じです。
構成図
RDS Multi-AZ とリードレプリカ
ステップ
- 書き込みは毎回、別 AZ のスタンバイへ同期でコピーされます。
- リードレプリカは非同期で受け取り、レポートツールはここから読み取るため、プライマリは遅くなりません。
- プライマリまたは AZ a に障害が起きると、RDS が DNS 名をスタンバイに切り替え、アプリは同じエンドポイントに再接続します。
Aurora: writer、reader、共有ストレージ
ステップ
- 書き込みは writer endpoint を通り、データは共有のクラスターボリュームに保存されます。
- 読み取りは reader endpoint を通り、Aurora Replica に分散されます（遅延は通常 100 ms 未満）。
Aurora Global Database
ステップ
- 書き込みはプライマリリージョンで行い、ストレージ層でセカンダリリージョンへレプリケーションされます（通常 1 秒未満）。
- ヨーロッパのユーザーは近いリージョンで読み取ります。プライマリリージョンに障害が起きたら、セカンダリクラスターにフェイルオーバーします。
RDS Proxy による Lambda の接続プール
ステップ
- Lambda の各実行環境は、データベースではなく Proxy に接続します。
- Proxy は小さな接続プールを再利用し、認証情報を Secrets Manager から取得します。フェイルオーバーも速くなります。
ElastiCache による cache-aside
DynamoDB の前段に DAX
ステップ
- 繰り返しの読み取りは DAX のメモリから返されます（マイクロ秒）。
- キャッシュミスまたは書き込み: DAX が DynamoDB を呼び出し、キャッシュを更新します。
DynamoDB のキー、GSI、LSI
ステップ
- LSI: 同じ顧客のデータを別の属性で並べ替えます。強い整合性のある読み取りが可能です。
- GSI: Scan なしでまったく別の属性で検索します。結果整合性のみです。
DynamoDB Streams で処理を起動
ステップ
- アプリはテーブルに書き込むだけで、DynamoDB が変更をストリームに流します。
- Lambda がストリームをバッチで読み取り、メール送信と検索インデックスの更新を行います。
DynamoDB Global Tables: 複数リージョンで書き込み
ステップ
- 各拠点は、近いリージョンのレプリカに読み書きします（active-active）。
- 変更は他のレプリカにレプリケーションされます。
データモデルに合わせたデータベース選び
RDS: 自動バックアップ、特定時点への復元、手動スナップショット
ステップ
- 自動バックアップ: バックアップウィンドウ中に毎日ボリュームのスナップショットを取得し、トランザクションログを 5 分ごとに S3 へ送ります。設定した日数だけ保持されます（0 は無効）。
- 手動スナップショットは自動では失効せず、インスタンスを削除しても残ります（リージョンあたり最大 100 個）。
- 特定時点への復元: バックアップ保持期間内の任意の時点を選べます。結果は新しいインスタンスになります。
- スナップショットからの復元も新しいインスタンスになります。アプリを新しいエンドポイントに向けてから、古いインスタンスを削除します。
稼働中の未暗号化 RDS を暗号化する
Aurora Serverless v2: writer と reader が ACU で自動スケール
ステップ
- Serverless writer は負荷に応じて最小 0.5 ACU 刻みで ACU を増減し、接続は切れません。新しいバージョンでは最小 0 ACU に対応します（アイドル時は自動一時停止）。
- promotion tier 0–1 の reader は writer に追従してスケールし、フェイルオーバーに備えます。tier 2–15 は独立してスケールします（レポート処理向き）。
- コンピュートが小さくなってもデータはクラスターボリューム上にそのまま残ります（3 AZ に 6 コピー）。同じクラスターに provisioned の reader も混在させられます。
DynamoDB の capacity モードの選び方
ステップ
- 新しいアプリケーションで、負荷が急増し予測できない場合: on-demand。リクエスト単位の課金で、キャパシティプランニングは不要です。
- 負荷が安定していて予測できる場合: provisioned（使い切らなくても事前設定したキャパシティ分を課金）+ auto scaling。
- 長期にわたって安定したベース負荷がある場合: provisioned 分の reserved capacity を購入して割引を受けます。
Redshift RA3: コンピュートと managed storage を分離、Spectrum でデータレイクを読み取り
ステップ
- leader がクエリを受け取り、compute node に分割して並列実行します。課金されるのは compute node のみです。
- ローカル SSD を超えたデータは自動的に S3 上の managed storage に退避されます。node を増やさずにストレージを増やせます。
- Spectrum は、クラスターにロードせずに S3（データレイク）上のファイルを直接クエリします。
- クラスターを管理したくない場合: Redshift Serverless がコンピュートを自動で割り当て、スケールします。
比較表
Multi-AZ とリードレプリカ
| Multi-AZ（DB インスタンス） | リードレプリカ | |
|---|---|---|
| 目的 | 高可用性、フェイルオーバー | 読み取り負荷の分散、DR |
| レプリケーション | 同期 | 非同期 |
| 読み取り可否 | 不可（スタンバイ） | 可 |
| 範囲 | 別 AZ、同一リージョン | 同一 AZ、別 AZ、または別リージョン |
| プライマリ障害時 | 自動で切り替わり、エンドポイントは変わらない | 昇格が必要で、エンドポイントは新しくなる |
RDS と Aurora
| RDS | Aurora | |
|---|---|---|
| エンジン | MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2 | MySQL 互換、PostgreSQL 互換 |
| ストレージ | インスタンスにアタッチされた EBS、事前にサイズを割り当て（autoscaling あり） | 共有クラスターボリューム、3 つの AZ にコピー、自動拡張 |
| リードレプリカ | 最大 15 台（MySQL）、非同期 | 最大 15 台、通常 100 ms 未満、フェイルオーバー先 |
| マルチリージョン | クロスリージョンのリードレプリカ | Global Database（セカンダリリージョン最大 10 個、1 秒未満） |
DynamoDB: GSI と LSI
| GSI | LSI | |
|---|---|---|
| パーティションキー | ベーステーブルと異なる | ベーステーブルと同じ |
| 作成 | いつでも可 | テーブル作成時のみ |
| 上限 | テーブルあたり 20（既定、引き上げ申請可） | テーブルあたり 5 |
| 強い整合性のある読み取り | 不可 | 可 |
| キャパシティ | 独立した RCU / WCU | テーブルと共有、item collection は最大 10 GB |
キャッシュの選び方
| DAX | ElastiCache (Valkey / Redis OSS) | ElastiCache (Memcached) | |
|---|---|---|---|
| 利用対象 | DynamoDB のみ | あらゆるデータソース | あらゆるデータソース |
| コード修正 | ほぼ不要（SDK が DynamoDB API と互換） | 必要（cache-aside、write-through） | 必要 |
| レプリケーション / フェイルオーバー | あり（プライマリ 1 台 + レプリカ最大 10 台） | あり | なし |
| バックアップ、データ構造 | — | バックアップあり。sorted set、list、pub/sub など | バックアップなし（node 単位）。単純なキーバリューのみ、マルチスレッド |
データモデル別のデータベース
| 要件 | サービス |
|---|---|
| リレーショナル、トランザクション（OLTP） | RDS、Aurora |
| 大規模なキーバリュー / ドキュメント、安定したレイテンシー | DynamoDB |
| MongoDB 互換 | DocumentDB |
| グラフ（SNS、レコメンド、不正検出） | Neptune |
| Cassandra 互換 | Keyspaces |
| 時系列（IoT、メトリクス） | Timestream |
| データウェアハウス、分析（OLAP） | Redshift |
| インメモリキャッシュ | ElastiCache |
| 耐久性のある Redis をプライマリデータベースとして使う | MemoryDB |
よく出る出題パターン
1RDS MySQL データベースは、AZ に障害が起きたときに自動で別のマシンに切り替わり、アプリケーションは接続文字列を変更しなくて済む必要があります。
答えを見る
正解: Multi-AZ を有効にする
スタンバイは同期されており、障害時には RDS が同じ DNS 名をスタンバイに自動で向け直します。
不正解: 別の AZ にリードレプリカを作成する
レプリカは非同期で、手動で昇格する必要があり、エンドポイントも変わります。
2月末のレポートクエリが、注文データベース（RDS PostgreSQL）を遅くしています。
答えを見る
正解: リードレプリカを作成し、レポートツールはレプリカから読み取らせる
重い読み取り負荷をプライマリから切り離せます。
不正解: Multi-AZ を有効にする
スタンバイは読み取りを処理しません。
不正解: インスタンスサイズを大きくする
数日分の負荷のために 1 か月分の費用がかかります。
3Aurora 上のグローバルアプリケーションで、RPO 約 1 秒の別リージョン DR と、ヨーロッパでの低レイテンシー読み取りが必要です。
答えを見る
正解: ヨーロッパにセカンダリクラスターを置いた Aurora Global Database
レプリケーションは通常 1 秒未満で、セカンダリクラスターが現地で読み取りを処理し、プライマリリージョン障害時には昇格できます。
不正解: 毎日のスナップショットを別リージョンにコピーする
RPO が最大 24 時間になります。
4数千の Lambda 関数が同時に実行され、RDS が「too many connections」エラーを返します。
答えを見る
正解: Lambda と RDS の間に RDS Proxy を置く
Proxy が共有の接続プールを保持し、IAM / Secrets Manager に対応して、フェイルオーバーも速くなります。
不正解: max_connections とインスタンスサイズを増やす
上限を押し上げるだけで、接続の開閉を繰り返す問題は解決しません。
5商品ページが同じデータを RDS から毎秒数千回読み取っています。DB の負荷とレイテンシーを下げたい。
答えを見る
正解: cache-aside と TTL を使った ElastiCache（Valkey / Redis OSS）
メモリからマイクロ秒単位で読み取れ、DB にはキャッシュミスの読み取りだけが届きます。
不正解: DAX
DAX は DynamoDB 専用です。
6DynamoDB テーブルで同じアイテムが何度も繰り返し読まれています。キャッシュのロジックを書き直さずに、マイクロ秒台のレイテンシーが必要です。
答えを見る
正解: DynamoDB Accelerator（DAX）
DynamoDB API 互換の write-through キャッシュで、クライアントを切り替えるだけで使えます。
不正解: ElastiCache
キャッシュのロジックとデータ同期を自分で実装する必要があります。
7新しいアプリケーションで、トラフィックが予測できず（ゼロの時もあれば急増する時もある）、キャパシティプランニングをしたくありません。
答えを見る
正解: DynamoDB on-demand
リクエスト単位の課金で、負荷に自動で対応します。
不正解: auto scaling なしの DynamoDB provisioned
急増時にスロットリングされ、閑散時は無駄になります。
8DynamoDB テーブルのキーは customerId です。Scan を使わずに、状態（status）で注文を検索する必要が出てきました。
答えを見る
正解: status をパーティションキーとする GSI を作成する
GSI は別のキーを持て、テーブル作成後にも追加できます。
不正解: status に LSI を作成する
LSI はテーブル作成時にしか作れず、パーティションキーも customerId のままです。
不正解: フィルター付きの Scan
テーブル全体を読み取り、RCU を消費します。
9DynamoDB に新しい注文が入るたびに確認メールを送る必要があります。注文を書き込むコードは変更しません。
答えを見る
正解: DynamoDB Streams を有効にし、Lambda でストリームを処理する
アイテムの変更ごとにストリームレコードが作られ、Lambda がバッチで取得します。
不正解: スケジュール実行の Lambda でテーブルをスキャンする
遅延があり、Scan で RCU も消費します。
10SNS アプリで「共通の趣味を持つ友人の友人」を高速に検索する必要があります。
答えを見る
正解: Amazon Neptune
グラフデータベースで、複数ホップの関係を効率よくたどれます。
不正解: 多数の JOIN を使った RDS
多段の JOIN は、データが増えるほど遅くなります。
早見表
データベースとスケール方法をどう選ぶか
| やりたいこと | 使うもの |
|---|---|
| リレーショナル、1 リージョン内で高可用性が必要 | RDS Multi-AZ または Aurora · 図を見る |
| RDS / Aurora の読み取り負荷を減らす | リードレプリカ / Aurora Replica + reader endpoint · 図を見る |
| 別リージョンへの DR、RPO 約 1 秒 | Aurora Global Database · 図を見る |
| Lambda が接続を開きすぎる | RDS Proxy · 図を見る |
| RDS からの読み取りが多いデータのキャッシュ | ElastiCache（cache-aside） · 図を見る |
| DynamoDB 向けのマイクロ秒キャッシュ | DAX · 図を見る |
| 大規模なキーバリュー、安定したレイテンシー | DynamoDB（適切なキー設計、別のクエリには GSI） · 図を見る |
| DynamoDB のデータ変更時に処理を実行 | DynamoDB Streams + Lambda · 図を見る |
| 複数リージョンで同時に書き込み | DynamoDB Global Tables · 図を見る |
| グラフ、ドキュメント、時系列、データウェアハウス | Neptune、DocumentDB、Timestream、Redshift · 図を見る |
| オンプレミスのデータベースを低ダウンタイムで AWS に移行 | DMS（エンジン変更時は Schema Conversion も） |
落とし穴
- 読み取り負荷の分散に Multi-AZ のスタンバイを使う（単一インスタンスの Multi-AZ は読み取れません）。
- 同一リージョン内の自動 HA としてリードレプリカを使う（レプリカは昇格が必要で、エンドポイントも変わります）。
- RDS の自動バックアップを 35 日を超えて保持できると思い込む。
- 「コード修正なし」が強調されているのに、RDS に DAX、または DynamoDB に ElastiCache を使う。
- レプリケーション、バックアップ、sorted set が必要なのに Memcached を選ぶ。
- テーブル作成後に LSI を作ろうとする（不可）、または GSI で強い整合性のある読み取りを求める。
- 大きなテーブルで、値の種類が少ない属性（例: status）をパーティションキーに選ぶ（ホットパーティション、スロットリング）。
- 頻繁なクエリに Query + GSI ではなく Scan を使う。
- DynamoDB に 400 KB を超えるアイテムを保存する（ファイルは S3 に置き、パスを保存する）。
- 稼働中の未暗号化 RDS の暗号化をそのまま有効にできると思い込む（スナップショット経由が必要）。
- OLTP に Redshift、または数十億行の分析に RDS を使う。
- 複数リージョンから同時に書き込む負荷に RDS を使う（正解は DynamoDB Global Tables）。
このモジュールのサービス
変わりやすい数値 (AWS ドキュメントで確認済み)
- RDS はリードレプリカへ非同期でレプリケーションします。リードレプリカは別リージョンにも置け、独立した DB に昇格できます。RDS はリードレプリカの台数を自動でスケールしません。 2026-10-16 確認 ↗
- RDS for MySQL: 1 つのソース DB インスタンスにつき、同一リージョン内で最大 15 台のリードレプリカ。 2026-10-16 確認 ↗
- RDS の自動バックアップは 0～35 日保持されます（0 は無効）。既定は console で作成すると 7 日、API / CLI で作成すると 1 日です。 2026-10-16 確認 ↗
- Aurora のクラスターボリュームは 3 つの AZ にコピーを持ち、エンジンバージョンによって最大 256 TiB まで自動拡張します。 2026-10-16 確認 ↗
- Aurora Replica は最大 15 台。レプリケーション遅延は通常 100 ms 未満で、レプリカはフェイルオーバー先になります。 2026-10-16 確認 ↗
- Aurora Global Database: プライマリリージョン 1 つとセカンダリリージョン最大 10 個。レプリケーションは通常 1 秒未満です。 2026-10-16 確認 ↗
- DynamoDB: アイテムは最大 400 KB。1 RCU = 4 KB 以下のアイテムを毎秒 1 回の強い整合性のある読み取り（または結果整合性の読み取り 2 回）。1 WCU = 1 KB 以下のアイテムを毎秒 1 回の書き込み。トランザクションは 2 倍。 2026-10-16 確認 ↗
- DynamoDB: テーブルあたり LSI は最大 5 つ、GSI は既定で 20 個。 2026-10-16 確認 ↗
- DynamoDB の PITR は最大 35 日間を秒単位で復元できます（1～35 日で設定可能）。 2026-10-16 確認 ↗
- DAX: クラスターあたり、プライマリ node 1 つとリードレプリカ 0～10 台。 2026-10-16 確認 ↗
- ElastiCache Memcached はマルチスレッドで、レプリケーション / フェイルオーバーはありません。Valkey と Redis OSS はレプリケーション、フェイルオーバー、pub/sub、sorted set、バックアップに対応します。 2026-10-16 確認 ↗
- RDS の特定時点への復元は新しい DB インスタンスを作成し、元のインスタンスは変更しません。RDS はトランザクションログを 5 分ごとに S3 へ送信します。 2026-10-19 確認 ↗
- RDS の暗号化は作成時にしか有効にできません。既存のインスタンスを暗号化するには、暗号化付きでスナップショットをコピーして復元します（または blue/green）。暗号化を無効にすることはできません。 2026-10-19 確認 ↗
- Aurora Serverless v2: 1 ACU ≈ 2 GiB の RAM。範囲は 0～256 ACU（0 ACU = 自動一時停止、エンジンバージョンによる）。クラスター内に serverless と provisioned を混在させられます。 2026-10-19 確認 ↗
- DynamoDB: on-demand が推奨される既定のモードです。reserved capacity は Standard クラスの provisioned テーブルのみが対象で、期間は 1 年（一部リージョンでは 3 年）です。 2026-10-19 確認 ↗
- Redshift RA3 / RG は managed storage（ローカル SSD + S3）を使い、compute とストレージは別々に課金されます。課金対象は compute node のみで、leader node は課金されません。 2026-10-19 確認 ↗