Amazon RDS (Relational Database Service)

は、MySQL、PostgreSQL、MariaDB、Oracle Database、Microsoft Server、Db2 などのをマネージドに運用するサービスです。データベースエンジンのセットアップ、バックアップ、パッチ適用、障害検出、、スケーリングなど、運用負荷の大きい作業を AWS に任せられます。

SAA では、RDS を「マネージド DB」として覚えるだけでは不十分です。、Read Replica、自動バックアップ、、暗号化、RDS Proxy、ストレージ、監視を組み合わせ、可用性、読み取り性能、復旧、コスト、運用負荷のトレードオフを判断できることが重要です。

Point

RDS = Relational Database Service の略です。
Relational Database は「表同士の関係を扱うデータベース」です。
RDS は「一般的な SQL データベースを AWS が運用しやすくしてくれるサービス」と覚えます。
和訳
- Relational: 関係のある
- Database: データベース
- Service: サービス
- Weblio英和辞書「relational」

概要

は、アプリケーションが利用するを簡単に作成・運用するためのサービスです。上に自分で DB をインストールする場合と比べて、管理、DB ソフトウェアのパッチ、バックアップ、などの作業を減らせます。

RDS の基本単位は DB インスタンスです。 DB インスタンスには、DB エンジン、インスタンスクラス、ストレージ、グループ、、パラメータグループ、オプショングループなどを設定します。

SAA では、まずデータベース要件がリレーショナルかどうかを見ます。、トランザクション、既存の MySQL/PostgreSQL/Oracle/SQL Server 互換性が必要なら RDS が候補です。高いスケールや固有のが必要なら Aurora、キーバリューやなら、分析用ならなどと比較します。

見るポイント	代表的な判断
可用性を高めたいか	配置を使います。
読み取り負荷を分散したいか	Read Replica を使います。
誤削除や障害から戻したいか	自動バックアップ、、を使います。
接続数が多すぎるか	RDS Proxy を検討します。
保存データを保護したいか	による保存時暗号化を使います。

主要技術

①DB エンジン、インスタンスクラス、ストレージ

は複数の商用・オープンソース DB エンジンに対応します。既存アプリケーションとの互換性、ライセンス、機能、運用要件に応じてエンジンを選びます。

DB エンジン	主な用途	SAA での判断ポイント
MySQL	一般的な Web アプリ	既存 MySQL 互換や一般的なで使います。
PostgreSQL	高機能な OSS	SQL 機能、拡張性、既存 PostgreSQL 互換で選びます。
MariaDB	MySQL 系 OSS DB	MariaDB 互換要件で選びます。
Oracle Database	既存 Oracle アプリ	ライセンスと互換性が判断軸です。
Microsoft SQL Server	Windows/SQL Server 系アプリ	SQL Server 互換や .NET 系で使います。
Db2	既存 Db2 ワークロード	Db2 互換要件で検討します。

PostgreSQL は PostGIS などの拡張機能を使えるため、空間関数を多用する既存の PostgreSQL アプリケーションは、RDS for PostgreSQL や PostgreSQL へ移すと SQL を書き換えずに済みます。 MySQL にも空間データ型はありますが、PostGIS の関数とは互換がありません。

DB インスタンスクラスは、メモリ、ネットワーク性能を決めます。 RDS はデータベース用途のため、メモリ不足や I/O 不足が性能問題になりやすいです。ストレージは General Purpose と Provisioned SSD を中心に考え、I/O 集約型の本番 DB では Provisioned IOPS が候補になります。

ストレージ種別	向いている用途	判断ポイント
General Purpose SSD	多くの汎用 DB、開発、通常本番	コストと性能のバランスがよい基本候補です。
Provisioned IOPS SSD	I/O 集約型、低要求	一貫した I/O 性能が必要な本番 DB で選びます。
Magnetic	廃止済み	新規の作成はできず、既存のボリュームは gp3 へ移行済みです (2026年6月に廃止が完了)。

gp2 のベースラインは容量 1GiB あたり 3 IOPS で、1,000GiB 未満のボリュームは I/O クレジットで 3,000 IOPS までバーストします。クレジットが尽きるとベースラインまで下がり、の BurstBalance が 0 になります。 gp3 は容量に関係なく 3,000 IOPS・125MiB/s のベースラインを持ちます（MySQL、PostgreSQL、MariaDB では 400GiB 以上で 12,000 IOPS になり、IOPS を追加でプロビジョンできます）。 io2 Block Express は指定した IOPS を持続して提供し、平均 1 ミリ秒未満の遅延で動作します。

よく参照するデータがメモリ（バッファ）に収まらなくなると、ディスクからの読み取りが増えて ReadIOPS と ReadLatency が上がります。 FreeableMemory が小さいままなら、ストレージを速くするより、メモリの大きいメモリ最適化クラス（db.r 系など）へ変更して原因を取り除きます。

Point

OLTP = Online Transaction Processing の略です。
注文、決済、在庫更新など、短いトランザクションを多数処理する用途です。
IOPS = Input/Output Operations Per Second の略です。
ストレージが 1 秒あたりに処理できる読み書き回数を表します。

⚠️ 頻出: 「DB の読み書き遅延が I/O 性能不足に起因する」場合は、インスタンスサイズだけでなくストレージタイプ、IOPS、CloudWatch を確認します。

②Multi-AZ と高可用性

は、の可用性を高めるための構成です。プライマリ DB と別のスタンバイを同期的に維持し、障害やメンテナンス時にします。アプリケーションは通常、同じ DB を使い続けます。

構成	目的	試験での判断ポイント
Single-AZ	低コスト、非本番	AZ 障害やメンテナンス時の可用性は弱いです。
Multi-AZ DB instance	、自動フェイルオーバー	読み取りスケールではなく可用性目的です。
Multi-AZ DB cluster	高可用性と読み取り可能なスタンバイ	より高い可用性・性能要件で検討します。

Multi-AZ のスタンバイは、基本的に読み取り用ではありません。読み取り性能を上げたい場合は Read Replica を使います。 Multi-AZ は、障害時のを短くし、データ損失リスクを下げるための選択肢です。

Multi-AZ DB クラスターは、同じの 3 つの AZ にライター 1 台と読み取り可能なリーダー 2 台を置く構成で、RDS for MySQL と RDS for PostgreSQL で使えます。準で複製し、リーダーは読み取りを受けながら自動フェイルオーバーの昇格先にもなります。フェイルオーバーにかかる時間の目安は、Multi-AZ DB インスタンスが 60〜120 秒程度、Multi-AZ DB クラスターが通常 35 秒未満です。エンジンを変えずに、待機用のインスタンスにも読み取りを担わせたい場合の候補です。

⚠️ 頻出: 「RDS の可用性を高め、自動フェイルオーバーしたい」は Multi-AZ です。「読み取り負荷を分散したい」は Read Replica です。

③Read Replica と読み取りスケーリング

Read Replica は、プライマリ DB から非同期に複製される読み取り用 DB です。読み取りクエリを Read Replica に逃がすことで、プライマリ DB の負荷を下げられます。

用途	Read Replica の判断ポイント
読み取り	SELECT など読み取りを replica へ逃がします。
レポート・分析	本番書き込み DB への影響を減らします。
クロス	別リージョンに replica を作り、災害対策に使えます。
移行	replica を昇格して切り替える構成で使う場合があります。

Read Replica はです。そのため、プライマリに書き込んだ直後のデータが replica にまだ反映されていない可能性があります。強い整合性が必要な読み取りはプライマリへ向ける設計にします。

Read Replica は昇格して独立した DB にできます。ただし、昇格後は元プライマリとのレプリケーション関係が変わるため、DR や移行手順では切り戻しやアプリケーション接続先の変更を考えます。

⚠️ 頻出: Read Replica は読み取りスケール用であり、通常の書き込み性能を直接上げるものではありません。レプリケーション遅延も考慮します。

④バックアップ、スナップショット、PITR

の復旧設計では、自動バックアップ、手動、Point-in-Time Recovery を使い分けます。自動バックアップを有効にすると、保持期間内の特定時点へ復元できます。手動スナップショットは、削除するまで保持されるバックアップとして使えます。

機能	用途	判断ポイント
自動バックアップ	日常的な復旧	保持期間内でに使えます。保持期間は最大 35 日です。
PITR	特定時点への復元	誤更新や障害発生前の時点へ戻す場合に使います。
手動スナップショット	長期保管、移行前、変更前	削除するまで残せます。
クロススナップショットコピー	、別リージョン復旧	リージョン障害への備えに使います。
クロスリージョン自動バックアップ複製	/ に余裕がある DR	スナップショットとトランザクションログを別リージョンに複製し、低コストな復旧ポイントを用意できます。
Server ネイティブバックアップ	.bak による移行、DB 単位の退避	上の .bak を使えますが、RDS のクロスリージョン DR ではスナップショットコピーや自動バックアップ複製を優先して考えます。
	複数サービスのバックアップ一元管理	統制や保持ポリシー管理に向きます。

RDS の復元は、既存 DB をその場で巻き戻すのではなく、新しい DB インスタンスとして復元するのが基本です。復元後は、アプリケーションの接続先切り替え、データ差分、、を確認します。

RDS for SQL Server では、ネイティブバックアップで DB を .bak ファイルとして S3 に出力できます。これは移行、DB 単位のコピー、追加の退避には有効ですが、リージョン障害に備える標準的な DR 判断では、クロスリージョンスナップショットコピーやクロスリージョン自動バックアップ複製を選びます。 RPO/RTO が 24 時間程度まで許容されるなら、常時稼働する別リージョン DB やの継続的より、バックアップ複製による復旧ポイントの方がコストを抑えやすいです。

Point

PITR = Point-in-Time Recovery の略です。
「特定時点への復旧」という意味です。
誤ってデータを消したり更新したりした場合に、事故直前の時点へ復元する用途で出ます。

自動バックアップの保持期間には上限があり、最大 35 日です。要件で数か月や数年の保管を求められる場合、保持日数を延ばす設定では満たせません。長期保管は、手動スナップショットを自分で取得して管理するか、AWS Backup のバックアップ計画で保持期間を指定して管理します。

「35 日を超える保管」と「直近の任意時点への復旧」が同時に求められる問題もよく出ます。AWS Backup では、継続的バックアップによる PITR 用のルールと、長期保持のスナップショット用のルールを 1 つの計画に並べられるため、両方の要件を運用負荷を上げずに満たせます。

⚠️ 頻出: 「誤ってデータを削除したので直前に戻したい」は PITR です。「長期保管や移行前のバックアップ」は手動スナップショットです。

バックアップの費用も保持の設計で変わります。自動バックアップと手動スナップショットが使うバックアップストレージは、リージョン内の DB ストレージの合計サイズまでは追加料金がかかりません。それを超えた分は GB 単位で課金されるため、手動スナップショットを削除せずに取り続けると、費用が積み上がります。自動バックアップは保持期間を過ぎると自動で消えますが、手動スナップショットは削除するまで残ります。

DB スナップショットのデータは、形式で S3 へエクスポートできます。エクスポートしたデータはやで直接分析でき、S3 のライフサイクルで安いへ移せます。ただし、エクスポートしたデータから DB インスタンスを直接復元することはできません。 DB として戻す必要がなく、監査のときに表のデータを参照できればよい長期保管に向きます。

⑤セキュリティ、暗号化、接続管理

は通常、に配置し、アプリケーションサーバーからのみ接続させます。インターネットから直接 DB にアクセスさせる構成は避けます。で、アプリケーションのセキュリティグループから DB ポートへの通信だけを許可する設計が基本です。

観点	関連機能	判断ポイント
ネットワーク分離	DB subnet group、Private subnet	DB を public にしない構成を優先します。
通信制御	Security Group	アプリ SG から DB SG への必要ポートだけ許可します。
保存時暗号化		DB ストレージ、バックアップ、を保護します。
転送時暗号化	/	アプリと DB 間の通信を暗号化します。
認証情報管理		DB パスワード管理とローテーションで使います。
DB 認証	IAM と一時トークン	対応エンジンでパスワード管理負荷を減らせます。

RDS 暗号化は作成時に有効化します。暗号化された DB のスナップショットも暗号化され、復元先でも暗号化が関係します。暗号化されていない既存 DB を暗号化したい場合は、スナップショットをコピーして暗号化し、そこから復元する流れを検討します。ブルー/グリーンデプロイで、グリーン環境に KMS キーを指定して暗号化し、切り替える方法もあります。一方、既存の DB インスタンスの設定変更で暗号化を有効にすること、暗号化されていない DB から暗号化されたを作ること、暗号化されていないスナップショットを暗号化された DB として直接復元することはできません。暗号化したスナップショットを別へコピーするときは、KMS キーがリージョンごとのリソースのため、コピー先リージョンの KMS キーを指定します。

を強制するには、DB パラメータグループで接続に TLS を必須にします。RDS for MySQL では require_secure_transport を ON にすると、TLS を使わない接続が拒否されます (再起動は不要です)。

RDS Proxy は、アプリケーションと RDS の間で接続プールを管理するサービスです。のように多数の短時間接続が発生するワークロードでは、DB 接続数を抑え、時の影響を軽減できます。

⚠️ 頻出: 「Lambda から RDS へ大量接続して DB 接続数が枯渇する」は RDS Proxy を検討します。「DB を直接インターネット公開」は基本的に避けます。

⑥監視、メンテナンス、コスト

の監視では、、Enhanced Monitoring、Performance Insights、RDS イベントを使います。、メモリ、ストレージ、、接続数、遅延、デッドロック、スロークエリなどを確認します。

監視・運用機能	用途	試験での判断ポイント
CloudWatch Metrics	基本メトリクス監視	CPU、FreeStorageSpace、DatabaseConnections などを見ます。
Enhanced Monitoring	レベルに近い詳細監視	DB インスタンスの詳細なリソース状況を見ます。
Performance Insights	DB 負荷と分析	ボトルネック SQL や待機イベントを調べます。
Event subscriptions	RDS イベント通知	障害、、メンテナンスを通知します。
Maintenance window	パッチ適用タイミング	業務影響の少ない時間に設定します。

RDS はですが、SQL チューニング、インデックス設計、スキーマ設計、接続管理、アプリケーション側のトランザクション設計は利用者の責任です。「RDS にすればすべて自動で速くなる」わけではありません。

コストは、DB インスタンスクラス、稼働時間、ストレージ、IOPS、バックアップ保持、、データ転送、、Read Replica、ライセンスによって変わります。本番では Multi-AZ やバックアップが必要になりやすい一方、読み取り負荷が少ないのに Read Replica を増やすとコストが増えます。

常時稼働する DB インスタンスは、リザーブド DB インスタンス（1 年または 3 年）で割り引けます。、DB エンジン、などが一致する使用量へ自動で適用され、Multi-AZ にも Single- にも使えます。割引されるのはインスタンスの時間料金だけで、ストレージ、バックアップ、I/O は対象外です。 MySQL、MariaDB、PostgreSQL、Db2、Oracle（）では、同じインスタンスクラスタイプの中でサイズに柔軟に適用されます。たとえば db.r6i.large の予約は、db.r6i.xlarge へ拡大すると使用量の半分に適用されますが、db.r7g のような別のタイプには適用されません。 SQL Server とライセンス込みの Oracle には、サイズの柔軟性がありません。

メジャーバージョンが RDS の標準サポート終了日を過ぎると、DB インスタンスは自動で RDS 延長サポートに登録され、追加料金がかかります。たとえば RDS for PostgreSQL 13 の標準サポートは 2026 年 2 月 28 日に終わり、翌日から延長サポートの料金が発生しています。延長サポートは最大 3 年の猶予で、料金をなくすには標準サポート中のメジャーバージョンへアップグレードします。

負荷に対して大きすぎるインスタンスクラスも、無駄な費用の原因です。 CloudWatch の CPUUtilization や FreeableMemory を数週間分見て、ピーク時でも余裕が大きいなら、1 つ小さいサイズへ変更します。

開発やテストの環境では、使わない時間帯に DB インスタンスを停止するとインスタンス料金を止められます。ただし RDS の停止には期限があり、停止したままにしておくと最大 7 日で自動的に起動します。平日夜間と週末を止め続けるような運用では、停止と起動を定期的に実行する仕組みが必要です。

時間外に止めたい対象	実現する仕組み	判断ポイント
RDS の起動と停止	Scheduler のユニバーサルターゲットで StartDBInstance / StopDBInstance を直接呼ぶ	関数のコードもサーバーも持たずに済みます。
と RDS の両方	EventBridge のスケジュール + から起動・停止を呼ぶ	停止前の確認など独自の処理を足したいときに向きます。
EC2 の台数だけ	グループのスケジュールドアクション	台数の増減であり、RDS には適用できません。
手順を持つ運用作業	Automation	停止前の確認など複数手順をまとめたい場合に向きます。

Read Replica の追加や削除は読み取りをスケールさせる手段で、時間外にコストを止める手段ではありません。管理用の EC2 を常時稼働させてスクリプトを回す構成も動きますが、そのインスタンス自体の費用とパッチ運用が残ります。

⚠️ 頻出: 「業務時間外だけ止めたい」は EventBridge Scheduler で起動・停止 API を定期的に呼ぶ構成です。ユニバーサルターゲットなら Lambda を挟まずに API を直接呼べます。RDS は停止しても最大 7 日で自動起動する点に注意します。

⚠️ 頻出: 「DB が遅い」問題では、インスタンスサイズだけでなく、SQL、インデックス、接続数、ストレージ I/O、Performance Insights を確認します。

試験対策

SAA の問題では、まず「可用性」「読み取り性能」「復旧」「接続管理」のどれが問われているかを切り分けます。可用性なら、読み取り性能なら Read Replica、誤削除からの復旧なら、長期保管なら手動、多数接続なら RDS Proxy が候補です。

Multi-AZ と Read Replica の混同は頻出です。 Multi-AZ はスタンバイを使った・のための機能です。 Read Replica は非同期複製による読み取りスケールや補助のための機能です。

問題文のキーワード	優先して考える機能	理由
DB 障害時に自動フェイルオーバー	Multi-AZ	別のスタンバイへ切り替えられます。
読み取り負荷が高い	Read Replica	読み取りクエリを分散できます。
書き込み直後の整合性が必要	Primary DB へ読み取り	Read Replica は遅延する可能性があります。
誤更新前の時点へ戻したい	PITR	自動バックアップ保持期間内の時点へ復元できます。
長期保管や変更前バックアップ	Manual snapshot	削除するまで保持できます。
別 DR で / が 24 時間程度まで許容される	Cross-Region automated backups / Snapshot copy	常時稼働する複製 DB より低コストに復旧ポイントを用意できます。
Server の .bak をに出力して DR としたい	Snapshot copy / Automated backup replication を比較	.bak は移行や DB 単位コピーに向きますが、RDS のリージョン DR ではバックアップ複製が標準候補です。
数分単位の RPO や継続同期が必要	Read Replica / などを検討	バックアップ復旧だけではデータ損失や復旧時間の要件を満たせない可能性があります。
から接続が急増	RDS Proxy	接続プールで DB 接続数を抑えます。
開発環境を業務時間外だけ止めたい	Scheduler（を直接呼ぶか Lambda）	RDS は停止しても最大 7 日で自動起動します。
DB を private にしたい	Private subnet + Security Group	アプリ層からのみ接続させます。
保存データを暗号化	encryption	DB、バックアップ、スナップショットを保護します。
SQL のボトルネック調査	Performance Insights	DB 負荷と待機イベントを分析できます。

よくある誤答は、DB を public subnet に置いてインターネットから直接接続させる構成です。通常は、とアプリケーション層を外部入口にし、RDS は private subnet に置き、でアプリケーション層からの通信だけを許可します。

との比較では、Aurora は RDS の一部として提供されるクラウド向け DB エンジンですが、SAA では RDS 標準エンジンと Aurora の可用性・性能・レプリカ・グローバル構成の違いが問われることがあります。「既存 Oracle/SQL Server 互換」が強い場合は RDS エンジン、「MySQL/PostgreSQL 互換で高い性能・可用性・クラウド最適化」が強い場合は Aurora も比較します。

コスト面では、Multi-AZ、Read Replica、Provisioned 、大きいインスタンス、バックアップ保持、ライセンスが増加要因です。 SAA では料金数値ではなく、可用性や性能を上げる機能はコストも増えるため、要件に対して過剰構成にしない判断が重要です。

Amazon RDS (Relational Database Service)

概要

主要技術

①DB エンジン、インスタンスクラス、ストレージ

②Multi-AZ と高可用性

③Read Replica と読み取りスケーリング

④バックアップ、スナップショット、PITR

⑤セキュリティ、暗号化、接続管理

⑥監視、メンテナンス、コスト

試験対策

参考文献