Amazon RDS for PostgreSQLは、AWSがバックアップ・パッチ適用・フェイルオーバーを引き受けた形でPostgreSQLを動かすマネージドサービスです。退避の仕組みは用意されますが、保持期間の決定と論理バックアップの取得は利用者側に残るため、方式そのものの選び方はPostgreSQLのバックアップ設計｜pg_dumpとPITRの使い分け・復旧検証の手順を参照してください。素のPostgreSQLと同じSQLが通る一方、可用性の組み方・入れられる拡張機能・版の期限・移行の入り口はRDS側の作法に従います。ここを設計時に決めておかないと、運用へ入ってから構成変更や課金の追加という形で跳ね返ってきます。
この記事では、マネージドサービス全般の料金モデルやエンジン選定はAmazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断に、Aurora側の版事情とBabelfishはAurora PostgreSQLとは？対応バージョン・拡張機能とBabelfish・RDSからの移行判断に譲り、PostgreSQLを標準RDSで動かすときの構成と運用に絞って扱います。データベースの種類そのものを整理したい場合はデータベースとは？種類・DBMS・RDBとNoSQLの選び方から読み進めてください。数値は2026年8月時点のAWS公式ドキュメントで実測しています。
まとめ：RDS for PostgreSQLで構築前に決める4点
- 可用性の型：スタンバイが読めないDBインスタンス配置か、2台が読めるDBクラスター配置か。後者はローカルNVMe付きインスタンスクラスに限られ、PostgreSQL 14なら14.5以上という下限も付きます
- 拡張の統制：
rds.allowed_extensionsは動的パラメータで再起動が要りませんが、shared_preload_librariesは再起動を挟みます。両者を混ぜて計画すると停止時間の見積りが崩れます - 版の期限：メジャー版よりマイナー版の標準サポート終了日が先に来ます。17.6や16.10などは2026年10月31日、13系はすでに標準サポートを抜けて延長サポートの課金帯へ入りました
- 移行の入り口：オンプレミスからDMSで移すなら
wal_levelをlogicalへ変える再起動が先に立ちます。主キーのないテーブルは変更データキャプチャで更新と削除が落ちます
マルチAZ DBインスタンス配置とDBクラスター配置の構成差
RDS for PostgreSQLの可用性には、名前の似た2つの型があります。どちらも「マルチAZ」と呼ばれますが、待機側が読めるかどうか、コミットが誰の承認を待つか、選べるインスタンスクラスは何かという点で別物です。設計の初手はここの選択になります。
スタンバイが読めない配置と2台が読めるクラスター配置の違いと設計判断
マルチAZ DBインスタンス配置は、プライマリと別のアベイラビリティーゾーンにスタンバイを1台置く形です。スタンバイは待機に徹し、アプリケーションから読み取りを投げられません。読み取りを分散したい場合は、別途リードレプリカを足す構成になります。
マルチAZ DBクラスター配置では、1台のライターと2台のリーダーが同一リージョン内の3つのアベイラビリティーゾーンに分かれて置かれます。2台のリーダーは読み取りトラフィックを受けられるため、待機のためだけに費用を払う構図から抜けられる形です。AWSはDBインスタンス配置と比べて、可用性・読み取り容量・書き込みレイテンシーの3点で優位があると説明しています。
| 観点 | DBインスタンス配置 | DBクラスター配置 |
|---|---|---|
| 台数と配置 | 2台・2つのAZ | 3台・3つのAZ |
| 待機側の読み取り | できない | 2台とも読める |
| 読み取りの拡張 | リードレプリカを別途追加 | リーダー2台をそのまま使う |
| PostgreSQLの下限 | 実質の下限なし | 14は14.5以上・13は13.4と13.7 |
準同期レプリケーションでコミットが待つ相手と書き込み遅延の関係
DBクラスター配置は準同期レプリケーションで動きます。変更を確定させるには、2台のリーダーのうち少なくとも1台からの承認が要ります。全台の書き込み完了を待たない設計のため、1台が遅れても書き込み全体が引きずられにくい構造です。
この差はフェイルオーバーの読み方にも効いてきます。切り替え時間はレプリカの遅延に左右されるので、遅延を監視項目へ入れておかないと復旧見込みを説明できません。切り替え中の接続断をアプリケーション側へ波及させたくないなら、RDS Proxyとは？対応エンジン・料金・仕組みと導入手順で扱った接続プールを前段に置く構成を併せて検討してください。マイナーバージョンアップグレードの停止時間を1秒以下へ縮められるという記述もあり、更新運用の面でも効き目があります。
クラスター配置で選べるインスタンスクラスと対応バージョンの下限
DBクラスター配置には見落としやすい制約があります。使えるインスタンスクラスがローカルNVMeストレージを持つ系統に限られ、db.c6gd・db.m5d・db.m6gd・db.m6id・db.m6idn・db.m8gd・db.r5d・db.r6gd・db.r6id・db.r6idn・db.r8gd・db.x2iednが対象です。mediumサイズを選べるのはdb.c6gdだけなので、小規模環境をクラスター配置で組もうとすると選択肢がほとんど残りません。
対応バージョンも一律ではありません。PostgreSQL 15から18までは全マイナー版が対象ですが、14は14.5以上、13は13.4と13.7以上という下限が付きます。リージョンにも差があり、東京と大阪は全対応版が使える一方、北カリフォルニア・台北・タイ・ニュージーランド・GovCloudでは利用できません。手元の条件で本当に組めるかは、次のコマンドで確かめられます。
aws rds describe-orderable-db-instance-options --engine postgres --db-instance-class db.r6gd.large --query "*[]|[?SupportsClusters].[EngineVersion]" --output textパラメータグループで拡張機能を統制するRDS固有の拡張管理作法
PostgreSQLの拡張機能は、RDSではインスタンスへ直接ファイルを置く形では入りません。AWSが用意した拡張の中から、パラメータグループとSQLの両方を通して有効にする流れになります。PostgreSQLのインストール手順｜Windows・Ubuntu別の導入とinitdbで決まる文字コードで扱ったローカル環境の感覚のまま進めると、権限とパラメータの2箇所で止まります。
rds.allowed_extensionsで入れられる拡張を絞り込む手順
RDSには、インストールできる拡張を明示的に列挙するパラメータがあります。rds.allowed_extensionsの既定値は'*'で、そのエンジンバージョンで使える拡張なら何でも入れられる状態です。統制をかけたい環境では、カンマ区切りで許可する拡張名だけを並べます。
rds.allowed_extensions = 'pg_stat_statements,pgaudit,pg_repack'現在の値はSQLで確認できます。動的パラメータなので、変更してもデータベースの再起動は要りません。
SHOW rds.allowed_extensions;使えるのはPostgreSQL 12.7以上、13.3以上、そして14以降の全バージョンです。古い版を引きずっている環境では、この統制そのものが効かない点に注意してください。AWSが提供する拡張には、orafce・pg_partman・pgAudit・pg_cron・pglogical・pgactive・pg_repack・PLV8・PL/Rust・PostGIS・pg_tleなどがあります。
拡張の一部は、サーバー起動時に読み込まれないと動きません。pg_stat_statementsは既定で読み込まれますが、ジョブスケジューラのpg_cronや実行計画を記録するauto_explainはshared_preload_librariesへの追記が要ります。こちらは静的パラメータで、反映には再起動を挟みます。
ここが前節との非対称です。許可リストの変更は無停止で通るのに、読み込み対象の追加は停止時間を伴います。作業計画を組むときは、再起動を要する変更をまとめて1回のメンテナンス枠へ寄せ、無停止で済む変更は別枠へ分けてください。両者を同じ手順書へ混ぜると、停止時間の見積りが実態から離れます。
信頼できる拡張とrds_superuserで変わる権限の境界線
誰がCREATE EXTENSIONを実行できるかは、バージョンで線が引かれています。PostgreSQL 12以前はrds_superuserの権限が要りました。13以降では信頼できる拡張という区分が入り、対象のデータベースに対する作成権限を持つロールなら、管理者権限なしで導入と利用ができます。
RDSでは素のsuperuserロールが利用者へ渡されないため、この区分が実務に効きます。開発チームへ拡張の導入を任せたいなら、信頼できる拡張に該当するかを先に確認し、該当しないものだけを運用側の作業として切り出す形が現実的です。権限設計を決めないまま進めると、環境ごとに入っている拡張が食い違い、本番だけ動かないという事故につながります。拡張のうちpgcryptoによる列暗号化と、保存時暗号化を有効にできる条件はPostgreSQLの暗号化｜TLS設定・pgcryptoの列暗号化とTDE不在時の選び方で扱っています。
マイナー自動更新と標準サポート終了後に始まる延長サポート課金
RDS for PostgreSQLは、コミュニティのリリースを追う周期が公開されています。メジャー版は新メジャーの初回マイナーがコミュニティで出てから30日以内、マイナー版は7日以内にRDSへ届く形です。この周期を前提に、版計画を年単位で引いておきます。
マイナー版の標準サポート終了日が先に来る前提の押さえ方と運用計画
期限の設計で見落とされやすいのが、メジャー版とマイナー版で終了日が別々に決まる点です。たとえばメジャー版14の標準サポート終了は2027年2月28日ですが、マイナー版14.19の終了は2026年10月31日で、こちらが先に来ます。17.6・16.10・15.14も同じ2026年10月31日です。
| メジャー版 | コミュニティEOL | RDS標準サポート終了 |
|---|---|---|
| PostgreSQL 18 | 2030年11月 | 2031年2月28日 |
| PostgreSQL 17 | 2029年11月 | 2030年2月28日 |
| PostgreSQL 16 | 2028年11月 | 2029年2月28日 |
| PostgreSQL 15 | 2027年11月 | 2028年2月29日 |
| PostgreSQL 14 | 2026年11月12日 | 2027年2月28日 |
| PostgreSQL 13 | 2025年11月 | 2026年2月28日 |
稼働中のインスタンスがどの版かを把握していないと、この表は使えません。サーバ側とクライアント側で見える値が違う点も含め、確認手順はPostgreSQLのバージョン確認方法｜サーバ・クライアント別コマンドとEOL判定・更新計画にまとめてあります。
新規作成できない状態に置かれるマイナー版の扱いの注意と構築時の確認
もう1つ、構築時に足を取られる仕様があります。一部のマイナー版は新規作成の対象から外され、そのバージョンで新しいDBインスタンスを立てられません。2026年2月12日にリリースされた18.2・17.8・16.12・15.16・14.21がこの扱いです。
すでに動いているインスタンスがその版のまま残るぶんには使えますが、同じ版で検証環境を新しく作ろうとすると弾かれます。構成管理コードにマイナー版を固定で書いている場合、ある日を境にコードが通らなくなる形です。版を固定するなら、この状態に置かれていないかを構築前に確かめてください。
延長サポートの課金開始と3年目に単価が上がる負担の試算と移行判断
標準サポートが切れた版を使い続ける道もあります。延長サポートに入れば、コミュニティが更新を止めた版にもAWSがセキュリティ修正を出し続けます。ただし有償です。米国東部（オハイオ）のPostgreSQL 12を例にすると、2025年3月1日から2027年2月28日まではvCPU時間あたり0.100 USD、2027年3月1日以降は0.200 USDへ上がると案内されています。東京リージョンの延長サポート単価と、Multi-AZ構成で月額がどれだけ増えるかの試算はAWS RDSの料金を東京リージョンの実額で計算するにまとめています。
実額に直すと負担が見えます。8vCPUのインスタンスを1か月730時間動かした場合、年1〜2年目の単価で8×0.100×730＝584 USD、3年目以降は1,168 USDが通常の料金へ上乗せされる計算です。インスタンス台数ぶん積み上がるため、検証環境まで古い版で残していると効いてきます。
厄介なのは、意図せず課金が始まる経路がある点です。標準サポート終了日を過ぎた版でインスタンスを作成した場合や、その版のスナップショットを復元した場合にも料金が発生します。13系は2026年2月28日に標準サポートを抜けて2026年3月1日から課金帯へ入り、3年目の単価は2028年3月1日から適用開始です。回避策は単純で、標準サポートの期間内にメジャーバージョンアップグレードを済ませることに尽きます。版計画とアップグレード検証の設計を含めた基盤構築はインフラ構築（AWS・Google Cloud・Azure）でも承っています。
オンプレミスのPostgreSQLからDMSで移行する手順と落とし穴
既存のPostgreSQLをRDSへ寄せる場合、AWS Database Migration Serviceを使うと全ロードと変更データキャプチャを組み合わせて停止時間を縮められます。ソースとして対応するのはPostgreSQL 9.4.x以降です。ただし移行元へ手を入れる前提があり、そこを詰めないままタスクを作ると初回から失敗します。
変更データキャプチャに必要な設定ファイルの書き換え項目と確認値
変更データキャプチャを使うなら、移行元のpostgresql.confを書き換えます。wal_levelはlogicalへ、レプリケーションスロットと送信プロセスの上限は実行するタスク数以上へ引き上げます。
wal_level = logical
max_replication_slots = 5
max_wal_senders = 5
wal_sender_timeout = 60000wal_sender_timeoutは既定で60,000ミリ秒です。AWSは最低でも10,000ミリ秒を確保し、マルチAZのフェイルオーバー時に遅延が出るのを避けるため5分未満へ収めるよう案内しています。0にするとタイムアウトが無効になりますが、推奨されていません。あわせてpg_hba.confへレプリケーションインスタンスからの接続を許可する行を足します。
host all all 12.3.4.56/32 md5
host replication dms 12.3.4.56/32 md5出力プラグインの選び分けと移行ユーザーに要る権限の切り分け方
論理デコードの出力プラグインは2択です。既定はtest_decodingで、追加の作業なしに動きます。対象を絞ってレプリケーションしたい場合はpglogicalが選べます。こちらはshared_preload_librariesへの追加とサーバー再起動を経て、CREATE EXTENSION pglogical;を実行する流れです。
権限はタスクの種類で変わります。全ロードのみなら移行対象の全列に対するSELECT権限があれば十分です。変更データキャプチャを含む場合はレプリケーション機能へ触れるため、スーパーユーザー権限が要ります。SELECT権限に欠けがあるとメタデータの食い違いを招き、タスクが途中で落ちるので、対象スキーマを列挙して事前に確認してください。
移行されないオブジェクトと主キーのないテーブルの手当ての実務判断
DMSはデータを移す仕組みで、スキーマ定義をそのまま持っていく道具ではありません。移行の前後で手当てが要るものを整理しておきます。
| 対象 | DMSでの扱い |
|---|---|
| マテリアライズドビュー | 非対応 |
| OID型のLOBデータ | 移行されない |
| パーティション表 | 親子を手動で作成 |
| 主キーのないテーブル | 更新と削除が無視される |
| 精度39以上のNUMERIC | 文字列へ変換 |
特に効くのが主キーの有無です。変更データキャプチャでは主キーが行を特定する手がかりになるため、これがないテーブルはDELETEとUPDATEが反映されません。ログテーブルのように追記しかしない表なら実害が出にくい一方、更新のある表を主キーなしで抱えているなら、移行前に一意キーを立てる作業を工程へ入れておきます。ARRAY型を含む列も主キーが要り、ない場合は全ロードの段階で中断します。NUMERICは既定でNUMERIC(28,6)として扱われる点も、金額列を持つシステムでは確認しておく箇所です。
RDS for PostgreSQLを採用する条件とAuroraへ寄せる場面の線引き
ここまでの構成と運用を踏まえて、採用の可否を条件で言い切ります。マネージドPostgreSQLの選択肢は標準RDSだけではないため、どこで線を引くかを先に決めておくと構成変更の手戻りを避けられます。
標準RDSのPostgreSQLで足りるワークロードの条件の見極め
標準RDSを採る条件は3つです。第1に、書き込みが単一インスタンスで捌ける規模で、読み取りの伸びもリーダー2台までで収まること。第2に、ストレージ料金を確保した容量ぶんの定額で見積もりたいこと。第3に、素のPostgreSQLと同じ挙動を前提に、既存のアプリケーションや運用手順をそのまま持ち込みたいことです。
この3つが揃うなら、標準RDSで組んで問題ありません。可用性はDBクラスター配置で待機側も読み取りへ回し、接続数の増減はプロキシで吸収する形が扱いやすい構成になります。
AuroraやサーバーレスPostgresへ寄せる場面の切り分け方
Auroraへ寄せるのは、読み取りレプリカを3台以上へ広げたい場合、ストレージを使った量だけで課金したい場合、そしてSQL Serverの資産を互換レイヤで受けたい場合です。Aurora側の対応バージョンや拡張の可否、移行経路の選び分けはAurora PostgreSQLとは？対応バージョン・拡張機能とBabelfish・RDSからの移行判断で扱っているので、比較検討はそちらを起点にしてください。
アクセスが断続的で、使われない時間帯にインスタンス料金を払いたくないなら、Neonとは？サーバーレスPostgresの構成・料金と採用判断のようなサーバーレス型が候補へ入ります。Azure側で同じエンジンを動かす場合の階層選択・ゾーン冗長HA・ネットワーク分離の決め方はAzure Database for PostgreSQLとは？フレキシブルサーバーの構成・ゾーン冗長HAと移行判断で扱っています。逆に、ライセンス費用を含めた総額でオンプレミス継続と比べたい段階なら、PostgreSQLのライセンスと価格：無償の範囲と実際に払う費用・5年総額での判断で前提を揃えてから見積もってください。
採用を見送るべき場面とはまりやすい3つの失敗パターンの防ぎ方
見送る判断が要る場面もあります。AWSが提供していない拡張やカスタムのC言語関数に依存しているなら、RDSでは動かせません。この場合はEC2への自前構築か、拡張への依存を外す改修を先に置きます。ファイルシステムへ直接アクセスする運用スクリプトを抱えている環境も同様です。
失敗パターンは3つに集約されます。1つ目は、DBクラスター配置を前提に設計したのにインスタンスクラスの制約で組めず、構成を差し戻すこと。2つ目は、マイナー版の期限を見ないまま構築し、稼働直後に更新作業へ追われること。3つ目は、主キーのないテーブルを抱えたままDMSのタスクを組み、切り替え直前に差分の欠落へ気づくことです。いずれも設計段階のチェックで防げます。
よくある質問
RDS for PostgreSQLと素のPostgreSQLはどこまで同じですか？
SQLの構文と挙動はコミュニティ版と同じです。相違点はサーバーの外側です。OSへのログインができず、superuserロールも渡されないため、拡張の導入とパラメータ変更はパラメータグループとRDS側のロールを通す形になります。ファイルシステムを直接触る運用手順を持ち込むと、そこだけ置き換えが要ります。
マルチAZにすれば読み取り性能も上がりますか？
配置によります。マルチAZ DBインスタンス配置のスタンバイは読み取りを受けないため、可用性は上がっても読み取り性能は変わりません。読み取りを分散したいなら、リードレプリカを足すか、リーダー2台が読めるマルチAZ DBクラスター配置を選んでください。
RDSで使えない拡張機能があるのはなぜですか？
RDSではAWSが検証した拡張だけがインストール可能な状態で用意されているためです。任意のソースをコンパイルして置く運用は想定されていません。導入できるかどうかは、エンジンバージョンごとの対応状況とrds.allowed_extensionsの設定の両方で決まります。
延長サポートの料金は自動で発生してしまいますか？
標準サポート終了日を過ぎた版で動かし続けた場合、そのまま課金対象になります。加えて、期限を過ぎた版で新しくインスタンスを作った場合や、その版のスナップショットを復元した場合にも発生します。避けるには、標準サポートの期間内にメジャーバージョンアップグレードを終えておくことです。
オンプレミスからの移行はどれくらい止まりますか？
全ロードだけで済ませるなら、データ量に応じて書き込みを止める時間が必要です。変更データキャプチャを併用すれば、全ロード中の変更を追いかけたうえで切り替えられるため、停止は接続先を変える数分程度へ抑えられます。ただし移行元のwal_level変更に再起動が要るので、その分の停止枠は別に確保してください。
