Azure VPN Gateway の Point-to-Site (P2S) で、VPN クライアント設定に cloudapp.net が含まれる“レガシーDNS”構成は、Basic SKU Public IP から Standard への移行フローでつまずきやすいポイントです。この記事では、2025年9月時点の公開状況と、いま現場でできる確認・準備・運用上の注意点をまとめます。
結論：2025年9月時点で「実施日ベースの移行スケジュール」は未公開
まず結論です。2025年9月時点では、P2S の接続先 FQDN が cloudapp.net で終わる（レガシーDNS）VPN Gateway に対して、「いつ・何日に・どの手順で移行できるか」という実施日ベースのスケジュールは公式に提示されていません。
また、のちに Microsoft Learn の手順書側では、レガシーDNS向けの専用移行（ガイド付きマイグレーション）は「開発中で、タイムラインは 2026年1月末までに告知予定」という表現になっており、少なくとも「まだ移行できない／いつから移行できるかの確定情報が出ていない」状況は継続しています。
したがって現場の最適解は、いま動いているP2Sは維持しつつ、対象判定と事前準備を先に終わらせ、公式の“ガイド付き”手順が公開された瞬間に動ける状態にしておくことです。
そもそも何が問題なのか：レガシー cloudapp.net DNS のP2Sは「標準の移行ツールが使えない」
Azure VPN Gateway の Basic SKU Public IP を Standard に移行する流れ（Azure portal の Migrate 機能や PowerShell コマンドで行う移行）では、一部のP2S構成が制約に引っかかります。
その代表例が、P2S のクライアント設定（ダウンロードできる VPN Client 構成）内のサーバ FQDN が cloudapp.net で終わる構成です。Microsoft Learn の移行手順書では、こうしたゲートウェイは現行の移行ツールでは移行できず、専用の移行方式（ガイド付き移行）が別途必要だと明記されています。
混同しやすいポイント： “Basic” は2種類ある
問い合わせや障害対応で混乱が起きがちなので、言葉をいったん整理します。
| 名称 | 対象 | 現場での論点 | よくある勘違い |
|---|---|---|---|
| Basic SKU Public IP | Public IP リソースのSKU（Basic/Standard） | 退役・移行対象。VPN Gateway に紐づいていると移行が特殊になる | 「VPN Gateway の Basic SKU と同じ話」と誤解しやすい |
| VPN Gateway Basic SKU | Virtual network gateway のSKU（Basic/VpnGw…） | Basic SKU 自体は“すぐ廃止”ではなく、ただし Public IP の扱いが変わっていく | 「Basic Public IP の退役＝Basic VPN Gateway も即停止」と誤解しやすい |
「今回困っているのはどちらの“Basic”か」を切り分けるだけで、原因調査と対策の精度が上がります。なお、Basic Public IP の退役そのものは 2025年9月30日として案内され、退役後も当面は動作し得るがサポート対象外になり得ることが説明されています。
2025年9月時点の状況整理：公開されていたのは「告知予定」まで
2025年9月時点で、Microsoft Q&A 側では「レガシー cloudapp.net DNS のVPN Gateway向けに、具体的な移行日・タイムラインはまだ出ていない」旨が回答されています。
一方で、その後に参照されることが多い Microsoft Learn の移行手順書では、レガシーDNS向けの扱いとして次の要点が押さえどころです。
- レガシー cloudapp.net DNS のP2S Gatewayは、現行ツールで移行できない
- 専用の移行方式（ガイド付き移行）を開発中
- タイムラインは 2026年1月末までに告知予定
- それまでの間はゲートウェイ自体は通常動作を継続するが、Standard Public IP へのアップグレードはできない
まずやるべきこと：自分のP2Sが「レガシーDNS」かを判定する
レガシーDNSかどうかは、推測ではなくクライアント設定ファイルで判定するのが確実です。Microsoft Learn でも、次の手順で確認するよう案内されています。
判定手順（Azure portal で実施）
- 対象の Virtual network gateway を開く
- Point-to-site configuration を開く
- Download VPN Client を実行し ZIP を取得
- ZIP を展開し、AzureVPN 配下の azurevpnconfig.xml を開く
<fqdn>...</fqdn>の値を確認する
確認する箇所（例）
<serverlist>
<serverEntry>
<fqdn>your-gateway-fqdn-here</fqdn>
</serverEntry>
</serverlist>ここで FQDN が cloudapp.net で終わる場合、そのゲートウェイはレガシーDNS構成であり、専用の移行プロセスが必要とされています。
判定結果ごとの対応方針（表で即決できるようにする）
| 判定結果 | 何が起きているか | 今すぐできること | 避けるべきこと |
|---|---|---|---|
| FQDN が cloudapp.net | レガシーDNS。現行の標準移行フローでは移行不可 | 現状維持＋準備（棚卸し・影響範囲把握・移行計画の下書き） | P2S設定の削除や、迂回目的の設定変更 |
| cloudapp.net 以外 | 標準移行フローの対象になり得る | 移行ツールの前提条件を満たすか確認し、計画移行 | 前提条件未達のまま“強行” |
運用上かなり重要：レガシーDNSの場合「やってはいけない変更」がある
レガシーDNS構成のP2Sでは、移行できないこと自体よりも、誤った変更で“取り返しがつかない状態”を作ることが最大のリスクです。
Microsoft Learn の移行手順書では、レガシーDNSの場合の注意事項として少なくとも次が明示されています。
- 既存の Point-to-Site 構成を削除して移行しようとしない
- P2S が未構成の既存ゲートウェイに、新規でP2S構成を追加しない（専用機能がリリースされるまで）
- 専用ツールが提供されるまでは現行構成のまま運用を継続
この手の注意書きは“面倒だから後回し”にされがちですが、実務では変更管理（Change Management）のルール化に落としておくのが効果的です。例えば、次のようにガードを作れます。
- 対象ゲートウェイのリソースグループに対し、P2S設定変更ができるRBACロールを最小化する
- 作業手順書に「P2S構成削除は禁止」「クライアント設定ZIPは保管」などの禁止事項を太字で明記する
- 定例会で“移行待ち資産”として可視化し、担当者が変わっても意図が引き継がれるようにする
標準の移行ツール側も押さえる：プレビュー、リージョン段階展開、前提条件
レガシーDNS以外の環境でも、移行はワンクリックでは終わりません。公式手順では、Basic SKU Public IP の移行機能はプレビューとして提供され、機能自体がリージョンへ段階的に展開される旨が書かれています。
つまり「ポータルに Migrate タブが出ない＝自分の手順が間違い」とは限らず、そのリージョンにまだ展開されていない可能性があります。
前提条件の代表例：GatewaySubnet の空きIPとサイズ
移行手順では、準備段階としてGatewaySubnet に十分な空きIPが必要であり、/28 など小さいサブネットだと失敗し得るためプレフィックス追加を検討するよう案内されています。
この条件は、レガシーDNSの“専用移行”が来たときにも類似の前提が求められる可能性が高いので、先に GatewaySubnet を健全化しておくと後工程が楽になります。
想定ダウンタイムと所要時間：現場に説明できる言い方
移行は“ゼロダウン”とは限りません。Microsoft Learn では、実行フェーズで短時間のダウンタイムが発生し得ること、また移行全体の所要時間目安が説明されています。
現場向けの説明としては、次の言い方が揉めにくいです。
- 移行は「準備」「実行」「コミット」の段階があり、通信断は主に実行フェーズ
- 通信断は数分〜最大10分程度を見込んで計画（環境条件で変動）
- 全体の手続きとしては、検証・承認も含めて余裕をもって時間枠を確保
いま現場でやるべき準備：移行“待ち”でも進められるタスク
レガシーDNS構成は、専用の移行機能が出るまで「待ち」の要素が残ります。ただし、待つだけだとリスクが増えます。公式情報が出た瞬間に動ける状態を作るために、次の準備は先に終わらせるのがおすすめです。
| 準備タスク | 狙い | 具体的なやり方（例） |
|---|---|---|
| 対象ゲートウェイの棚卸し | 影響範囲の確定 | サブスク全体で Virtual network gateway を一覧化し、P2S有無、FQDN末尾、SKU、リージョンを記録 |
| クライアント影響の把握 | “どこが止まるか”を明確に | 配布している Azure VPN Client 設定、証明書方式/Entra ID方式、利用ユーザー数、利用時間帯を整理 |
| GatewaySubnet の健全化 | 移行前提条件の先取り | 空きIP、/27以上への拡張可否、アドレス設計の承認フローを先に通しておく |
| メンテナンス設計 | 当日の意思決定を高速化 | 切替手順、ロールバック手順、連絡テンプレ、監視項目（接続数/ログ）を作っておく |
| 監視と通知 | 発表の見落とし防止 | VPN Gateway の “What’s new” を定期確認し、RSS 等で更新検知を仕組み化する |
“待てない”場合の代替策：再作成は最終手段として設計する
「専用移行が来るまで待てない」という事情（監査対応、サポート期限、社内基準など）があるケースもあります。その場合、理屈上はゲートウェイを削除して作り直すことで Standard Public IP 前提へ寄せられますが、公式FAQでも示される通り、削除・再作成はIPが変わるなどの影響が大きく、P2Sはクライアント配布や証明書運用まで巻き込むため、計画なしに選ぶべきではありません。
| 選択肢 | メリット | デメリット | 向いている状況 |
|---|---|---|---|
| 専用のガイド付き移行を待つ | 公式の想定ルートで安全性が高い | 時期が読みにくい | 現状のP2Sが安定しており、短期で仕様変更できない |
| 標準移行ツール（対象なら） | IPが変わらない前提で進めやすい | 前提条件を満たさないと失敗し得る／リージョン展開待ちがあり得る | cloudapp.net 以外で、移行ツールの対象条件を満たす |
| 削除して再作成 | “待ち”を排除できる | IP変更・クライアント再配布・ダウンタイム増大のリスク | 業務要件でどうしても待てず、周辺システムも含めて再設計できる |
再作成を選ぶ場合は、「VPN接続先の変更（FQDN/IP）」「クライアント設定配布」「証明書更新」「ユーザー周知」がセットです。移行そのものより、周辺オペレーションが本体になります。
移行当日に慌てないための“ランブック”雛形
専用ツールが出たとき、現場で本当に必要なのは「読むだけで動ける手順書」です。以下は雛形です（組織の承認フローに合わせて調整してください）。
| フェーズ | 作業 | 確認ポイント | 失敗時の切り戻し |
|---|---|---|---|
| 事前 | 対象の判定（cloudapp.netか）／現行設定のバックアップ | azurevpnconfig.xml のFQDNを保管 | 変更はまだしない |
| 準備 | GatewaySubnet の空きIP確認／必要なら拡張 | 前提条件が満たせる状態か | 拡張作業をロールバックできる設計か |
| 実行 | 移行ツール（Portal/PowerShell）で実行 | 監視（接続・ログ）で断が許容範囲か | Abort/ロールバック手順を即実行 |
| 検証 | P2S 接続確認（複数端末）／業務アプリ疎通 | 社内DNS、プロキシ、ルーティングの想定通りか | 問題が再現するなら切り戻す |
| 完了 | コミット／旧リソース整理 | 監視アラート・運用手順の更新 | チケットに経緯を残す |
PowerShell を使う場合、Microsoft Learn では Prepare/Execute/Commit/Abort に相当するコマンド例が提示されています（実際の利用可否・前提は環境と提供状況に依存します）。
# 例（Microsoft Learn の記載に基づくイメージ）
Invoke-AzVirtualNetworkGatewayPrepareMigration
Invoke-AzVirtualNetworkGatewayExecuteMigration
Invoke-AzVirtualNetworkGatewayCommitMigration
Invoke-AzVirtualNetworkGatewayAbortMigration最新情報の追い方：見るべき公式ソースは2つ
レガシーDNS向けの専用移行は「いつ出るか」が最大の論点なので、ウォッチ先を固定しましょう。公式に案内されている“実務で効く”追い方は次の2系統です。
- Azure VPN Gateway の “What’s new（新機能・変更点）”：Projected changes（今後の予定）に、移行ツールや期限の更新が載ります。RSS購読も案内されています。
- Basic SKU Public IP マイグレーションの手順書：レガシーDNSの制約、判定方法、注意事項が明記されています。
また、VPN Gateway 全体としては Basic IP の移行ウィンドウや期限が更新され得るため、FAQ 側のタイムライン表も参照しておくと、社内説明の根拠として使いやすいです。
よくある質問（現場で実際に困るところ）
cloudapp.net だと、今すぐ止まりますか？
「レガシーDNSで移行できない＝即停止」ではありません。公式手順では、専用移行が提供されるまでの間、該当ゲートウェイは通常動作を継続するとされています。ただし Standard Public IP へのアップグレードはできないため、期限が絡む施策では“未対応資産”として残ります。
ポータルに Migrate タブが出ません
移行機能はリージョンへ段階展開され、見えない場合は「まだ利用できない」可能性がある、と手順書に記載があります。焦って手順を変えるより、まずは展開状況と前提条件を確認するのが安全です。
社内にどう説明すればいいですか？
説明は次の3点に絞ると通りやすいです。
- 対象は「P2Sで cloudapp.net のレガシーDNS」の一部ゲートウェイ
- 現行ツールでは移行できず、専用のガイド付き移行が開発中
- スケジュール確定前でも、棚卸し・影響把握・GatewaySubnet 健全化は先に進められる
まとめ：移行日が出ていなくても、勝負は準備で決まる
レガシー cloudapp.net DNS を使う P2S VPN Gateway は、2025年9月時点で「いつ移行できるか」の具体日程が未公開であり、現行の標準移行ツールでは移行できないケースがあることがポイントです。
だからこそ、次の順番で進めるのが現実的です。
- まず azurevpnconfig.xml で cloudapp.net か判定
- レガシーDNSなら触らずに維持し、準備（棚卸し・影響範囲・GatewaySubnet）を先に完了
- 公式の “What’s new” と移行手順書をウォッチし、タイムラインが出たら計画移行
この形にしておくと、発表が遅れても慌てず、発表が出た瞬間に最短距離で移行に入れます。
コメント