Azure Firewall FAQ

Azure Firewallは、Azure Virtual Network リソースを保護するクラウドベースのマネージド ネットワーク セキュリティ サービスです。 完全にステートフルなサービスとしてのファイアウォールで、組み込みの高可用性とクラウドによる無制限のスケーラビリティを備えています。 サブスクリプションと仮想ネットワークをまたいでアプリケーションとネットワークの接続ポリシーを一元的に作成、適用、記録できます。

Azure Firewall機能の詳細な一覧については、「Azure Firewall 機能」を参照してください。

Azure Firewallは、任意の仮想ネットワークにデプロイできます。 ただし、通常はハブ アンド スポーク モデルの中央の仮想ネットワークにデプロイされ、他の仮想ネットワークがピアリングされます。 ピアリングされた仮想ネットワークからの既定のルートは、この中央のファイアウォール仮想ネットワークを指すよう設定されます。 グローバル仮想ネットワーク ピアリングはサポートされていますが、リージョン間でパフォーマンスと待機時間の問題が発生する可能性があるため、推奨されません。 最適なパフォーマンスを得られるように、リージョンごとに 1 つのファイアウォールをデプロイします。

このモデルでは、異なるサブスクリプション間で複数のスポーク VNet を一元的に制御でき、各仮想ネットワークにファイアウォールをデプロイする必要がないようにすることでコストを削減できます。 コスト削減は、トラフィック パターンに基づいて関連するピアリング コストに対して評価する必要があります。

Azure Firewallは、Azure ポータル、PowerShell、REST API、またはテンプレートを使用してデプロイできます。 詳細な手順については、「Tutorial: Azure ポータルを使用してAzure Firewallをデプロイして構成するを参照してください。

Azure Firewallでは、ルールとルール コレクションが使用されます。 ルール コレクションは、順序と優先度が同じルールのセットです。 ルール コレクションは優先順位で実行されます。 DNAT ルール コレクションは、ネットワーク ルール コレクションよりも優先度が高く、アプリケーション ルール コレクションよりも優先順位が高くなります。 すべてのルールが終了しています。

次の 3 つの種類のルール コレクションがあります。

• アプリケーション ルール: 仮想ネットワークからアクセスできる完全修飾ドメイン名 (FQDN) を構成します。
• ネットワーク ルール: 送信元アドレス、プロトコル、宛先ポート、および宛先アドレスを使用して規則を構成します。
• "NAT 規則": 受信インターネットまたはイントラネット (プレビュー) 接続を許可するように DNAT 規則を構成します。

詳細については、「Azure Firewall ルールの構成」を参照>。

Azure Firewallは、ログを表示および分析するためのAzure Monitorと統合されます。 ログは、Log Analytics、Azure Storage、または Event Hubs に送信し、Log Analytics、Excel、Power BIなどのツールを使用して分析できます。 詳細については、「Tutorial: Azure Firewall ログの監視」を参照してください。

Azure Firewallは、仮想ネットワーク リソースを保護するクラウドベースのマネージド ネットワーク セキュリティ サービスです。 完全にステートフルなサービスとしてのファイアウォールで、組み込みの高可用性とクラウドによる無制限のスケーラビリティを備えています。 これは、仮想ネットワークとブランチ インターネット接続のセキュリティを強化するために、サードパーティのサービスとしてのセキュリティ (SECaaS) プロバイダーと事前に統合されています。 詳細については、「Azure ネットワーク セキュリティ」を参照してください。

Application Gateway WAF は、一般的な悪用や脆弱性に対する Web アプリケーションの一元的な受信保護を提供します。 Azure Firewallでは、HTTP/S 以外のプロトコル (RDP、SSH、FTP など) の受信保護、すべてのポートとプロトコルの送信ネットワーク レベルの保護、および送信 HTTP/S に対するアプリケーション レベルの保護が提供されます。

Azure Firewallは NSG を補完して、より優れた "多層防御" ネットワーク セキュリティを提供します。 NSG では、分散ネットワーク層のトラフィック フィルタリングが提供され、各サブスクリプションの仮想ネットワーク内のトラフィックが制限されます。 Azure Firewallは、サブスクリプションと仮想ネットワーク全体で、一元化された完全ステートフル ネットワークとアプリケーション レベルの保護を提供します。

Azure Firewallは、NIC レベルの NSG を使用したプラットフォーム保護 (表示不可) を含む、複数の保護レイヤーを持つマネージド サービスです。 サブネット レベルの NSG は AzureFirewallSubnet では必要ありません。また、サービスの中断を防ぐために無効になっています。

プライベート エンドポイントは、Private Linkのコンポーネントであり、パブリック IP アドレスではなくプライベート IP アドレスを使用して Azure PaaS サービスと対話できるようにするテクノロジです。 Azure Firewallを使用すると、パブリック IP アドレスへのアクセスを防ぐことができます。そのため、Private Linkを利用していないAzure サービスへのデータ流出を回避したり、組織内でそれらのAzure PaaS サービスにアクセスする必要があるユーザーを定義してゼロトラスト ポリシーを実装したりできますPrivate Link既定では、企業ネットワーク全体のネットワーク アクセスが開きます。

Azure Firewallを使用してプライベート エンドポイントへのトラフィックを検査するための適切な設計は、ネットワーク アーキテクチャによって異なります。詳細については、プライベート エンドポイント宛てのトラフィックを検査するシナリオAzure Firewallに関する記事を参照してください。

Virtual Network サービス エンドポイントは、Azure PaaS サービスへのネットワーク アクセスを制御するPrivate Linkの代替手段です。 クライアントが引き続きパブリック IP アドレスを使用して PaaS サービスにアクセスする場合でも、ソース サブネットが表示され、宛先 PaaS サービスでフィルター規則を実装し、サブネットごとにアクセスを制限できます。 両方のメカニズムの詳細な比較については、「 プライベート エンドポイントとサービス エンドポイントの比較」を参照してください。

Azure Firewallアプリケーション ルールを使用して、不正なサービスへのデータ流出が行われないようにし、サブネット レベルを超えて細分性を高めたアクセス ポリシーを実装できます。 通常、仮想ネットワーク サービス エンドポイントは、Azure サービスに接続するクライアントのサブネットで有効にする必要があります。 ただし、Azure Firewallを使用してサービス エンドポイントへのトラフィックを検査する場合は、代わりに Azure Firewall サブネットで対応するサービス エンドポイントを有効にし、実際のクライアント (通常はスポーク仮想ネットワーク) のサブネットで無効にする必要があります。 これにより、Azure Firewallのアプリケーション ルールを使用して、Azure ワークロードがアクセスできるAzure サービスを制御できます。

価格の詳細については、「Azure Firewall Pricing」を参照してください。

サービスの制限については、Azureサブスクリプションとサービスの制限、クォータ、制約を参照してください。

Azure Firewallは、顧客データをデプロイ先のリージョン外に移動したり、保存したりすることはありません。

いいえ。現在、カタールでは、セキュリティで保護された仮想ハブ (vWAN) のAzure Firewallはサポートされていません。

はい。Azure Firewallでは、受信トラフィックと送信トラフィックのフィルター処理の両方がサポートされます。 通常、受信フィルター処理は、RDP、SSH、FTP などの HTTP 以外のプロトコルに使用されます。 受信 HTTP および HTTPS トラフィックの場合は、Azure Web Application Firewall (WAF) などの Web アプリケーション ファイアウォール、または Azure Firewall Premium の TLS オフロードおよびディープ パケット検査機能の使用を検討してください。

はい。Azure Firewall Basic では強制トンネリングがサポートされます。

TCP ping は、実際にはターゲット FQDN に接続しません。 Azure Firewallは、ルールによって明示的に許可されていない限り、ターゲット IP アドレスまたは FQDN への接続をブロックします。

TCP ping の場合、トラフィックを許可するルールがない場合、ファイアウォール自体はクライアントの TCP ping 要求に応答します。 この応答は、ターゲット IP アドレスまたは FQDN に到達せず、ログに記録されません。 ネットワーク ルールでターゲット IP アドレスまたは FQDN へのアクセスが明示的に許可されている場合、ping 要求はターゲット サーバーに到達し、その応答はクライアントに中継されます。 このイベントは、ネットワーク ルール ログに記録されます。

いいえ。Azure Firewallは BGP ピアリングをネイティブにサポートしていません。 ただし、Autolearn SNAT ルート機能はAzure Route Server経由で間接的に BGP を使用します。

Azure Firewallは ESP (セキュリティ ペイロードのカプセル化) をネイティブにサポートしていませんが、次のようにネットワーク ルールを構成することで ESP トラフィックを許可できます。

Azure Firewall構成 (ネットワーク 規則):

• プロトコル: 任意
• ソース ポート: * (任意)
• 宛先ポート: * (任意)
• 送信元/宛先: 必要に応じて IP アドレスを指定する

この構成により、ESP パケット (IP プロトコル番号 50) とその他の TCP/UDP 以外のトラフィックが規則に一致することを許可します。 ただし、Azure Firewallは ESP ペイロードを検査しないことに注意してください。

参照: Azure Firewall: NSG は ESP (IP プロトコル番号 50) を指定する直接オプションを提供しませんが、ESP パケットは次の設定を使用して許可できます。

• プロトコル: 任意
• ポート: * (任意)
• 送信元/宛先: 必要に応じて IP アドレスを指定する

Recommendations:

• IPsec VPN 構成の場合は、Azure VPN Gatewayを使用することをお勧めします。
• 要件に応じて、NVA (ネットワーク仮想アプライアンス) パターンの使用を検討してください。

Azure PowerShellを使用して、Azure Firewallの割り当てを解除して割り当てることができます。 プロセスは構成によって異なります。

管理 NIC のないファイアウォールの場合:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

管理 NIC を使用するファイアウォールの場合:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

セキュリティで保護された仮想ハブ内のファイアウォールの場合:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

初期デプロイ時に可用性ゾーンを構成することをお勧めします。 ただし、次の場合は、デプロイ後にそれらを再構成できます。

• ファイアウォールは仮想ネットワークにデプロイされます (セキュリティで保護された仮想ハブではサポートされていません)。
• リージョンは可用性ゾーンをサポートしています。
• アタッチされているすべてのパブリック IP アドレスは、同じゾーンで構成されます。

可用性ゾーンを再構成するには:

1. ファイアウォールの割り当てを解除します。

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. ゾーン構成を更新し、ファイアウォールを割り当てます。

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

はい：

• Azure Firewallと仮想ネットワークは、同じリソース グループ内に存在する必要があります。
• パブリック IP アドレスは、別のリソース グループに含めることができます。
• すべてのリソース (Azureファイアウォール、仮想ネットワーク、パブリック IP) は、同じサブスクリプション内にある必要があります。

プロビジョニングの失敗状態は、1 つ以上のバックエンド インスタンスで構成の更新が失敗したことを示します。 Azure Firewallは引き続き動作しますが、構成に一貫性がない可能性があります。 プロビジョニングの状態が [成功] に変わるまで、更新を再試行します。

Azure Firewallでは、複数のバックエンド ノードを含むアクティブ/アクティブ構成が使用されます。 計画メンテナンス中は、接続の段階的切断によって円滑な更新が保証されます。 計画外の障害の場合、障害が発生したノードは新しいノードによって置き換えられ、通常は 10 秒以内に接続が復元されます。

はい。ファイアウォール名は 50 文字に制限されています。

/26 サブネットを使用すると、Azure Firewallによって追加の仮想マシン インスタンスがプロビジョニングされるため、スケーリングに十分な IP アドレスが確保されます。

いいえ。すべてのスケーリング シナリオには、/26 サブネットで十分です。

Azure Firewallは、CPU 使用率、スループット、接続数に基づいて自動的にスケーリングされます。 スループット容量の範囲は、最初は 2.5 ~ 3 Gbps から 30 Gbps (Standard SKU) または 100 Gbps (Premium SKU) です。

はい。 詳細については、「Azureサブスクリプションとサービスの制限、クォータ、制約を参照してください。

いいえ。IP グループを別のリソースグループに移動することは現在サポートされていません。

ネットワーク ファイアウォールの標準的な動作では、TCP 接続が確実に維持されるようにして、アクティビティがない場合はすぐに終了するようになっています。 TCP アイドル タイムアウトAzure Firewallは 4 分です。 この設定はユーザーが構成することはできませんが、Azure サポートに問い合わせて、受信接続と送信接続のアイドル タイムアウトを最大 15 分まで増やすことができます。 East-West トラフィックのアイドル タイムアウトは変更できません。

アイドル時間がタイムアウト値よりも長い場合、TCP や HTTP のセッションが維持される保証はありません。 一般的な方法として、TCP keep-alive を使用します。 この方法を使用すると、接続が長時間アクティブ状態に維持されます。 詳細については、.NETの例を参照してください。

はい。ただし、強制トンネリング モードでファイアウォールを構成する必要があります。 この構成では、Azure Firewallが操作に使用するパブリック IP アドレスを持つ管理インターフェイスが作成されます。 このパブリック IP アドレスは、管理トラフィック用です。 Azure プラットフォームでのみ使用され、他の目的には使用できません。 テナント データ パス ネットワークは、パブリック IP アドレスなしで構成でき、インターネット トラフィックは、別のファイアウォールに強制的にトンネリングするか、完全にブロックすることができます。

はい。 詳細については、「Azure Firewall と Azure Firewall ポリシーを Logic Apps でバックアップする方法」を参照してください。

PaaS サービスへのアクセスをセキュリティで保護するには、サービス エンドポイントをお勧めします。 Azure Firewall サブネットでサービス エンドポイントを有効にし、接続されたスポーク仮想ネットワークで無効にすることもできます。 このようにして、サービス エンドポイントのセキュリティとすべてのトラフィックの一元的ログ記録という、両方の機能の長所を活かすことができます。

はい。ハブ仮想ネットワーク内のAzure Firewallを使用して、複数のスポーク仮想ネットワーク間でトラフィックをルーティングおよびフィルター処理できます。 各スポーク仮想ネットワーク内のサブネットには、このシナリオが正常に機能するための既定のゲートウェイとしてAzure Firewallを指す UDR が必要です。

はい。 ただし、同じ仮想ネットワーク内のサブネット間でトラフィックをリダイレクトするように UDR を構成するには、さらに注意が必要です。 UDR のターゲット プレフィックスとして仮想ネットワーク アドレス範囲を使用するだけで十分ですが、これにより、1 つのマシンから同じサブネット内の別のマシンにすべてのトラフィックが Azure Firewall インスタンス経由でルーティングされます。 これを回避するには、仮想ネットワークの次ホップの種類を持つ UDR にサブネットのルートを含 めます。 これらのルートの管理は、手間がかかり、誤りが発生する可能性もあります。 内部ネットワークのセグメント化について推奨される方法は、UDR を必要としないネットワーク セキュリティ グループを使用する方法です。

宛先 IP アドレスがプライベート ネットワークの IANA RFC 1918 または IANA RFC 6598 ごとのプライベート IP 範囲である場合、Azure Firewallは SNAT を行いません。 組織がプライベート ネットワークにパブリック IP アドレス範囲を使用している場合、Azure Firewall はAzureFirewallSubnet内のファイアウォールのプライベート IP アドレスの1つにトラフィックをSNATします。 パブリック IP アドレス範囲を SNATしないように Azure Firewall を構成できます。 詳細については、「Azure Firewall SNAT プライベート IP アドレス範囲」を参照>。

さらに、アプリケーション ルールによって処理されたトラフィックでは、常に SNAT が実行されます。 FQDN トラフィックのログに元の送信元 IP アドレスを表示する場合は、宛先 FQDN でネットワーク規則を使用できます。

強制トンネリングは、新しいファイアウォールを作成するときにサポートされます。また、強制トンネリング用の管理 NIC を追加することで、既存のファイアウォールでもサポートされます。 新しいデプロイの詳細については、「Azure Firewall強制トンネリング」を参照>。 既存のファイアウォールについては、「Azure Firewall 管理 NIC」を参照してください。

Azure Firewallは、インターネットに直接接続されている必要があります。 AzureFirewallSubnet が BGP 経由のオンプレミス ネットワークへの既定のルートを学習する場合は、インターネットへの直接接続を保持するために、NextHopType の値を Internet に設定した 0.0.0.0/0 UDR でこれを上書きする必要があります。

使用する構成でオンプレミスのネットワークへの強制的なトンネリングが必要であり、インターネット上のアクセス先のターゲット IP プレフィックスを決定できる場合は、AzureFirewallSubnet 上のユーザー定義のルートを介して、次のホップとしてオンプレミスのネットワークに対してこれらの範囲を構成することができます。 または、BGP を使用してこれらのルートを定義することもできます。

• URL - アスタリスクは、右端または左端に配置すると機能します。 左側にある場合、FQDN の一部にすることはできません。
• FQDN - アスタリスクは、左端に配置すると機能します。
• GENERAL - 左端のアスタリスクは、文字通り左側の "何か" が一致することを意味します。つまり、複数のサブドメインや望ましくない可能性のあるドメイン名のバリエーションが一致します。以下の例を参照してください。

例 :

いいえ。 Azure Firewallは、既定でActive Directoryアクセスをブロックします。 アクセスを許可するには、AzureActiveDirectory サービス タグを構成します。 詳細については、「Azure Firewall サービス タグ」を参照してください。

はい。Azure PowerShellを使用して実行できます。

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

TCP ping は実際にはターゲット FQDN に接続していません。 Azure Firewallでは、許可する明示的な規則がない限り、ターゲット IP アドレス/FQDN への接続は許可されません。

TCP ping は特異なユース ケースであり、許可するルールがない場合、TCP ping はターゲット IP アドレスや FQDN に到達しませんが、ファイアウォール自体がクライアントの TCP ping 要求に応答します。 この場合、イベントはログされません。 ターゲット IP アドレスや FQDN へのアクセスを許可するネットワーク ルールがある場合は、ping 要求はターゲット サーバーに到達し、その応答がクライアントに送り返されます。 このイベントは、ネットワーク ルール ログに記録されます。

はい。 詳細については、「Azureサブスクリプションとサービスの制限、クォータ、制約」を参照してください>

いいえ。IP グループを別のリソースグループに移動することは現在サポートされていません。

ネットワーク ファイアウォールの標準的な動作では、TCP 接続が確実に維持されるようにして、アクティビティがない場合はすぐに終了するようになっています。 TCP アイドル タイムアウトAzure Firewallは 4 分です。 この設定はユーザーが構成することはできませんが、Azure サポートに問い合わせて、受信接続と送信接続のアイドル タイムアウトを最大 15 分まで増やすことができます。 East-West トラフィックのアイドル タイムアウトは変更できません。

アイドル時間がタイムアウト値よりも長い場合、TCP や HTTP のセッションが維持される保証はありません。 一般的な方法として、TCP keep-alive を使用します。 この方法を使用すると、接続が長時間アクティブ状態に維持されます。 詳細については、.NETの例を参照してください。

はい。ただし、強制トンネリング モードでファイアウォールを構成する必要があります。 この構成では、Azure Firewallが操作に使用するパブリック IP アドレスを持つ管理インターフェイスが作成されます。 このパブリック IP アドレスは、管理トラフィック用です。 Azure プラットフォームでのみ使用され、他の目的には使用できません。 テナント データ パス ネットワークは、パブリック IP アドレスなしで構成でき、インターネット トラフィックは、別のファイアウォールに強制的にトンネリングするか、完全にブロックすることができます。

Azure Firewallは、デプロイ先のリージョンから顧客データを移動したり、保存したりすることはありません。

はい。 詳細については、「Azure Firewall および Azure Firewall ポリシーのバックアップ（Logic Apps 使用）」を参照してください。

いいえ。現在、保護された仮想ハブ (vWAN) のAzure Firewallはカタールではサポートされていません。

Azure Firewallは、Azure 仮想マシンの下で使用され、その上で接続数に厳しい制限が設けられています。 仮想マシンあたりのアクティブな接続の合計数は 250,000 です。

ファイアウォールあたりの合計制限は、仮想マシンの接続制限 (250k) x ファイアウォール バックエンド プール内の仮想マシンの数です。 Azure Firewall 2 つの仮想マシンから始まり、CPU 使用率とスループットに基づいてスケールアウトされます。

Azure Firewallは現在、アイドル待機時間なしで、送信 SNAT トラフィックに TCP/UDP ソース ポートを使用しています。 TCP/UDP 接続が閉じられると、使用された TCP ポートは、今後の接続ですぐに使用可能と見なされます。

特定のアーキテクチャの回避策として、NAT Gateway と Azure Firewall を使用してデプロイおよびスケーリングし、可変性と可用性のために SNAT ポートのより広いプールを提供できます。

特定の NAT については、その動作が、ファイアウォールの構成と、構成されている NAT の種類によって異なる場合があります。 たとえば、ファイアウォールに、受信トラフィック用の DNAT 規則と、ファイアウォールを経由する送信トラフィック用のネットワーク規則とアプリケーション規則がある場合があります。

詳細については、「Azure Firewall NAT の動作を参照してください。

計画されたメンテナンスにおいて、接続ドレイン機能はスムーズにバックエンドノードを更新します。 Azure Firewallは、既存の接続が閉じるまで 90 秒待機します。 最初の 45 秒間、バックエンド ノードは新しい接続を受け入れず、残りの時間はすべての着信パケットに で応答します。 必要に応じて、クライアントは別のバックエンド ノードへの接続を自動的に再確立できます。

Azure Firewall VM インスタンスのシャットダウンは、仮想マシン スケール セットのスケール イン (スケール ダウン) 中またはフリート ソフトウェアのアップグレード中に発生する可能性があります。 このような場合、新しい着信接続は残りのファイアウォール インスタンスに負荷分散され、ダウンしたファイアウォール インスタンスには転送されません。 45 秒後、ファイアウォールは TCP RST パケットを送信して既存の接続の拒否を開始します。 さらに 45 秒が経過すると、ファイアウォール VM がシャットダウンします。 詳細については、「Load Balancer TCP リセットとアイドル タイムアウトを参照してください。

平均スループットまたは CPU 消費量が 60%の場合、または接続の使用量が 80%の場合、Azure Firewallは徐々にスケーリングされます。 たとえば、最大スループットの 60% に達すると、スケールアウトが開始されます。 最大スループット数は、Azure Firewall SKU と有効な機能によって異なります。 詳細については、「Azure Firewall performance」を参照してください。

スケールアウトには 5 から 7 分かかります。 パフォーマンス テストの場合は、少なくとも 10 ~ 15 分間テストし、新しく作成されたAzure Firewall ノードを利用するために新しい接続を開始してください。

接続にアイドル タイムアウト (アクティビティなし 4 分) がある場合、Azure Firewallは TCP RST パケットを送信して接続を正常に終了します。

Azure サービスでは、機能、信頼性、パフォーマンス、およびセキュリティを強化するために、定期的なメンテナンス更新が行われます。 メンテナンス期間が構成されている場合、ゲスト OS のメンテナンスとサービスメンテナンスは、その期間中に実行されます。 ただし、お客様が管理するメンテナンスには、ホストの更新プログラムや重要なセキュリティ更新プログラムは含まれません。

Azure Firewallメンテナンスの詳細通知は使用できません。

いいえ。5 時間以上のメンテナンス期間が必要です。

いいえ。現在、メンテナンス期間は毎日繰り返されるように構成されています。

顧客が管理するメンテナンスでは、ゲスト OS とサービスの更新プログラムがサポートされます。これは、お客様にとって懸念されるほとんどのメンテナンス項目を考慮しています。 ただし、ホストの更新プログラムなど、一部の更新プログラムは、顧客が管理するメンテナンスの範囲外です。 まれに、重大度の高いセキュリティの問題に対処するために、メンテナンス期間の制御をオーバーライドすることがあります。

はい。

いいえ。 現在、Azure Firewallに関連付けることができるメンテナンス構成は 1 つだけです。

すべてのAzure Firewall SKU - Basic、Standard、Premium では、顧客が管理するメンテナンスがサポートされます。

メンテナンス ポリシーが関連付けられた後、Azure Firewallがメンテナンス スケジュールに従うのに最大 24 時間かかる場合があります。

Azure Firewallのメンテナンス アクティビティは、スケジュールされたメンテナンス期間の前の期間中は一時停止されません。 メンテナンス スケジュールに含まれていない日数の場合、定期的なメンテナンス操作はリソースで通常どおり続行されます。

詳細については、「 顧客が管理するメンテナンスの構成」を参照してください。