Microsoft から「Basic SKU のパブリック IP を Standard SKU にアップグレードしてください」というメールが届いたものの、そもそも今その IP が使われているのか分からない――そんな担当者は少なくありません。本記事では、4 つのパブリック IP を例に、要否の見極め方と、安全に Standard SKU へ移行するための実務的な手順を、Azure ポータルの画面操作レベルまで具体的に解説します。
Azure から届いた「Basic → Standard にアップグレードしてください」通知の意味
2025 年 9 月 30 日をもって、Azure の Basic SKU パブリック IP アドレスはリタイア（サポート終了）しました。Microsoft の公式ドキュメントでも、Basic SKU パブリック IP は 2025 年 9 月 30 日がリタイア日であり、Standard SKU への移行が推奨されています。
現在は既にリタイア日を過ぎているため、Basic SKU を使い続けている環境は、
- サポート対象外・SLA 適用外である
- 将来のプラットフォーム更新で突然動かなくなるリスクがある
という「いつ止まってもおかしくない」状態です。
この記事の想定シナリオは次のようなものです。
- Basic SKU のパブリック IP が 4 つ存在する
- 用途が共有されないまま担当者が変わり、誰も詳しく覚えていない
- 過去にリモートアクセス用のサーバー（RDP / VPN 等）を廃止している
- 今も必要な IP と、もう要らない IP が混在していそうだが、判断できない
結論から言うと、以下の方針になります。
- 未使用の IP：削除してよい（コスト削減）
- 使用中の IP：Standard SKU への移行（またはアップグレード）が必須
以降では、4 つの IP を「棚卸し」しながら、削除か移行かを判断し、実際の移行作業までを一気通貫で整理していきます。
パブリック IP アドレスの役割を整理する
パブリック IP は、インターネットから Azure 上のリソースへアクセスするための“表口”です。どのリソースにひも付いているかが分かれば、「それを消したら何が止まるか」を逆算できます。
Azure でパブリック IP がひも付きやすい代表例
| リソース種別 | 典型的な用途 | IP を消すとどうなるか |
|---|---|---|
| 仮想マシン（VM） | RDP（3389）/ SSH（22）での管理接続、簡易 Web 公開 | リモート接続ができなくなる。公開 Web も停止 |
| VPN Gateway | 拠点間 VPN、クライアント VPN（P2S）の終端 | 社内拠点やリモート PC から Azure への VPN 接続が不可 |
| ロードバランサ （LB / Application Gateway） | インターネット向け Web / API の公開 | 外部公開している Web / API が一斉停止 |
| Azure Firewall / NAT Gateway | インターネット向け通信の出口 IP 統一 | SaaS 側の IP 制限に引っかかる、インターネット接続が失敗 |
| その他（PaaS 等） | 一部の古いサービスで利用される固定 IP | サービスへのアクセス不能、または外部連携の失敗 |
この一覧に該当するリソースを使っていない場合、そのパブリック IP は不要である可能性が高いと言えます。
4 つのパブリック IP を「棚卸し」する具体手順
まずは、4 つの IP が どのリソースにひも付いているか を Azure ポータルで確認します。この「見える化」が、その後の判断を 9 割決めると言っても過言ではありません。
Azure ポータルでの確認手順
- Azure ポータルにサインイン
- 左メニューまたは検索ボックスから
「すべてのサービス」 > 「ネットワーク」 > 「パブリック IP アドレス」 を開く - 一覧から該当する 4 つの IP を順番にクリック
- 各 IP の「概要」または「設定」画面で以下を確認
- SKU（Basic / Standard）
- IP アドレス（例: 203.0.113.10）
- 関連付け先（NIC / ロードバランサ / VPN Gateway / Application Gateway / Firewall 等）
- リソースグループ（RG）
- タグ（Project 名 / Owner 等が入っていればヒント）
この情報を、後述の「棚卸しシート」にそのまま転記していきます。
棚卸しでチェックすべき項目
| 項目 | 確認内容 | ポイント |
|---|---|---|
| リソース名 | public-ip-prod-01 等 | 命名規則から用途が分かることも多い |
| IP アドレス | 203.0.113.10 など | DNS や取引先 FW の設定と突合できる |
| SKU | Basic / Standard | Basic だけが今回の対象。Standard にも統一したい |
| 関連付け先 | VM NIC / LB / VPN GW 等 | 何を止める可能性があるかの根拠になる |
| 状態 | 関連付けあり / なし | 未関連付けなら削除候補。課金だけ続いているケースも |
| タグ | Owner, System, Environment など | 担当部署やシステム名の手掛かりになる |
4 つの IP 向け「棚卸しシート」ひな型
実務では、次のような表を Excel / OneNote / Notion 等に作って埋めていくとスムーズです。
| IP 番号 | リソースグループ | SKU | IP アドレス | ひも付け先リソース | 運用状況 | 対応方針 | メモ |
|---|---|---|---|---|---|---|---|
| IP-1 | RG-XXXX | Basic | 203.0.113.10 | VM nic-vm01 | 本番で利用中 | Standard へ移行 | Web サーバー用、DNS A レコードあり |
| IP-2 | RG-YYYY | Basic | 203.0.113.11 | なし（未関連付け） | 不明（ログなし） | 削除候補 | 念のため 1 週間監視してから削除 |
| IP-3 | RG-Remote | Basic | 203.0.113.12 | VPN Gateway | リモートアクセス VPN 廃止済 | VPN GW ごと削除 | 2022 年にリモートアクセス用サーバーを停止 |
| IP-4 | RG-Shared | Standard | 203.0.113.13 | Azure Firewall | 現用 | そのまま利用 | 今回通知の対象外 |
質問文にもある通り、4 つの IP のうち 複数が「2022 年まで使っていたリモートアクセス用サーバー」に関連している ようなケースは現場でよくあります。その場合、多くは既に実運用が止まっているため、後述のチェックを行った上で削除してコスト最適化を図ることができます。
Basic と Standard の違い（移行判断の前提）
「なぜわざわざ Standard に移行しないといけないのか？」を理解するために、Basic と Standard の違いをざっくり整理しておきます。
| 項目 | Standard SKU | Basic SKU |
|---|---|---|
| セキュリティモデル | Secure by default。NSG で明示的に許可したトラフィックのみ通す（デフォルトは閉じている） | デフォルトでインターネットに公開される。NSG は推奨だが必須ではない |
| 可用性ゾーン | ゾーン冗長 / ゾーン固定 / 非ゾーンを選択可能（地域による） | 可用性ゾーン非対応 |
| ロードバランサ | Standard Load Balancer 用。IPv4/IPv6 両対応 | Basic Load Balancer 用。Standard LB とは混在不可 |
| Azure Firewall / NAT Gateway | 利用可能（IPv4） | 非対応 |
| ルーティングプレファレンス / Global Tier | 利用可能。Anycast IP やインターネット経路制御が可能 | 非対応 |
| 課金の考え方 | 原則として、作成した時点から IP 時間課金。未関連付けでも課金されるケースが多い | 同様に IPv4 は名目上の課金あり。古いドキュメントの「一部無料」は既に廃止されている |
つまり、本番用途であれば Standard 一択と言ってよい状況です。Basic はリタイア済みであり、新規作成も 2025 年 3 月 31 日以降はできなくなっています。
削除か移行かを決めるシンプルな判断フロー
棚卸しシートが埋まったら、次のフローで 4 つの IP を「削除」か「Standard へ移行」かに分類します。
| 状態 | 判断 | 具体的な対応 |
|---|---|---|
| 関連付け先がない（未関連付け） | 原則削除 | DNS、取引先 FW、SaaS 側ホワイトリストで IP が参照されていないかだけ確認し、問題なければ削除 |
| 廃止済みリソース（停止中 VM / 使っていない VPN / テスト用 LB 等）にひも付き | 削除方向 | リソース自体を削除（必要なら事前にスナップショット）し、最後にパブリック IP を削除 |
| 本番や検証で利用中のリソースにひも付き | Standard へ移行必須 | 後述の手順で Standard SKU に切り替え。停止時間を最小化する計画が必要 |
この時点で「4 つのうち 2 つは削除、残り 2 つは移行」といったレベルまで整理できていれば、残りの作業は「移行パターンの選択」と「実作業」のフェーズに入れます。
Standard SKU への移行パターンは 2 つ
Basic から Standard への移行には、大きく分けて次の 2 パターンがあります。
- 新しい Standard IP を作成して、リソースの「表口」を付け替える方式
- 既存の Basic IP 自体を Standard にアップグレードする方式
それぞれの特徴を整理しておきましょう。
| 方式 | 概要 | IP アドレスの変化 | 向いているケース |
|---|---|---|---|
| 方式 1 新規 Standard へ付け替え | Standard SKU パブリック IP を新規作成し、VM / LB / VPN GW 等のフロントエンドをその IP に切り替える | 通常は変わる | IP 固定の外部要件が特にない、もしくは DNS / ホワイトリストをまとめて更新できる環境 |
| 方式 2 Basic IP を Standard にアップグレード | 一度 IP をリソースから切り離し、同じ IP そのものの SKU を Basic → Standard に変更する | IP アドレスは変わらない （Microsoft 公式ドキュメントで明記） | 取引先や SaaS 側の IP 制限などで「どうしても IP を変えられない」ケース |
以下で、それぞれの進め方を詳しく見ていきます。
方式 1：IP が変わってもよい場合（新しい Standard IP に付け替え）
最もシンプルでトラブルが少ないのは、この方式です。
- Standard SKU のパブリック IP を新規作成
- リソースグループ・リージョンを既存 Basic IP と揃える
- 名前は
pip-xxx-stdのように分かりやすく - 必要に応じて可用性ゾーン / ルーティングプレファレンスを設定
- 対象リソースのフロントエンド設定を Standard IP に切り替え
例：VM なら NIC の「パブリック IP アドレス」欄で付け替え、ロードバランサならフロントエンド IP 設定を切り替える。 - 動作確認
- RDP / SSH 接続が可能か
- Web / API が新しい IP から正常に応答するか
- VPN なら接続確立とトラフィック通過を確認
- DNS レコード・ホワイトリストを更新
- 独自ドメインを使っている場合は A / AAAA レコードを新 IP に変更
- 取引先 FW や利用中の SaaS に登録している IP 制限も更新
- 問題ないことを確認したら、古い Basic IP を削除
IP が変わる点さえ許容できれば、Azure 側の操作は比較的簡単で、「アップグレード失敗で元に戻せない」というリスクもありません。
方式 2：IP を変えずに Basic を Standard にアップグレード
IP アドレスを絶対に変えられない場合は、Microsoft のドキュメントで案内されている Basic IP → Standard IP へのアップグレードを利用します。この方法では、
- パブリック IP リソースから一度関連付けを外す
- SKU を Basic → Standard に変更する
- 再度、元のリソースに関連付けし直す
という流れで進みます。アップグレード後も IP アドレス自体は変わりません。
ただし、重要な注意点があります。
- アップグレードは元に戻せない（Standard → Basic には戻せない）
- アップグレード対象の IP は「静的割り当て」である必要がある（動的割り当てのままでは警告が出てアップグレードできない）
- アップグレード中は一時的にリソースから IP を外すため、短時間の停止が発生する
- 多くのケースで、アップグレード後も可用性ゾーンは「なし」のまま（ゾーン冗長 IP にはならない）
「停止時間が取れるか」「静的 IP に変えても大丈夫か」などを加味し、方式 1 と 2 を使い分けるとよいでしょう。
リソース別：移行時にハマりやすいポイント
仮想マシン（VM）の場合
VM のパブリック IP を移行する場合は、次の 2 パターンがあります。
- 新しい Standard IP を作成し、NIC の設定で付け替える
- Microsoft 提供のスクリプトで、VM にひも付いた Basic IP を Standard にアップグレードする
どちらにしても、以下の点に注意してください。
- Standard IP は NSG での明示的許可がないと通信が通らない（Secure by default）
- 従来 Basic で何となく開いていたポート（RDP/SSH など）が、移行直後に繋がらなくなる典型パターン
- 事前に NSG を確認し、必要なポートに対して 許可ルールを作成しておく
Basic Load Balancer を利用している場合
Basic Load Balancer と Basic パブリック IP はセットで利用されています。Standard IP へ移行する場合、Load Balancer も Standard SKU へアップグレードし、フロントエンド IP を Standard に切り替える必要があります。
Microsoft は Basic LB → Standard LB へのアップグレード用スクリプトも提供しているため、該当する場合はこれを活用すると手作業を減らせます。
VPN Gateway / ExpressRoute Gateway の場合
VPN Gateway や ExpressRoute Gateway で Basic IP を使っている場合も、Microsoft のガイダンスに沿った Gateway の移行が必要です。移行にあたっては、
- ダウンタイムを許容できる時間帯の調整
- オンプレミス側ルーター設定の変更（接続先 IP の更新）
- クライアント VPN（P2S）利用者への周知
など、ネットワークチーム・現場ユーザーを巻き込んだ計画が必須になります。
Application Gateway v1 の場合
Application Gateway v1 は Basic IP と組み合わせて利用されているケースが多いですが、Standard IP を使うには Application Gateway v2 への移行が必要です。
Basic IP のリタイア自体は v1 AppGW の寿命に合わせて猶予が設けられていますが、
- SSL/TLS の最新機能
- パフォーマンス / スケーリング
- WAF の機能強化
などを考えると、v2 への移行と同時に Standard IP へ統一するのが現実的です。
リモートアクセス用サーバー廃止済みの場合の確認ポイント
質問にあったように、「昔 VPN やリモートデスクトップ用サーバーを Azure に置いていたが、今はオンプレミスや別サービスに切り替えている」というケースはよくあります。その場合、Basic IP が「過去の遺物」として残っている可能性が高いです。
削除してよいかを判断するために、次のチェックを行いましょう。
- DNS レコードの確認
vpn.example.co.jp → 203.0.113.12のようなレコードが残っていないか、DNS 管理画面で確認。 - 接続ログ / 監視の確認
Azure Monitor / オンプレ FW / VPN 装置のログを見て、ここ数か月その IP 宛の通信があるか。 - 社内ポータルやマニュアルの確認
「在宅勤務の手引き」などに、古い Azure VPN の手順が残っていないか。 - 一部部門だけ使っていないかのヒアリング
特定部署がこっそり旧 VPN を使い続けている、ということも稀にあるため、念のため情報システム部門内で共有。
これらを確認した上で「誰も使っていない」「DNS・マニュアルからも痕跡なし」と判断できれば、
- VPN Gateway / VM など関連リソースを削除
- 最後に Basic パブリック IP を削除
という順でクリーンアップして構いません。
Standard SKU 移行後に必ず行いたい動作確認
Standard へ切り替えた後は、次の 5 項目をチェックリストとして確認しましょう。
- 接続テスト
- RDP / SSH / VPN / Web など、想定している入口からすべて接続確認
- クライアント OS やブラウザの違いも可能な範囲で確認
- NSG ルールの最終確認
- 必要なポートの Allow ルール が存在するか
- 不要なポートが開きっぱなしになっていないか
- 監視・アラートの確認
- Health Probe（LB / AppGW）のステータス
- Azure Monitor / ログアラートが想定通りに動いているか
- DNS / ホワイトリストの反映確認
- nslookup / dig で新 IP が引けているか
- 取引先や SaaS ベンダーに IP 更新が反映されたか
- 不要リソースの消し漏れ確認
- Basic IP や旧リソースが残っていないか
- 「停止中だが課金だけされている VM / Gateway」がないか
コストと運用の観点から見直したいポイント
今回の Basic → Standard 移行は、単なる「SKU の置き換え」で終わらせず、同時に パブリック IP の数を減らすチャンスでもあります。
- 管理用の RDP / SSH は Azure Bastion / VPN 経由に集約
- 各 VM ごとにパブリック IP を持たせるのではなく、Bastion 経由の接続に切り替える
- これにより、VM ごとのパブリック IP を削減しつつセキュリティも向上
- インターネット向け出口 IP を NAT Gateway / Azure Firewall で集約
- アプリケーションごとにパブリック IP を持つのではなく、NAT Gateway 経由で共通の出口にする
- Private Endpoint / Private Link の活用
- ストレージアカウントや SQL Database などは、可能な限りプライベート接続に移行
- パブリック IP への依存を減らし、セキュリティとコストを両方改善
Standard IP は未関連付けでも時間課金されるため、「いつか使うかもしれないから」と残しておくのは NG です。使わないと判断した時点で、早めに削除することがコスト最適化の第一歩になります。
今すぐ着手したい実務向けチェックリスト
最後に、この記事全体を「いまやるべき ToDo」として整理します。4 つのパブリック IP があるケースを想定していますが、数が多くても考え方は同じです。
- [ ] 各パブリック IP の SKU（Basic / Standard） と 関連付け先リソース を Azure ポータルで確認
- [ ] 棚卸しシートに、IP-1 ～ IP-4 の情報（RG / SKU / ひも付け先 / 用途 / 担当者）を書き出す
- [ ] 各 IP について、現用か / 廃止済みか / 不明 を分類する
- [ ] DNS レコード、取引先 FW / SaaS 側ホワイトリストなど、固定 IP 依存の箇所を洗い出す
- [ ] 「未使用」「廃止済み」と判断できた IP は、関連リソースの削除も含めてクリーンアップ計画を立てる
- [ ] 「現用」と判断した IP について、
- IP が変わってもよいか？（DNS / ホワイトリスト更新が許容されるか）
- メンテナンス時間帯を確保できるか？
- [ ] Standard へ移行する各リソースの NSG 設定を事前に見直し、必要なポートを明示的に許可
- [ ] 移行後に、接続テスト・監視・ログを確認し、問題なければ旧 Basic IP を削除
- [ ] 最後に、環境全体を見渡して 「そもそもパブリック IP が本当に必要な箇所」だけに絞り込む
Basic SKU パブリック IP のリタイア日である 2025 年 9 月 30 日 を既に過ぎている場合、まだ Basic を使っている環境はサポート外の「レガシー構成」です。
この記事のステップに沿って、まずは 4 つの IP がどこにひも付いているのかを見える化し、未使用 IP の削除によるコスト削減と、Standard SKU への計画的な移行を進めていきましょう。
まとめると、
- 未使用のパブリック IP は迷わず削除し、コストとセキュリティリスクを同時に削減
- 使用中の Basic IP は、Standard への移行（付け替え or アップグレード）を早期に実施
- 移行時は NSG / DNS / ホワイトリスト / 監視設定まで含めて「トータルの設計」を見直す
この 3 点を押さえておけば、「Azure のパブリック IP が 4 つあるが用途が分からない」「Basic から Standard へどう移行すればいいのか分からない」という状況から、一歩先に進むことができます。
コメント