Azure の Basic SKU Public IP を Standard SKU へ移行したいが、外部に公開している IP アドレスは変えたくない――そんな本番運用でよくある悩みに向けて、VM の NIC に紐づく Basic（動的）Public IP を、できるだけ同じ IP のまま Standard へアップグレードする手順と注意点をまとめます。
結論：IP を変えずに Basic → Standard へ上げる基本ルート
VM の NIC に関連付いた Basic SKU の Public IP（動的）を 同じ IP のまま Standard SKU にするなら、基本は次の流れです。
- 動的 → 静的（Static）へ変更して IP を固定する
- Public IP を NIC から一時的に関連付け解除（Dissociate）する
- Public IP リソースを Standard SKU にアップグレードする
- 同じ Public IP を NIC に再関連付け（Associate）する
ポイントは、削除しないことと、関連付け解除の前に静的化しておくことです。公式ドキュメントでも「Public IP をアップグレードすると IP アドレスは保持される」と明記されています。
なぜ今すぐ対応が必要なのか
Basic SKU Public IP は「廃止（retired）」扱いとなっており、今後も運用を続ける前提としては Standard SKU への移行が前提になります。Microsoft Learn では、廃止後も一定期間は動作し得るものの、サポート対象外で SLA の保証もないことが説明されています。つまり「今は動いているから大丈夫」ではなく、障害・変更・増設のタイミングで詰むリスクが高い状態です。
Basic と Standard の違い（アップグレード前に必ず理解する）
「アップグレードできたのに繋がらない」事故の多くは、SKU の思想が違うことを把握せずに進めてしまうのが原因です。特に重要なのは、Standard が Secure by default（閉じていて、必要な通信だけ開ける）という点です。
| 観点 | Standard SKU Public IP | Basic SKU Public IP |
|---|---|---|
| 割り当て方法 | 静的（Static）のみ | IPv4 は動的/静的、IPv6 は動的 |
| セキュリティモデル | Secure by default（受信は閉じが基本） 通信を通すには NSG などで明示許可が必要 | Open by default（基本は開いている） NSG は推奨だが必須ではない |
| 可用性ゾーン | ゾーン/ゾーン冗長/非ゾーンを選択可能（地域要件あり） | 非対応 |
| ルーティング優先設定 | 対応 | 非対応 |
| グローバル Tier | 対応（クロスリージョン LB など） | 非対応 |
| Standard Load Balancer / NAT Gateway / Azure Firewall 連携 | 対応（要件により） | 非対応 |
「同じ IP を維持したい」場合の最重要注意点
静的化しないまま関連付け解除すると IP を失う可能性が高い
Public IP が動的のまま NIC から外すと、IP が解放されて次回同じ IP を再取得できない可能性があります。公式ドキュメントでも、動的割り当ては停止・削除等で IP が解放されること、IP を変えたくないなら Static にするべきことが説明されています。
Standard は「閉じる」ので、NSG が無いと移行後に繋がらない
Standard SKU Public IP は Secure by default のため、受信通信は閉じが基本です。移行後に想定外の停止を避けるため、Public IP が付く NIC（またはサブネット）に対して NSG を適用し、必要な受信ルールを明示的に許可しておきます。
アップグレードは不可逆（戻せない）
Basic → Standard へのアップグレードは元に戻せません。作業前に「影響範囲」「代替アクセス」「ロールバック方針」を整理し、メンテナンスとして実施してください。
ゾーン要件に注意（アップグレード後の Standard IP はゾーン無しのままになりがち）
Microsoft Learn では、Basic から Standard へアップグレードした Public IP は、多くの場合 Availability Zone 情報を持たないため、ゾーン冗長や特定ゾーン紐づけのリソースに関連付けできない可能性がある、と注意されています。ゾーン構成（VM をゾーンに固定している等）を採用している場合は、アップグレードよりも「新規でゾーン冗長の Standard IP を作成して付け替え」のほうが現実的になることがあります（ただし IP は変わります）。
Load Balancer と SKU が混在していると詰むことがある
VM の NIC がロードバランサーのバックエンドプール等に関連付いていると、Public IP と Load Balancer の SKU 整合が必要になり、単体でのアップグレードができないケースがあります（Basic と Standard の混在は不可）。該当する場合は、ロードバランサー側も含めた移行計画が必要です。
アップグレード前チェックリスト（本番で必ずやる）
| チェック項目 | 確認場所（例） | NG の場合に起きがちなこと | 対策 |
|---|---|---|---|
| Public IP の SKU が Basic か | Public IP リソースの「概要」 | Standard なら作業不要 | Basic なら移行計画へ |
| 割り当て方法が動的か静的か | Public IP リソースの「構成」 | 動的のまま外すと IP 喪失 | 先に Static に変更 |
| NIC に NSG が適用されているか | NIC または サブネットの NSG | Standard 化後に受信が塞がる | 必要な受信許可ルールを作成 |
| VM/NIC がゾーン固定か | VM の作成情報 / 可用性 | 再関連付け不可の可能性 | ゾーン要件を先に整理 |
| NIC が Load Balancer に関連付いていないか | NIC の設定 / LB のバックエンドプール | SKU 不整合でアップグレード不可 | LB も含めた移行へ |
| 外部接続元が IP ホワイトリスト運用か | FW / SaaS / 取引先設定 | IP が変わると一斉に影響 | 本手順で IP を維持（削除しない） |
ダウンタイムの考え方（どこで止まる？どこまで止まる？）
本手順では、Public IP を NIC から外す瞬間に インターネット経由の通信が一時停止します。RDP/SSH/HTTPS/独自ポートなど、Public IP に向いている通信はすべて影響を受ける前提でメンテナンス枠を確保してください。
| タイミング | 影響 | 注意 |
|---|---|---|
| 関連付け解除（Dissociate） | 受信（インターネット→VM）が停止 | 管理アクセスも切れる可能性があるため、Bastion/Serial Console 等の代替手段があると安心 |
| アップグレード実行 | Public IP リソース側の更新 | 不可逆。完了まで待つ |
| 再関連付け（Associate） | 受信が復旧（ただし NSG 次第） | Standard は閉じが基本。NSG の許可が無いと「戻らない」ように見える |
手順：Azure ポータルで Basic SKU → Standard SKU（IP を変更しない）
ここからは、質問の前提どおり「VM の NIC にぶら下がっている Basic SKU Public IP」を対象に、ポータル操作での実施手順を、つまずきポイント込みで詳しく書きます。
Public IP を「静的（Static）」に変更して IP を固定する
- Azure ポータルで対象の Public IP アドレス リソースを開きます。
- 左メニューの ［設定］→［構成］ を開きます。
- 割り当て方法 を「動的」から 静的（Static） に変更し、［保存］をクリックします。
- 保存後、画面右上に「保存されました」などの通知が出ることを確認します。
- 念のため ［概要］ でも割り当て方法が Static になっていること、IP アドレスが想定どおりであることを確認します（反映に時間がかかる場合はリロード）。
Standard SKU は動的割り当てをサポートしないため、アップグレード前に Static へ変更するのは必須です。
NIC との関連付けを一時的に外す（ここで一時停止が発生）
- 同じ Public IP リソース画面で ［関連付けの解除（Dissociate）］ を選びます。
- ダイアログで表示される NIC 名（または VM 名）をメモします（あとで再関連付けします）。
- ［はい］ で関連付け解除を実行します。
この瞬間から、インターネットからの到達性が落ちます。事前に「今切れて困る通信」がないか（外部システム、バッチ、監視、運用端末）を確認してから実施してください。
Basic SKU → Standard SKU にアップグレードする
- Public IP リソースの概要画面上部に表示される アップグレードのバナー、または ［Upgrade to Standard SKU］ をクリックします。
- 注意事項（不可逆であること等）を確認し、チェックボックスに同意して実行します。
- 完了通知が出たら、Public IP の SKU が Standard になっていることを確認します。
アップグレードには「Static であること」「どのリソースにも関連付いていないこと」が求められます。また、公式には「アップグレードにより IP アドレスは保持される」ことが説明されています。
VM の NIC に Public IP を再関連付けする
- Public IP リソース画面で ［関連付け（Associate）］ をクリックします。
- リソースの種類で Network interface（ネットワーク インターフェイス） を選択します。
- 先ほどメモした NIC を選択して関連付けます。
- 必要に応じて、VM 側のネットワーク画面でも Public IP が付いていることを確認します。
ここまでで「同じ IP アドレスを持つ Standard SKU Public IP」が VM に戻ります。ただし Standard は Secure by default のため、NSG の設定が弱い（または無い）と「戻ったのに繋がらない」状態になります。
アップグレード後に必ず確認すること（復旧確認の型）
| 確認項目 | 期待値 | 確認のしかた |
|---|---|---|
| Public IP の SKU | Standard | Public IP リソースの「概要」 |
| 割り当て方法 | Static | Public IP リソースの「構成」 |
| IP アドレス | 移行前と同一 | Public IP リソースの「概要」 |
| 必要な受信ポートの到達性 | 想定どおり通る | 外部からの疎通（HTTPS/SSH/RDP 等）＋ NSG ルール確認 |
| NSG の適用 | NIC またはサブネットに NSG が関連付く | NIC/サブネットの NSG 設定 |
Standard にしたら繋がらない…を防ぐ「NSG 設計」例
Standard SKU は「必要な通信だけ明示的に許可」する前提なので、最小許可の NSG を事前に作っておくと安全です。以下は「よくある公開パターン」の例です（実際は要件に合わせて送信元やポートを絞ってください）。
| 優先度 | 方向 | 許可/拒否 | プロトコル | 送信元 | 宛先ポート | 用途 |
|---|---|---|---|---|---|---|
| 100 | 受信 | 許可 | TCP | 管理拠点の固定 IP | 22 または 3389 | SSH / RDP（運用） |
| 110 | 受信 | 許可 | TCP | 0.0.0.0/0（必要最小へ推奨） | 443 | Web 公開 |
| 120 | 受信 | 許可 | TCP | 取引先の固定 IP | 要件のポート | 外部連携 |
| 4096 | 受信 | 拒否 | Any | Any | Any | それ以外は遮断 |
「Basic のときは NSG がなくても繋がっていた」環境ほど、Standard 化で突然死します。移行作業とセットで NSG を見直すのが、本番での成功率を上げる近道です。
よくあるトラブルと対処法
| 症状 | 原因の典型 | 対処 |
|---|---|---|
| 「Upgrade to Standard」が押せない / 警告が出る | 動的のまま、または関連付けが残っている | Static 化を確認 → Dissociate → 再度アップグレード |
| アップグレード後に RDP/SSH/HTTPS が通らない | Standard の Secure by default で受信が閉じている（NSG 不備） | NIC/サブネットに NSG を適用し、必要な受信ルールを許可 |
| 再関連付けができない | ゾーン要件の不一致、または LB との SKU 整合など | VM がゾーン固定か、LB が絡むかを確認し、設計ごと見直す |
| IP が変わってしまった | 動的のまま外した、または Public IP を削除して作り直した | 削除した場合は原則復旧不可。今後は Static 化してから作業する |
CLI / PowerShell で作業したい場合（自動化のヒント）
ポータルでの手順が基本ですが、複数 VM を一括対応したい場合は CLI / PowerShell のほうがミスを減らせます。公式ドキュメントでは、アップグレードは次のような形で実施できることが示されています（前提として「Static」「非関連付け」が必要）。
Azure CLI（例）
# 1) Public IP を Standard にアップグレード（事前に Static 化＆関連付け解除が必要）
az network public-ip update --resource-group <rg> --name <pipName> --sku Standard
# 2) NIC から Public IP を外す（関連付け解除）
az network nic ip-config update --name --resource-group --nic-name --public-ip-address null NIC から外すコマンド例は Microsoft Learn にも掲載されています。
PowerShell（考え方）
PowerShell でも同様に「NIC の PublicIpAddress を null にして反映」→「Public IP の SKU を Standard に更新」→「再関連付け」という流れです。
複数の Public IP が VM に付いているなら「公式アップグレードスクリプト」も有効
VM に複数の Public IP が付いている（または多数の VM をまとめて処理したい）場合、Microsoft Learn で公開されているアップグレードスクリプトの利用も検討できます。このスクリプトは「Static 化してからデタッチ→アップグレード→再アタッチ」を自動化し、Static にしてから外すため スクリプトが失敗しても IP が変わらない旨が説明されています。なお、ロードバランサーに関連付いた NIC など非対応シナリオがある点は要注意です。
まとめ：本番で「IP を変えない」アップグレードを成功させるコツ
- Public IP リソースを削除しない（削除すると同じ IP は原則戻らない）
- 動的 → 静的へ変更してから関連付け解除する
- Standard はSecure by default。NSG の受信ルールを事前に整備する
- ゾーン要件・ロードバランサー有無など、環境の前提を先に潰す
- アップグレードは不可逆。メンテ枠と検証手順を用意してから実施する
この型で進めれば、VM の NIC に紐づく Basic SKU Public IP を、同じ IP のまま Standard SKU へ移行できる確度が高くなります。
コメント