既存のファイアウォールから新しいファイアウォールへ Public IP を付け替えようとしたところ、「Different basic sku and standard sku load balancer or public Ip resources in availability set is not allowed」というエラーに悩まされるケースは少なくありません。この記事では、Azure の Basic/Standard SKU の違いから原因を丁寧に整理しつつ、実運用を意識した具体的な解決手順と、将来のトラブルを防ぐための設計・移行のベストプラクティスまでまとめて解説します。
Firewall の WAN インターフェースに既存 Public IP を付け替えたらエラーになった
オンプレミスの機器を Azure にリフト＆シフトしたり、古いファイアウォールの VM を新しいイメージやアプライアンスに置き換える際、既存の Public IP をそのまま新しいファイアウォールに付け替えたい、という要件は非常に多いです。
ところが、Azure Portal で新しいファイアウォールの NIC（WAN側）に既存 Public IP を Associate しようとすると、次のようなエラーが表示されることがあります。
Different basic sku and standard sku load balancer or public Ip resources in availability set is not allowed
メッセージだけ見ると少し分かりづらいですが、要するに「同じ可用性セット（Availability Set）内に Basic SKU と Standard SKU のリソースを混在させてはいけない」という制約に引っかかっている状態です。
この制約を正しく理解しないまま作業を進めてしまうと、Public IP の付け替えができず、切り戻しも難しい状況に追い込まれかねません。ここからは、エラーの意味と Azure の仕組みを整理しながら、具体的な対応方法を解説していきます。
Azure の Public IP と SKU（Basic / Standard）の基本
まずは前提となる Azure ネットワークの仕様を整理します。Azure では、以下のようなリソースに対して SKU（スキュー）という概念があります。
- Public IP アドレス
- Load Balancer
- Azure Firewall など一部の PaaS / NVA
SKU は主に Basic と Standard の 2 種類があり、機能・可用性・セキュリティモデルが異なります。
| 項目 | Basic SKU | Standard SKU |
|---|---|---|
| 用途のイメージ | 開発・検証環境、小規模構成 | 本番環境、大規模・高可用性構成 |
| 可用性 | ゾーン冗長なし（リージョン依存） | ゾーン冗長構成が可能（Zone-redundant / Zonal） |
| セキュリティモデル | 許可寄り（既定で一部ポートが開くケースあり） | 拒否寄り（NSG などで明示的に許可が必要） |
| NSG の扱い | なくても通信できる場合がある | 必要なポートを NSG で明示的に開放する必要あり |
| 推奨度 | 新規構成では非推奨になりつつある | Microsoft 推奨（特に本番環境） |
重要なのは、同じ可用性セット内や同じ VM / LB の構成内で Basic と Standard を混在させられないという点です。これが今回のエラーの直接的な原因になります。
エラー「Different basic sku and standard sku …」の意味
エラーメッセージを分解すると、次のような意味になります。
- Different basic sku and standard sku
Basic SKU と Standard SKU が混ざっています。 - load balancer or public Ip resources
対象は Load Balancer または Public IP リソースです。 - in availability set is not allowed
同じ可用性セット内では SKU が混在していてはいけません。
つまり、
- 同じ可用性セットに所属する VM に紐づいた NIC / LB / Public IP の組み合わせの中で
- Basic SKU と Standard SKU が同居している
という状態になると、このエラーが発生します。
| 組み合わせ例 | SKU の状態 | 結果 |
|---|---|---|
| VM（可用性セット A）＋ Basic LB ＋ Basic Public IP | すべて Basic | 問題なし |
| VM（可用性セット A）＋ Standard LB ＋ Standard Public IP | すべて Standard | 問題なし |
| VM（可用性セット A）＋ Basic LB ＋ Standard Public IP | Basic と Standard が混在 | エラー発生 |
| VM（可用性セット A）＋ Standard LB ＋ Basic Public IP | Basic と Standard が混在 | エラー発生 |
今回のように「既存ファイアウォールから新ファイアウォールに Public IP を付け替えたい」というシナリオでは、旧構成と新構成で SKU が揃っていないことがよくあります。
なぜ新しいファイアウォールの WAN インターフェースに割り当てられないのか
よくあるパターンとして、次のような構成が考えられます。
- 旧ファイアウォール：Basic SKU の Public IP ＋ Basic SKU の Load Balancer
- 新ファイアウォール：Standard SKU の Load Balancer（または Azure Firewall Standard）
この状態で、旧ファイアウォールから外した Basic SKU の Public IP を、新ファイアウォール側の NIC や Load Balancer に関連付けようとすると、可用性セットや LB バックエンドプールの組み合わせの中で Basic と Standard が混在することになり、エラーが発生します。
また、次のような点でも制約を踏んでいるケースがあります。
- Public IP の SKU は Basic のままなのに、新ファイアウォールの構成はすべて Standard 前提
- 旧ファイアウォールと新ファイアウォールが同じ可用性セット内に存在し、その配下で SKU が混在してしまう
- Public IP を付け替える前に、旧ファイアウォール側の関連付け解除が完全に完了していない
これらの要素が重なって、今回のようなエラーとして表面化します。
全体像を押さえたうえでの解決方針
解決の方向性はシンプルで、関係するリソースの SKU を Standard に統一することです。新規構成や更改タイミングであれば、Basic に合わせるのではなく、将来を見据えて Standard へ寄せるのが現実的です。
ここからは、実際の作業フローに沿って詳しく見ていきます。
ステップ 1: 関連リソースの SKU を洗い出す
まずは、どのリソースが Basic で、どのリソースが Standard なのかを正確に把握します。対象となるのは、主に以下のリソースです。
- Public IP アドレス
- Load Balancer
- ファイアウォール VM（NVA）や Azure Firewall
- 可用性セット（配下の VM / NIC）
Azure Portal から確認する場合は、各リソースを開いて「SKU」の項目を確認します。
- Public IP：概要 (Overview) または 設定 (Configuration) に SKU が表示
- Load Balancer：概要 に SKU が表示
- Azure Firewall：作成時に選択した SKU（Standard / Premium）などとあわせて確認
Azure CLI で確認する場合の例は次のとおりです。
# Public IP の SKU を確認
az network public-ip show \
-g <ResourceGroup> \
-n <PublicIPName> \
--query "sku.name" \
-o tsv
# Load Balancer の SKU を確認
az network lb show \
-g <ResourceGroup> \
-n <LoadBalancerName> \
--query "sku.name" \
-o tsv
NIC 自体には SKU の概念はありませんが、どの Load Balancer や Public IP に紐づいているかによって制約を受けます。必要に応じて、NIC の設定も合わせて確認しましょう。
# NIC の IP 設定（Public IP や LB バックエンドの紐づき）を確認
az network nic show \
-g <ResourceGroup> \
-n <NicName> \
--query "ipConfigurations"
ステップ 2: Public IP を Standard SKU にアップグレードする
旧ファイアウォールに紐づいていた Public IP が Basic SKU だった場合、多くのケースでは次のような流れになります。
- 旧ファイアウォール（または旧 NIC）から Public IP の関連付けを解除（Dissociate）する
- Public IP リソースの設定画面から「Upgrade to Standard」を実行する
- Standard SKU に変換された Public IP を、新しいファイアウォール側に付け替える
注意点として、Basic → Standard の一方向のみがサポートされ、Standard → Basic へのダウングレードはできません。一度 Standard に上げると Basic に戻せないため、構成全体を Standard ベースで揃える前提で計画を立てる必要があります。
また、Public IP を Dissociate した直後は、ポータル上の状態が「Updating」となっている時間帯があります。この間は別のリソースへの関連付けがうまくいかない場合があるので、状態が「Succeeded」になってから再試行するのがおすすめです。
ステップ 3: NIC / Load Balancer / ファイアウォール側を Standard に統一
Public IP を Standard にしただけでは、構成全体の SKU が揃っていないと同じエラーが再発します。次のポイントを順番に確認していきます。
Load Balancer の SKU を確認・統一
ファイアウォールの前段に Load Balancer を置いている場合、以下のようなパターンがあります。
- 旧構成：Basic Load Balancer ＋ Basic Public IP
- 新構成：Standard Load Balancer ＋ Standard Public IP
あるいは、旧構成の Basic Load Balancer に Standard Public IP を後付けした場合などに、SKU の混在が発生します。基本的には、
- 既存の Load Balancer ごと Standard SKU で作り直す
- Standard で新規作成した Load Balancer に、新しいファイアウォールをぶら下げる
といった形で、LB と Public IP の SKU を揃えることが重要です。
ファイアウォール VM / Azure Firewall の構成確認
Network Virtual Appliance（NVA）として動作するファイアウォール製品や Azure Firewall を利用している場合、それぞれの推奨構成が Standard SKU を前提としていることが多くなっています。
- Standard Public IP ＋ Standard Load Balancer ＋ 可用性セット or 可用性ゾーン
- NSG を用いた明示的な許可ルールの定義
もし旧構成が Basic ベースで組まれている場合は、この機会に 構成ごと Standard 前提に刷新したほうが、後々のトラブルを回避しやすくなります。
ステップ 4: 可用性セットとリソース配置の整合性を確認
エラーメッセージにも「in availability set」とある通り、同じ可用性セット内で Basic と Standard を混在させることはできません。そのため、次の点を確認します。
- 旧ファイアウォール VM と新ファイアウォール VM が同じ可用性セットに属していないか
- 同じ可用性セット配下の VM に紐づく Load Balancer / Public IP が混在していないか
設計上のベストプラクティスとしては、次のように考えると分かりやすくなります。
- 可用性セット単位で「Basic 環境」「Standard 環境」を分ける
- 新規構成は基本的に Standard のみを使う
- 古い Basic 構成は、段階的に切り離していく
また、Public IP はリージョン単位での制約があるため、VM / NIC / LB / Public IP が同一リージョンにあることもあわせて確認しておくと安心です。
ステップ 5: Public IP を新ファイアウォールの WAN NIC に再関連付け
ここまでの作業で、
- Public IP：Standard SKU にアップグレード済み
- Load Balancer：Standard SKU に統一済み（必要な場合）
- ファイアウォール VM / Azure Firewall：Standard 構成と整合性がとれている
- 可用性セット：Basic / Standard の混在なし
という状態になっていれば、改めて Public IP を新しいファイアウォールの WAN NIC に Associate できるはずです。
Portal からの操作イメージは次の通りです。
- 新ファイアウォールの NIC（WAN 用）を開く
- IP 構成 (IP configurations) から WAN 用の IP 設定を選択
- Public IP アドレスの項目で、Standard SKU にアップグレードした既存 Public IP を選択
- 保存 (Save) を実行
もしここで再び同じエラーが出る場合は、まだどこかに SKU の混在が残っている可能性があります。次章のチェックリストを参考に、もう一度構成を見直してみてください。
Standard SKU を利用する際の追加ポイント
Standard SKU に統一すると、可用性やセキュリティの観点でメリットが大きい一方、いくつか設計上の注意点があります。
NSG による明示的な許可設定が必須
Standard SKU の Public IP / Load Balancer は、「セキュア by デフォルト」の考え方に基づいており、Basic と比べてより厳格な閉域スタートになっています。そのため、
- VM / NIC / サブネットに NSG を作成・割り当て
- 必要なポート（管理用 SSH/RDP、アプリケーション用ポートなど）を明示的に許可
といった作業が必須です。Basic のときに「なんとなく繋がっていた」通信が、Standard への移行後に NSG 設定漏れで止まる、という事故は非常に多いので注意しましょう。
ゾーン冗長化や可用性ゾーンとの組み合わせ
Standard SKU の Public IP では、以下のようなモードを選択できます。
- ゾーン冗長（Zone-redundant）
- ゾーン固有（Zonal）
- リージョン冗長（リージョンと SKU による）
ファイアウォールを複数の可用性ゾーンにまたがってデプロイする場合は、ゾーン冗長な Standard Public IP と組み合わせることで、ゾーン障害にも強い構成を取ることができます。Public IP を付け替えるタイミングで、可用性ゾーン設計を見直しておくのも良いタイミングです。
ダウンタイムを最小限にする移行手順の例
本番環境でファイアウォールを更改しつつ、既存の Public IP を引き継ぐ場合、ダウンタイムをできるだけ短く抑えたいところです。以下は 1 つの例です。
- 事前に新ファイアウォール環境（Standard SKU 前提）を構築
- 新ファイアウォール側では一時的な別の Public IP を割り当てて、疎通確認・ルール検証を完了
- DNS を使っている場合は、切替前に TTL を短めに調整しておく
- メンテナンス時間帯に入り、旧ファイアウォールから既存 Public IP を Dissociate
- 既存 Public IP を Standard SKU にアップグレード（必要な場合）
- 新ファイアウォールの WAN NIC に既存 Public IP を Associate
- 動作確認（外部からの疎通、内外双方向の通信、ログなど）
- 問題なければ一時的に使っていた Public IP を開放する
このように、「新環境を先に立ち上げてから Public IP だけ後から付け替える」方式を取ることで、ダウンタイムを数分～十数分程度に抑えることができます。
トラブルシューティング用チェックリスト
最後に、似たトラブルが起きたときに利用できるチェックリストをまとめます。
| 確認項目 | 確認方法 | OK の状態 |
|---|---|---|
| Public IP の SKU | Portal の概要 / 設定、または CLI | Standard に統一されている |
| Load Balancer の SKU | Portal の概要、または CLI | Public IP と同じく Standard |
| ファイアウォール VM の所属可用性セット | VM の設定画面 | 可用性セット内で Basic / Standard が混在していない |
| 旧ファイアウォールとの関連付け | 旧ファイアウォールの NIC / LB の設定 | 既存 Public IP と紐づいていない |
| Public IP の状態 | Portal で状態フィールドを確認 | 「Succeeded」になっている |
| NSG の許可ルール | NIC / サブネットの NSG 設定 | 必要なポートが明示的に Allow されている |
よくある質問と補足
Basic SKU のままではダメなのか？
技術的には Basic SKU でも動作しますが、以下の理由から本番環境では Standard が推奨されます。
- ゾーン冗長構成との親和性
- セキュア by デフォルトな設計
- 今後の新機能やサポートの観点で有利
今回のような更改タイミングでは、将来の拡張性も考慮して Standard へ移行しておくことをおすすめします。
Basic から Standard に変えたあと、元に戻せる？
いいえ、Basic → Standard へのアップグレードは可能ですが、Standard → Basic へのダウングレードはできません。もし何らかの理由で Basic に戻す必要がある場合は、新しく Basic SKU の Public IP を作成し直す必要があります。
Public IP を付け替えたのに通信がうまくいかない
SKU のエラーが解消されても、以下のような理由で通信がうまくいかないことがあります。
- 新ファイアウォール側のルール設定（許可 / 拒否）が旧環境と一致していない
- NSG の許可ルールが不足している（Standard SKU で顕在化しやすい）
- 経路テーブル（UDR）の宛先が旧ファイアウォールの IP アドレスのままになっている
- DNS の TTL が長く、古い IP を引き続きキャッシュしている
Public IP の付け替え作業と同時に、ファイアウォールルール・NSG・UDR・DNS など周辺の設定も一緒に確認する習慣を付けると安全です。
まとめ：SKU を理解しておけば Public IP の付け替えは怖くない
「Different basic sku and standard sku load balancer or public Ip resources in availability set is not allowed」というエラーは、一見すると難解ですが、ポイントは次の 3 つに集約できます。
- Public IP や Load Balancer には Basic / Standard の 2 種類の SKU がある
- 同じ可用性セットや同じ構成内で Basic と Standard を混在させることはできない
- 解決するには、関係するリソースの SKU を Standard に統一し、構成全体を整理する
既存ファイアウォールから新ファイアウォールへの移行は、一見単純な「IP の付け替え」に見えますが、実際には Azure ネットワークの設計思想や SKU の制約を理解していないとハマりやすいポイントです。この記事の内容を踏まえて、事前に構成を整理し、ダウンタイムとトラブルを最小限に抑えたスマートな移行を実現していただければと思います。
コメント