MENU

Azure Basic SKU パブリックIP退役対応完全ガイド｜期限・影響・安全なStandard移行手順

Azure

Azure で長年使われてきた Basic SKU のパブリック IP が「2025年9月30日」に退役します。この記事では、期限後の挙動や猶予の有無、実務で迷いやすい影響範囲を整理しつつ、ダウンタイムを最短化する現実的な移行計画（ポータル手順・自動化・検証と運用変更）までを一気通貫で解説します。

目次

Azure Basic SKU パブリック IP退役への対応

質問と要点のまとめ

項目結論補足
退役日2025年9月30日この日までに移行を完了しておくのが安全
期限後に動作を続ける？動作保証なし割当解除・通信断が起こり得るため前倒し移行が必須
猶予期間・自動フォールバックなし自動移行も提供されない想定。計画停止の確保が現実解
対象外Cloud Services (Extended Support) 付随の Basic IPそれ以外の Basic IP は原則対象

なぜ「今」動くべきか

パブリック IP は外部公開の入口です。割当やルーティングが無効化されると、一見正常でも外部疎通だけが失われます。期限間際の駆け込みは、作業枠や承認、夜間要員の確保が難しくなり、復旧に時間がかかるリスクが跳ね上がります。業務影響を最小化するには、2025年前半に全移行を完了し、運用・監視まで見直すのが現実的です。

影響の考え方とスコープ

影響を受けやすいパターン

  • 単独の Basic 公開 IP を VM/NIC に直付けしている
  • Basic Load Balancer と組み合わせて外部公開している
  • 古い設計で NSG が緩く、Basic の「開放デフォルト」に依存している

比較表：Basic と Standard の違い

観点Basic SKUStandard SKU移行時の注意
可用性ゾーン非対応/限定ゾーン冗長・ゾーンピン留め可ゾーン戦略（ZRS/単一ゾーン）を決める
セキュリティ既定開放デフォルト閉域デフォルトNSG/UTM の許可ルールを明示的に設定
メトリック最小限接続/フロー等が強化監視としきい値の再設計が必要
互換性Basic LB などと整合Standard LB などと整合LB/Firewall 等も Standard へ揃える
コストやや低廉やや上昇する場合ありIP個数・転送量・ゾーン冗長で差分試算

結論：退役日以降の動作保証はない／猶予も自動移行もない

Microsoft はサービス中断回避のため、退役日前に Standard SKU へアップグレードすることを強く推奨しています。退役日以降、Basic IP は割当解除・解放され、外部疎通が消失する可能性があります。猶予期間や自動移行・自動フォールバックは提供されません。唯一の例外は、Azure Cloud Services (Extended Support) に紐づく Basic IP で、これは今回の退役対象外です。

現場で使える移行シナリオ

最短・安全重視：同一アドレスを保持しつつ Standard へ移行（ポータル）

  1. 対象 Basic IP の設定 → 構成で割当方法を動的から静的へ変更し保存（IP を固定化）。
  2. プロパティタブでStaticを確認。
  3. Dissociate（関連付け解除）を実行して NIC から切り離し（この瞬間、外部通信が一時停止）。
  4. 画面上部のUpgrade to Standard SKUをクリックし、確認チェックのうえ実行（数秒～数十秒）。
  5. Associate（関連付け）で元の NIC を選び再割当て。

ポイント：先に静的化しておけば、通常は同じグローバル IP アドレスのまま Standard SKU に移行できるため、DNS レコードの変更は不要です。

影響最小化オプション：二重公開によるブルー/グリーン

WAF／CDN／Application Gateway／Front Door をフロントに置いている場合、先に Standard IP を別名で発行し、WAF 側のバックエンドを段階的に切替える「二重公開」でダウンタイムを実質ゼロにできます。DNS TTL を30～60秒に落としておけばロールバックも迅速です。

大規模環境のための自動化・在庫化

① 在庫の一括可視化（Azure Resource Graph）

テナント横断で Basic 公開 IP を洗い出します。アクセス許可のあるサブスクリプションが対象です。

Resources
| where type =~ 'microsoft.network/publicipaddresses'
| where tostring(sku.name) =~ 'Basic'
| project subscriptionId, resourceGroup, name, location,
          ip=properties.ipAddress,
          version=properties.publicIPAddressVersion,
          attachedTo=properties.ipConfiguration.id,
          state=properties.provisioningState

② 作業対象の優先度付け

優先度条件対処
高外部顧客向け本番/ピーク帯に大量アクセスブルー/グリーン採用、長めのメンテナンス枠
中社内向けだが業務時間に影響業務時間外で一括、事前周知と手順書整備
低検証/一時リソース削除または新規 Standard で再作成

③ 自動化の考え方（CLI/PowerShell/Terraform）

  • Azure CLI / PowerShell：対象 IP を列挙 → 静的化 → NIC 切離し → SKU 変更 → 再割当て。事前にメンテナンス枠と疎通監視を仕込む。
  • Terraform：既存リソースを import して状態管理に取り込み、sku = "Standard" 化。変更順序（depends_on）と lifecycle の create_before_destroy を駆使してダウンタイムを最小化。
  • Azure Advisor：「退役予定の Basic IP」の推奨を一覧取得して着手順を決める。

サンプル（PowerShell：対象抽出と静的化）

# すべての Basic 公開 IP を列挙（要: Az.Network）
$pubIps = Get-AzPublicIpAddress -ErrorAction Stop | Where-Object { $_.Sku.Name -eq "Basic" }

foreach ($ip in $pubIps) {
if ($ip.PublicIpAllocationMethod -ne "Static") {
$ip.PublicIpAllocationMethod = "Static"
Set-AzPublicIpAddress -PublicIpAddress $ip -ErrorAction Stop
}
}

サンプル（CLI：対象列挙）

# 拡張機能: az extension add --name resource-graph
az graph query -q "
Resources
| where type =~ 'microsoft.network/publicipaddresses'
| where tostring(sku.name) =~ 'Basic'
| project id, name, resourceGroup, subscriptionId, properties.ipAddress"

注：環境・API バージョンにより SKU 変更の具体的なコマンドや順序が異なる場合があります。実施前に検証用サブスクリプションでのリハーサルを推奨します。

標準手順書（SOP）：人手でも迷わないチェックリスト

事前チェック

  • 対象 IP と関連リソース（NIC、VM、LB、Application Gateway、NSG、Route Table）を特定。
  • DNS の関連（A/AAAA、CNAME、PTR）の有無と TTL。
  • 監視の有無（HTTP ヘルスチェック、Ping、TCP ポート監視）。
  • 業務オーナー承認、メンテナンス告知、バックアウト条件。
  • 踏み台や VPN 経路など、作業者のリモート経路が影響を受けないこと。

実施手順（要計画停止）

  1. 監視を一時サプレッション（誤検知・自動復旧動作を防ぐ）。
  2. ポータルで静的化 → Dissociate → Upgrade → Associate。
  3. LB/AGW/Firewall 等の関連設定が「Standard 前提」か再確認。
  4. 監視サプレッション解除、疎通試験（セレクタは後述の表を使用）。
  5. 作業記録（誰が、いつ、どの IP を、どの手順で）。

疎通試験の観点

観点コマンド例合格条件
TCP オープンTest-NetConnection <IP> -Port 443成功（応答時間の増加がない）
HTTP ヘルスcurl -I https://<FQDN>/healthz200/204 が返る
名前解決nslookup <FQDN>同一 IP を指し続ける（TTL 減少を確認）
Inbound NAT / LBLB 規則経由の RDP/SSH事前と同一手順で接続可

運用・監視の見直しポイント

  • 閉域デフォルト化：Standard では未許可トラフィックが通りません。NSG の許可ルールとログを棚卸し。
  • メトリック強化：接続数・ドロップなど新規メトリックを Azure Monitor で可視化。しきい値を再設計。
  • アラート整備：IP のステート、バックエンドのヘルス、レイテンシの上振れを個別に監視。
  • 変更管理：以後は新規作成時の既定を「Standard」に統一。ポリシーで Basic を禁止。

コスト差の考え方（概算フレームワーク）

料金はリージョンと転送量で変動します。以下は差分の考え方であり、実額は料金ページで再計算してください。

要素BasicStandard差分の傾向
IP の時間単価低中軽微に上昇し得る
ゾーン冗長不可/限定可冗長化で増加する場合あり
データ転送共通共通設計の影響が大きい

実務 TIPS：IP を整理統合（不要な静的 IP の解放、WAF や LB で集約）すると Standard 移行の増分を相殺できるケースが多いです。

よくある落とし穴と回避策

  • NSG の既定許可に依存：Standard で閉塞して疎通不可に。移行前に許可ルールを明示化。
  • LB の SKU ミスマッチ：Public IP だけ Standard にすると LB が Basic のままでアタッチ不可。LB/AGW も揃える。
  • 監視の誤作動：ダウンタイム検知で自動フェイルオーバーが発動し、復旧が複雑化。サプレッションを必ず設定。
  • 踏み台も停止：作業用経路の IP を先に切ってしまう事故。作業者経路は最後に切替。

ローリング方式（複数 IP / 複数リージョン）

複数サイトを運用している場合は、リージョン単位・役割単位で波及を抑えたローリングをおすすめします。

波対象作業内容合否基準バックアウト
Wave 1検証環境（全リージョン）標準手順のドライラン全監視合格、手順書確定スナップショットから巻戻し
Wave 2本番・低重要度夜間帯で一括外形監視 0 アラートDNS 切戻し/代替 IP
Wave 3本番・高重要度二重公開 + 切替SLA 指標を満たすTraffic Manager で旧経路へ

リスク評価（例）

リスク発生確率影響度対策検知
IP 再割当て失敗低～中高作業順守・リハーサル・代替 IP 準備外形監視・接続試験
NSG 設定漏れ中中～高ルール棚卸し・テンプレート化フローログ・接続診断
想定外の連携断低中通信相関図の作成・影響分析アプリログ・APM

バックアウト（切戻し）戦略

  • ブルー/グリーンの場合：WAF/Front Door のバックエンドを旧経路へ即時戻す。
  • 単一 IP の場合：事前に「代替の Standard IP」をプールしておき、アプリ側で複数バインドを許容しておくと復旧が速い。
  • DNS を触る場合は TTL を短縮（30～60秒）し、切戻し時の伝播時間を最小化。

移行後のバリデーションと仕上げ

  1. エッジからの疎通（ISP/拠点/モバイル回線）で実利用と同条件を再現。
  2. 監視アラートの再チューニング（Standard の新メトリックを活用）。
  3. タグ/CMDB へ「SKU=Standard」「移行日」「担当者」を記録し、再発防止のポリシー（Basic 作成禁止）を適用。

FAQ

  • Q. 期限を過ぎても、たまたま動くことは？
    A. 期待すべきではありません。業務継続の観点からは「停止する前提」で計画してください。
  • Q. どうしても同じ IP を維持したいのですが？
    A. 先に静的化したうえでポータルの「Upgrade to Standard SKU」を使うのが最短です。
  • Q. 影響対象外は本当に Cloud Services (Extended Support) だけ？
    A. はい。基本的にはそれ以外の Basic 公開 IP が対象です。構成ごとの影響は事前棚卸しで確認を。
  • Q. ダウンタイムはどれくらい？
    A. 多くのケースで数秒～数分です。ピーク以外の時間帯を確保してください。

実行プラン（テンプレート）

フェーズ期間主なタスク成果物
アセスメント今すぐ～2週在庫化、影響分析、優先度付け、関係者調整対象一覧、計画書、周知文面
パイロット3～4週検証サブスクでリハーサル、SOP 固定化確定手順書、ロールバック手順
本番展開1～2か月低重要度 → 高重要度の順にローリング作業記録、監視調整
運用定着継続ポリシー適用、コスト最適化、監視改善再発防止策、KPI レポート

今回の要点（要約）

  • 退役日：2025年9月30日。前倒しで移行完了を。
  • 期限後の動作保証なし／猶予・自動移行なし。停止前提で計画。
  • ポータルの静的化 → 切離し → アップグレード → 再割当てが最短・確実。
  • 大規模は ARG で在庫化し、スクリプト/Terraform でローリング移行。
  • Standard への設計変更（閉域デフォルト・メトリック強化・LB/AGW 揃え）と運用見直しをセットで。

補足情報

  • 実施タイミング：数秒～数分の通信停止が発生し得るため、業務の閑散時間帯で。
  • 検証環境：テスト VM で手順と影響を確認後、本番へ展開。
  • 推奨スケジュール：2025 年前半に全 IP の移行を完了し、監視・運用まで見直す。
  • 参考ドキュメント（名称のみ）：「Basic パブリック IP アドレス (SKU) の退役通知」「Basic から Standard パブリック IP へのアップグレード方法」
Azure
ネットワーク 移行 Azure Public IP Standard SKU

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次