PostgreSQLのVNet統合からPrivate Linkへの移行がGA：不可逆な切替とTerraformの再作成を検証する

結論：不可逆な切替は、接続とIaCの受入条件をそろえて判断する

【確認済み事実】Azure Database for PostgreSQL Flexible Serverでは、委任サブネットを使うVNet統合から、Private Linkのプライベートエンドポイントを利用できる構成へ変更できます。変更後にサーバーを元のVNetへ戻す操作はできません。根拠は公式資料1・2です。

【編集上の判断】プライベート接続の集約や接続元の分離が必要な環境では採用候補になります。実施可否は、変更を開始できることに加え、業務接続の回復、IaCの再適用、失敗時の代替復旧が成立するかで決めます。GAの告知を既存構成への一律の移行要求とは扱いません。

背景と技術的要因：委任サブネットへの依存から接続点の設計へ

【確認済み事実】Microsoftは2026年11月2日付で、このネットワーク変更の一般提供を告知しました。REST APIの公式リリースノートは、2026-01-01-previewに含まれたネットワーク移行を、安定版2026-10-01の対応機能として掲載しています。根拠は公式資料1・3です。

【編集上の設計案】移行前はサーバーと委任サブネットの関係を中心に管理していた構成を、接続元、プライベートエンドポイント、名前解決、経路、認証の依存表へ書き換えます。同じデータベースでも経路の変更で利用不能になる接続元を洗い出し、移行対象サーバーだけの変更票で完結させない設計を提案します。

適用期日・数値・対象リソースとAPIバージョン

【確認済み事実】対象はVNet統合のAzure Database for PostgreSQL Flexible Serverです。公式資料2は変更全体が通常最大20分、その間の接続不能が通常最大10分と説明し、既存接続の切断と新規接続の拒否を明記しています。これは保証時間ではなく、変更後の接続設定が未完了なら接続不能は続きます。

【日付の区別】公式資料1のロードマップ登録日は2026-11-02、GA欄は2026年11月です。一般提供の厳密な適用日、同告知の更新日、強制移行期限、非推奨化期日は確認できずnullです。公式資料2の表示更新日は2026-11-04、資料3は2026-10-30、資料4は2026-08-14です。初回公表日が示されないLearn資料の初回公表日はnullとします。

【確認済み事実】安定版APIの識別子は2026-10-01です。この文字列を公表日や機能の適用日には読み替えません。本稿の公開日・最終確認日は2026-11-08です。sourcesのsourceDateは資料1では登録日、資料2〜4では表示更新日を保持しています。

【編集上の提案】停止枠には、処理時間だけでなくPrivate Endpoint作成、DNS反映確認、接続プール再確立、業務試験の時間を加えます。最大10分という通常値だけで業務再開時刻を約束しない計画にします。

設計・実装上の確認事項：TerraformとDNSを切替後の実体へ合わせる

【確認済み事実】公式資料2は、変更後のazurerm_postgresql_flexible_serverからdelegated_subnet_idを外し、public_network_access_enabledを実際の公開設定に合わせ、terraform planで再作成がないことを確認するよう案内しています。後者を省略するとプロバイダーの既定値trueにより公開アクセスを有効にしようとする点にも注意が必要です。

【確認済み事実】AzureパブリッククラウドのFlexible Server向けプライベートDNSゾーンはprivatelink.postgres.database.azure.com、パブリックDNSのフォワーダー対象はpostgres.database.azure.comです。根拠は公式資料4です。

【編集上の設計案】Private Endpointを使う構成ではpublic_network_access_enabled = falseを明示する案を検証します。変更前にstateを保全し、変更後は実体を読み直したplanを審査します。再作成差分が残る場合はapplyを止め、利用中のプロバイダー版と状態の扱いを調査します。stateの直接改変を標準手順にしません。

【編集上の設計案】Bicep・ARMでも既存の委任サブネットやDNS設定を再投入する参照を棚卸しします。APIのGAと使用中ツールの対応を分け、バージョンを固定して検証します。新しい接続点、DNSゾーンのリンク、オンプレミスの条件付き転送、経路・NSGを依存表へ記録し、通常のサーバー更新だけでネットワーク移行まで完了すると仮定しません。

運用・監視・フェイルオーバーと責任分界：Readyの先まで試験する

【確認済み事実】公式資料1・2は移行前のバックアップが維持されると説明しています。公式資料2はgeo冗長バックアップも含むこと、論理レプリケーションのパブリッシャーへの旧経路が失われ得ることを説明し、各サブスクライバーから新しいプライベートエンドポイントへの到達確認を求めています。

【編集上の運用案】サーバー状態のReadyと業務復旧を別の観測点にします。実際のアプリ経路でDNS応答、TCP接続、TLS、認証、代表SQL、再接続時のエラーと遅延を時刻付きで採取します。論理レプリケーションは接続の回復に加え、遅延と滞留の解消を測定します。

【編集上のDR設計案】HAの有無だけで計画変更時の無停止を保証しません。該当構成でフェイルオーバー、レプリカ昇格、バックアップからの復元を試験し、復旧先のDNS・経路・認証も再確認します。バックアップの保持を同じネットワークへ即時に切り戻せる根拠にはせず、代替サーバーへの復旧可否、RPO・RTOとデータ追随を事前に検証します。

【編集上の責任分界案】DB担当は移行状態とデータ整合、ネットワーク担当はPrivate Endpoint・DNS・経路、アプリ担当は再接続と再送の重複防止、IaC担当はplan審査を担当する案を定めます。委託範囲、停止の承認者、復旧の判断者、証跡の提出者を業務開始前に確認します。

【適用上の前提】本稿は個別環境の設計保証や法的助言を行いません。実装適用には検証環境での事前テストおよび業務範囲の確認が必要です。以下のチェックリストは編集上の提案であり、環境に応じて受入基準を具体化してください。