データベース — RDS / Aurora / DynamoDB / Redshift | AWSコンポーネント詳解

分析用にRedshiftの導入を検討していたら、気づけばAuroraのリードレプリカで済む規模だったということがある。データベースの選定では「将来の規模」を過大に見積もりがちで、その感覚のズレを調整しておきたい。

RDS — マネージドリレーショナルDB

AWSデータベースサービス詳解（RDS/Aurora/DynamoDB/Redshift）

図1: RDS・Aurora・DynamoDB・Redshift の用途別配置

Amazon RDS（Relational Database Service） は MySQL・PostgreSQL・MariaDB・Oracle・SQL Server をマネージドで提供するサービスです。 OS のパッチ適用・バックアップ・フェイルオーバーを AWS が自動管理するため、 DBA の運用負担を大幅に削減できます。

マルチAZ 配置

プライマリとスタンバイを別 AZ に配置し、AZ 障害時に数分以内で自動フェイルオーバーする。本番環境での採用を強く推奨。

リードレプリカ

読み取り専用レプリカを1〜5台作成し、READ トラフィックを分散できる。Aurora と異なり非同期レプリケーション。

RDS Proxy

Lambda など大量の短命接続を持つアプリのための接続プーリングサービス。コネクション枯渇を防ぎ、フェイルオーバーを透過的に処理する。

自動バックアップ

最大35日間の自動バックアップ + PITR（ポイントインタイムリカバリ）で任意の時点に復元可能。

Aurora — 高可用・高性能 RDB

Amazon Aurora は MySQL/PostgreSQL 互換の AWS 独自 RDB エンジンです。ストレージを6つのコピーに分散保存（3 AZ × 2 コピー）することで、標準 MySQL の最大5倍の書き込みスループットを実現します。

機能	内容
Aurora Serverless v2	ACU（Aurora Capacity Unit）でキャパシティを自動スケール。アイドル時のコストを最小化できる
Global Database	複数リージョンにまたがるリードレプリカを作成し、DR構成や地理的分散読み取りを実現
フェイルオーバー	30秒以内のフェイルオーバー（標準 RDS の数分より高速）
リードレプリカ	最大15台のリードレプリカを同一クラスターに追加可能。同期レプリケーション
ストレージ	10GB から最大128TB まで自動拡張。事前プロビジョニング不要

✅ RDS vs Aurora の判断

新規構築で MySQL/PostgreSQL 互換 RDB を選ぶなら Aurora が基本推奨です。Oracle / SQL Server など商用 DB ライセンスが必要な場合のみ RDS を選択します。Aurora Serverless v2 で開発環境のコストも抑えられます。

DynamoDB — サーバーレス NoSQL

Amazon DynamoDB はフルマネージドのサーバーレス NoSQL データベースです。任意のスケールで1ケタ ms のレイテンシーを保証し、 1日に数十兆件のリクエストを処理する実績があります。

スキーマレス

テーブルには主キー（パーティションキー + ソートキー）のみ事前定義が必要。その他の属性はアイテムごとに自由に定義できる。

オンデマンド vs プロビジョンド

オンデマンドモードはトラフィック変動に自動対応。プロビジョンドモードは事前にキャパシティを指定しコストを予測可能にできる。

DynamoDB Streams

テーブルの変更イベントをキャプチャして Lambda に連携できる。イベント駆動アーキテクチャのトリガーとして活用される。

DAX（インメモリキャッシュ）

DynamoDB 専用のインメモリキャッシュ層。マイクロ秒レベルのレイテンシーが必要な場合に利用。

⚠️ DynamoDB の設計上の注意

アクセスパターンを事前に決めてから設計する必要があります。後から複雑なクエリを追加すると、テーブル設計を見直す必要が生じます。JOIN が必要なリレーショナルなデータモデルには向きません。

Redshift — データウェアハウス

Amazon Redshift は列指向の分散処理データウェアハウスです。ペタバイト規模のデータに対する複雑な分析クエリを高速に実行できます。 S3 上のデータを直接クエリする Redshift Spectrum と組み合わせることで、データレイクとDWHを統合した分析基盤を構築できます。

ElastiCache — インメモリキャッシュ

Amazon ElastiCache は Redis または Memcached をマネージドで提供するインメモリキャッシュサービスです。 DB への繰り返しクエリをキャッシュしてレイテンシーを下げ、バックエンド DB の負荷を軽減します。

比較項目	Redis	Memcached
データ構造	String / Hash / List / Set / Sorted Set など豊富	シンプルな Key-Value のみ
永続化	あり（RDB / AOF）	なし（メモリのみ）
レプリケーション	あり（Primary + Replica）	なし
用途	セッション管理・ランキング・パブサブ・キューなど多用途	シンプルなオブジェクトキャッシュ

比較表

サービス	種別	代表的な用途	スケーリング
RDS	マネージドRDB	既存アプリのDB移行・業務トランザクション	垂直スケール + リードレプリカ
Aurora	高可用RDB	高可用・高性能が必要なWebアプリDB	Aurora Serverless v2 で自動スケール
DynamoDB	サーバーレスNoSQL	サーバーレスAPI・IoT・ゲームスコア	自動水平スケール
Redshift	データウェアハウス	BI・大規模分析クエリ	クラスターノード追加
ElastiCache	インメモリキャッシュ	セッション・DBキャッシュ・ランキング	クラスターシャーディング

選択フロー

🔀 Step 1 — 分析用途か？（大規模 SELECT クエリ・BIツール連携）

Yes → Redshift。ペタバイト規模の分析に特化したDWH。No → 次へ。

🔀 Step 2 — リレーショナルデータモデルが必要か？（JOIN・ACID トランザクション）

Yes → Aurora（新規）または RDS（商用DB必要時）。No → 次へ。

🔀 Step 3 — 超高スループット / 低レイテンシー / スキーマ柔軟性が必要か？

Yes → DynamoDB。アクセスパターンが決まっており、水平スケールが必要な場合に最適。

🔀 Step 4 — DB クエリの高速化が目的か？

Yes → ElastiCache（Redis） をキャッシュ層として追加。

AWSデータベース選定でよくある誤り

RDS・Aurora・DynamoDBなどDBサービスの選択ミスは、後から移行コストが高くなります。

誤り/失敗パターン	何が起きるか	正しい対処/防止策
RDSをシングルAZ構成で本番運用する	AZ障害時にDBがダウンしサービス停止になる	本番環境はMulti-AZ配置を有効化してフェイルオーバーを自動化する
DynamoDBをRDBの代替として使いJOINが必要な設計をする	DynamoDBはJOINをサポートしておらずアプリ側で複数クエリが必要になり複雑化する	複雑なリレーション・JOINが必要なデータはRDS/Auroraを使いDynamoDBはシンプルなKV/ドキュメント操作に使う
RDS自動バックアップの保持期間をデフォルト（1日）のまま運用する	障害時に1日以上前のデータしか復元できない	保持期間をビジネス要件に合わせて7〜35日に設定する

PART 04 — データベース
RDS / Aurora / DynamoDB / Redshift / ElastiCache