EC2 で1台のサーバーを立てられるようになると、次に「データはどこに置くのか」で手が止まります。EC2 に MySQL を入れれば動きはします。ただ、教材や試験の問題では、ほぼ決まって Amazon RDS が出てきます。「RDS はマネージドだから楽」と説明されても、何が楽になって、何が自分に残るのかが言えないと、マルチ AZ とリードレプリカの問題で迷います。
この記事は、RDS が引き受ける作業と利用者に残る作業を1枚の積み木で分けたうえで、EC2 に自分で DB を置く場合との責任の違い、Aurora と DynamoDB がどこに位置するかまでを整理します。
この記事の結論
- Amazon RDS は、リレーショナルデータベースを動かす土台（OS・DB エンジンの更新・バックアップ・冗長化）を AWS が運用するマネージドサービスです。
- RDS を使っても、テーブルの設計・SQL・アクセス権・バックアップの保持期間やマルチ AZ にするかどうかの判断は利用者に残ります。
- マルチ AZ 配置は「止まりにくくする」ための仕組みで、リードレプリカは「読み取りを分散する」ための仕組みです。目的が違います。
- EC2 に DB を自分で入れると、ゲスト OS のパッチからバックアップ・冗長化の仕組みまで利用者の責任になります。
- Aurora は RDS の仲間で MySQL・PostgreSQL 互換のエンジン、DynamoDB はリレーショナルではない NoSQL のデータベースです。
Amazon RDS とは（何を借りるサービスか）
Amazon RDS（Amazon Relational Database Service）は、表の形でデータを持ち、SQL で読み書きするリレーショナルデータベースを、AWS 上で動かすためのマネージドサービスです。エンジンは MySQL・PostgreSQL・MariaDB・Oracle・SQL Server・Db2 から選べます。
たとえると、RDS は「管理人つきのデータベースの部屋」を借りる形です。建物の設備の点検や、鍵のかかった倉庫への控えの保管は管理人がやってくれます。一方で、部屋に何をどう並べるか、合鍵を誰に渡すかは借りた人が決めます。
正確な言葉に戻すと、RDS で利用者が作るのは DB インスタンスです。DB インスタンスは EC2 と同じように「インスタンスクラス（CPU とメモリの大きさ）」と「ストレージ」を選んで作りますが、中の OS にログインすることはできません。公式ドキュメントも、マネージドの体験を保つために DB インスタンスへのシェルでのアクセスを提供せず、高い権限が要る一部のシステムの手続きやテーブルへのアクセスも制限すると説明しています。利用者は、エンドポイント（接続先の名前）に SQL のクライアントやアプリから接続して使います。
「中に入れない」ことは不便に見えますが、裏返すと OS の面倒を見なくてよいということです。ここが EC2 との一番大きな違いで、次の章の「何を引き受けてくれるのか」はすべてここから出てきます。
WHAT YOU OWNどこまで任せるか
RDS にすると、自分でやるのはデータと権限だけになる
オンプレミス
- 設備・ハードウェア
- OS のパッチ
- DB ソフトの導入と更新
- バックアップ
- 別 AZ への冗長化
- テーブル設計・SQL
- データとアクセス権
EC2 に自分で置く
- 設備・ハードウェア
- OS のパッチ
- DB ソフトの導入と更新
- バックアップ
- 別 AZ への冗長化
- テーブル設計・SQL
- データとアクセス権
Amazon RDS
- 設備・ハードウェア
- OS のパッチ
- DB ソフトの導入と更新
- バックアップ
- 別 AZ への冗長化
- テーブル設計・SQL
- データとアクセス権
自分でやるAWS がやる
「マネージド」は何を引き受けてくれるのか？
RDS が引き受ける作業と、利用者に残る作業を並べると次のようになります。ポイントは、作業は AWS が回しても、どう回すかの設定を決めるのは利用者だということです。
| 作業 | RDS が引き受けること | 利用者に残ること |
|---|---|---|
| バックアップ | 日次の自動バックアップと、トランザクションログの保存 | 保持期間を決める（0 日にすると自動バックアップが止まる）。長く残したいものは手動のスナップショットを取る |
| 復元 | 保持期間内の任意の時点への復元（ポイントインタイムリカバリ） | いつの時点に戻すかを決め、復元先の新しい DB インスタンスにアプリを向ける |
| OS と DB エンジンの更新 | メンテナンスウィンドウの中で、OS の更新やマイナーバージョンの更新を当てる | メンテナンスウィンドウの時間帯を決める。メジャーバージョンの更新の時期を決める |
| 障害への備え | マルチ AZ 配置なら、別の AZ のスタンバイへ自動で切り替える | マルチ AZ にするかどうかを決める（費用が増える） |
| 読み取りの分散 | リードレプリカへの非同期の複製 | リードレプリカを作るか、アプリが参照をどちらへ送るかを決める |
| データと権限 | ― | テーブルの設計、SQL、DB ユーザーの権限、セキュリティグループで誰に接続を許すか |
自動バックアップと、ポイントインタイムリカバリ
自動バックアップを有効にすると、RDS は日次のバックアップに加えてトランザクションログを保存し、保持期間の中の任意の時点に戻せるようにします。保持期間は最長 35 日で、0 日にすると自動バックアップは無効になります。
保持期間を過ぎたものは消えるので、「リリース前の状態を半年残したい」ような用途には手動の DB スナップショットを使います。手動スナップショットは、利用者が削除するまで残ります。
パッチとメンテナンスウィンドウ
OS の更新や DB エンジンのマイナーバージョンの更新は、利用者が決めたメンテナンスウィンドウの時間帯に当てられます。ただし公式ドキュメントは、メンテナンスの一部は DB インスタンスを短時間オフラインにすること、ウィンドウは「始まる時間」を決めるもので終わる時間を保証しないことを書いています。夜間の空いた時間帯を選んでおくのは、利用者の判断として残ります。
CHECK 1ここまでの確認
RDS を使っても利用者の側に残る作業はどれ?
答えと解説
答え: 2. テーブルの設計と、どのユーザーに何の権限を渡すかの決定
RDS が引き受けるのは「DB を動かす土台」の作業です。中に置くデータの設計と、誰に何を許すかは利用者の仕事として残ります。「マネージドは何を引き受けるのか」の表を読み直してください。
マルチ AZ とリードレプリカは何が違うのか？
名前が似ていて混同しやすいのが、この2つです。目的が違うので、片方でもう片方の代わりはできません。
AVAILABILITY VS READ SCALE似た名前の2つ
マルチ AZ は止まりにくく、リードレプリカは読み取りを分ける
マルチ AZ 配置
可用性のため
- 別 AZ のスタンバイへ同期で複製
- 障害時は自動で切り替わる
- 接続先の名前は変わらない
- スタンバイは読み取りを受けない
リードレプリカ
読み取りの分散のため
- 非同期で複製する
- 参照の問い合わせを受ける
- 別リージョンにも置ける
- 昇格させると独立した DB になる
マルチ AZ 配置は「止まりにくくする」
マルチ AZ 配置（DB インスタンスの場合）では、RDS が別の AZ にスタンバイを用意し、プライマリから同期で複製し続けます。プライマリの障害や AZ の障害が起きると、RDS は DB インスタンスの DNS の記録をスタンバイに向け直して自動で切り替えます（フェイルオーバー）。接続先のエンドポイントの名前は変わらないので、アプリの設定を書き換える必要はありません。ただし、つながっていた接続は張り直しになります。
大事なのは、このスタンバイは読み取りの問い合わせを受けないことです。スタンバイは「待っている予備」で、負荷を分ける役ではありません。なお、読み取りも受けられるスタンバイを2つ持つ「マルチ AZ DB クラスター」という別の形もあります。
リードレプリカは「読み取りを分散する」
リードレプリカは、プライマリの変更を非同期で複製した読み取り専用のコピーです。一覧ページや集計のような参照の問い合わせをリードレプリカに向けると、プライマリの負荷を下げられます。非同期なので、プライマリで書いた直後の値がまだ届いていないこと（レプリカの遅れ）があります。
リードレプリカは別のリージョンにも置けて、必要なときに昇格させると独立した DB インスタンスになります。この性質を使って、リージョン単位の障害への備え（DR）にも使えます。ただし昇格は手動の判断で、マルチ AZ のような自動の切り替えではありません。
| 見る点 | マルチ AZ 配置（DB インスタンス） | リードレプリカ |
|---|---|---|
| 目的 | 障害時に止まりにくくする（可用性） | 読み取りの負荷を分ける（性能） |
| 複製の方式 | 同期 | 非同期 |
| 予備は読み取りを受けるか | 受けない | 受ける |
| 障害時 | 自動でスタンバイへ切り替わり、エンドポイントは同じ | 自動では切り替わらない。昇格させると独立した DB になる |
| 置ける場所 | 同じリージョンの別の AZ | 同じリージョン、または別のリージョン |
CHECK 2ここまでの確認
参照の問い合わせが多すぎてプライマリが重いとき、まず検討するのはどちら?
答えと解説
答え: 2. リードレプリカを作り、参照系の問い合わせをそちらへ向ける
マルチ AZ 配置（DB インスタンス）のスタンバイは、障害に備えて待つ役で、読み取りの問い合わせは受けません。読み取りを分けるのはリードレプリカの役割です。「マルチ AZ とリードレプリカ」の章を読み直してください。
EC2 に DB を自分で置く場合と、責任はどう変わるか？
同じ MySQL は、EC2 に自分でインストールしても動きます。違うのは、動かし続けるための作業を誰が持つかです。AWS の責任共有モデルは「クラウド”の”セキュリティは AWS、クラウド”内の”セキュリティは利用者」と整理していて、どこまでが「クラウドの」側に入るかは、サービスの種類によって変わります。
| 作業 | EC2 に自分で入れた MySQL | Amazon RDS for MySQL |
|---|---|---|
| ゲスト OS のパッチ | 利用者 | AWS（OS に入れない代わりに、OS の面倒を見なくてよい） |
| DB ソフトの導入と更新 | 利用者 | AWS がメンテナンスウィンドウで当てる（時期の判断は利用者） |
| バックアップ | EBS のスナップショットやダンプを自分で仕組む | 自動バックアップと、保持期間内の時点への復元がある |
| 別の AZ への冗長化 | レプリケーションと切り替えの仕組みを自分で組む | マルチ AZ 配置を選ぶと自動で切り替わる |
| OS の中の自由度 | 高い。OS の設定や独自の拡張も入れられる | 低い。OS に入れず、使える設定と機能は RDS が用意した範囲 |
| テーブル設計・SQL・権限 | 利用者 | 利用者 |
表の最後の行が示すように、どちらを選んでもデータの中身と権限は利用者の責任です。RDS は「DB の管理者が要らなくなる」サービスではなく、OS と DB エンジンの面倒と、その上の仕組みづくりを減らすサービスだと捉えるのが正確です。
EC2 に自分で置く理由があるのは、RDS が対応していないエンジンや拡張を使いたいとき、OS の中の設定まで触る必要があるときです。そうでなければ、学習の段階では RDS から始めると、バックアップや冗長化の考え方を「設定の選択」として学べます。
READ ALSO — 未経験向け・段1 入口
EC2 とは何か｜インスタンス・AMI・EBS・セキュリティグループを「借りた1台」で理解する
CHECK 3ここまでの確認
同じ MySQL を EC2 に自分で入れて動かす場合、RDS と比べて何が変わる?
答えと解説
答え: 1. OS のパッチ、DB の導入と更新、バックアップと冗長化の仕組みまで、自分で用意して回すことになる
EC2 で AWS が持つのは仮想サーバーの土台までで、ゲスト OS から上は利用者の責任です。「EC2 に DB を自分で置く場合」の表を読み直してください。
Aurora と DynamoDB はどこに位置するのか？
RDS を学ぶと、隣に Aurora と DynamoDB が出てきます。入口として、3つの位置関係だけを押さえておきます。
WHERE EACH SITSDB の置き方の地図
RDS の隣に、Aurora と DynamoDB がある
-
自前
EC2 に自分で置く — OS から上をすべて自分で持つ
自由度は高いが、パッチ・バックアップ・冗長化も自分で
-
RDS
Amazon RDS — エンジンを選び、土台の運用を任せる
MySQL・PostgreSQL・MariaDB・Oracle・SQL Server・Db2
-
Aurora
Amazon Aurora — RDS の仲間の互換エンジン
ストレージを3つの AZ にまたがって複製する
-
NoSQL
Amazon DynamoDB — 表と SQL ではなく、キーで読み書き
サーバーレス。インスタンスの大きさを選ばない
Aurora は「RDS の仲間の、クラウド向けに作り直したエンジン」
Amazon Aurora は、MySQL または PostgreSQL と互換のリレーショナルデータベースで、RDS と同じ画面と API で扱います。違いはストレージの作りです。Aurora の DB クラスターは、データを1つのリージョンの3つの AZ にまたがって複製したクラスターボリュームに置き、書き込み用のプライマリと、同じボリュームを読む Aurora レプリカ（最大 15 台）を持てます。
既存の MySQL や PostgreSQL のアプリを大きく書き換えずに、可用性と読み取りの伸びしろを上げたいときの候補になります。
DynamoDB は「表と SQL ではない」データベース
Amazon DynamoDB は、サーバーレスでフルマネージドの NoSQL データベースです。表の結合や自由な SQL で集計するのではなく、キーを指定して項目を読み書きする形で使います。サーバーやインスタンスの大きさを選ぶ場面がなく、アクセスの量に合わせて伸び縮みさせる使い方に向きます。
「リレーショナルか、そうでないか」の違いは、エンジンの好みではなく、データの持ち方と問い合わせの形で決まります。どれを選ぶかの判断は設計の段で扱います。
| Amazon RDS | Amazon Aurora | Amazon DynamoDB | |
|---|---|---|---|
| 種類 | リレーショナル（SQL） | リレーショナル（MySQL・PostgreSQL 互換） | NoSQL（キーで読み書き） |
| 利用者が選ぶもの | エンジン・インスタンスクラス・ストレージ | エンジン・インスタンス（サーバーレスの構成もある） | テーブルのキーの設計と、容量の扱い方 |
| 止まりにくさの作り | マルチ AZ 配置を選ぶ | ストレージが3つの AZ にまたがって複製される | サービスの側で複数の AZ にまたがる |
| 向く場面 | 既存の DB をそのまま移す、エンジンを選びたい | リレーショナルのまま可用性と読み取りを伸ばしたい | キーで引くアクセスが大量にある |
まとめ
- RDS は、リレーショナルデータベースの土台の運用を AWS に任せるマネージドサービスで、OS には入れない代わりに OS の面倒を見なくて済みます。
- バックアップ・パッチ・冗長化の「作業」は RDS が回しますが、保持期間・メンテナンスウィンドウ・マルチ AZ にするかの「判断」は利用者に残ります。
- マルチ AZ 配置は可用性、リードレプリカは読み取りの分散のための仕組みで、スタンバイは読み取りを受けません。
- EC2 に自分で DB を置くと、ゲスト OS のパッチから冗長化の仕組みまでが利用者の責任になります。
- Aurora は RDS の仲間の MySQL・PostgreSQL 互換エンジン、DynamoDB は NoSQL で、どれを選ぶかは可用性・費用・手間のトレードオフとして次の段で判断します。
READ ALSO — プロフェッショナル向け・段4 設計
トレードオフの考え方｜「なぜそのサービスか」を根拠つきで説明する型と、Well-Architected の6本柱の使い方
参照ソース
- What is Amazon Relational Database Service (Amazon RDS)? — RDS の定義と対応エンジン、マネージドの範囲（2026年9月時点の AWS 公式ドキュメント）
- Amazon RDS for MySQL — DB インスタンスへのシェルでのアクセスを提供しないこと（2026年9月時点の AWS 公式ドキュメント）
- Introduction to backups（Amazon RDS） — 自動バックアップ、保持期間（最長 35 日・0 日で無効）、ポイントインタイムリカバリ（2026年9月時点の AWS 公式ドキュメント）
- Maintaining a DB instance（Amazon RDS） — メンテナンスウィンドウ、OS の更新、短時間のオフライン（2026年9月時点の AWS 公式ドキュメント）
- Multi-AZ DB instance deployments for Amazon RDS — 同期のスタンバイ、スタンバイは読み取りを受けないこと、マルチ AZ DB クラスターとの違い（2026年9月時点の AWS 公式ドキュメント）
- Failing over a Multi-AZ DB instance for Amazon RDS — フェイルオーバーで DNS の記録がスタンバイに向くこと、接続の張り直し（2026年9月時点の AWS 公式ドキュメント）
- Working with DB instance read replicas — 非同期の複製、別リージョンへの配置、昇格（2026年9月時点の AWS 公式ドキュメント）
- What is Amazon Aurora? と Amazon Aurora DB clusters — MySQL・PostgreSQL 互換、3つの AZ にまたがるクラスターボリューム、最大 15 台の Aurora レプリカ（2026年9月時点の AWS 公式ドキュメント）
- What is Amazon DynamoDB? — サーバーレスでフルマネージドの NoSQL データベースであること（2026年9月時点の AWS 公式ドキュメント）
- 責任共有モデル — 「クラウドのセキュリティ」と「クラウド内のセキュリティ」の分担（_data/registry.yml の shared-responsibility。確認日は台帳に従う）
