テクノロジー

Amazon RDSとは?仕組み・特徴・料金・DBエンジンの選び方を現役AWSエンジニアが解説

著者近影
HIROTO

「データベースのサーバー管理がつらい」「パッチ適用やバックアップに時間を取られて、開発が前に進まない」。AWSでデータベースを扱うエンジニアなら、こんな悩みを抱えたことがあるのではないでしょうか。

そうした課題を解消するのが、Amazon RDS(Amazon Relational Database Service)です。AWSが提供するフルマネージド型のリレーショナルデータベースサービスで、面倒なインフラ管理をAWSに任せながら、7種類のDBエンジンを柔軟に選んで使えます。

この記事では、現役AWSエンジニアが、RDSの仕組み・主要機能・料金体系・DBエンジンの選び方まで、実務の視点を交えながら解説します。「RDSを使うべきか迷っている」「EC2上のDBとの違いが知りたい」という方は、ぜひ最後まで読んでみてください。

監修:HIROTO
AWS基盤のインフラ設計・構築から維持運用、チームマネジメントなどを幅広く担当するインフラエンジニア。

オンプレからのAWS移行、マルチアカウント化、新規基盤の設計構築などの実績に加え、並行してセキュリティ領域のPJではPLを担当。2025 All AWS Certifications Engineers

運営元:ALH株式会社
ALH株式会社は、AWSパートナーネットワーク(APN)において、以下の認定を取得しているAWSパートナー企業です。

◆ AWS 1000 APN Certification Distinction
AWS認定資格の取得数が1,000件を超えたパートナーに与えられる認定

◆ AWS Training Partner
AWS公認の研修トレーニングを提供できるパートナー認定

◆ AWS Select Tier Services Partner
AWSサービスの構築・運用において一定の実績を持つパートナー認定

1. Amazon RDS(リレーショナルデータベースサービス)とは?【まずは結論】

1-1. RDSの定義:フルマネージドDBとはなにか

Amazon RDS(Relational Database Service)とは、AWSが提供するクラウド型のフルマネージドなリレーショナルデータベースサービスです。「マネージド」とは「管理された」という意味で、データベースの運用に必要なサーバー管理・OSパッチ適用・バックアップ・フェイルオーバーといった作業をAWSが代行してくれる仕組みを指します。

リレーショナルデータベース(RDB)とは、データをテーブル(表)形式で管理し、SQL(Structured Query Language)で操作するデータベースの総称です。MySQLやPostgreSQL、Oracleなどが代表例として知られています。

通常、これらのDBを自前のサーバーで動かすには、OSのインストールやDBソフトのセットアップ、定期的なメンテナンスが欠かせません。RDSを使えば、そうした作業の大部分をAWSが担うため、開発者はアプリケーション本体の開発に集中できます

1-2. RDSが登場した背景

クラウドが普及する前、データベースは自社のオンプレミスサーバーで動かすのが一般的でした。サーバーの調達から始まり、OSのセットアップ、DBソフトのインストール、定期バックアップ、セキュリティパッチの適用など、インフラチームには膨大な運用作業が伴っていました。

AWSのEC2(仮想サーバー)が登場し、サーバーはクラウドで調達できるようになりました。しかし、EC2の上にDBを構築する場合、OSレイヤー以上の管理は依然として利用者の責任です。

パッチ適用のタイミング管理、冗長化のアーキテクチャ設計、障害発生時の切り替え対応など、DBの安定運用に必要なノウハウは決して少なくありません。こうした課題に応えるために登場したのがAmazon RDSです。2009年10月のリリース以来、多くの企業のDB運用を支えてきました。

1-3. RDSとEC2上DBの違い【比較表】

管理項目EC2上のDB(自己管理)Amazon RDS
ハードウェア調達AWS管理AWS管理
OSのインストール利用者AWS管理
OSパッチ適用利用者AWS管理
DBソフトのインストール利用者AWS管理
DBバージョンアップ利用者自動または手動で選択可
バックアップ利用者AWS管理(自動)
フェイルオーバー利用者が設計自動
スケーリング利用者数クリックで変更可
SSHログイン可能不可(マネージドのため)

この表が示す通り、EC2上のDBと比較してRDSは大部分の運用タスクをAWSに委ねられます。その代わり、OSへの直接ログインや独自のDBソフトインストールはできないという制約があります。

2. Amazon RDSの仕組みと基本アーキテクチャ

2-1. DBインスタンスとは

RDSの核となる概念が「DBインスタンス」です。DBインスタンスとは、クラウド上で動作する独立したデータベース環境のことで、CPU・メモリ・ストレージが割り当てられています。利用者はこのインスタンスに対してSQLで接続し、データを操作します。

インスタンスには「インスタンスクラス(タイプ)」があり、用途に応じて選択します。T系(バースト型・開発環境向け)、M系(汎用・本番環境向け)、R系(メモリ最適化・大規模DB向け)の3系統が主流です。詳細は第7章で解説します。

2-2. ストレージの種類

DBインスタンスに使われるストレージは、主に以下の3種類から選べます。

ストレージタイプ特徴向いているケース
汎用SSD(gp3)コストと性能のバランスが良い。基本性能で3,000 IOPSほとんどの本番ワークロード
プロビジョンドIOPS SSD(io1/io2)高IOPSを安定して確保。最大256,000 IOPS(DBエンジンにより上限が異なり、SQL Serverは最大64,000 IOPS)IOPS要件が厳しいDBワークロード
マグネティック旧世代。新規では非推奨利用非推奨

gp3は2022年に登場した新世代で、旧型のgp2に比べてコストを抑えつつ安定したIOPS性能を発揮するため、現在の標準的な選択肢はgp3と考えてよいでしょう。

2-3. VPC・サブネット・セキュリティグループとの関係

RDSのインスタンスは必ずVPC(Virtual Private Cloud)の中に配置されます。インターネットから直接アクセスできないようプライベートサブネット内に置くのがセキュリティのベストプラクティスです。

アクセス制御はセキュリティグループで行います。「EC2インスタンスからのみポート3306への接続を許可する」といったルールを設定することで、不要な外部アクセスを遮断できます。

3. Amazon RDSの主要機能5選

3-1. 自動バックアップとポイントインタイムリカバリ(PITR)

RDSには自動バックアップ機能が標準搭載されており、設定した保持期間(最大35日間)の範囲で任意の時点にデータベースを復元できます。これを「ポイントインタイムリカバリ(PITR)」と呼びます。なお、PITRは既存のDBを上書きするのではなく、指定した時点の状態を復元した新しいDBインスタンスとして作成されます。

また、任意のタイミングでスナップショット(手動バックアップ)を取得することも可能です。スナップショットは保持期間に依存しないため、重要な変更前のバックアップとして活用できます。

自動バックアップはデフォルトで有効になっており、バックアップウィンドウ(バックアップを実行する時間帯)を設定するだけで自動的に取得されます。オンプレやEC2上のDBで手動バックアップを管理していた担当者にとっては、この自動化だけでも大きなメリットを感じられるはずです。

3-2. マルチAZ配置による高可用性

マルチAZ(Multi-Availability Zone)は、RDSの高可用性を実現する中核機能です。プライマリDBと同期するスタンバイインスタンスを別のアベイラビリティゾーン(AZ)に自動で配置する仕組みで、プライマリに障害が発生した場合、通常1〜2分以内に自動的にスタンバイへ切り替わります(フェイルオーバー)

重要なのは、スタンバイインスタンスは原則として通常時の読み取りには使えないという点です。あくまで「障害時の切り替え先」として機能します(Multi-AZ DBクラスター構成では、スタンバイインスタンスを読み取りに利用できるオプションもあります)。

読み取り処理の負荷分散にはリードレプリカを使います(次節参照)。マルチAZはオプション(追加料金あり)ですが、本番環境では基本的に有効にしておくことをおすすめします。

3-3. リードレプリカによる読み取り負荷分散

リードレプリカは、プライマリDBの読み取り専用コピーを作成する機能です。SELECTクエリ(データの参照処理)をリードレプリカに向けることで、プライマリDBへの負荷を分散させ、パフォーマンスを改善できます。

リードレプリカはDBエンジンによって最大数が異なります(MySQL・PostgreSQL・MariaDB・SQL Serverは最大15個、Oracleも最大15個)。ただしOracleは、レプリケーション遅延を最小限に抑えるため5個までの利用が推奨されています。なお、AuroraはAuroraレプリカとして同じく最大15個まで作成でき、フェイルオーバー時のプロモーション(昇格)も高速なのがポイントです。

3-4. 自動パッチ適用とメンテナンスウィンドウ

セキュリティパッチやDBエンジンのマイナーバージョンアップは、設定したメンテナンスウィンドウの時間帯に自動で適用されます。適用タイミングは週1回の指定時間帯に集約されるため、予期せぬ停止のリスクを管理しやすくなります。

マイナーバージョンの自動アップグレードは「有効/無効」から選択できます。メジャーバージョンアップグレード(例:MySQL 5.7 → 8.0)は自動適用されないため、計画的に実施する必要があります。

3-5. 暗号化・IAM認証・セキュリティ機能

RDSは複数のセキュリティ機能を標準で備えています。

  • 保存時の暗号化:KMS(AWS Key Management Service)を使ったストレージ暗号化。DBインスタンス作成時に有効化し、後から変更はできない点に注意
  • 転送中の暗号化:SSL/TLSによる通信の暗号化
  • IAM認証:パスワードではなくIAMポリシーでDB接続を管理できる
  • VPCセキュリティグループ:ネットワークレベルのアクセス制御

4. RDSで使えるDBエンジン7種類の特徴と選び方

4-1. Amazon Aurora(AWS独自のクラウドネイティブDB)

Amazon Auroraは、AWSが独自開発したクラウドネイティブなDBエンジンで、MySQLとPostgreSQLの両方と高い互換性を持ちます。通常のMySQLと比べて最大5倍のパフォーマンス、PostgreSQLと比べて最大3倍を発揮するとされており、RDSエンジンの中で最もハイパフォーマンスな選択肢です。

分散ストレージ(クラスターボリューム)を採用しており、データを6つのコピーとして3つのAZに自動分散する仕組みが特徴です。実務でも、パフォーマンスと可用性の両立が求められる本番環境では、MySQLやPostgreSQLより先にAuroraを検討することが多くあります。

4-2. MySQL

世界で最も広く使われているオープンソースのRDBMSの一つ。Amazon RDS for MySQLとして提供されており、Web系アプリケーションのバックエンドDBとして多くのシステムで採用されています。

注意点として、MySQL 8.0の標準サポートは2026年7月31日に終了予定です。延長サポートを利用する場合は追加料金が発生するため、Auroraへの移行も含めた計画的な対応が必要です。

4-3. PostgreSQL

高機能なオープンソースRDBMSで、複雑なクエリや大量データの処理に強いのが特徴です。JSON型のネイティブサポートやウィンドウ関数など、MySQL以上の高度なSQL機能を備えています。「脱Oracle」の移行先として採用されるケースも多くあります。

4-4. MariaDB

MySQLからフォークされた(分岐して作られた)OSSのRDBMS。MySQLとほぼ互換性があり、ライセンス面でMySQL(Oracle傘下)を避けたいケースに使われることが多くあります。

4-5. Oracle

エンタープライズ向けの商用RDBMSの代表格です。基幹システムや金融系システムでの採用実績が多くあります。ライセンス方式には「ライセンス込み」と「ライセンス別途持ち込み(BYOL)」があり、ライセンスコストが高くなりがちな点を考慮する必要があります。

4-6. Microsoft SQL Server

Microsoftが提供する商用RDBMSで、Windowsベースのシステムや.NETアプリケーションとの親和性が高いDBです。Windowsベースのシステムをクラウドに移行する際の選択肢として検討されることが多くあります。

4-7. Db2(IBM)

IBMが提供するRDBMSです。2023年11月に新たにRDSへ追加されたエンジンで、IBM Db2を使ったシステムのクラウド移行を想定しています。既存のDb2ワークロードをAWSへ移行するケースで利用されます。

4-8. ユースケース別DBエンジンの選び方早見表

DBエンジン向いているケースコスト感
Amazon Aurora高パフォーマンス・高可用性が求められる本番環境中〜高
MySQLWeb系アプリのスタンダードなDB低〜中
PostgreSQL複雑なクエリ・JSON活用・脱Oracle移行先低〜中
MariaDBMySQLの代替・OSSライセンスを重視するケース低〜中
Oracle既存Oracleシステムのクラウド移行
SQL ServerWindowsベース・.NETアプリ連携中〜高
Db2既存IBM Db2システムのクラウド移行中〜高

5. Amazon RDSのメリット・デメリット

5-1. メリット3つ

① 運用負荷を大幅に削減できる

バックアップ・パッチ適用・フェイルオーバーの自動化により、DBの日常運用にかかる工数を大幅に削減できます。インフラ専任担当がいない小〜中規模チームほど、この恩恵は大きくなります。

② 高可用性を低コストで実現できる

マルチAZとフェイルオーバー機能により、オンプレで同等の冗長構成を組む場合と比較して、はるかに低コストで高可用性を確保できます。自前で冗長化を設計するには相応のインフラ知識が必要ですが、RDSはオプション一つで実現できます。

③ スケーリングが容易

ビジネスの成長に合わせて、インスタンスタイプの変更やストレージの拡張を数クリックで対応できます。ストレージはオートスケーリングの設定も可能で、容量不足による障害リスクを低減できます。

5-2. デメリット・注意点2つ

① OSへの直接アクセスができない

RDSでは、DBが稼働するOSにSSHでログインすることはできません。特定のOSレベルの設定変更や、DBソフトの独自カスタマイズが必要なケースでは制約となります。そうした場合は、EC2上にDBを構築するほうが柔軟性は高くなります。

② 利用状況によってはコストが高くなる

24時間365日フル稼働の本番環境ではリザーブドインスタンスで割引が効きますが、開発・検証環境のように使用頻度が低い環境では、適切なインスタンスタイプの選択やスケジュール停止を怠ると余計なコストが発生しやすくなります。

6. Amazon RDSの料金体系を完全解説

6-1. 料金の構成要素

Amazon RDSの料金は、以下の要素で構成されます。

料金項目内容
インスタンス料金DBインスタンスの起動時間に対する従量課金
ストレージ料金GB単位の保存容量に対する月額課金
I/O料金gp2やio1の場合はI/O操作に応じた課金(gp3は一定IOPS含む)
バックアップストレージDBサイズを超える分のバックアップ容量
データ転送料金RDSから外部へのデータ転送(同一AZ内は無料)
マルチAZ追加料金シングルAZの約2倍のインスタンス料金

具体的な料金はリージョンやDBエンジンによって異なります。AWSの公式料金ページ(Amazon RDS料金)で最新の料金をご確認ください。

6-2. オンデマンドvsリザーブドインスタンス

RDSのインスタンス料金には2つの購入オプションがあります。

オンデマンドインスタンスは、起動中の時間単位で課金されます。初期費用なし・縛りなしで利用できるため、開発・テスト環境や利用頻度が読めない初期フェーズに向いています。

リザーブドインスタンスは、1年または3年の使用を前払いまたは一部前払いで契約することで、オンデマンドと比べて最大40〜60%【要確認】の割引が受けられます。長期間の本番運用が確定しているDBには、積極的に活用したいオプションです。

6-3. 無料利用枠の内容と条件

AWSの無料利用枠(Free Tier)の内容は、アカウントの作成時期によって異なります。

【2025年7月14日以前に作成したアカウント】

  • db.t2.microまたはdb.t3.microインスタンス:月750時間(12か月間)
  • 汎用SSDストレージ:20GB
  • 自動バックアップストレージ:20GB

【2025年7月15日以降に新規作成したアカウント】

  • サインアップ時に最大200ドル分のクレジットが付与され、最長6か月間、対象サービスに利用できるモデルに変更されている

ただし、AuroraはFree Tierの対象外という点に注意しましょう。RDSをはじめて試す場合は、MySQLまたはPostgreSQLのdb.t3.microインスタンスから始めるとコストを抑えられます。

6-4. コストを抑える3つのポイント

  1. 長期運用はリザーブドインスタンスを活用:本番DBが1年以上稼働することが確定しているなら、リザーブド購入で大幅なコスト削減が可能
  2. 開発環境はスケジュール停止を活用:開発・検証用のDBは業務時間外に自動停止させることで、不要なインスタンス料金を節約できる(最大7日間まで停止可能)
  3. ストレージはgp3を選ぶ:旧世代のgp2よりコストパフォーマンスが高く、必要なIOPS性能を柔軟に設定できる

6-5. MySQL 8.0の延長サポートに注意

2026年7月31日に、Amazon RDS for MySQL 8.0の標準サポートが終了する予定です。標準サポート終了後もRDSでMySQL 8.0を使い続けると、自動的に「延長サポート」に移行し、追加料金が発生します

MySQL 8.0を利用中の場合は、Aurora MySQL(MySQL 8.0互換)への移行、またはMySQL 8.4へのバージョンアップを検討する時期に来ています。

7. インスタンスタイプの種類と選び方

7-1. T系・M系・R系の違い

系統特徴主な用途
T系(T3、T4gなど)バーストパフォーマンス型。負荷が低い時は課金を抑え、突発的な高負荷に対応できる開発・テスト環境、小規模アプリ
M系(M5、M6g、M7gなど)汎用型。バランスの取れたCPU・メモリ中規模以上の本番環境のスタンダード
R系(R5、R6g、R7gなど)メモリ最適化型。メモリ対CPUの比率が高い大規模DB、インメモリ処理が多いワークロード

7-2. 本番環境vs開発環境での選び方

本番環境では、安定したパフォーマンスが求められるため、バースト型のT系は避け、M系またはR系を選ぶのが基本です。高負荷時にCPUクレジットが枯渇するT系は、本番DBの安定性を損なうリスクがあります。

開発・検証環境では、コスト最小化が優先されることが多いため、T系(db.t3.micro、db.t3.smallなど)で十分なケースがほとんどです。

8. Amazon RDSの始め方【3ステップ】

8-1. 事前準備

  1. VPCとサブネットの確認:RDSを配置するVPCが存在するか確認。DBはプライベートサブネットに置くのが原則
  2. DBサブネットグループの作成:RDSが使用するサブネットのグループを作成(マルチAZに対応するため、複数AZにまたがるサブネットを指定)
  3. セキュリティグループの設定:RDSへの接続を許可するセキュリティグループを作成。接続元(EC2など)のセキュリティグループからのみ許可するのが推奨

8-2. DBインスタンスの作成

AWSマネジメントコンソールの「RDS」メニューから「データベースの作成」を選択し、以下の項目を設定します。

  • DBエンジンの選択(MySQL、PostgreSQL、Aurora等)
  • テンプレートの選択(本番用・開発用・無料利用枠)
  • インスタンスクラスの設定
  • ストレージ設定(タイプ・容量・オートスケーリング有無)
  • マルチAZ設定
  • VPC・サブネット・セキュリティグループの設定
  • バックアップ設定(保持期間等)

8-3. 接続確認

インスタンスの起動後、エンドポイント(接続先のホスト名)が発行されます。MySQL Workbenchやpsqlなどのクライアントツールで接続テストを行い、アプリケーションからの接続を確認します。

9. よくある質問(FAQ)

Q1. RDSとEC2上のDBはどちらを選ぶべきですか?
特別な理由がない限り、RDSを選ぶことを推奨します。運用の自動化・高可用性の確保・バックアップの容易さなど、開発チームの負荷を大幅に軽減できます。EC2上のDBが有利なのは、OSレベルのカスタマイズが必要な場合や、RDSが未対応の特定機能を使いたい場合に限られます。

Q2. RDSのOSにSSHでログインできますか?
できません。RDSはマネージドサービスのため、ユーザーはDBエンドポイントへの接続のみを行う設計になっています。OS操作が必要な場合はEC2上のDBを検討する必要があります。

Q3. RDSを停止中も料金はかかりますか?
インスタンスを停止した場合、インスタンス料金は発生しません。ただし、ストレージ料金は継続して発生することに注意しましょう。また、RDSは最大7日間しか停止状態を維持できず、7日を経過すると自動的に再起動されます。

Q4. AuroraとRDS for MySQLは何が違いますか?
最大の違いはアーキテクチャです。通常のRDS for MySQLは単一のストレージにデータを書き込む構造ですが、AuroraはデータをAWS独自の分散ストレージに6コピー保存します。その結果、フェイルオーバーの速度・リードレプリカの最大数・パフォーマンスなどでAuroraが優位になります。

Q5. 無料枠でRDSを試せますか?
試せます。ただし内容はアカウントの作成時期によって異なります。2025年7月14日以前からのアカウントは、db.t2.microまたはdb.t3.microのインスタンスを月750時間まで12か月間無料で使えます。2025年7月15日以降に新規作成したアカウントは、最大200ドル分のクレジットで最長6か月間利用できるモデルが適用されます。MySQLまたはPostgreSQLのdb.t3.microインスタンスから始めるのが、コストリスクを抑えた方法です。なお、Auroraは無料枠の対象外となります。

10. まとめ

この記事では、Amazon RDSの仕組みから主要機能・料金・DBエンジンの選び方まで解説しました。

  • Amazon RDSとは、AWSが提供するフルマネージド型のリレーショナルDBサービス。OSの管理・バックアップ・フェイルオーバーをAWSが自動化する
  • EC2上のDBと比べ、運用負荷・高可用性・スケーラビリティの面でRDSが有利
  • DBエンジンは7種類。パフォーマンスと可用性を重視するならAurora、コストを抑えたいならMySQL・PostgreSQLが基本的な選択軸
  • 料金は複数の要素で構成。長期稼働ならリザーブドインスタンスで大幅削減できる
  • MySQL 8.0のサポート終了(2026年7月31日予定)には早めの対応が必要

RDSを活用して、インフラ運用の負荷を減らし、開発に集中できる環境を整えていきましょう。

参考リンク

※いずれも2026年8月時点の情報です。料金・仕様・提供状況は改定される場合があるため、最新情報は各公式ページでご確認ください。

関連記事

AWS S3 ストレージクラス8種はどう選ぶ?料金で損しない使い分けを現役エンジニアが解説

2026.8.4

AWS Lambdaとは?できること・料金・つまずき所まで現役AWSエンジニアが解説

2026.7.16

【2026年最新】Amazon EC2とは?インスタンスタイプの選び方と料金体系を現役AWSエンジニアが解説

2026.7.27

【2026年最新】AWS IAMとは?ユーザー・ロール・ポリシーの違いを現役AWSエンジニアがわかりやすく解説

2026.7.30

Amazon CloudWatchとは?現役AWSエンジニアが機能・料金・使い方を徹底解説

2026.8.18

【2026年最新】AWS資格一覧|全12種類の難易度・略称・受験料・取得順を徹底解説

2026.6.4

この記事を書いた人

著者近影

HIROTO

AWS基盤のインフラ設計・構築から維持運用、チームマネジメントなどを幅広く担当するインフラエンジニア。
オンプレからのAWS移行、マルチアカウント化、新規基盤の設計構築などの実績に加え、並行してセキュリティ領域のPJではPLを担当。2025 All AWS Certifications Engineers。 このライターの他の記事を見る

この記事をシェアする

採用情報RECRUITING Info.