SAA 06 データベース(RDS・Aurora・DynamoDB・ElastiCache)

更新日: 2026-10-25

← SAA_05_ストレージ(S3・EBS・EFS・FSx) / 次 → SAA_07_疎結合と分析(SQS・SNS・EventBridge・Kinesis・Athena)

選び方の全体像

欲しいもの	サービス
リレーショナル(SQL・JOIN・トランザクション)を手軽に	RDS
リレーショナルで、もっと速く・高可用性に	Aurora
キーで超高速に読み書き、無制限にスケール、サーバーレス	DynamoDB
DB の前に置くキャッシュ(ミリ秒以下)	ElastiCache
大量データの分析(データウェアハウス)	Redshift
ドキュメント DB(MongoDB 互換)	DocumentDB
グラフ(関係のつながり)	Neptune
時系列データ	Timestream
Cassandra 互換	Keyspaces

RDS

対応エンジン:MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2(+ Aurora)。
AWS がバックアップ・パッチ・フェイルオーバーを担当する。OS には入れない(入りたいなら RDS Custom か EC2 に自分で DB)。

マルチAZ とリードレプリカ(最頻出の区別)

図を表示しています…

【マルチAZ】 可用性のため
  AZ-a: プライマリ ══同期レプリケーション══▶ AZ-c: スタンバイ(読めない)
        障害時は DNS が自動で切り替わる(1〜2分)
 
【リードレプリカ】 読み取り性能のため
  プライマリ ──非同期──▶ レプリカ1(読める)
                └──────▶ レプリカ2(別リージョンにも置ける)

	マルチAZ	リードレプリカ
目的	高可用性・自動フェイルオーバー	読み取りの負荷分散
レプリケーション	同期	非同期(少し遅れる)
読み取りに使えるか	使えない(※マルチAZ DB クラスターは読める)	使える
別リージョン	不可	可(DR にも使える)

→ 「読み取りが多くて遅い」= リードレプリカ(またはキャッシュ)、「AZ 障害でも止めたくない」= マルチAZ。

その他

自動バックアップ:最大35日、ポイントインタイムリカバリ(秒単位で戻せる)
手動スナップショット:消すまで残る。別リージョンにコピーできる
暗号化:作成時にしか有効にできない → 暗号化していない DB は、スナップショット → 暗号化コピー → 復元
RDS Proxy:接続をまとめて使い回す。Lambda からの大量接続、フェイルオーバー時間の短縮
IAM データベース認証:パスワードの代わりに IAM で接続
ストレージの自動拡張

Aurora

MySQL / PostgreSQL 互換。AWS が作り直したクラウド用 DB
3つの AZ に6つのコピーを自動で保存。容量は自動で増える
リードレプリカ最大15台、フェイルオーバーが速い。リーダーエンドポイントで読み取りを分散

機能	用途	キーワード
Aurora Serverless v2	負荷に応じて自動で容量を伸び縮み	「負荷が予測できない」「たまにしか使わない」
Aurora Global Database	別リージョンに通常1秒未満で複製。リージョン障害時に1分程度で昇格	「RPO 秒、RTO 分のリージョン DR」「世界中で低遅延の読み取り」
Aurora クローン	本番のコピーを素早く作る(書き換えた分だけ容量を使う)	「本番データでテスト環境」
バックトラック	時間を巻き戻す(MySQL 互換のみ)	「誤操作の直前に戻す」

DynamoDB

NoSQL(キーバリュー)。サーバーレス、1桁ミリ秒の応答、どれだけ増えてもスケール
パーティションキー(+ソートキー)で検索。JOIN や複雑な SQL は苦手
1アイテム最大 400KB(大きいデータは S3 に置いてキーだけ保存)

機能	用途	キーワード
オンデマンド / プロビジョンド	使った分だけ / 容量を決めて安く(Auto Scaling 可)	「予測不能」/「安定した負荷」
DAX	DynamoDB 専用のインメモリキャッシュ。マイクロ秒	「読み取りをさらに速く」
グローバルテーブル	複数リージョンで読み書き両方できる(マルチアクティブ)	「世界中で書き込み」
DynamoDB Streams	変更をイベントとして流す → Lambda で処理	「データが変わったら通知」
TTL	期限が来たアイテムを自動削除(無料)	「セッションデータを自動で消す」
PITR	過去35日の任意の時点に戻せる	「誤更新からの復旧」
GSI / LSI	別のキーで検索するためのインデックス	「パーティションキー以外で検索したい」

ElastiCache

DB の前に置くインメモリキャッシュ。読み取りを速くし、DB の負荷を下げる。

エンジン	特徴
Redis OSS / Valkey	複製・マルチAZ・永続化・バックアップ、ソート済みセット(ランキング)、Pub/Sub
Memcached	シンプル・マルチスレッド。複製や永続化はなし

→ 「ゲームのリーダーボード」= Redis のソート済みセット、「セッション情報を複数サーバーで共有」= ElastiCache(または DynamoDB)。

キャッシュの戦略

遅延読み込み(Lazy Loading):キャッシュになければ DB から読んで入れる
書き込みスルー(Write-through):DB に書くとき同時にキャッシュも更新
TTL を付けて古いデータを残さない

移行

DMS(Database Migration Service):DB を止めずに移行・継続的に複製
SCT(Schema Conversion Tool):エンジンが違う移行(Oracle → Aurora PostgreSQL)でスキーマを変換

確認ポイント

マルチAZ とリードレプリカの違いを図で説明できる
RDS の暗号化を後から有効にする手順を言える
Aurora Global Database と DynamoDB グローバルテーブルの使いどころを言える
DAX と ElastiCache の違い(DynamoDB 専用か)を言える
RDS Proxy が必要な場面を言える