RDS延長サポートを無効化すると再起動する？ PostgreSQL 18.3で接続影響を検証

検証および公式資料の確認は、2026年9月13日に実施しました。

今回の検証で分かったこと

標準サポート期間内のRDS for PostgreSQL 18.3で、RDS延長サポートの設定だけを無効化したところ、観測範囲内でDB再起動・接続断・SQLエラーは発生しませんでした。

変更前5分以上、変更反映後15分以上にわたり、同じDB接続で1秒間隔のSQLを実行しました。別途、10秒間隔で新規接続も確認しています。

この結果は、すべてのエンジン・バージョン・負荷条件で無停止を保証するものではありません。特に、標準サポートが終了したメジャーバージョンでは扱いが異なります。

検証のきっかけ

RDS延長サポートという設定を意識せずに運用していた既存RDSで、コンソールに「RDS延長サポート：有効」と表示されていることを確認しました。

そこで気になったのが、「この設定を無効にすると、RDSが再起動したり、アプリケーションのDB接続が切れたりするのか」という点です。

本番環境を直接変更する前に、新規VPCと空の業務データを持つ検証用RDSを用意し、設定変更前後の接続を観測しました。今回の検証対象は無効化時の動作です。既存RDSがいつ、どの経路で有効になったかは調査対象に含めていません。

「有効」と「延長サポート料金が発生中」は別

ここで無効化するのは、RDS延長サポートへの登録設定です。RDSの標準サポートや、AWSアカウントのサポートプランを無効にする操作ではありません。

AWS公式資料では、延長サポート料金は原則として対象メジャーバージョンのRDS標準サポート終了後に発生します。コンソールで「有効」と表示されることだけを理由に、すでに延長サポート料金が発生しているとは判断できません。RDS延長サポートの料金

今回使用したPostgreSQL 18は、検証日時点で標準サポート期間内です。公式カレンダーでは、メジャーバージョン18の標準サポート終了日は2031年2月28日、マイナーバージョン18.3の終了時期は2027年3月とされています。メジャーバージョンと個々のマイナーバージョンの期限は分けて確認します。PostgreSQLのリリースカレンダー

標準サポート終了済みのバージョンでは注意が必要です。 AWSは、すでに標準サポート終了日を過ぎたDBの延長サポート登録を無効化すると、次のサポート対象メジャーバージョンへ自動更新すると説明しています。その場合はアップグレードに伴う停止や互換性の確認が必要で、今回の「再起動なし」という結果を適用できません。登録変更時の動作

検証環境

Multi-AZのDBインスタンスで検証しました。AuroraやMulti-AZ DBクラスターを検証した記事ではありません。

無効化するAWS CLIコマンド

以下はPowerShell向けの例です。変数には自分の環境の値を設定してください。DB名は記事用の例示名で、公開用本文には実アカウントID、実エンドポイント、認証情報を含めていません。

1. 実行先と変更前の設定を確認する

$PocProfile = "default"
$PocRegion = "ap-northeast-1"
$PocDbId = "example-rds-postgres"

aws sts get-caller-identity --profile $PocProfile --query Account --output text

aws rds describe-db-instances --profile $PocProfile --region $PocRegion --db-instance-identifier $PocDbId --query "DBInstances[0].{DB:DBInstanceIdentifier,Status:DBInstanceStatus,Engine:Engine,Version:EngineVersion,ExtendedSupport:EngineLifecycleSupport,Pending:PendingModifiedValues}" --output json --no-cli-pager

期待するアカウントとDBであることを確認し、取得したエンジンバージョンのサポート期限を公式カレンダーと照合します。今回の変更前の値は次のとおりでした。

{
  "Status": "available",
  "Engine": "postgres",
  "Version": "18.3",
  "ExtendedSupport": "open-source-rds-extended-support",
  "Pending": {}
}

上記JSONは、実測値から関連項目を抜粋したものです。

保留中のメンテナンスは別APIで確認します。

$PocDbArn = aws rds describe-db-instances --profile $PocProfile --region $PocRegion --db-instance-identifier $PocDbId --query "DBInstances[0].DBInstanceArn" --output text
aws rds describe-pending-maintenance-actions --profile $PocProfile --region $PocRegion --resource-identifier $PocDbArn --output json --no-cli-pager

2. 延長サポートだけを無効化する

次のコマンドは対象DBの設定を変更します。 標準サポート期間と対象DBを確認してから実行します。

aws rds modify-db-instance --profile $PocProfile --region $PocRegion --db-instance-identifier $PocDbId --engine-lifecycle-support open-source-rds-extended-support-disabled --query "DBInstance.{Status:DBInstanceStatus,ExtendedSupport:EngineLifecycleSupport}" --output json --no-cli-pager

変更属性は EngineLifecycleSupport だけです。AWS CLIでは --engine-lifecycle-support に open-source-rds-extended-support-disabled を指定します。modify-db-instanceの公式リファレンス

今回、--apply-immediately は指定しませんでした。このフラグは今回の変更だけでなく、保留中の変更にも作用します。他の変更まで直ちに適用される影響を考慮する必要があります。変更を適用するタイミング

本検証では、このフラグなしで約2.7秒後に無効状態を確認できました。ただし、これは今回の実測時間です。反映時間や再起動不要を一律に保証する仕様として扱わず、実際の設定値を確認します。

3. 変更後の設定を確認する

aws rds describe-db-instances --profile $PocProfile --region $PocRegion --db-instance-identifier $PocDbId --query "DBInstances[0].{DB:DBInstanceIdentifier,Status:DBInstanceStatus,Version:EngineVersion,ExtendedSupport:EngineLifecycleSupport,Pending:PendingModifiedValues}" --output json --no-cli-pager

今回の確認結果では、ExtendedSupport が open-source-rds-extended-support-disabled に変わり、Status は available、Version は 18.3 のままでした。

APIが成功したことやDBが available であることだけでは、途中の接続断までは判断できません。そこでSQLも連続実行しました。

再起動と接続断をどう観測したか

Session ManagerでEC2へ実接続し、クライアントと接続準備を確認しました。そのセッションは正常終了しています。連続SQLは別のSSM Run Commandから起動し、管理用セッションが閉じても観測を継続しました。

測定は次の2系統です。

• 継続接続：同じpsqlプロセス・同じDB接続で、1秒間隔の読み取りSQLを実行。
• 新規接続：10秒間隔で別のpsqlプロセスを起動し、新しい接続でもSQLが成功するかを確認。

各SQLで、起動時刻、バックエンドPID、接続先IP、リカバリー状態、バージョン、TLSを取得しました。使用した観測SQLは次の内容です。

SELECT json_build_object(
    'server_time', clock_timestamp(),
    'backend_pid', pg_backend_pid(),
    'postmaster_start_time', pg_postmaster_start_time(),
    'server_ip', inet_server_addr(),
    'in_recovery', pg_is_in_recovery(),
    'server_version', current_setting('server_version'),
    'tls', (SELECT ssl FROM pg_stat_ssl WHERE pid = pg_backend_pid()),
    'tls_version', (SELECT version FROM pg_stat_ssl WHERE pid = pg_backend_pid())
);

SQL自体は観測値を返すものです。実測では、別途作成した観測プログラムが実行間隔、タイムアウト、成功・エラー・欠測、再接続を記録しました。このSQLを1回実行するだけで同じ検証が完了するわけではありません。

接続タイムアウトは5秒、statement_timeout は4秒です。継続SQLの応答待ちは5秒、新規接続全体の上限は8秒としました。観測時間は単調増加時計で検証し、失敗後に再接続できても、エラーや再接続の件数を消さない方式です。

DB認証情報はEC2内でSecrets Managerから取得し、子プロセスの環境変数で使用しました。パスワードをコマンド引数や観測ログへ出力していません。

実測結果

時刻はすべて2026年9月13日のJSTです。

変更前の基準区間は318.832秒、無効反映後の観測区間は902.000秒でした。変更APIの呼び出し中も継続SQLを停止していません。

設定値の前後比較でも、比較対象属性の差分は EngineLifecycleSupport だけでした。クラス、エンジンバージョン、Multi-AZ、エンドポイントなどに差分はありませんでした。

RDSイベント0件だけを根拠にした判断ではありません。DB起動時刻の不変、継続接続PIDの不変、エラー・再接続0件を合わせて、今回の接続先で再起動や接続断を検出しなかったと判断しました。

基準区間と変更後区間の間にも10回の継続SQLがあり、総数は1,233回です。継続SQLの最初の1回は接続確立を含むため、変更前の最大値と変更後の最大値だけで性能差を判断していません。

運用へ反映するときの判断

今回の結果から言えるのは、標準サポート期間内のPostgreSQL 18.3で、延長サポートだけを無効化した今回の操作では、再起動・接続断を観測しなかったということです。

参照したAWSの登録変更説明とCLIパラメータ説明には、この設定について全条件で再起動不要・停止なしを保証する明示は確認できませんでした。ブログや作業説明でも、公式仕様と今回の観測結果を区別するのが適切です。

本番へ適用するときは、エンジンとバージョン、標準サポート期限、保留変更、同時に変更する属性を確認します。今回の読み取りSQLでは、書き込み・COMMIT、長時間トランザクション、本番負荷、スタンバイ内部の動作までは検証していません。また、1秒間隔の測定の間に収まり、接続も切断しない短い停止は完全には除外できません。

検証終了後は延長サポート無効を維持し、観測プロセスを終了しました。生ログ回収後、EC2上の一時ファイルも削除しています。

Terraformなどで管理している場合は、希望する設定値も無効へ揃えます。今回も設定コードを同期しましたが、CLIによる変更だけでTerraform stateが更新されるわけではありません。後続作業では最新の実リソースを取得したうえで差分を確認する必要があります。

RDS延長サポートの無効化を検討している場合、まず確認したいのは「対象バージョンが標準サポート期間内か」です。その条件を満たす今回の環境では、既存接続を保ったまま無効化できました。