AWS DB サービスの全体像

AWS のデータベースサービスは用途別に多数存在するが、移行で主に検討するのは以下の4つだ。

サービス種別対応するオンプレ主な用途
Amazon RDSリレーショナルMySQL / PostgreSQL / Oracle / SQL Server / MariaDBOLTP・汎用業務DB
Amazon AuroraリレーショナルMySQL / PostgreSQL（互換）高性能・高可用性が必要なOLTP
Amazon DynamoDBNoSQL（KV/ドキュメント）MongoDB / Redis（一部）/ Cassandra大規模・高スループット・スキーマレス
Amazon ElastiCacheインメモリ（キャッシュ）Redis / Memcachedキャッシュ・セッション管理・リアルタイム集計

判断フロー

Q1. データはリレーショナル（テーブル構造・JOIN が必要）か？
　├─ Yes → Q2 へ
　└─ No（KV / ドキュメント / 非構造化）→ Q4 へ

Q2. 既存のDBエンジンをそのまま使いたいか？（Oracle / SQL Server など）
　├─ Yes（エンジン固定が必要）→ RDS（該当エンジン）
　└─ No（MySQL / PostgreSQL 互換で可）→ Q3 へ

Q3. 性能・可用性を最大化したいか？
　├─ Yes（高スループット・自動フェイルオーバー・Global Database等）→ Aurora
　└─ 普通でよい → RDS（MySQL or PostgreSQL）

Q4. キャッシュ・セッション管理が主な用途か？
　├─ Yes → ElastiCache（Redis）
　└─ No → Q5 へ

Q5. スケールが読めない / 大量データ / スキーマが変動するか？
　├─ Yes → DynamoDB
　└─ 検索・全文検索が主 → OpenSearch Service

RDS を選ぶとき

Amazon RDS はオンプレの DB エンジンをそのままマネージドサービスとして使える。 移行の観点では Replatform 戦略の代表格 だ。 アプリのコードは DB 接続先を変えるだけで、OS パッチ・バックアップ・フェイルオーバーは AWS が管理してくれる。

サポートエンジン： MySQL / PostgreSQL / MariaDB / Oracle / SQL Server / IBM Db2

RDS の主な特徴：

  • 自動バックアップ（最大35日保持）、ポイントインタイムリカバリ
  • Multi-AZ 配置で自動フェイルオーバー（RPO/RTO を最小化）
  • Read Replica でリードスケールアウト
  • Performance Insights で SQL レベルのパフォーマンス可視化

⚠️ Oracle / SQL Server のライセンス注意

Oracle や SQL Server を RDS で使う場合、ライセンスモデルが2種類ある。「License Included」はライセンス込みの時間課金で手軽だが、エンタープライズ版は使えない機能もある。「BYOL（Bring Your Own License）」は既存ライセンスを持ち込む形で、エディションの制約が少ない。既存のライセンス契約を確認してから選択しよう。

Aurora を選ぶとき

Amazon Aurora は MySQL / PostgreSQL と互換性を持ちながら、AWS が独自開発したストレージエンジンを採用した高性能 DB だ。 通常の MySQL RDS に比べ最大5倍、PostgreSQL RDS に比べ最大3倍のスループットを発揮する。

Aurora を選ぶ判断基準：

  • ピーク時に大量の読み書きが発生する（OLTP ヘビー）
  • フェイルオーバー時間を最小化したい（Aurora は通常30秒以内）
  • マルチリージョン構成（Aurora Global Database）が必要
  • Aurora Serverless v2 でトラフィックに応じて自動スケールさせたい

RDS vs Aurora の選び方

観点RDS（MySQL/PostgreSQL）Aurora
コスト相対的に安いRDS より高い（性能分）
性能標準的最大5倍（MySQL互換比）
フェイルオーバー60〜120秒程度通常30秒以内
エンジン互換性完全互換（OSS と同じ）MySQL/PostgreSQL と高互換（一部挙動差あり）
ServerlessなしAurora Serverless v2 あり
向いているケース低〜中負荷・コスト重視高負荷・高可用性が必要

💡 判断の目安

「月10万円以上の DB コストが見込まれ、かつ高可用性が必要」なら Aurora の性能向上分がコスト差を上回ることが多い。小〜中規模・開発環境は RDS で十分なことが多い。

DynamoDB を選ぶとき

DynamoDB は Key-Value / ドキュメント型の NoSQL で、スケールが読めない大規模ワークロードに強い。 テーブルスキーマが柔軟で、1桁ミリ秒の一貫したレイテンシを保ちながら自動スケールする。

向いているケース：

  • ユーザーセッション・ゲームプレイデータ・IoT センサーデータなど大量 KV データ
  • アクセスパターンが単純（主キー・インデックスでの検索が中心）
  • スキーマが変動しやすい（アジャイル開発）
  • グローバルテーブルでマルチリージョンレプリケーションが必要

DynamoDB の注意点：

  • JOIN は使えない。複雑なリレーション処理には向かない
  • トランザクションは限定的（TransactWriteItems 等、ただし RDB ほど柔軟でない）
  • テーブル設計時にアクセスパターンを先に決める必要がある（後から変えにくい）

ElastiCache を選ぶとき

ElastiCache はインメモリ DB のマネージドサービスで、Redis と Memcached に対応する。 オンプレで Redis や Memcached を使っていた場合の Replatform 先として最も一般的だ。

主な用途：

  • DB クエリキャッシュ：重いクエリ結果を Redis にキャッシュしてレスポンスを高速化
  • セッション管理：EC2/ECS のスケールアウト時に共有セッション保持
  • リアルタイム集計・ランキング：Redis の Sorted Set を活用
  • Pub/Sub メッセージング：軽量なメッセージブローカーとして

💡 Redis vs Memcached の選び方

基本的に Redis を選べば問題ない。データ構造（List/Set/Hash/Sorted Set）・永続化・Pub/Sub・クラスタリングなど機能が豊富。Memcached を選ぶのは「シンプルなキャッシュのみ・水平スケールをできるだけ単純にしたい」場合に限られる。

DB 移行ツール：DMS の活用

オンプレ DB を AWS に移行する際に使うのが AWS Database Migration Service（DMS） だ。 ソース DB からターゲット DB へのデータ転送を管理し、移行中もソース DB を稼働させながら移行できる（ダウンタイム最小化）。

DMS の主な機能：

  • フルロードマイグレーション：既存データを一括移行
  • CDC（Change Data Capture）：移行中の差分を継続同期し、カットオーバー時のダウンタイムを最小化
  • Schema Conversion Tool（SCT）：Oracle → Aurora などの異種 DB 移行時にスキーマ・SQL を変換

実務での判断ポイント

  • 既存クエリの互換性：Oracle 固有の SQL 構文（ROWNUM、ヒント句など）を大量に使っている場合、Aurora/RDS への移行は SQL 書き換えコストが発生する。DMS の SCT で自動変換できる割合を事前に確認
  • 接続数の見積もり：RDS/Aurora はコネクション数上限があるため、ECS や Lambda からの接続が多い場合は RDS Proxy を挟んでコネクションプーリングを行う
  • DynamoDB のキャパシティモード：「オンデマンド（従量課金）」と「プロビジョンド（上限設定）」を選択できる。開発・テスト環境はオンデマンド、本番は予測可能な場合プロビジョンドが割安

✅ 次の章では…

PART 04 ではストレージの選び方を解説する。EBS・EFS・S3 の用途の違いと、オンプレの NAS / SAN / ファイルサーバーに対応する選択肢を整理する。

→ PART 04 — ストレージの選び方へ