Merge pull request #296465 from duongau/fwfreshness1

Azure Firewall - Freshness review (Batch 1 - March 2025)

Author: AnnaMHuff

articles/firewall/choose-firewall-sku.md

@@ -5,27 +5,49 @@ services: firewall
 author: duongau
 ms.service: azure-firewall
 ms.topic: concept-article
-ms.date: 04/03/2024
+ms.date: 03/17/2025
 ms.author: duau
 ---
 
 # Choose the right Azure Firewall version to meet your needs
 
-Azure Firewall now supports three different versions to cater to a wide range of customer use cases and preferences.
+Azure Firewall offers three versions to meet various customer needs:
 
-- Azure Firewall Premium is recommended to secure highly sensitive applications (such as payment processing). It supports advanced threat protection capabilities like malware and TLS inspection.
-- Azure Firewall Standard is recommended for customers looking for Layer 3–Layer 7 firewall and needs autoscaling to handle peak traffic periods of up to 30 Gbps. It supports enterprise features like threat intelligence, DNS proxy, custom DNS, and web categories.
-- Azure Firewall Basic is recommended for SMB customers with throughput needs of 250 Mbps.
+- **Azure Firewall Premium**: Ideal for securing highly sensitive applications, such as payment processing. It includes advanced threat protection features like malware and TLS inspection.
+- **Azure Firewall Standard**: Suitable for customers requiring Layer 3–Layer 7 firewall capabilities with autoscaling to manage peak traffic up to 30 Gbps. It includes enterprise features like threat intelligence, DNS proxy, custom DNS, and web categories.
+- **Azure Firewall Basic**: Designed for SMB customers with throughput requirements up to 250 Mbps.
 
 ## Feature comparison
 
-Take a closer look at the features across the three Azure Firewall versions:
+Compare the features of the three Azure Firewall versions:
+
+| Category | Feature | Firewall Basic | Firewall Standard | Firewall Premium |
+| --- | --- | --- | --- | --- |
+| **L3-L7 filtering** | Application level FQDN filtering (SNI based) for HTTPS/SQL | ✓ | ✓ | ✓ |
+|  | Network level FQDN filtering – all ports and protocols |  | ✓ | ✓ |
+|  | Stateful firewall (5 tuple rules) | ✓ | ✓ | ✓ |
+|  | Network address translation (SNAT+DNAT) | ✓ | ✓ | ✓ |
+| **Reliability & performance** | Availability zones | ✓ | ✓ | ✓ |
+|  | Built-in HA | ✓ | ✓ | ✓ |
+|  | Cloud scalability (auto-scale as traffic grows) | Up to 250Mbps | Up to 30 Gbps | Up to 100 Gbps |
+|  | Fat flow support | N/A | 1 Gbps | 10 Gbps |
+| **Ease of management** | Central management via firewall manager | ✓ | ✓ | ✓ |
+|  | Policy analytics (rule management over time) | ✓ | ✓ | ✓ |
+| **Enterprise integration** | Full logging including SIEM integration | ✓ | ✓ | ✓ |
+|  | Service tags and FQDN tags for easy policy management | ✓ | ✓ | ✓ |
+|  | Easy DevOps integration using REST/PowerShell/CLI/templates/Terraform | ✓ | ✓ | ✓ |
+|  | Web content filtering (web categories) |  | ✓ | ✓ |
+|  | DNS proxy + custom DNS |  | ✓ | ✓ |
+| **Advanced threat protection** | Threat intelligence-based filtering (known malicious IP address/domains) | Alert | ✓ | ✓ |
+|  | Inbound TLS termination (TLS reverse proxy) |  |  | Using Azure Application Gateway |
+|  | Outbound TLS termination (TLS forward proxy) |  |  | ✓ |
+|  | Fully managed IDPS |  |  | ✓ |
+|  | URL filtering (full path - including SSL termination) |  |  | ✓ |
 
-:::image type="content" source="media/choose-firewall-sku/azure-firewall-sku-table.png" alt-text="Table of Azure Firewall version features." lightbox="media/choose-firewall-sku/azure-firewall-sku-table-large.png":::
 
 ## Flow chart
 
-You can use the following flow chart to help you choose the Azure Firewall version that best fits you needs.
+Use the following flow chart to determine the best Azure Firewall version for your needs.
 
 <!-- Art Library Source# ConceptArt-0-000-011 -->
 :::image type="content" source="media/choose-firewall-sku/firewall-sku-flow.svg" alt-text="Flow chart to help you choose a firewall version." lightbox="media/choose-firewall-sku/firewall-sku-flow.svg":::

articles/firewall/firewall-faq.yml

@@ -7,7 +7,7 @@ metadata:
   ms.service: azure-firewall
   ms.custom: devx-track-azurepowershell
   ms.topic: faq
-  ms.date: 02/29/2024
+  ms.date: 03/17/2025
   ms.author: duau
 title: Azure Firewall FAQ
 summary: |

articles/firewall/firewall-multi-hub-spoke.md

@@ -5,45 +5,44 @@ services: firewall
 author: duongau
 ms.service: azure-firewall
 ms.topic: concept-article
-ms.date: 05/30/2023
+ms.date: 03/17/2025
 ms.author: maroja
 ---
 
 # Use Azure Firewall to route a multi hub and spoke topology
 
-The hub and spoke topology is a common network architecture pattern in Azure. The hub is a virtual network (VNet) in Azure that acts as a central point of connectivity to your on-premises network. The spokes are VNets that peer with the hub, and can be used to isolate workloads. The hub can be used to isolate and secure traffic between spokes. The hub can also be used to route traffic between spokes. The hub can be used to route traffic between spokes using various methods. 
+The hub and spoke topology is a common network architecture pattern in Azure. In this setup, the hub is a virtual network (VNet) that serves as a central point of connectivity to your on-premises network. The spokes are VNets that peer with the hub and can be used to isolate workloads. The hub can secure and route traffic between spokes using various methods.
 
-For example, you can use Azure Route Server with dynamic routing and network virtual appliances (NVAs) to route traffic between spokes. This can be a fairly complex deployment. A less complex method uses Azure Firewall and static routes to route traffic between spokes.
+For instance, you can use Azure Route Server with dynamic routing and network virtual appliances (NVAs) to route traffic between spokes, though this can be complex. A simpler method involves using Azure Firewall and static routes.
 
-This article shows you how you can use Azure Firewall with static user defined routes (UDRs) to route a multi hub and spoke topology. The following diagram shows the topology:
+This article demonstrates how to use Azure Firewall with static user-defined routes (UDRs) to route traffic in a multi hub and spoke topology. The following diagram illustrates the topology:
 
 :::image type="content" source="media/firewall-multi-hub-spoke/multi-hub-spoke-architecture.png" alt-text="Conceptual diagram showing hub and spoke architecture." lightbox="media/firewall-multi-hub-spoke/multi-hub-spoke-architecture.png":::
 
-
 ## Baseline architecture
 
-Azure Firewall secures and inspects network traffic, but it also routes traffic between VNets. It's a managed resource that automatically creates [system routes](../virtual-network/virtual-networks-udr-overview.md#system-routes) to the local spokes, hub, and the on-premises prefixes learned by its local Virtual Network Gateway. Placing an NVA on the hub and querying the effective routes would result in a route table that resembles what is found within the Azure Firewall.
+Azure Firewall not only secures and inspects network traffic but also routes traffic between VNets. It automatically creates [system routes](../virtual-network/virtual-networks-udr-overview.md#system-routes) to local spokes, the hub, and on-premises prefixes learned by its local Virtual Network Gateway. Placing an NVA on the hub and querying the effective routes would show a route table similar to that within Azure Firewall.
 
-Since this is a static routing architecture, the shortest path to another hub can be done by using global VNet peering between the hubs. So the hubs know about each other, and each local firewall contains the route table of each directly connected hub. However, the local hubs only know about their local spokes. Additionally, these hubs can be in the same region or a different region.
+In this static routing architecture, the shortest path to another hub is achieved using global VNet peering between hubs. Each hub knows about the other hubs, and each local firewall contains the route table of each directly connected hub. However, local hubs only know about their local spokes. These hubs can be in the same or different regions.
 
 ## Routing on the firewall subnet
 
-Each local firewall needs to know how to reach the other remote spokes, so you must create UDRs in the firewall subnets. To do this, you first need to create a default route of any type, which then allows you to create more specific routes to the other spokes. For example, the following screenshots show the route table for the two hub VNets:
+Each local firewall needs to know how to reach remote spokes, so you must create UDRs in the firewall subnets. Start by creating a default route, then add more specific routes to the other spokes. The following screenshots show the route tables for the two hub VNets:
 
 > [!NOTE]
-> The address prefix in the hub virtual route table should encompass the two spoke virtual network address spaces.
+> The address prefix in the hub virtual route table should encompass the address spaces of the two spoke virtual networks.
 
 **Hub-01 route table**
 :::image type="content" source="media/firewall-multi-hub-spoke/hub-01-route-table.png" alt-text="Screenshot showing the route table for Hub-01.":::
 
 **Hub-02 route table**
-:::image type="content" source="media/firewall-multi-hub-spoke/hub-02-route-table.png" alt-text="Screenshot showing the route table for Hub-02. ":::
+:::image type="content" source="media/firewall-multi-hub-spoke/hub-02-route-table.png" alt-text="Screenshot showing the route table for Hub-02.":::
 
 ## Routing on the spoke subnets
 
-The benefit of implementing this topology is that with traffic going from one hub to another, you can reach the next hop that is directly connected via the global peering.
+This topology allows traffic to move from one hub to another, reaching the next hop directly connected via global peering.
 
-As illustrated in the diagram, it's better to place a UDR in the spoke subnets that have a 0/0 route (default gateway) with the local firewall as the next hop. This locks in the single next hop exit point as the local firewall. It also reduces the risk of asymmetric routing if it learns more specific prefixes from your on-premises environment that might cause the traffic to bypass the firewall. For more information, see [Don’t let your Azure Routes bite you](https://blog.cloudtrooper.net/2020/11/28/dont-let-your-azure-routes-bite-you/).
+As shown in the diagram, it's best to place a UDR in the spoke subnets with a 0/0 route (default gateway) pointing to the local firewall as the next hop. This ensures a single exit point through the local firewall and reduces the risk of asymmetric routing if more specific prefixes from your on-premises environment cause traffic to bypass the firewall. For more information, see [Don’t let your Azure Routes bite you](https://blog.cloudtrooper.net/2020/11/28/dont-let-your-azure-routes-bite-you/).
 
 Here's an example route table for the spoke subnets connected to Hub-01:
 

articles/firewall/fqdn-filtering-network-rules.md

@@ -5,32 +5,32 @@ services: firewall
 author: duongau
 ms.service: azure-firewall
 ms.topic: concept-article
-ms.date: 05/10/2024
+ms.date: 03/17/2025
 ms.author: duau
 ms.custom: engagement-fy23
 ---
 
 # Use FQDN filtering in network rules
 
-A fully qualified domain name (FQDN) represents a domain name of a host or one or more IP addresses. You can use FQDNs in network rules based on DNS resolution in Azure Firewall and Firewall policy. This capability allows you to filter outbound traffic with any TCP/UDP protocol (including NTP, SSH, RDP, and more). You must enable DNS Proxy to use FQDNs in your network rules. For more information, see [Azure Firewall DNS settings](dns-settings.md).
+A fully qualified domain name (FQDN) represents the complete domain name of a host or one or more IP addresses. In Azure Firewall and Firewall policy, you can use FQDNs in network rules based on DNS resolution. This feature allows you to filter outbound traffic using any TCP/UDP protocol, including NTP, SSH, and RDP. To use FQDNs in your network rules, you must enable DNS Proxy. For more information, see [Azure Firewall DNS settings](dns-settings.md).
 
 > [!NOTE]
-> By design, FQDN filtering in network rules doesn’t support wildcards
+> FQDN filtering in network rules doesn't support wildcards by design.
 
 ## How it works
 
-Once you define which DNS server your organization needs (Azure DNS or your own custom DNS), Azure Firewall translates the FQDN to an IP address or addresses based on the selected DNS server. This translation happens for both application and network rule processing.
+First, define the DNS server your organization uses (either Azure DNS or a custom DNS). Azure Firewall then translates the FQDN to an IP address or addresses based on the chosen DNS server. This translation applies to both application and network rule processing.
 
-When a new DNS resolution takes place, new IP addresses are added to firewall rules. Old IP addresses expire in 15 minutes when the DNS server no longer returns them. Azure Firewall rules are updated every 15 seconds from DNS resolution of the FQDNs in network rules.
+When a new DNS resolution occurs, new IP addresses are added to the firewall rules. Old IP addresses expire after 15 minutes if the DNS server no longer returns them. Azure Firewall updates its rules every 15 seconds based on the DNS resolution of the FQDNs in network rules.
 
-### Differences in application rules vs. network rules
+### Differences between application rules and network rules
 
-- FQDN filtering in application rules for HTTP/S and MSSQL is based on an application level transparent proxy and the SNI header. As such, it can discern between two FQDNs that are resolved to the same IP address. This isn't the case with FQDN filtering in network rules. 
+- FQDN filtering in application rules for HTTP/S and MSSQL relies on an application-level transparent proxy and the SNI header. This allows it to differentiate between two FQDNs that resolve to the same IP address. This capability isn't available with FQDN filtering in network rules.
 
-   Always use application rules when possible:
-  - If the protocol is HTTP/S or MSSQL, use application rules for FQDN filtering.
+  Always use application rules when possible:
+  - For HTTP/S or MSSQL protocols, use application rules for FQDN filtering.
   - For services like AzureBackup and HDInsight, use application rules with FQDN tags.
-  - For any other protocols, you can use network rules for FQDN filtering.
+  - For other protocols, use network rules for FQDN filtering.
 
 ## Next steps
 

articles/firewall/index.yml

@@ -10,7 +10,7 @@ metadata:
   ms.topic: landing-page
   author: duongau
   ms.author: duau
-  ms.date: 05/30/2024
+  ms.date: 03/17/2025
   ms.custom: e2e-hybrid
 
 # linkListType: architecture | concept | deploy | download | get-started | how-to-guide | learn | overview | quickstart | reference | tutorial | whats-new