Aurora PostgreSQLとは？対応バージョン・拡張機能とBabelfish・RDSからの移行判断を実装者目線で解説

Aurora PostgreSQLの検討でつまずくのは、分散ストレージの仕組みより手前にある地味な確認です。使いたい拡張が対象の版に入っているか、選んだメジャーバージョンの標準サポートがいつ切れるか、既存のRDS for PostgreSQLをどの経路で移すか。ここを詰めずに構築へ進むと、移行の直前に「Aurora側がまだその版へ追いついていない」と判明したり、依存する拡張が入らず改修が発生したりします。

この記事では、Aurora PostgreSQL互換エディションについて、版の提供サイクルとサポート期限、拡張機能の対応状況、SQL Server資産を受けるBabelfish、RDS for PostgreSQLからの移行経路という順で、構築前に確定させる論点を扱います。各章の終わりには、その場で打てるAWS CLIコマンドとSQLを置きました。分散ストレージやI/O課金といったAurora共通の仕組みはAmazon Auroraとは？仕組み・RDSとの違いと料金モデルで整理済みのため、本記事はPostgreSQL互換版に固有の互換性と移行へ絞りました。選定そのものの前提はデータベースとは？種類・DBMS・RDBとNoSQLの選び方で確認できます。数値は2026年9月時点でAWS公式ドキュメントを実測した値です。

まとめ：Aurora PostgreSQLで構築前に決める4点

結論を先に4点で示します。第一に、版の選定はコミュニティ版のEOLではなくAurora側の標準サポート終了日で見ます。18系は2026年6月11日に18.3がAuroraで提供開始となり、13系の標準サポートは2026年2月28日で終了済みです。終了日を過ぎた版は有償のRDS Extended Supportへ自動的に移ります。

第二に、同じメジャー内でもLTSリリースと通常マイナーで期限が違います。17.7（LTS）の標準サポート終了は2030年2月28日ですが、通常マイナーの17.10は2027年12月31日で切れます。更新頻度を落としたいならLTSを選ぶ判断になるでしょう。

第三に、拡張機能はメジャーごとに対応版が違い、エンジンを上げても自動では上がりません。pgvectorは18.4と17.10と16.14で0.8.2ですが、16.2では0.5.1どまりです。依存する拡張の必要版から逆算してエンジンの版を決めてください。

第四に、RDS for PostgreSQLからの移行は4経路あり、停止時間の許容度で選びます。計画の初期にマイナーバージョン自動アップグレードを切るのも定石です。

この4点は机上で決めきれるものではなく、リージョンごとの提供状況や既存クラスタの拡張一覧を打って確かめる作業が挟まります。以下、根拠の一次情報と、確認に使うコマンドを章ごとに並べます。

対応バージョンと標準サポート終了日をCLIで確認して更新計画を引く

Auroraの版はコミュニティ版の番号がそのまま使われ、13.3・12.8・11.13以降はAurora独自の番号が付きません。この点はAWSのAurora PostgreSQLのリリースとエンジンバージョンに明記されています。まず提供サイクルと期限の並びを押さえ、そのうえで自分のリージョンで何が取れるかを打って確かめます。

利用できるエンジン版をCLIで一覧し提供サイクルと突き合わせる

AWSは版の追随ペースを明示しています。メジャーはコミュニティが新メジャーの最初のマイナーを出してから8か月以内、マイナーはコミュニティのリリースから3か月以内、LTSは該当メジャーのAuroraリリースから12か月以内という目安です。実際、PostgreSQL 18はコミュニティが2026年2月26日に出し、AuroraではAurora PostgreSQL 18.3として2026年6月11日に提供が始まりました。

ただしこの目安はグローバルの話で、手元のリージョンに何が来ているかは別です。AWS公式が案内している確認方法は、次のCLIコマンドを叩いて実在の版を並べるやり方になります。

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --region ap-northeast-1 \
  --query "DBEngineVersions[].[EngineVersion,DBEngineVersionDescription]" \
  --output text

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version 17 \
  --region ap-northeast-1 \
  --query "DBEngineVersions[].ValidUpgradeTarget[].EngineVersion" \
  --output text

前者で提供中の版が一覧でき、後者では17系から直接上げられる先が出ます。設計書に書いた版が出てこなければ、そのリージョンではまだ取れません。標準サポート終了日はメジャーごとに定まり、おおむねコミュニティEOLの数か月後に置かれます。更新計画はこの日付から逆算します。

終了日を過ぎても即座に停止するわけではなく、有償のRDS Extended Supportで稼働を継続できます。登録状態はクラスタ単位の EngineLifecycleSupport パラメータで切り替えられ、変更はダウンタイムなしで即時反映される仕組みです。ここで見落としやすいのが、登録を外したときの挙動でしょう。標準サポート終了日を過ぎたクラスタで登録を解除すると、次のサポート対象メジャーへ自動的にアップグレードされます。延命の上限はコミュニティEOLから最大3年で、その後は同じく自動で上がります。延命の値段を払うか自分のタイミングで上げるかの判断になるため、終了日の1年前には検証環境で上位版を動かしておきたいところ。稼働中の版を確認する手順はPostgreSQLのバージョン確認方法とEOL判定にまとめています。

LTSと通常マイナーの期限差を洗い出して更新頻度を決める手順

見落とされやすいのが、同じメジャー内での期限差です。LTSリリースはそのメジャーの標準サポート終了日まで同じマイナー版に留まれますが、通常のマイナー版はリリースからおよそ1年半で個別に切れます。

2026年8月21日提供の最新マイナーは18.4・17.10・16.14・15.18・14.23で、標準サポート終了はいずれも2027年12月31日です。一方、16.8（LTS）は2029年2月28日、15.10（LTS）は2028年2月29日まで持ちます。最新マイナーを追う運用は、1年半ごとに更新検証が回る前提になります。

LTSが放置されるわけではない点も押さえておきましょう。リリースノートを見ると、17.7には2026年7月20日の17.7.5、16.8には2026年8月5日の16.8.8というパッチリリースが当たっています。マイナー番号を動かさないまま脆弱性修正が入る形なので、回帰テストの再実行範囲はマイナー更新より小さく収まります。

LTSを選ぶ条件は明確です。回帰テストが重くマイナー更新のたびに検証工数を割けない場合、あるいは監査の都合で構成変更の頻度を抑えたい場合はLTSへ寄せます。修正や拡張の新版を早く取り込みたい開発寄りの環境なら通常マイナーで構いません。なお18系のLTSは2026年9月時点で未設定です。

Limitless Databaseを使う前提なら16系に固定して判断する

書き込みを水平にスケールさせるAurora PostgreSQL Limitless Databaseは、通常のエンジン版とは別系列で提供されます。2026年9月時点で公開されているのは16系のlimitless版までで、17系や18系の版は並んでいません。将来Limitlessを使う前提なら16系に留まる必要があり、17系や18系の新機能とは同時に取れない構図です。

判断の順序としては、シャーディングが要件に入るかを先に決めます。単一ライターで捌ける規模なら、Limitlessを外して最新メジャーを取るほうが拡張の新版も付いてきて得でしょう。逆に将来の分割が確実なら、16系で設計しておいたほうが後の作り直しを避けられます。

拡張機能の対応版を先に確定してからエンジンの版を決める作業手順

Aurora PostgreSQLは同じ拡張機能の仕組みを持ち、CREATE EXTENSION で導入します。ただしAWSが検証した版だけが入る点と、Aurora側が独自に足すモジュールがある点で扱いが変わります。

pgvectorやPostGISの対応版をメジャーごとに突き合わせる

拡張のバージョンはエンジンのメジャー・マイナーに紐づきます。AWSのAurora PostgreSQLがサポートする拡張一覧を2026年9月時点で引くと、主要な拡張でも差がはっきり出ます。

同じ18系でも18.3ではpgvectorが0.8.1、PostGISが3.6.1と一段古く、マイナーひとつで拡張の版が動きます。ベクトル検索の索引方式のように、拡張の版が上がって初めて使える機能があるため、pgvectorのリポジトリで必要な機能が入った版を確かめてから、その版が載るエンジンを選ぶ順序を取ってください。逆順で進めると、構築後に「入っている版では要件を満たせない」と判明します。

なおAWS側は、拡張の新版が出た次の四半期リリースで取り込む方針を公開しています。拡張のサポート終了についても、可能な場合は12か月前に告知するとされています。コミュニティの最新版へ即座に追随する前提では設計しないほうが安全でしょう。

Aurora固有モジュールとAWS連携関数の依存を棚卸しする

コミュニティ由来の拡張に加えて、Aurora固有のモジュールが用意されています。統計情報を取る aurora_stat_utils（全版で1.0）、実行計画を固定・管理する apg_plan_mgmt（18系で3.0、17.10で2.9）が代表です。後者は問い合わせ計画の揺れを抑えたい業務システムで効きます。

AWSサービスとの連携口も拡張の形で提供されます。aws_commons（1.2）を土台に、S3との入出力を担う aws_s3（18系・17.10以降・16.14以降で2.0）、Lambda関数を呼ぶ aws_lambda（18系で2.1）、SageMakerやBedrockの推論を叩く aws_ml（18系から16系で2.0）が並びました。素のPostgreSQLには無いため、RDSやオンプレミスへ戻す可能性がある構成では依存を作らない判断もあり得ます。

棚卸しの単位は「この拡張が無いと動かないSQLがどこにあるか」です。aws_s3 を使ったバルク取り込みが日次バッチの中核に入っていると、移行先の選択肢がAurora以外へ広がりません。設計レビューの時点で、AWS固有の関数を呼ぶ箇所に印を付けておくと後で効きます。

エンジン更新の前後で拡張版を確認してALTER EXTENSIONを流す

ここは事故が起きやすい箇所です。エンジンの版を上げても、インストール済みの拡張は自動でアップグレードされません。16.2で0.5.1のpgvectorを入れたクラスタを16.14へ上げても、明示的に更新するまで0.5.1のままです。AWSの拡張一覧にも、エンジン更新のワークフローでは拡張版が自動的に上がらないと書かれています。

手当ての順序は、エンジン更新の前に導入済み拡張と利用可能版を突き合わせ、更新後にALTER EXTENSIONの UPDATE 句を流す形になります。そのまま貼って使えるSQLは次のとおりです。

-- 導入済みの拡張と、現在のエンジンで使える版を突き合わせる
SELECT e.extname,
       e.extversion              AS installed,
       max(v.version)            AS available_max
  FROM pg_extension e
  JOIN pg_available_extension_versions v ON v.name = e.extname
 GROUP BY e.extname, e.extversion
 ORDER BY e.extname;

-- エンジン更新の後に、差のある拡張だけを上げる
ALTER EXTENSION vector  UPDATE;
ALTER EXTENSION postgis UPDATE TO '3.6.3';

-- 上がったかどうかをもう一度確認する
SELECT extname, extversion FROM pg_extension ORDER BY extname;

1本目の結果で installed と available_max が食い違う行が、更新漏れの候補です。チェックリストへ入れておかないと、版が上がったつもりで古い実装が残り続けます。自社で抱えきれない場合は、AWSを含むクラウドインフラ構築の相談窓口で版計画と拡張の棚卸しをあわせて相談する手もあります。

BabelfishでSQL Server資産を受けるクラスタを作る前提と制約

Aurora PostgreSQLにあってRDS for PostgreSQLにない代表的な機能がBabelfishです。SQL Server向けのアプリケーションを、ドライバを替えずに接続させる仕組みで、移行案件の選択肢を広げます。AWSの説明では、初出はAurora PostgreSQL 13.4で、以降のリリースごとにT-SQLの対応範囲が広がってきました。

クラスタ作成時にrds.babelfish_statusをonにして起動する

BabelfishはAurora PostgreSQLクラスタに追加のエンドポイントを与え、SQL Serverのワイヤプロトコルであるtabular data stream（TDS）を解釈します。対応はTDS 7.1から7.4まで。接続ポートは方言ごとに分かれ、T-SQLは既定で1433、PL/pgSQLは既定で5432を使います。

実装上の前提は次のとおりです。有効化はDBクラスターパラメータグループの rds.babelfish_status を on にしたうえでクラスタを作成する形を取ります。babelfish_db は予約名で、同名のデータベースを自分で作るとプロビジョニングが失敗します。マスターユーザー名は小文字で作らないとTDSポート経由で接続できません。Babelfishクラスタの作成手順に沿って、パラメータグループの用意からクラスタ作成までをCLIで通すと次の形になります。

aws rds create-db-cluster-parameter-group \
  --db-cluster-parameter-group-name bbf-pg17 \
  --db-parameter-group-family aurora-postgresql17 \
  --description "babelfish enabled"

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name bbf-pg17 \
  --parameters \
    "ParameterName=rds.babelfish_status,ParameterValue=on,ApplyMethod=pending-reboot" \
    "ParameterName=babelfishpg_tsql.migration_mode,ParameterValue=multi-db,ApplyMethod=pending-reboot"

aws rds create-db-cluster \
  --db-cluster-identifier bbf-demo \
  --engine aurora-postgresql \
  --engine-version 17.10 \
  --db-cluster-parameter-group-name bbf-pg17 \
  --master-username bbfadmin \
  --manage-master-user-password

データベース移行モードはsingle databaseとmultiple databasesの2択で、Aurora PostgreSQL 16以降は後者が既定です。単一のSQL Serverインスタンス由来の複数DBを束ねるなら後者、最終的にBabelfishを外す計画なら前者を選びます。もう一点、スナップショットから復元したクラスタはBabelfishクラスタとしては戻らず、復元後にパラメータグループ側で改めて有効化する手順が要ります。

TDSポートへ接続して落ちるAurora機能と非対応拡張を確認する

クラスタ作成後、インスタンスがAvailableになるまで最大20分かかります。立ち上がったらライターエンドポイントに対して、TDS側とPostgreSQL側の両方から接続して疎通を取ります。

sqlcmd -S bbf-demo.cluster-xxxx.ap-northeast-1.rds.amazonaws.com,1433 \
  -U bbfadmin -d master -Q "SELECT @@version"

psql "host=bbf-demo.cluster-xxxx.ap-northeast-1.rds.amazonaws.com \
      port=5432 dbname=babelfish_db user=bbfadmin sslmode=require" \
  -c "SHOW babelfishpg_tsql.migration_mode"

接続まわりで版差が出るのがTLSの扱いです。Babelfishクラスタへの接続のページによると、Babelfish 5.1.0以降は端から端までの接続暗号化が既定で強制されます。クライアント側に証明書を入れていないと、版を上げた途端につながらなくなる形です。従来の挙動へ戻すならDBクラスターパラメータグループの rds.force_ssl を0にしますが、暗号化を切る判断になるため恒久策にはしないでください。JDBCはmssql-jdbc-8.2.2以上が対象で、オープンソースのjTDSドライバは対象外です。

次に、Babelfishを有効にすると使えなくなるAurora機能を潰します。Babelfishの制限事項で2026年9月時点に非対応と明記されているのは7件です。

クライアント側ではMSDTC関連の接続属性が通らず、JDBCのXA呼び出しも対象外になります。拡張についても11個が非対応です。bloom、btree_gin、btree_gist、citext、cube、hstore、hypopg、ltree、pgcrypto、pglogical による論理レプリケーション、apg_plan_mgmt による実行計画管理が使えません。pgcrypto を前提にした暗号化や、計画固定で性能を担保する設計とは正面から衝突します。

判断としては、Babelfishは「SQL Serverアプリの改修を最小限にして移す」ための橋であって、移行後の定常運用の姿ではないと捉えるのが妥当です。段階的に素のAurora PostgreSQLへ寄せる出口を最初から設計へ入れておくと、非対応機能の制約が恒久的な足枷になりません。

RDS for PostgreSQLからAuroraへ移す4経路を停止時間で選ぶ

移行方式はAWS公式の移行ガイドのとおり4つに整理できます。移行元がPostgreSQL互換かどうかと、許容できる停止時間の長さで選び分けます。

スナップショットとAuroraリードレプリカ経由を使い分ける

もっとも単純なのは、RDS for PostgreSQLのDBスナップショットからAurora PostgreSQL DBクラスタを直接作る経路です。移行元となる標準RDS側の構成や拡張の扱いは、Amazon RDS for PostgreSQLとは？マルチAZ構成・拡張機能の統制と延長サポート課金・DMS移行にまとめてあります。手順が短く、検証環境の複製や停止時間を確保できる移行に向きます。難点は取得時点以降の差分が反映されない点です。

停止時間を詰めたい場合はAuroraリードレプリカ経由を選びます。RDS for PostgreSQLインスタンスに対してAurora PostgreSQLのリードレプリカを作り、レプリカ遅延がゼロになった時点でレプリケーションを止め、独立したDBクラスタへ昇格させる流れです。読み書き可能になった時点で接続先を切り替えます。レプリカ遅延の扱いはデータベースレプリケーションとは？同期・非同期の違いとレプリカ遅延の設計で整理しました。

残る2つは補助的な位置づけです。Amazon S3上のファイルからテーブルへ取り込むインポートと、PostgreSQL互換でないデータベースから移すAWS Database Migration Serviceがそれにあたります。オンプレミスのOracleやSQL Serverからの移行では後者が主経路になるでしょう。なお移行中はKerberos認証を有効にできず、有効化できるのは独立したDBクラスタになってからです。

移行計画の初手でマイナー自動アップグレードを切って版を揃える

AWS自身が強く推奨している手当てがあります。Aurora PostgreSQLへ移す計画があるなら、早い段階で移行元インスタンスのマイナーバージョン自動アップグレードを無効にしておくことです。

理由は版の追随速度の差にあります。RDS for PostgreSQL側が自動で上がった先の版を、Aurora PostgreSQLがまだ提供していないケースが起こり得るからです。マイナーは3か月以内という目安はあくまで目安で、その隙間に自動更新が走ると移行そのものが待たされます。modify-db-instanceで自動更新を切り、移行先の対応版を確認してから手動で版を揃える順序を取ってください。

aws rds modify-db-instance \
  --db-instance-identifier legacy-pg \
  --no-auto-minor-version-upgrade \
  --apply-immediately

aws rds describe-db-instances \
  --db-instance-identifier legacy-pg \
  --query "DBInstances[].[EngineVersion,AutoMinorVersionUpgrade]" \
  --output text

2本目で False が返れば設定が効いています。RDS製品ファミリー全体での位置づけはAmazon RDSとは？仕組み・対応エンジンと料金モデルで確認できます。

昇格の直前にレプリカ遅延と接続先の切替所要時間を実測する手順

Auroraリードレプリカ経由の移行で当日の段取りを決めるには、遅延がゼロへ落ちるまでの時間と、昇格から接続可能になるまでの時間を先に測っておきます。遅延はPostgreSQLの標準関数で見られるため、リハーサル環境に対して次のSQLを定期実行してグラフにします。

-- レプリカ側で、直近に反映されたトランザクションからの経過を見る
SELECT pg_is_in_recovery()                               AS is_replica,
       pg_last_xact_replay_timestamp()                   AS last_replay,
       now() - pg_last_xact_replay_timestamp()           AS replay_lag;

-- 書き込み側で、進行中のレプリケーションの宛先を並べる
SELECT client_addr, state, sent_lsn, replay_lsn,
       write_lag, flush_lag, replay_lag
  FROM pg_stat_replication;

各関数の意味はPostgreSQL公式のシステム管理関数に定義されています。replay_lag が秒未満で安定してから昇格へ進むのが安全側の段取りです。あわせて、アプリケーション側の接続文字列をどう切り替えるかも当日までに決めておきます。DNSのTTLを事前に短くしておかないと、昇格自体が数分で終わってもクライアントが旧エンドポイントをつかみ続け、体感の停止時間だけが伸びます。

Aurora PostgreSQLを採用する条件と標準RDSへ寄せる場面の切り分け

ここでは判断を言い切ります。Aurora PostgreSQLは互換性をほぼ保ったまま、版管理と拡張管理の自由度が一段落ちる代わりに可用性と運用の手離れを得る選択です。この交換条件が要件に合うかで決めます。

Aurora PostgreSQLの採用が効くワークロードの条件を見極める

採用が効くのは、次の3条件のうち2つ以上が重なるときです。参照系の負荷が高くリードレプリカで捌きたい、可用性を仕組みで担保したい、S3やLambdaやBedrockとの連携をDB側から張りたい。3つめは aws_s3 や aws_ml が直接効く領域で、素のPostgreSQLでは自前実装になります。

SQL Server資産を抱えていて、ドライバとT-SQLをできるだけ触らずにAWSへ寄せたい案件も該当します。Babelfishを橋として使い、段階的に素のAurora PostgreSQLへ移す計画が立てられるならAurora側が有利でしょう。ACU課金にしたい場合の挙動はAmazon Aurora Serverless v2とは？料金・スケーリングの仕組みで扱っています。

標準RDSやほかのPostgreSQL互換へ寄せる場面を切り分ける

標準のRDS for PostgreSQLへ寄せるべきなのは、可用性はMulti-AZで足り、コストを優先したい中小規模のワークロードです。Auroraが対応していない拡張やコミュニティ版の最新マイナーへすぐ追随したい要件でも、標準RDSのほうが自由度が高くなります。ライセンス面から見直すならPostgreSQLのライセンスと価格：無償の範囲と実際に払う費用が入り口です。

AWS以外も視野に入るなら、Google CloudのPostgreSQL互換マネージドDBも比較対象になります。分析寄りの問い合わせが多い構成では、カラム型エンジンを持つAlloyDBとは？PostgreSQL互換マネージドDBの構成・カラム型エンジンのほうが素直に効く場面があるでしょう。同じAuroraでもMySQL互換版を選ぶかどうかは既存資産で決まり、その版事情はAurora MySQL 8.4の全体像と移行の前提にまとめました。

Aurora PostgreSQLを見送る条件とはまりやすい失敗例を潰す

見送るべきなのは、特定の拡張やコミュニティ版の特定マイナーに強く依存し、Aurora側の提供を待てないシステムです。もう1つはOSレベルの設定に触れる必要がある構成で、この場合はEC2上への自前構築が候補になります。

はまりやすい失敗は3つあります。第一に、拡張の対応版を確認せずエンジン版を先に決め、構築後に要件を満たせないと気づくパターン。第二に、エンジンを上げれば拡張も上がると思い込むパターン。第三に、通常マイナーとLTSの期限差を見ておらず、想定より早く更新作業が回ってくるパターンです。いずれも構築前の確認で潰せます。

潰し方は単純で、この記事に並べたコマンドを設計レビューのチェックリストへ写すだけです。describe-db-engine-versionsでリージョンの提供版を取り、pg_available_extension_versionsで拡張の差を取り、modify-db-instanceで自動更新を止める。拡張の必要版から逆算してエンジンの版を決める——この順序さえ守れば、Aurora PostgreSQLの互換性は素直に効きます。

よくある質問

構築検討で実装者から挙がる質問を、一次情報に基づいて整理します。

Aurora PostgreSQLと素のPostgreSQLはどこまで同じですか？

SQLの文法・データ型・ドライバはコミュニティ版と同じで、接続コードを書き替える必要は基本的にありません。違いはストレージ層と運用にあり、拡張機能はAWSが検証した版だけが入ります。スーパーユーザー権限も付与されないため、OSレベルの操作を前提にした処理は動かない形です。移行前に依存拡張と権限要件を洗い出してください。

Aurora PostgreSQLで使えるバージョンはどれですか？

2026年9月時点の最新メジャーは18系で、Auroraでは2026年6月11日に18.3から提供が始まり、最新マイナーは2026年8月21日提供の18.4です。17系から14系も標準サポート内にあり、13系は2026年2月28日で終了しています。利用可能な版はリージョンで差があるため、aws rds describe-db-engine-versions を実行して確定させてください。

Aurora PostgreSQLでpgvectorは使えますか？

使えます。ただし版がエンジンに紐づき、18.4・17.10・16.14・15.18ではpgvector 0.8.2、18.3では0.8.1、16.2では0.5.1と差が出ます。索引方式や距離関数のうち新しい版でしか使えないものがあるため、必要な機能が入る最小の拡張版から逆算してエンジン版を選んでください。導入済みの拡張はエンジン更新で自動的には上がりません。

BabelfishはRDS for PostgreSQLでも使えますか？

使えません。BabelfishはAurora PostgreSQL固有の機能で、初出はAurora PostgreSQL 13.4です。有効化はDBクラスターパラメータグループで rds.babelfish_status をonにしてクラスタを作成する形になり、既存クラスタへ後から足す運用は想定されていません。スナップショットから復元した場合も無効で戻るため、改めて有効化する手順が要ります。

RDS for PostgreSQLからの移行はどれくらい止まりますか？

選ぶ経路で変わります。スナップショット経由なら取得時点以降の書き込みを止める必要があり、データ量に応じた停止時間が発生する形です。Auroraリードレプリカ経由なら、レプリカ遅延がゼロになるまで同期を続けたうえで昇格させるため、停止は接続先の切り替えに要する数分程度へ抑えられます。本番では後者を基本に置き、事前に検証環境で昇格までの所要時間を実測しておいてください。

関連記事

• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断
• Amazon RDS for PostgreSQLとは？マルチAZ構成と拡張機能の統制
• Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提
• Amazon Aurora Serverless v2とは？料金・スケーリングとv1移行
• Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断
• AlloyDBとは？PostgreSQL互換マネージドDBの構成と採用判断
• PostgreSQLのバージョン確認方法とEOL判定・更新計画の立て方
• データベースとは？種類・DBMS・RDBとNoSQLの選び方