RDSはデータベースのサービスらしいけど、そもそもデータベースが何なのか分からない
EC2にMySQLを入れるのと、RDSを使うのとで何が違うのか分からない
作成画面の「エンジン」「インスタンスクラス」「マルチAZ」で手が止まってしまう
こんな悩みを解決していきます!

現在はCIerで、クラウドの設計・構築をしているインフラエンジニアです。
AWSの資格は、SAA(ソリューションアーキテクト アソシエイト)とSAP(ソリューションアーキテクト プロフェッショナル)を持っています。
結論から言うと、RDSは「データベースの部屋を、管理人付きマンションで借りるサービス」です。
建物の点検・修繕・見回り(OSの更新・バックアップ・故障時の切り替え)は管理会社のAWSがやってくれて、部屋の中身(データ)は自分で使う、と覚えれば全体がつながります。
この記事で分かることは3つです。
・データベースとは何か、RDSの部品がマンションのどこに当たるか
・EC2に自分で入れる場合との違い、Auroraとの違い
・バックアップ・マルチAZ・リードレプリカの違いと、料金のかかり方
\ AWSを詳しく学びたい方はこちら /
RDSとは?わかりやすく言うと「管理人付きマンション」

RDSは、データベースを置く部屋を「管理人付きマンション」で借りるサービスです。

上の図は、これまでの記事で作ってきたAWSの街に、管理人付きマンションを1棟建てたところです。
街の中には、EC2の記事で建てた建物と、S3の記事で建てた大きな倉庫があります。その並びに、管理人が常駐しているマンションが建っています。これがRDSです。
マンションの部屋を借りると、部屋の中は自分の好きなように使えます。
一方で、建物の点検・壊れた所の修繕・故障の見回りは、管理会社がやってくれます。住む人は、建物の面倒を見なくても部屋を使うことに集中できるのが、管理人付きマンションのよいところです。
公式ドキュメントでは、RDSは「AWSクラウドでリレーショナルデータベースを簡単にセットアップし、運用し、スケーリングできるウェブサービス」と紹介されています。何をAWSに任せられるかを表にまとめます。
| RDSでできること | マンションで例えると | ポイント |
| データベースを作る・動かす・広げる | 部屋を借りる・住む・広い部屋に移る | データベースの準備・運用・拡張をしやすくする |
| バックアップ | 管理人が記録をつけておく | AWSが自動でとってくれる |
| ソフトの修正(パッチ) | 建物の点検と修繕 | AWSが管理する |
| 故障の検出と復旧 | 異常に気づいて直す | AWSが自動で見つけて復旧する |
ポイントは、RDSは「マネージド(管理を任せられる)」なデータベースサービスだということです。
ただし、管理人が何でもやってくれるわけではありません。どこまでが管理人の仕事で、どこからが自分の仕事かは、この後の「EC2との違い」の章で表にします。
街そのもの(VPC)の考え方は、VPCの記事で解説しています。
厳密には
- RDS:AWSクラウドでリレーショナルデータベースのセットアップ・運用・スケーリングをしやすくするウェブサービス
- マネージド:ほとんどの管理タスクをRDSが担う。バックアップ・ソフトウェアパッチ・自動的な障害検出・復旧を管理する
- DBインスタンス:AWSクラウド内の独立したデータベース環境。RDSの基本単位
そもそもデータベースとは?何人もが同時に使う「大きな表」

データベースは、何人もが同時に読み書きできる、決まった形の大きな表です。

上の図は、「会員の表」と「注文の表」が、会員番号でつながっているところです。
表の形はExcelに近く、行(1人分・1件分のデータ)と列(名前・住所などの項目)でできています。そして、その表を何台ものパソコンやアプリが同時に読んだり書いたりしています。
RDSの「R」は、リレーショナル(関係のある)の意味です。表どうしを、共通の番号でつないで使うデータベースを、リレーショナルデータベースと呼びます。
会員の表と注文の表を会員番号でつなげば、「この会員が何を注文したか」をすぐに取り出せます。
| 言葉 | 意味 | 会員の表で言うと |
| テーブル(表) | データを入れる表 | 会員の表・注文の表 |
| 行 | 1件分のデータ | 会員1人分 |
| 列 | データの項目 | 名前・住所・会員番号 |
| 表どうしのつながり | 共通の項目で表をつなぐ | 会員番号で注文の表とつなぐ |
| SQL | データベースに話しかける言葉 | 「この会員の注文を出して」と頼む |
Excelとの大きな違いは、何人もが同時に、決まった形で、表どうしをつないで使えることです。
一般的には、Excelのファイルを何人もで同時に書き換えると、上書きし合って壊れやすくなります。データベースは、それが起きないように作られた「みんなで使う表」だと考えてください。
つまり、データベースはただのファイル置き場ではありません。会員・注文・在庫のように行と列で整理できるデータを入れて、何人もが同時に読み書きするためのものです。写真・書類・バックアップの控えのように置いておくだけのものは、S3の大きな倉庫に預けます。
厳密には
- リレーショナルデータベース:あらかじめ関係が決まったデータの集まり。表(テーブル)でできていて、行と列で値を持つ
- 表どうしのつながり:複数の表の行は、主キーと外部キーの組み合わせでつながる
- SQL:リレーショナルデータベースとやり取りするための主な手段
RDSの部品をマンションで例えると

RDSの作成画面に出てくる言葉は、マンションの部屋選びにそのまま当てはまります。

上の図は、マンションの間取りチラシに、RDSで決めることを書き込んだものです。
部屋を借りるときは、どんな種類の部屋か・どれくらいの広さか・収納はどれくらいかを選びます。RDSでデータベースを作るときも、同じことを決めます。
対応を表にしたのが、次の表です。左の列(マンション)だけ覚えておけば、RDSの名前は後からついてきます。
| マンションで例えると | RDSの名前 | 一言で |
| 借りた部屋 | DBインスタンス | データベースが動く1つの環境 |
| 部屋の種類 | DBエンジン | MySQL・PostgreSQLなど、どのデータベースのソフトを使うか |
| 部屋の広さ | DBインスタンスクラス | 計算する力とメモリの大きさ |
| 部屋の収納 | ストレージ | データをしまっておく場所の大きさと種類 |
| 管理会社 | AWS | 建物の点検・修繕・見回りを受け持つ(部屋の受付のルールは自分) |
| 入口の受付 | セキュリティグループ | 誰を部屋まで通すか |
部屋の種類=DBエンジン
DBエンジンは、部屋で動かすデータベースのソフトの種類です。
RDSでは、MySQL・PostgreSQL・MariaDB・Oracle・Microsoft SQL Server・IBM Db2の6つから選べます。和室か洋室かを選ぶように、使いたいデータベースに合わせて部屋の種類を決めます。
部屋の広さ=インスタンスクラス、収納=ストレージ
インスタンスクラスは、部屋の広さ=計算する力とメモリの大きさです。
広い部屋ほど、たくさんの人が同時に使っても余裕があります。使っているうちに狭くなったら、後から広い部屋(大きいインスタンスクラス)に変えられます。
ストレージは、データをしまっておく収納です。
収納には種類があり、「汎用(SSD)」や「プロビジョンドIOPS」などから選びます。同じ広さの部屋でも、収納の種類を変えると、出し入れの速さ(性能)と価格が変わります。
厳密には
- DBエンジン:DBインスタンスで動くリレーショナルデータベースのソフト。Db2・MariaDB・SQL Server・MySQL・Oracle・PostgreSQL
- DBインスタンスクラス:DBインスタンスのコンピューティングとメモリの容量を決める。後から変更できる
- ストレージ:Amazon EBSのボリュームを使う。汎用(SSD)・プロビジョンドIOPSなどがあり、性能と価格が違う
RDSとEC2の違い|「管理人付きマンション」と「一戸建て」

EC2に自分でデータベースを入れるのは一戸建て、RDSは管理人付きマンションです。

上の図の左は一戸建てです。土地と建物の骨組み(ハードウェア)はAWSが用意しますが、屋根の修理も見回りも、建物の中のことは全部自分でやる必要があります。その代わり、どこをどう直すかは自由に決められます。
右はマンションです。点検や修繕は管理人がやってくれるので、住む人は部屋を使うことに集中できます。その代わり、建物の作りには手を入れられません。
EC2の上にMySQLなどを自分で入れても、データベースは動かせます。違うのは、「誰が何をやるか」です。公式ドキュメントの分担表を、マンションの言葉で並べます。
| 作業 | 一戸建て(EC2に自分で入れる) | 管理人付きマンション(RDS) |
| OSの導入と修正 | 自分 | AWS |
| データベースのソフトの導入と修正 | 自分 | AWS |
| バックアップ | 自分 | AWS |
| 故障に備えた予備(高可用性) | 自分 | AWS |
| 広さの変更(スケーリング) | 自分 | AWS |
| サーバーの保守・ハードウェア | AWS | AWS |
| アプリに合わせた使い方の調整 | 自分 | 自分 |
一戸建て(EC2)の弱点は、手作業の更新で、うっかりアプリを止めてしまうような人為ミスが起きやすいことです。
OSやデータベースのソフトを自分で更新すると、その作業のたびに止まる心配があります。マンション(RDS)なら、その作業を管理人に任せられます。
建物(EC2)そのものの考え方は、EC2の記事で解説しています。
管理人に任せられないこと
管理人付きマンションでも、部屋の中のことは、住む人の仕事です。RDSでも、次のことは自分で受け持ちます。
| 自分の仕事 | マンションで例えると | RDSでは |
| データの中身 | 部屋に置く家具や荷物 | どんなデータを入れるか・消すか |
| 表の作り | 部屋の家具の並べ方 | テーブルの作り方(データベースの設計) |
| 速さの調整 | 部屋を使いやすく整える | SQLの書き方を直して速くする(クエリの調整) |
| 誰に使わせるか | 合い鍵を誰に渡すか | データベースのユーザーや、入れる相手の設定 |
RDSでは部屋の奥(OS)には入れない
マンションでは、住む人が建物の機械室に入ることはできません。RDSも同じで、データベースが動いているサーバーのOSには、SSH(離れたサーバーを操作するための接続)などで直接入れません。
データベースには、MySQLのクライアントのような「SQLで話しかける道具」で接続します。管理人に任せる代わりに、建物の奥には入れない、という決まりです。
よくある誤解:RDSにすれば全部AWSがやってくれる
- AWSが受け持つのは、建物の点検・修繕・見回り
→ OS・ソフトの修正、バックアップ、故障時の切り替えなど - データの中身・表の作り・SQLの調整は自分の仕事
→ 部屋の中のことは、マンションでも住む人が決める - 誰を部屋まで通すかも自分で決める
→ 入口の受付(セキュリティグループ)のルールは、住む人が書く
厳密には
- 分担:OSとDBソフトの導入・パッチ、バックアップ、高可用性、スケーリングはEC2では利用者、RDSではAWS。アプリの最適化はどちらも利用者
- 責任共有:RDSはDBインスタンスのソフトとインフラを受け持ち、利用者はクエリのチューニングを受け持つ
- シェル接続:RDSはDBインスタンスへのシェル接続を提供しない。SSHなどでホストに直接入れない
もっと詳しく知りたい方や、ハンズオンで学びたい方は、CloudTech(クラウドテック)もチェックしてみてください。
\ 詳しく知りたい方はこちら /
RDSのバックアップとスナップショットの違い

自動バックアップは管理人が決まった時間帯につけてくれる記録帳、スナップショット(その時点の部屋の中身を丸ごと保存したもの)は自分で撮っておく写真です。

上の図の左は、管理人が管理人室で記録帳をつけているところです。自分で決めた時間帯(バックアップウィンドウ)に部屋全体の記録をとり、決めた保管期限が過ぎた記録は、順に消えていきます。
右は、住む人が自分で撮った部屋の写真です。好きなときに撮れて、自分で消すまで残ります。
| 自動バックアップ | 手動スナップショット | |
| マンションで例えると | 管理人が決まった時間帯につける記録帳 | 自分で撮る部屋の写真 |
| 誰がとるか | AWSが、決めた時間帯に自動でとる | 自分が好きなときにとる |
| いつまで残るか | 決めた保管期間(0〜35日)が過ぎると消える | 自分で消すまで残る |
| どこまで戻せるか | 保管期間の中の、好きな時点に戻せる | 写真を撮った時点に戻せる |
自動バックアップの保管期間は、0〜35日の間で決めます。0日にすると、自動バックアップは止まるので注意してください。
保管期間の中なら、「昨日の15時の状態」のように、好きな時点まで戻せます。手動スナップショットは保管期間の対象外なので、大事な作業の前に「この時点を残しておきたい」というときに使います。
戻すときは「新しい部屋」として作る
写真(スナップショット)から戻すときは、今の部屋を上書きするのではなく、新しい部屋を1つ用意して、そこに中身を戻します。
スナップショットから戻したデータベースは、元とは別の、新しいDBインスタンスとしてできあがります。元の部屋に上書きはできない、と覚えておいてください。
よくある勘違いが、「DBインスタンスを消しても、バックアップは全部残る」というものです。自動バックアップは、削除のときに「残す」を選ばないと一緒に消えます。残したいデータがあるなら、削除の前に手動スナップショットを撮っておきましょう。手動スナップショットはインスタンスを消しても残り、残っている間はバックアップの保管の料金がかかります。
厳密には
- 自動バックアップ:バックアップウィンドウの間にDBインスタンス全体を保存し、保持期間(0〜35日・0で無効)に従って残す。期間内の任意の時点に復元できる
- 手動スナップショット:保持期間の対象外で期限切れにならず、インスタンスを削除しても消えない
- 復元:スナップショットから復元すると新しいDBインスタンスができる。既存のインスタンスへは復元できない
実際に画面で手を動かして覚えたい方は、CloudTech(クラウドテック)もチェックしてみてください。
\ ハンズオンで学びたい方はこちら /
マルチAZとリードレプリカとは?「別の棟の予備の部屋」と「読むだけの写し」

マルチAZは故障に備えた、別の棟の予備の部屋、リードレプリカは読むだけに使う写しの部屋です。

上の図の真ん中が、ふだん使っている元の部屋です。
左にあるのは、別の棟に用意した予備の部屋。元の部屋と同じ中身をいつも用意しておき、元の部屋が故障したら、こちらに切り替えます。右は、元の部屋の写しです。読むだけなら、こちらの部屋を使えます。
マルチAZ=別の棟の予備の部屋
マルチAZは、別のアベイラビリティゾーン(AZ)に、予備のDBインスタンスを自動で用意しておく仕組みです。AZは、同じリージョン(AWSの地域)の中にある、ほかのAZの故障の影響を受けないように分けられた場所です。マンションで言えば、同じ敷地に建つ別の棟だと考えてください。
元の部屋に書いた内容は、同時に(同期で)予備の部屋にも書き込まれます。だから、予備の部屋はいつも元の部屋と同じ中身を持っていて、いざという時にすぐ切り替えられます。
注意したいのは、予備の部屋はふだん立ち入り禁止で、読むためには使えないことです。予備は「いざという時に切り替えるため」の部屋で、ふだんの仕事を手伝う部屋ではありません。
リードレプリカ=読むだけの写しの部屋
リードレプリカは、元のデータベースの、読み取り専用の写しです。
データを「読むだけ」の仕事をこちらに回すと、元の部屋の混雑を減らせます。元の部屋に書いた内容は、少し遅れて(非同期で)写しに反映されます。なお、写しは自動では増えないので、必要な数は自分で作る決まりです。
| マルチAZの予備 | リードレプリカ | |
| マンションで例えると | 別の棟の予備の部屋 | 読むだけの写しの部屋 |
| 目的 | 故障したときに切り替える | 読む仕事を分けて、元の部屋の混雑を減らす |
| 写し方 | 同時に書き込む(同期) | 少し遅れて写す(非同期) |
| 読む仕事に使えるか | 使えない | 使える |
| 料金 | 予備の部屋への写しのやり取り(AZ間の転送)にもかかる | 普通の部屋1つと同じようにかかる |
厳密には
- マルチAZ(DBインスタンス):別のAZに同期のスタンバイを自動で用意し、障害時に切り替える。スタンバイは読み取りに使えない
- マルチAZ(DBクラスター):スタンバイが2つあり、切り替えに加えて読み取りにも使える
- リードレプリカ:DBインスタンスの読み取り専用のコピー。更新は非同期でコピーされ、自動では増減しない
RDSとAuroraの違い|同じマンションの「新しい型の部屋」

Auroraは、RDSの中で選べる、MySQL・PostgreSQL互換のエンジンです。

上の図は、RDSというマンションの中に、ふつうの部屋(MySQL・PostgreSQLなど)と、新しい型の部屋(Aurora)が並んでいるところです。
Auroraは別のマンションではありません。同じRDSのマンションの中で選べる、部屋の種類の1つです。作成画面でエンジンを選ぶときに、「Aurora MySQL」か「Aurora PostgreSQL」を選びます。
新しい型の部屋のいちばんの違いは、収納の作りです。
ふつうの部屋は、部屋ごとに収納(ストレージ)を付けます。Auroraは、高性能な専用の収納の仕組みを持っていて、必要に応じて収納が自動で広がります。また、ふだんの管理も1部屋ずつではなく、写しを含めた部屋のまとまり(クラスター)単位で行います。
| ふつうのRDS(MySQL・PostgreSQLなど) | Aurora | |
| マンションで例えると | ふつうの部屋 | 収納が自動で広がる新しい型の部屋 |
| 何か | MySQLなどのデータベースのソフトをそのまま動かす | MySQL・PostgreSQLと互換のある、フルマネージド(管理をほぼ任せられる)のエンジン |
| データの置き方 | DBインスタンスごとのストレージ | 専用の分散ストレージ。必要に応じて自動で増える |
| 管理の単位 | DBインスタンス(1部屋ずつ) | クラスター(部屋のまとまり) |
| 公式の説明書 | RDSのユーザーガイド | Auroraのユーザーガイド(別冊) |
どちらを選べばいい?
MySQLかPostgreSQLを使うなら、Auroraも選択肢に入ります。
Auroraは互換のエンジンなので、今MySQLやPostgreSQLで使っているコード・道具・アプリを、そのままAuroraで使えます。ふつうのRDSのMySQLやPostgreSQLから、スナップショットなどを使ってAuroraへデータを移すこともできます。
学習の最初は、ふつうのRDSで1部屋作ってみて、仕組みに慣れてからAuroraを試す順番がおすすめです。
よくある誤解:AuroraはRDSとは別のサービス
- AuroraはRDSの一部
→ RDSで新しいデータベースを作るとき、エンジンの選択肢として選ぶ - 説明書(ユーザーガイド)が別になっているだけ
→ どちらも、RDSというマネージドなデータベースサービスの中のもの
厳密には
- Aurora:MySQLとPostgreSQLと互換のある、フルマネージドなリレーショナルデータベースエンジン
- RDSとの関係:AuroraはRDSの一部。RDSで作るときのエンジンの選択肢として Aurora MySQL / Aurora PostgreSQL を選ぶ
- ストレージ:高性能な分散ストレージを持ち、必要に応じて自動で増える。管理は通常クラスター単位
AuroraやRDSを実際に触って学びたい方は、CloudTech(クラウドテック)もチェックしてみてください。
\ 詳しく学びたい方はこちら /
RDSの料金はどこにかかる?

RDSの料金は、部屋を借りている時間・収納の大きさ・記録の保管・外とのやり取りなどにかかります。

上の図は、RDSの料金がかかる主なものを4つ並べたものです。
マンションの家賃も、「どの部屋を、どれくらいの期間借りたか」で決まります。RDSも同じで、使った分だけの料金で、最低料金はありません。そのかわり、何に料金がかかるかを知っておくことが大切です。
| かかるもの | マンションで例えると | ポイント |
| DBインスタンスの時間 | 部屋を借りている時間 | インスタンスクラス(部屋の広さ)によって変わる |
| ストレージ | 収納の大きさ | 用意した大きさにかかる |
| バックアップの保管 | 記録帳と写真の保管 | 自動バックアップと手動スナップショットの保管にかかる |
| データ転送 | 外とのやり取り | インターネットとの間のデータのやり取りにかかる |
| マルチAZ | 別の棟の予備の部屋 | 予備の部屋への写しのための、AZ間のやり取りにもかかる |
| リードレプリカ | 写しの部屋 | 普通の部屋1つと同じようにかかる。同じリージョン内の写しのやり取りは無料 |
学習で使うなら、試し終わった部屋は片付けることを習慣にしておくと安心です。
具体的な金額は、部屋の広さや使い方によって変わります。使う前に、AWSの料金ページで確かめてください。
もう1つ気をつけたいのは、料金は部屋を借りている時間だけではないことです。収納や記録の保管にもかかり、スナップショットは部屋を片付けても残るので、保管の料金がかかり続けます。マルチAZやリードレプリカを付けると、その分も料金が増えます。
厳密には
- 料金:使った分だけで、最低料金はない
- 主な内訳:インスタンスの時間・用意したストレージ・バックアップの保管・インターネットとのデータ転送・マルチAZのAZ間転送など
- リードレプリカ:通常のDBインスタンスと同じ料金。同じリージョン内の複製のデータ転送には料金がかからない
RDSはVPCのどこに置く?セキュリティグループで入れる人を決める

RDSも街(VPC)の中に建て、ふつうは外から直接入れない奥の区画に置いて、受付(セキュリティグループ)で入れる人を決めます。

上の図は、街の表通りの区画に建物(EC2)、奥の区画にマンション(RDS)が建っているところです。
マンションの入口には受付があり、「建物(EC2)から来た人だけ通す」というルールで見張っています。このルールを書くのは管理人ではなく、部屋を借りた自分です。インターネットから来た人は、マンションまでたどり着けません。
| 決めること | マンションで例えると | RDSでは |
| どこに建てるか | 街(VPC)の奥の区画 | VPCの中の、インターネットから直接届かないサブネット(プライベートサブネット)に置く |
| 誰を通すか | 入口の受付 | セキュリティグループで、通してよいIPアドレスの範囲やEC2を決める |
| どう使うか | 建物の人がマンションに用事を頼む | EC2のアプリからRDSのデータベースに接続する |
よくある形は、表通りの建物(EC2)でアプリを動かし、奥のマンション(RDS)にデータを置く組み合わせです。
利用者はEC2のアプリにアクセスし、アプリがRDSに話しかけます。RDSを奥の区画に置き、受付でEC2からの人だけを通すので、インターネットから直接データベースを狙われにくくなります。
街の区画(サブネット)はVPCの記事、受付の考え方はEC2の記事、AWSの操作を誰に許すかはIAMの記事で解説しています。
厳密には
- VPC:DBインスタンスはVPCの中で動かせる。典型例では、プライベートサブネットに置かれ、インターネットからのリクエストは届かない
- セキュリティグループ:指定したIPアドレス範囲やEC2インスタンスからのアクセスを許可して、DBインスタンスへのアクセスを制御する
もっと詳しく学びたい方は、CloudTech(クラウドテック)もチェックしてみてください。
\ 手を動かして覚えたい方はこちら /
まとめ|RDSはAWSの街の管理人付きマンション

RDSは、点検・修繕・見回りを管理会社(AWS)に任せて、データベースの部屋を使うことに集中できる管理人付きマンションです。
この記事のまとめ
- 管理人付きマンション=RDS
→ リレーショナルデータベースの準備・運用・拡張をしやすくするマネージドサービス - 部屋=DBインスタンス、種類・広さ・収納
→ エンジン・インスタンスクラス・ストレージを選んで作る - 一戸建て=EC2に自分で入れる
→ OSやソフトの修正・バックアップ・予備は自分。RDSならAWSが受け持つ - 記録帳と写真=自動バックアップとスナップショット
→ 自動は保管期間まで、手動は消すまで残る - 予備の部屋と写しの部屋=マルチAZとリードレプリカ
→ 予備は切り替え専用で読めない。写しは読むだけ - 新しい型の部屋=Aurora
→ RDSの中で選べる、MySQL・PostgreSQL互換のエンジン
迷ったときは、「これは管理人の仕事か、部屋に住む自分の仕事か」を考えてみてください。
それだけで、RDSの画面に並ぶ言葉のほとんどが、どこに当たるか分かるはずです。
街(VPC)・建物(EC2)・入館管理(IAM)・大きな倉庫(S3)は、VPCの記事・EC2の記事・IAMの記事・S3の記事で復習できます。
もっと詳しく知りたい方や、ハンズオンで学びたい方は、CloudTech(クラウドテック)の評判記事もどうぞ。