What’s new in Azure Firewall: Recent innovations
Organizations are modernizing their networks while managing a growing mix of applications, protocols, and security requirements. Recent Azure Firewall releases strengthen this journey with simpler traffic routing, expanded protocol support, more flexible application controls, improved health visibility, and higher intrusion-detection performance. This roundup highlights five recent capabilities now available in general availability or public preview. In this update: Explicit proxy, IPv6 support, HTTP header insertion, auto-learn SNAT routes, and IDPS performance improvements. Explicit proxy is now generally available Explicit proxy enables clients and applications to send HTTP and HTTPS traffic directly to Azure Firewall by configuring the firewall as their proxy. Instead of relying only on route-based traffic steering, organizations can use familiar proxy settings to centralize outbound web access through Azure Firewall. This release provides a simpler way to use Azure Firewall as a managed forward proxy. It can help teams consolidate web egress controls, support workloads that natively understand proxy configuration, and transition from traditional proxy appliances without introducing another infrastructure layer. Direct proxy configuration: Configure supported clients and applications to use Azure Firewall for HTTP and HTTPS traffic. Centralized web controls: Apply Azure Firewall policy and application rules to proxied traffic. Operational simplicity: Use a managed Azure service instead of deploying and maintaining separate proxy infrastructure. Migration flexibility: Support environments that already use proxy-aware applications or proxy auto-configuration workflows. For more details, visit - Azure Firewall explicit proxy | Microsoft Learn IPv6 support is now in public preview As address requirements grow and organizations adopt dual-stack architectures, IPv6 support is becoming an important part of cloud network design. Azure Firewall IPv6 support, now in public preview, extends centralized traffic filtering to IPv6 scenarios and helps customers protect applications and networks as they introduce IPv6 connectivity. With this preview, teams can evolve IPv4-only environments toward dual-stack networking while continuing to use Azure Firewall as a central enforcement point. This reduces the need to maintain separate security architectures for IPv4 and IPv6 traffic and provides a more consistent policy and operational model. Secure IPv6 traffic across hybrid environments: Filter east-west and hybrid IPv6 traffic across Azure and on-premises networks. Works seamlessly with IPv6-enabled Azure services: Integrate Azure Firewall into end-to-end IPv6 architectures alongside services like ExpressRoute and Virtual Network. Prepare for the future of networking: Build and secure dual-stack environments today while accelerating your IPv6 adoption journey. For more details, visit -Deploy Azure Firewall in dual stack mode (preview) | Microsoft Learn HTTP header insertion is now generally available HTTP header insertion enables Azure Firewall to add configured headers to HTTP requests that match application rules. This gives security and network teams an additional policy control for communicating trusted context to downstream services without requiring every client or application to add the header itself. The capability can support scenarios where applications use headers to enforce organization-specific access requirements, identify traffic handled by a trusted network path, or apply downstream controls. Because configuration is centralized in Azure Firewall policy, teams can apply the behavior consistently across matching traffic and reduce application-side changes. Tenant restriction enforcement: Organizations can inject tenant restriction headers into traffic destined for Microsoft Entra ID, helping prevent users from authenticating unauthorized tenants and strengthening identity governance controls. Secure egress for AVD and enterprise workloads: Support AVD, VDI, and enterprise egress scenarios where organizations need web traffic to carry approved tenant or context headers. Security and Compliance Enforcement: Administrators can add organization-specific headers to web traffic to support security policies, compliance requirements, and backend validation workflows. This helps ensure that only approved applications, tenants, or services are accessed through corporate environments. Operational Efficiency: Customers no longer need dedicated proxy devices solely for HTTP header injection. Azure Firewall can now perform header insertion natively as part of the application rule, reducing operational complexity and infrastructure costs. For more details, visit - Azure Firewall HTTP Header Insertion Configuration | Microsoft Learn Auto-learn SNAT routes is now generally available Source network address translation behavior depends on whether Azure Firewall treats a destination as private or public. In complex enterprise and hybrid networks, manually maintaining the private address ranges that should not be source-NATed can become time-consuming and error-prone as the environment changes. Auto-learn SNAT routes simplifies this process by dynamically learning relevant routes through Azure Route Server and using them to update the firewall’s private IP range configuration. This helps Azure Firewall preserve original source addresses for traffic destined to learned private networks while reducing ongoing configuration maintenance. Reduce manual SNAT management : Automatically learn private and registered routes through Azure Route Server, eliminating the need to manually maintain large No-SNAT prefix lists. Preserve source IPs across hybrid networks : Automatically apply learned routes as No-SNAT destinations, helping maintain source IP visibility and predictable routing for internal traffic. For more details, visit- Azure Firewall SNAT private IP address ranges | Microsoft Learn IDPS performance improvements are now generally available Azure Firewall Premium includes signature-based intrusion detection and prevention to identify and block malicious network activity. The latest IDPS performance improvements increase the amount of protected traffic that Azure Firewall Premium can process, helping organizations apply advanced inspection to demanding production workloads. Azure Firewall Premium now supports up to 22 Gbps with TLS inspection and IDPS in Deny mode, and up to 600 Mbps for a single TCP connection when IDPS is enabled in Alert or Deny mode. Actual performance depends on traffic characteristics, rule configuration, enabled features, and deployment conditions. Higher aggregate throughput: Protect larger traffic volumes while using advanced inspection capabilities. Improved single-flow performance: Better support applications that rely on high-throughput TCP connections. Strong prevention posture: Use IDPS Deny mode to actively block matching malicious traffic. Premium-scale security: Apply TLS inspection and IDPS to more bandwidth-intensive enterprise workloads For more details, visit - Azure Firewall performance | Microsoft Learn Building an advanced, more capable cloud firewall Together, these releases expand how Azure Firewall can protect modern networks. Explicit proxy and HTTP header insertion provide more flexible application-layer controls; IPv6 support helps customers evolve toward dual-stack architectures; Auto-learn SNAT routes reduces operational overhead in dynamic and hybrid environments; and IDPS performance improvements extend advanced threat prevention to higher-throughput workloads. Explore these capabilities in Azure Firewall and review the applicable Azure documentation for configuration requirements, supported scenarios, regional availability, and preview terms before enabling them in production environments.
ExpressRoute Gateway Microsoft initiated migration
Important: Microsoft initiated Gateway migrations are temporarily paused. You will be notified when migrations resume. Objective The backend migration process is an automated upgrade performed by Microsoft to ensure your ExpressRoute gateways use the Standard IP SKU. This migration enhances gateway reliability and availability while maintaining service continuity. You receive notifications about scheduled maintenance windows and have options to control the migration timeline. For guidance on upgrading Basic SKU public IP addresses for other networking services, see Upgrading Basic to Standard SKU. Important: As of September 30, 2025, Basic SKU public IPs are retired. For more information, see the official announcement. You can initiate the ExpressRoute gateway migration yourself at a time that best suits your business needs, before the Microsoft team performs the migration on your behalf. This gives you control over the migration timing. Please use the ExpressRoute Gateway Migration Tool to migrate your gateway Public IP to Standard SKU. This tool provides a guided workflow in the Azure portal and PowerShell, enabling a smooth migration with minimal service disruption. Backend migration overview The backend migration is scheduled during your preferred maintenance window. During this time, the Microsoft team performs the migration with minimal disruption. You don’t need to take any actions. The process includes the following steps: Deploy new gateway: Azure provisions a second virtual network gateway in the same GatewaySubnet alongside your existing gateway. Microsoft automatically assigns a new Standard SKU public IP address to this gateway. Transfer configuration: The process copies all existing configurations (connections, settings, routes) from the old gateway. Both gateways run in parallel during the transition to minimize downtime. You may experience brief connectivity interruptions may occur. Clean up resources: After migration completes successfully and passes validation, Azure removes the old gateway and its associated connections. The new gateway includes a tag CreatedBy: GatewayMigrationByService to indicate it was created through the automated backend migration Important: To ensure a smooth backend migration, avoid making non-critical changes to your gateway resources or connected circuits during the migration process. If modifications are absolutely required, you can choose (after the Migrate stage complete) to either commit or abort the migration and make your changes. Backend process details This section provides an overview of the Azure portal experience during backend migration for an existing ExpressRoute gateway. It explains what to expect at each stage and what you see in the Azure portal as the migration progresses. To reduce risk and ensure service continuity, the process performs validation checks before and after every phase. The backend migration follows four key stages: Validate: Checks that your gateway and connected resources meet all migration requirements for the Basic to Standard public IP migration. Prepare: Deploys the new gateway with Standard IP SKU alongside your existing gateway. Migrate: Cuts over traffic from the old gateway to the new gateway with a Standard public IP. Commit or abort: Finalizes the public IP SKU migration by removing the old gateway or reverts to the old gateway if needed. These stages mirror the Gateway migration tool process, ensuring consistency across both migration approaches. The Azure resource group RGA serves as a logical container that displays all associated resources as the process updates, creates, or removes them. Before the migration begins, RGA contains the following resources: This image uses an example ExpressRoute gateway named ERGW-A with two connections (Conn-A and LAconn) in the resource group RGA. Portal walkthrough Before the backend migration starts, a banner appears in the Overview blade of the ExpressRoute gateway. It notifies you that the gateway uses the deprecated Basic IP SKU and will undergo backend migration between March 7, 2026, and April 30, 2026: Validate stage Once you start the migration, the banner in your gateway’s Overview page updates to indicate that migration is currently in progress. In this initial stage, all resources are checked to ensure they are in a Passed state. If any prerequisites aren't met, validation fails and the Azure team doesn't proceed with the migration to avoid traffic disruptions. No resources are created or modified in this stage. After the validation phase completes successfully, a notification appears indicating that validation passed and the migration can proceed to the Prepare stage. Prepare stage In this stage, the backend process provisions a new virtual network gateway in the same region and SKU type as the existing gateway. Azure automatically assigns a new public IP address and re-establishes all connections. This preparation step typically takes up to 45 minutes. To indicate that the new gateway is created by migration, the backend mechanism appends _migrate to the original gateway name. During this phase, the existing gateway is locked to prevent configuration changes, but you retain the option to abort the migration, which deletes the newly created gateway and its connections. After the Prepare stage starts, a notification appears showing that new resources are being deployed to the resource group: Deployment status In the resource group RGA, under Settings → Deployments, you can view the status of all newly deployed resources as part of the backend migration process. In the resource group RGA under the Activity Log blade, you can see events related to the Prepare stage. These events are initiated by GatewayRP, which indicates they are part of the backend process: Deployment verification After the Prepare stage completes, you can verify the deployment details in the resource group RGA under Settings > Deployments. This section lists all components created as part of the backend migration workflow. The new gateway ERGW-A_migrate is deployed successfully along with its corresponding connections: Conn-A_migrate and LAconn_migrate. Gateway tag The newly created gateway ERGW-A_migrate includes the tag CreatedBy: GatewayMigrationByService, which indicates it was provisioned by the backend migration process. Migrate stage After the Prepare stage finishes, the backend process starts the Migrate stage. During this stage, the process switches traffic from the existing gateway ERGW-A to the new gateway ERGW-A_migrate. Gateway ERGW-A_migrate: Old gateway (ERGW-A) handles traffic: After the backend team initiates the traffic migration, the process switches traffic from the old gateway to the new gateway. This step can take up to 15 minutes and might cause brief connectivity interruptions. New gateway (ERGW-A_migrate) handles traffic: Commit stage After migration, the Azure team monitors connectivity for 15 days to ensure everything is functioning as expected. The banner automatically updates to indicate completion of migration: During this validation period, you can’t modify resources associated with both the old and new gateways. To resume normal CRUD operations without waiting 15 days, you have two options: Commit: Finalize the migration and unlock resources. Abort: Revert to the old gateway, which deletes the new gateway and its connections. To initiate Commit before the 15-day window ends, type yes and select Commit in the portal. When the commit is initiated from the backend, you will see “Committing migration. The operation may take some time to complete.” The old gateway and its connections are deleted. The event shows as initiated by GatewayRP in the activity logs. After old connections are deleted, the old gateway gets deleted. Finally, the resource group RGA contains only resources only related to the migrated gateway ERGW-A_migrate: The ExpressRoute Gateway migration from Basic to Standard Public IP SKU is now complete. Frequently asked questions How long will Microsoft team wait before committing to the new gateway? The Microsoft team waits around 15 days after migration to allow you time to validate connectivity and ensure all requirements are met. You can commit at any time during this 15-day period. What is the traffic impact during migration? Is there packet loss or routing disruption? Traffic is rerouted seamlessly during migration. Under normal conditions, no packet loss or routing disruption is expected. Brief connectivity interruptions (typically less than 1 minute) might occur during the traffic cutover phase. Can we make any changes to ExpressRoute Gateway deployment during the migration? Avoid making non-critical changes to the deployment (gateway resources, connected circuits, etc.). If modifications are absolutely required, you have the option (after the Migrate stage) to either commit or abort the migration.Azure Firewall explicit proxy is now generally available
We are excited to announce the general availability of explicit proxy in Azure Firewall. This capability brings the familiar explicit proxy configuration model natively to Azure Firewall, enabling applications and browsers to send outbound HTTP and HTTPS traffic directly to the firewall through standard proxy settings. Customers can now gain centralized policy enforcement and visibility while reducing their dependence on self-managed forward proxy appliances. Proxy the traffic you choose—not the entire subnet Traditional route-based steering can require all traffic from a subnet to traverse a firewall. Explicit proxy offers a more targeted model: configure selected applications or browsers to use the Azure Firewall private IP and proxy port, while other traffic continues on its existing route. This application-level control can simplify migrations, reduce unnecessary routing changes, and help teams apply inspection where it matters most. What’s new for general availability A simpler single-port experience: Serve both HTTP and HTTPS destinations through one HTTP explicit proxy endpoint port, reducing client configuration complexity. More secure PAC file access: Retrieve customer-owned proxy auto-configuration files from Azure Blob Storage using a managed identity. PAC files can be up to 256 KB. A streamlined portal workflow: Enable Explicit proxy when creating a Firewall Policy, with added guidance and validation to help prevent common configuration errors. Built for real-world modernization Modernize legacy proxy infrastructure. Use Azure Firewall as the forward proxy endpoint while retaining the explicit proxy model already configured in applications and browsers. This can help organizations consolidate infrastructure and reduce operational overhead associated with self-hosted proxy appliances. Apply selective application-level steering. Direct only the workloads that require centralized inspection through Azure Firewall, without forcing every flow on a subnet through the same path. Secure Azure Arc connectivity in hybrid environments. Organizations using ExpressRoute or VPN can configure Azure Firewall as a forward proxy for Azure Arc-enabled servers, providing an inspected, policy-controlled outbound path to required Azure services without opening direct internet access from corporate networks. How it works Enable explicit proxy in the Azure Firewall Policy and choose the HTTP proxy port used for both HTTP and HTTPS destinations. Configure applications manually with the firewall’s private IP and proxy port or enable proxy auto-configuration. If you use a PAC file, store it in Azure Blob Storage and configure the required managed identity and access permissions. Create an application rule in the Firewall Policy to allow the intended outbound destinations. Get started today Ready to simplify outbound web traffic steering? Explore the Azure Firewall explicit proxy documentation for prerequisites, portal and API configuration steps, PAC file guidance, and supported scenarios. With explicit proxy now generally available, Azure Firewall gives organizations another flexible path to modernize secure egress—combining a familiar proxy model with the simplicity, scale, and centralized management of a cloud-native service.Simplify Virtual WAN Spoke Connectivity at Scale with Azure Virtual Network Manager
With Azure Virtual Network Manager (AVNM) integration, organizations using Virtual WAN for transitive connectivity can simplify spoke connectivity and policy management across large-scale hub-and-spoke deployments. By using a Virtual WAN hub as the hub in an AVNM hub-and-spoke topology, organizations can define connectivity and routing intent once at the network group level and apply it consistently across large numbers of spoke VNets. This reduces repetitive per-spoke connection and routing configuration, helps maintain operational consistency as deployments expand, and makes it easier to manage hub-and-spoke environments at scale. Together, AVNM’s centralized, group-based orchestration and Virtual WAN’s managed routing, security integration, and hybrid connectivity provide a more streamlined way to simplify operations and scale with confidence. What is Azure Virtual Network Manager? Azure Virtual Network Manager is a management service that lets you group, configure, and deploy network connectivity and security policies across virtual networks at scale. Instead of configuring VNet peering and access rules on each virtual network individually, you define network groups — logical collections of virtual networks based on static selection or dynamic Azure Policy conditions — and apply connectivity configurations and security admin rules to those groups. Key capabilities include: Hub-and-spoke and mesh topologies — Define how virtual networks in a network group connect to a central hub or to each other. Network groups — Group VNets statically or dynamically (using tags, subscriptions, resource group names, or other Azure Policy conditions). Security admin rules — Author and enforce access control lists across all VNets in a network group, providing a centralized layer of defense that complements NSGs and firewalls. Region-scoped deployment — Deploy configurations to specific Azure regions, enabling incremental rollout and controlled blast radius. AVNM operates as an overlay management layer — it orchestrates VNet peering, connectivity, and security rules without replacing the underlying networking primitives. What is Azure Virtual WAN? Azure Virtual WAN as a service brings together routing, security, VPN, ExpressRoute, and transitive connectivity in a hub-and-spoke architecture. A Virtual WAN hub is a managed regional resource that acts as a central transit point for branch connectivity, remote users, private enterprise connectivity, spoke virtual networks, and private traffic routing through security services. Site-to-site VPN connectivity (branch offices, SD-WAN devices) Point-to-site VPN connectivity (remote users) ExpressRoute private connectivity (on-premises datacenters) VNet-to-VNet transitive connectivity (spoke virtual networks) Routing, firewall, and encryption for private traffic All hubs in a Standard Virtual WAN are connected in a full mesh over the Microsoft backbone, enabling any-to-any connectivity between spokes, branches, and remote users across regions. Virtual WAN removes the need to manually manage complex route tables and transit VNets — routing is handled by the hub's built-in router. What this integration enables When you select a Virtual WAN hub as the hub in an AVNM connectivity configuration, AVNM handles the spoke-to-hub wiring for you. For each virtual network in your selected network groups: If the VNet is not yet connected to the Virtual WAN hub, AVNM creates the Virtual Network connection to Virtual WAN hub and applies a consistent routing configuration with Virtual WAN connection policy. If the VNet is already connected, AVNM updates the existing Virtual Network connection to utilize the routing properties in the Virtual WAN connection policy. A connection policy is a hub-level Virtual WAN resource that defines shared routing behavior for the virtual network connections it governs, including route table association and propagation, route maps, internet security settings, and propagated labels. Because the policy applies these settings consistently across governed connections, it helps standardize routing and overrides conflicting settings configured directly on individual connections. How it works The setup follows AVNM's standard workflow: Create a network group. Add virtual networks as members — either statically (by selecting specific VNets) or dynamically (using Azure Policy conditions such as tags or resource group names). Create a connectivity configuration. Choose hub-and-spoke topology, select your Virtual WAN hub as the hub, and select or create a connection policy. Deploy. Commit the configuration to your target regions. AVNM connects all VNets in the network groups to the Virtual WAN hub and applies the connection policy in parallel. You can also enable direct connectivity within a spoke network group. When enabled, VNet-to-VNet traffic within that group routes directly between virtual networks instead of transiting the Virtual WAN hub — useful for latency-sensitive or high-throughput east-west workloads. By default, direct connectivity is regional; enable global mesh to extend it across Azure regions. Key use cases Bulk spoke onboarding Connect many virtual networks to a Virtual WAN hub in one operation. All connections are orchestrated in parallel by AVNM, and the pre-defined routing configuration is automatically applied. Policy-based dynamic onboarding Use Azure Policy to define network group membership conditions. When a new virtual network matches those conditions—for example, a VNet tagged env:prod—it is automatically added to the network group. On the next deployment, AVNM connects it to the Virtual WAN hub with the correct routing configuration, reducing manual onboarding effort. Batch routing configuration updates Push routing changes to all virtual networks in a network group as a single, fully parallelized operation. This significantly reduces maintenance window duration for network-wide changes and makes rollback straightforward. Incremental deployment Segment your network into precise update domains by creating separate network groups — for example, by environment (staging, dev, production) or by region. Deploy connection policies to each group or region independently. This lets you test changes on a smaller subset before applying them broadly, minimizing blast radius. Mesh for selective inspection bypass If you use routing intent to send all private traffic through a firewall in the Virtual WAN hub, certain high-throughput or latency-sensitive flows (such as database replication) may benefit from bypassing that inspection. Enable direct connectivity in AVNM to create a mesh between selected spokes, allowing VNet-to-VNet traffic to route directly while all other traffic continues through the hub firewall. Security admin rules at scale Define network groups for your Virtual WAN spokes, then use AVNM security admin rules to author and deploy access control lists across those spokes. This provides an additional layer of defense alongside next-generation firewalls in the Virtual WAN hub. Getting started Prerequisites: An existing Azure Virtual Network Manager instance An existing Azure Virtual WAN and Virtual WAN hub One or more virtual networks to use as spoke members To configure: Go to your Network Manager instance in the Azure portal. Create a network group and add your spoke VNets. Create a connectivity configuration → select hub-and-spoke → select your Virtual WAN hub → select or create a connection policy → add spoke network groups. Deploy the configuration to your target regions. In your Virtual WAN resource, verify that the expected spoke VNet connections are in a connected state. Review effective routes in the virtual hub to confirm routing behavior matches the selected connection policy. For detailed step-by-step instructions, see Configure Azure Virtual WAN hub for Azure Virtual Network Manager. For more on connection policy, see Connection policy in Azure Virtual WAN. Learn more Azure Virtual Network Manager documentation Virtual WAN and Virtual Network Manager integration overview Azure Virtual WAN documentationScale limits in network security perimeter
Presently, network security perimeter functionality can be used to support deployments of PaaS resources with common public network controls with following scale limitations: Limitation Description Number of network security perimeters Supported up to 100 as recommended limit per subscription. Profiles per network security perimeters Supported up to 200 as recommended limit. Number of rule elements per profile Supported up to 200 for inbound and outbound each as hard limit. Number of PaaS resources across subscriptions associated with the same network security perimeter Supported up to 1000 as recommended limit. These limits were deployed as soft limits. The updated limits will be as given in the table below and will now be implemented as hard limits Limitation Description Number of network security perimeters Supported up to 1000 as hard limit per subscription. Profiles per network security perimeters Supported up to 200 as hard limit. Number of rule elements per profile Supported up to 200 for inbound and outbound each as hard limit. Number of PaaS resources across subscriptions associated with the same network security perimeter Supported up to 2500 as hard limit. What do the changes mean to users? Rule elements' creation limit will be capped at 200 for new customers. (presently at 500) Existing customers who have rule elements >200 per profile, will be allowed to continue above 200 with an option to replace/edit, decrease/reduce but not increase/add the current rule elements without any service interruption till 10/31/26. For example, scenario(s): A user has a profile with rule elements = 400 They cannot increase/add new rule elements and try to go above 400. They can replace/edit existing rule elements and continue at 400. They can decrease/reduce rule elements to anything till 200 and that will be their upper ceiling i.e. if they reduce to 250, that will be their new upper ceiling. If they decrease/reduce to <200, say 150, they can go till 200 but not back to the 400. After 10/31/26, profiles with rule elements above 200 will be allowed to continue above 200 but only with an option to reduce. There will be no replace/edit and increase options. For example, scenario(s): A user has a profile with rule elements = 400 They cannot increase/add new rule elements and try to go above 400. They cannot replace/edit existing rule elements but can continue at 400 without touch the rule-elements. They can decrease/reduce rule elements to anything till 200 but cannot stop above 200 or maintain above 200. If they decrease/reduce to <200, say 150, they can go till 200 but not back to the 400. For questions or clarifications, please reach out to nsppmvteam@microsoft.comAzure Firewall explicit proxy Migration Guide
Purpose of the blog This blog outlines the key upcoming changes to Azure Firewall explicit proxy and provides detailed migration guidance for customers using PAC file–based configurations. It also covers the supported deployment options for enabling explicit proxy after the changes are released, including the Azure portal, PowerShell, and Azure CLI. Who is this article for? This article is intended for customers currently using Azure Firewall explicit proxy in preview. If you use PAC file–based proxy configuration, follow the steps below to configure the new PAC file SAS URL retrieval method, which will become the standard approach going forward. Azure Firewall explicit proxy Azure Firewall operates in a transparent proxy mode by default. In this mode, you use a user-defined route (UDR) configuration to send traffic to the firewall. The firewall intercepts that traffic inline and passes it to the destination. When you set up explicit proxy on the outbound path, you can configure a proxy setting on the sending application (such as a web browser) with Azure Firewall configured as the proxy. As a result, traffic from the sending application goes to the firewall's private IP address and therefore egresses directly from the firewall without using a UDR. The Azure Firewall explicit proxy feature is in Preview at the time this article was published. Upcoming changes to the explicit proxy feature in Azure Firewall PAC (Proxy Auto-Configuration) file size is now limited to 256 KB. Support HTTP and HTTPS traffic over a single HTTP proxy port. Removal of the previous dual-port configuration requirement (explicit proxy v1). Ability to enable explicit proxy directly using Firewall Policy creation in the Azure portal. Following general availability (GA), explicit proxy will require both a PAC file SAS URL and Managed Identity (MSI), along with the appropriate role assignments to meet Microsoft security standards. Follow the steps below to migrate to the new PAC file retrieval model that uses customer-managed Azure Storage and Managed Identity authentication. Step 1: Create a PAC File SAS URL Create an Azure Storage container by following the steps in Manage blob containers using the Azure portal - Azure Storage | Microsoft Learn. Note: Use a subscription in which required permissions to add roles exist. Upload the PAC file to the storage container. Select the uploaded file and copy the file URL. Example URL: "https://eproxypstestresources.blob.core.windows.net/explicitproxycontainer/proxy.pac" Step 2: Create a Managed Identity and assign required roles Navigate to Managed Identity blade and create a Managed Identity. See Manage user-assigned managed identities using the Azure portal - Managed identities for Azure resources | Microsoft Learn for more details. Go to the storage account resource created in the previous step and navigate to Access Control (IAM). Select Add to add the role assignment. Go to the Add role assignment page and search for Storage Blob Data Contributor and Storage Blob Data Reader, then select both. Go to Members → Managed Identity and select the identity created earlier. Review the changes and click Assign in Review + Assign blade. Verify that your changes are reflected under Role Assignments by searching for the managed identity. Note: Make sure that the Managed Identity created has prefix "PacFileMSI-". Configuration using portal, PowerShell and Azure CLI Portal configuration After obtaining the PAC file SAS URL and Managed Identity, enable the PAC file in the explicit proxy configuration by: providing the PAC file SAS URL, and selecting the Managed Identity created in the previous steps. PowerShell configuration To securely use explicit proxy, customers must provide: the PAC file SAS URL, and a Managed Identity with the required permissions to access the PAC file from the customer-managed Blob Storage account. Create Firewall Policy with explicit proxy settings: $exProxy = New-AzFirewallPolicyExplicitProxy ` -EnableExplicitProxy ` -HttpPort 100 ` -EnablePacFile ` -PacFilePort 130 ` -PacFile "https://sampleurlfortesting.blob.core.windows.net/container/proxy.pac" Update Firewall Policy with explicit proxy configuration: New-AzFirewallPolicy ` -Name "fp1" ` -ResourceGroupName "TestRg" ` -ExplicitProxy $exProxy ` -UserAssignedIdentityId "/subscriptions/e7eb2257-46e4-4826-94df-153853fea38f/resourcegroups/testrg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/PacFileMSI-eproxyidentity" Azure CLI configuration Create Firewall Policy with explicit proxy settings: az network firewall policy create -g "testrg" -n "testfwpolicy" --sku Premium --explicit-proxy enable-explicit-proxy=true http-port=9001 enable-pac-file=true pac-file-port=122 pac-file="https://eproxypstestresources.blob.core.windows.net/explicitproxycontainer/proxy.pac" --identity "Identity_ID" Update Firewall Policy with Explicit Proxy Configuration: az network firewall policy update -g "testrg" -n "testfwpolicy" --explicit-proxy enable-explicit-proxy=true http-port=9001 enable-pac-file=true pac-file-port=124 pac-file="https://eproxypstestresources.blob.core.windows.net/explicitproxycontainer/proxy.pac" --identity "Identity_ID"Network security perimeter for Azure Service Bus & also now available in Azure Gov. Regions
TL; DR Network security perimeter support for Azure Service Bus is now Generally Available. With this, you can now place your Service Bus namespace inside a central security boundary and apply perimeter-based governance for inbound/outbound network access—while keeping key PaaS-to-PaaS scenarios secure and auditable. Introduction We’re excited to announce that network security perimeter support for Azure Service Bus is now Generally Available (GA). This milestone brings one of Azure’s most widely used messaging services into the network security perimeter ecosystem, enabling customers to define a centralized security boundary across messaging and data services. Alongside this, we are also expanding network security perimeter’s reach — network security perimeter is now available in Azure Government regions, including: Texas Arizona Virginia DoD East DoD Central This ensures that customers operating in regulated, sovereign, and mission-critical environments can adopt network security perimeter while meeting their compliance and regional requirements. Why this matters? Modern applications rely heavily on messaging layers like Service Bus. These systems often connect microservices, data platforms, key management systems and external integrations. As architectures scale, managing network access individually becomes complex and error prone. Network security perimeter changes this by introducing a perimeter-based access model, where: Communication is restricted by default Access must be explicitly allowed Governance is applied consistently across services With Service Bus now onboarded and network security perimeter extending into Azure Gov regions, customers can apply this model across both commercial and sovereign environments. What you can do with Service Bus + network security perimeter Confine communication within a security boundary Service Bus namespaces communicate only with resources inside the perimeter by default—blocking unintended access. Secure PaaS-to-PaaS communication Enable secure interactions between Service Bus, Azure Key Vault (for CMK scenarios) and other network security perimeter-enabled services (What is a network security perimeter? - Azure Private Link | Microsoft Learn) Define explicit access controls Inbound rules → IP ranges and subscriptions Outbound rules → FQDN-based filtering Enable audit and compliance visibility Diagnostic logs capture all access attempts, supporting compliance and investigation workflows. Use Private Link seamlessly Private endpoint traffic continues to work without additional configuration inside the perimeter. Azure Government Availability With this update, network security perimeter is now available in key Azure Government regions (Texas Arizona Virginia DoD East DoD Central), enabling: Consistent security across clouds Apply the same network security perimeter model across public Azure regions and Azure Government environments. Support for regulated workloads Customers in federal, defence, and highly regulated industries can now: Enforce perimeter-based governance Reduce exposure risks Meet compliance requirements Enable secure cross-service patterns in Gov clouds Azure Government boundaries now support scenarios like: CMK with Key Vault Service-to-service messaging Controlled external access More details of onboarded PaaS services are detailed in What is a network security perimeter? - Azure Private Link | Microsoft Learn What’s next Service Bus GA further strengthens network security perimeter’s growing coverage across Azure PaaS services. We will continue to: Expand PaaS service onboarding Improve access rule capabilities (e.g. Service tag-based access, identity-based access)
Metrics Filtering and Log Aggregation Now GA for Advanced Container Networking Services
We are thrilled to announce that Advanced Container Networking Services (ACNS) for Azure Kubernetes Service (AKS) now delivers two powerful observability features in General Availability: container network metrics filtering and container network log filtering and aggregation. Together, these capabilities set a new standard for Kubernetes network observability, giving you high-fidelity visibility at dramatically lower cost and noise. These capabilities fundamentally redefine how network observability works at scale while delivering up to 97% cost reduction. Why this is a Milestone? Most Kubernetes observability solutions face a fundamental tension: collect everything and drown in noise and cost, or sample and miss the signals that matter, with new features of Advanced Container Networking Services that tradeoff has been eliminated. With this release, Azure becomes the first cloud provider to deliver on-node metrics filtering and flow log aggregation for Kubernetes networking, capabilities now also contributed to the upstream Hubble project, making them available to the broader open-source community. For AKS customers running Cilium-based clusters, this means: Every flow you care about is captured. Everything else is dropped at the source. Log volume is compressed by up to 45% through aggregation, without losing security verdicts or error context. Costs scale with what you monitor, not with cluster size. What’s been improved in observability? This release introduces two capabilities that work together: container network metrics filtering and container network log filtering and aggregation. Both are available on AKS clusters with the Cilium data plane and give you precise controls to keep observability costs predictable while maintaining the visibility you need. Container Network Metrics Filtering Container network metrics are generated for all pods by default whenever Advanced Container Networking Services is enabled. With metrics filtering, you now control what gets collected at the point of ingestion, on the node, before anything is scraped or transmitted. A single ContainerNetworkMetric CRD per cluster defines which metric types (dns, flow, tcp, drop), namespaces, pod labels, and protocols to ingest. It supports both include and exclude filters, so you can maintain broad collection while carving out specific workloads or namespaces. Anything that doesn't match is dropped on the node. Changes reconcile in a few seconds, with no Cilium agent or Prometheus restarts required. Container Network Log Filtering and Aggregation Unlike metrics, container network logs are not generated automatically. You start capturing network flows only after applying a ContainerNetworkLog CRD that defines exactly which traffic to capture-by namespace, pod, service, protocol, or verdict. Only matching flows are logged, giving you a precise, targeted view rather than a fire hose. This is where Azure's first-to-market innovation comes in. Flow log aggregation, now built into Advanced Container Networking Services and contributed upstream to Hubble for the open-source community, groups similar flows into summarized records every 30 seconds. The result is dramatically reduced data volume while preserving security verdicts, service identity, and error context. What previously required custom post-processing pipelines is now built directly into the platform before storage costs are incurred. Every matched flow log captures: source and destination pods, namespaces, ports, protocols, traffic direction, and policy verdicts. Logs are stored in a Log Analytics workspace (ContainerNetworkLogs table) with a choice of using the Analytics or Basic tier. Built-in Azure portal dashboards are available for both tiers. Logs can also be exported to external log collectors such as Splunk or Datadog. First to Market: Azure and the upstream Hubble Contribution Advanced Container Networking Services built-in filtering and aggregation capabilities were engineered from the ground up to solve real production observability challenges at scale. Rather than keeping this innovation proprietary, Azure contributed the log aggregation and filtering capabilities to the upstream Hubble project, the observability layer of the Cilium ecosystem. This means: AKS customers get a fully managed, Azure-native experience with portal dashboards, Log Analytics integration, and Grafana visualization, out of the box. The broader open-source community gains access to the same filtering and aggregation primitives through upstream Hubble. Azure is the first to ship this capability in a managed Kubernetes service, and the first to give it back to the community. Key Benefits 💰 Lower observability cost. Metrics filtering drops unwanted data on the node before Prometheus ever scrapes it. Flow log aggregation compresses log data by up to 97% in lab testing. Your cost scales with what you choose to monitor, not with cluster size. 📉 Less noise, more signal. Metrics filtering carves out the namespaces and workloads that matter, so dashboards show only relevant signals. Log filters scope collection to specific pods and verdicts. Engineers start every investigation with data that's already relevant. ⚡ Faster root-cause isolation. Every metric carries source and destination pod context. Targeted flow logs add the forensic detail, which policy, destination, or port is involved. Together, they cut mean time to resolution from hours of guesswork to minutes of structured investigation. 🔒 Full signal, zero gaps. Within the scope you define, every flow is captured and every pattern is preserved. Aggregation compresses volume without losing security verdicts or error context. Who Benefits Platform engineers managing multi-tenant clusters can scope data collection per namespace, so each team gets visibility into their own traffic without contributing to a shared cost pool. SREs can isolate packet drops, TCP resets, or DNS failures to a specific workload in minutes, starting with data that's already scoped to what matters. Decision-makers evaluating observability spend get predictable, controllable ingestion costs that scale with intent, not infrastructure size. How to optimize metrics and logs with filtering? Enable Advanced Container Networking Services ( ACNS) on your AKS cluster with the Cilium data plane: az aks create --enable-acns Or on an existing cluster: az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER --enable-acns Apply a ContainerNetworkMetric CRD to filter which metrics are collected on each node. Start by excluding noisy system namespaces, then scope to business-critical workloads. Apply a ContainerNetworkLog CRD to define which flows to capture. Enable Azure Monitor integration with --enable-container-network-logs to send logs to a Log Analytics workspace, or export logs from the node to an external logging system such as Splunk or Datadog. Check your dashboards. Open your cluster in the Azure portal and go to Monitor > Insights > Networking for bytes, drops, DNS errors, and flows. For flow logs, use the built-in Azure portal dashboards available for both Basic and Analytics tiers. Conclusion Kubernetes network observability has long meant choosing between visibility and cost. With container network metrics filtering and log filtering and aggregation now GA in Advanced Container Networking Services (ACNS) and contributed to upstream Hubble for the open-source community, that tradeoff is gone. Azure is first to market with this capability. AKS customers get it fully managed, out of the box, with built-in dashboards with Log Analytics integration. And the broader Cilium ecosystem gets it through upstream Hubble. High-fidelity visibility. Lower cost. No compromise. Learn more: Container network metrics overview: Container network metrics overview - Azure Kubernetes Service | Microsoft Learn Container network logs overview: Container Network Logs Overview - Azure Kubernetes Service | Microsoft Learn Configure container network metrics filtering: Configure Container network metrics filtering for Azure Kubernetes Service (AKS) - Azure Kubernetes Service | Microsoft Learn Set up container network logs: Set up container network logs - Azure Kubernetes Service | Microsoft Learn
Azure virtual network terminal access point (TAP) public preview announcement
What is virtual network TAP? Virtual network TAP allows customers continuously stream virtual machine network traffic to a network packet collector or analytics tool. Many security and performance monitoring tools rely on packet-level insights that are difficult to access in cloud environments. Virtual network TAP bridges this gap by integrating with our industry partners to offer: Enhanced security and threat detection: Security teams can inspect full packet data in real-time to detect and respond to potential threats. Performance monitoring and troubleshooting: Operations teams can analyze live traffic patterns to identify bottlenecks, troubleshoot latency issues, and optimize application performance. Regulatory compliance: Organizations subject to compliance frameworks such as Health Insurance Portability and Accountability Act (HIPAA), and General Data Protection Regulation (GDPR) can use virtual network TAP to capture network activity for auditing and forensic investigations. Why use virtual network TAP? Unlike traditional packet capture solutions that require deploying additional agents or network appliances, virtual network TAP leverages Azure's native infrastructure to enable seamless traffic mirroring without complex configurations and without impacting the performance of the virtual machine. A key advantage is that mirrored traffic does not count towards virtual machine’s network limits, ensuring complete visibility without compromising application performance. Additionally, virtual network TAP supports all Azure virtual machine SKU. Deploying virtual network TAP The portal is a convenient way to get started with Azure virtual network TAP. However, if you have a lot of Azure resources and want to automate the setup you may want to use a PowerShell, CLI, or REST API. Add a TAP configuration on a network interface that is attached to a virtual machine deployed in your virtual network. The destination is a virtual network IP address in the same virtual network as the monitored network interface or a peered virtual network. The collector solution for virtual network TAP can be deployed behind an Azure Internal Load balancer for high availability. You can use the same virtual network TAP resource to aggregate traffic from multiple network interfaces in the same or different subscriptions. If the monitored network interfaces are in different subscriptions, the subscriptions must be associated to the same Microsoft Entra tenant. Additionally, the monitored network interfaces and the destination endpoint for aggregating the TAP traffic can be in peered virtual networks in the same region. Partnering with industry leaders to enhance network monitoring in Azure To maximize the value of virtual network TAP, we are proud to collaborate with industry-leading security and network visibility partners. Our partners provide deep packet inspection, analytics, threat detection, and monitoring solutions that seamlessly integrate with virtual network TAP: Network packet brokers Partner Product Gigamon GigaVUE Cloud Suite for Azure Keysight CloudLens Security analytics, network/application performance management Partner Product Darktrace Darktrace /NETWORK Netscout Omnis Cyber Intelligence NDR Corelight Corelight Open NDR Platform LinkShadow LinkShadow NDR Fortinet FortiNDR Cloud FortiGate VM cPacket cPacket Cloud Suite TrendMicro Trend Vision One™ Network Security Extrahop RevealX Bitdefender GravityZone Extended Detection and Response for Network eSentire eSentire MDR Vectra Vectra NDR AttackFence AttackFence NDR Arista Networks Arista NDR See our partner blogs: Bitdefender + Microsoft Virtual Network TAP: Deepening Visibility, Strengthening Security Streamline Traffic Mirroring in the Cloud with Azure Virtual Network Terminal Access Point (TAP) and Keysight Visibility | Keysight Blogs eSentire | Unlocking New Possibilities for Network Monitoring and… LinkShadow Unified Identity, Data, and Network Platform Integrated with Microsoft Virtual Network TAP Extrahop and Microsoft Extend Coverage for Azure Workloads Resources | Announcing cPacket Partnership with Azure virtual network terminal access point (TAP) Gain Network Traffic Visibility with FortiGate and Azure virtual network TAP Get started with virtual network TAP To learn more and get started, visit our website. We look forward to seeing how you leverage virtual network TAP to enhance security, performance, and compliance in your cloud environment. Stay tuned for more updates as we continue to refine and expand on our feature set! If you have any questions please reach out to us at azurevnettap@microsoft.com.Announcing Azure DNS security policy with Threat Intelligence feed general availability
Azure DNS security policy with Threat Intelligence feed allows early detection and prevention of security incidents on customer Virtual Networks where known malicious domains sourced by Microsoft’s Security Response Center (MSRC) can be blocked from name resolution. Azure DNS security policy with Threat Intelligence feed is being announced to all customers and will have regional availability in all public regions.
