Azure の「Reliability in Azure Firewall」が2026年6月16日に更新されたものの、Azure Firewallの設定や可用性、料金が変わったわけではありません。更新履歴を確認すると、同日の変更はドキュメントのメタデータ1行を削除したもので、本文に仕様変更はありません。Microsoft Learn上の本文更新日も2026年2月10日のままです。(GitHub)
ただし、現在の公式情報には、新規Azure Firewallのゾーン冗長化、既存環境の自動移行、単一ゾーン構成の扱いなど、2026年中に管理者が確認すべき重要事項が含まれています。通知を見て慌てて設定を変更する必要はありませんが、現在の構成とIaC定義は一度確認しておくべきです。
Azureの新機能・変更点：Reliability in Azure Firewallの変更点
2026年6月16日のGitHub上の更新では、reliability-firewall.mdから次のメタデータが削除されました。
ai-usage: ai-assistedAzure Firewallの可用性に関する本文、ゾーン設定、SLA、移行方針は変更されていません。今回の更新を、Azure Firewallの新機能リリースや強制的な構成変更と捉える必要はありません。(GitHub)
| 確認項目 | 2026年6月16日の変更 |
|---|---|
| Azure Firewallの機能 | 変更なし |
| 可用性ゾーンの設定 | 変更なし |
| 既存リソースの移行方針 | 変更なし |
| 料金体系 | 変更なし |
| 利用者向けの対応期限 | 新設なし |
| Microsoft Learnのメタデータ | 1行削除 |
一方で、現在の「Reliability in Azure Firewall」では、Azure Firewallの標準的な配置方法がゾーン冗長を前提とする構成へ移行していることが明確に説明されています。
Reliability in Azure Firewallとは
「Reliability in Azure Firewall」は新しい機能名ではなく、Azure Firewallの信頼性設計を説明するMicrosoft Learnのドキュメントです。
主に次の内容を扱っています。
- 一時的な障害への耐性
- 可用性ゾーン障害時の動作
- リージョン全体の障害への備え
- サービスメンテナンスへの対応
- SLAを満たすための構成
Azure Firewallは、通常の構成でも少なくとも2つの内部インスタンスを使用し、正常性監視や障害インスタンスの交換をAzure側で行います。スループットやCPU、接続数に応じたスケールアウトも自動で実行されます。(Microsoft Learn)
新規Azure Firewallはゾーン冗長がデフォルト
可用性ゾーンに対応するリージョンでは、ゾーンを明示的に指定せずAzure Firewallを作成すると、複数の可用性ゾーンに分散するゾーン冗長構成になります。
この動作はAzureポータルだけでなく、Azure CLI、PowerShell、Bicep、ARMテンプレート、Terraformなどを使用する場合にも適用されます。ただし、APIやIaCで単一のゾーンを明示した場合は、その指定が優先されます。(Microsoft Learn)
| 配置方法 | 構成 | ゾーン障害への耐性 |
|---|---|---|
| ゾーン冗長 | 2つ以上のゾーンに分散 | Azureが自動でフェイルオーバー |
| ゾーン指定なし | 対応リージョンではバックエンドでゾーン冗長 | Azureが自動管理 |
| 単一ゾーン指定 | 1つのゾーンに固定 | そのゾーンの障害に弱い |
| AZ非対応リージョン | リージョナル配置 | リージョン内のゾーン冗長は利用不可 |
日本国内では、公式リージョン一覧上、Japan EastとJapan Westの両方が可用性ゾーンに対応しています。ただし、実際のデプロイ可否はサービスの提供状況やリージョンの容量にも左右されます。(Microsoft Learn)
既存の非ゾーン指定Azure Firewallは自動移行される
既存のAzure Firewallのうち、ゾーン冗長にも単一ゾーンにも設定されていない「非ゾーン指定」または「リージョナル」と呼ばれる構成は、可用性ゾーン対応リージョンでゾーン冗長へ順次移行されます。
公式情報では、2026年中を通じて移行を進める方針が示されています。移行はAzureプラットフォーム側で実行され、管理者による操作や停止時間は不要とされています。(Microsoft Learn)
ただし、移行後も互換性維持のため、ARMテンプレート、リソースJSON、Azure Resource Graphのzonesプロパティへ移行結果がすぐに反映されないことがあります。zonesが空だからゾーン冗長ではない、と判断できない点が重要です。(Microsoft Learn)
単一ゾーンに固定したAzure Firewallは別扱い
zones: ["1"]のように単一ゾーンへ明示的に配置したAzure Firewallは、現時点の非ゾーン指定リソース向け自動移行の対象ではありません。
公式ドキュメントでは、単一ゾーン構成も将来ゾーン冗長へ移行する方針が示されていますが、具体的な実施日は明記されていません。高可用性が必要なシステムでは、将来の自動移行だけに依存せず、現在の構成を評価する必要があります。(Microsoft Learn)
誰に影響するのか
今回の2026年6月16日の文書更新そのものによる利用者への影響はありません。ただし、現在のゾーン冗長方針は次の管理者に関係します。
| 対象 | 確認すべきこと |
|---|---|
| 新規環境を作成する管理者 | IaCで単一ゾーンを意図せず指定していないか |
| 既存の非ゾーン指定環境 | 自動移行対象であることを運用担当者と共有する |
| 単一ゾーン構成の管理者 | ゾーン障害時の停止リスクを許容できるか |
| 監査・構成管理担当者 | zonesプロパティだけで移行状況を断定しない |
| アプリケーション担当者 | 接続切断に備えた再試行処理があるか |
| DR設計担当者 | ゾーン冗長とマルチリージョンを混同していないか |
特に注意したいのは、TerraformやBicepなどで過去の設定を再利用している環境です。以前の設計を引き継いだ結果、zonesに1つだけ値が設定され、新しいデフォルトのゾーン冗長化を無効にしている可能性があります。
現在のゾーン構成を確認する手順
Azure CLIでは、次のコマンドでAzure Firewallのリソース情報を確認できます。
az network firewall show \
--resource-group <RESOURCE_GROUP> \
--name <FIREWALL_NAME> \
--query "{name:name,location:location,zones:zones,provisioningState:provisioningState,sku:sku}" \
--output json表示されたzonesは、次のように判断します。
zonesの例 | 一般的な意味 |
|---|---|
["1","2","3"] | 複数ゾーンを明示したゾーン冗長構成 |
["1"] | 単一ゾーンに固定したゾーナル構成 |
nullまたは空 | 非ゾーン指定、新規デフォルト配置、自動移行済みのいずれか |
nullまたは空の場合は、リソースプロパティだけではバックエンドの状態を確定できません。可用性の監査証跡が必要な場合は、デプロイ時期、リージョン、IaC定義、Azure側の通知を確認し、必要に応じてMicrosoftサポートへ確認するのが安全です。
パブリックIPも確認する
ゾーン冗長Azure Firewallでは、Standard SKUのパブリックIPアドレスが必要です。新しくStandardパブリックIPを作成し、ゾーンを指定しなかった場合は、原則としてゾーン冗長として構成されます。ファイアウォールとパブリックIPを異なる単一ゾーンへ配置することはできません。(Microsoft Learn)
パブリックIPのSKUとゾーン情報は、次のコマンドで確認できます。
az network public-ip show \
--resource-group <RESOURCE_GROUP> \
--name <PUBLIC_IP_NAME> \
--query "{name:name,sku:sku.name,zones:zones,ipAddress:ipAddress}" \
--output json複数のパブリックIPをAzure Firewallへ関連付けている場合は、すべてのSKUとゾーン構成を確認してください。
手動でゾーン構成を変更するときの注意点
仮想ネットワークに配置したAzure Firewallは、一定の条件を満たせば、デプロイ後にゾーン構成を変更できます。
主な条件は次のとおりです。
- Azure Firewallが仮想ネットワークに配置されている
- リージョンが可用性ゾーンに対応している
- 関連付けたすべてのパブリックIPでゾーン構成が一致している
一方、セキュリティ保護付き仮想ハブでは、同じ方法によるデプロイ後の再構成はサポートされていません。(Microsoft Learn)
手動変更ではAzure Firewallを一度割り当て解除してから再割り当てします。この操作によりプライベートIPアドレスが変わる可能性があるため、ルートテーブルで固定IPを次ホップに指定している環境では通信障害につながります。(Microsoft Learn)
実施前に、少なくとも次の項目を確認してください。
- UDRの次ホップIP
- DNATルールで使用するパブリックIP
- 強制トンネリングの設定
- 管理用NICと管理用パブリックIP
- 接続元アプリケーションの再接続動作
- 変更後の疎通確認手順
- 切り戻し手順
非ゾーン指定環境は自動移行の対象であるため、zones表示を変える目的だけで手動再構成するのは避けるべきです。
ゾーン障害時に何が起きるのか
ゾーン冗長Azure Firewallでは、可用性ゾーンの障害をAzure側が検出し、正常なゾーンへトラフィックを自動的に振り替えます。管理者がフェイルオーバー操作を実行する必要はありません。
ただし、障害が発生したゾーンのインスタンスが処理していた進行中の接続は切断される可能性があります。公式情報では、ゾーン冗長構成の停止時間は通常数秒程度とされていますが、アプリケーション側には指数バックオフを使った再試行処理が推奨されています。(Microsoft Learn)
一方、単一ゾーン構成では、対象ゾーンが停止するとAzure Firewallも利用できなくなります。別ゾーンのファイアウォールやトラフィック切り替えを用意していない場合、ゾーンが復旧するまで通信を再開できません。
ゾーン冗長でもリージョン障害には対応できない
Azure Firewallは単一リージョンのサービスです。ゾーン冗長化によってデータセンターや可用性ゾーン単位の障害には強くなりますが、リージョン全体が利用できない障害には対応できません。
リージョン障害にも備える場合は、リージョンごとに独立したAzure Firewallを配置し、Azure Firewall Policyでルールを集約したうえで、別途トラフィックの切り替え設計を用意します。(Microsoft Learn)
「ゾーン冗長だからDR対策も完了している」と判断しないことが重要です。業務継続要件でリージョン障害が対象になっている場合は、セカンダリリージョンへの経路、名前解決、ルートテーブル、ポリシー同期まで確認してください。
料金は変わるのか
ゾーン冗長でAzure Firewallを配置すること自体に追加料金はありません。今回の2026年6月16日の更新による値上げや料金項目の追加も確認されていません。(Microsoft Learn)
ただし、Azure Firewall全体が無料になるわけではありません。通常どおり、主に次の料金が発生します。
- Azure Firewallのデプロイ時間に応じた料金
- 処理したデータ量に応じた料金
- パブリックIPアドレスなど関連リソースの料金
- Log Analyticsなどへログを保存する場合の料金
- プリスケーリングを有効にした場合の追加キャパシティ料金
Azure Firewallの料金はSKU、リージョン、契約通貨によって異なるため、固定額ではなくAzure料金計算ツールや実際のCost Managementで確認してください。公式料金ページでは、デプロイ時間とデータ処理量を中心に課金されることが示されています。(Microsoft Azure)
SLAはどう変わるのか
2つ以上の可用性ゾーンへ配置したゾーン冗長Azure Firewallには、99.99％の稼働率SLAが適用されます。可用性ゾーンをサポートしないリージョンのリージョナル配置には、99.95％の稼働率SLAが適用されます。(Microsoft Learn)
2026年6月16日の更新によってSLAの数値が変更されたわけではありません。ただし、自社の可用性目標が99.99％である場合は、単にAzure Firewallを利用するだけでなく、ゾーン冗長の適用条件を満たしているか確認する必要があります。
対応期限はあるのか
2026年6月16日の更新に伴う、利用者向けの対応期限や移行期限は発表されていません。
既存の非ゾーン指定Azure Firewallについて示されている「2026年中」という期間は、Azure側が順次プラットフォーム移行を実施する期間です。利用者が特定日までに設定を変更しなければならない、という意味ではありません。(Microsoft Learn)
また、既存の単一ゾーン構成をゾーン冗長へ移行する具体的な日付も示されていません。単一ゾーン障害のリスクを現在許容できない場合は、将来の自動移行を待つのではなく、手動変更や構成の再作成を検討します。
メンテナンス時間も合わせて見直す
Azure Firewallでは、サービス更新を実施する時間帯に合わせて、日次のメンテナンスウィンドウを設定できます。
メンテナンスウィンドウは最低5時間必要で、Basic、Standard、PremiumのすべてのSKUが対象です。長時間接続を維持するシステムや、接続切断の影響が大きい業務では、利用の少ない時間帯へ設定すると運用リスクを抑えられます。(Microsoft Learn)
ただし、重大なセキュリティ問題への対応など、一部の更新は指定したメンテナンスウィンドウ外で実行される可能性があります。
管理者が今すぐ確認すべきチェックリスト
今回の文書更新だけを理由に、Azure Firewallを再作成する必要はありません。代わりに、次の順番で環境を確認します。
- 所有するAzure Firewallを一覧化する
- 配置リージョンが可用性ゾーンに対応しているか確認する
- IaCの
zones指定が空、単一、複数のどれか確認する - 関連付けたパブリックIPのSKUとゾーン構成を確認する
- 非ゾーン指定環境は自動移行対象として管理台帳へ記録する
- 単一ゾーン環境は業務要件と照らして移行の要否を判断する
- アプリケーションの再試行処理をテストする
- リージョン障害が要件に含まれる場合はマルチリージョン構成を検討する
2026年6月16日の変更はメタデータ整理にとどまりますが、Azure Firewall全体ではゾーン冗長が標準的な配置方法になっています。まずはIaCで単一ゾーンを固定していないかを確認し、既存の非ゾーン指定環境は不要な再デプロイを避けながら自動移行を追跡してください。
コメント