Azure Networking Blog articles

Pod CIDR Expansion Generally Available and IP Address Planning on Azure CNI Overlay

Sam_Foo — Fri, 05 Jun 2026 00:14:24 GMT

In networking with Azure CNI Overlay, the cluster-wide pod CIDR is logically partitioned into smaller “node” blocks where each node is assigned a fixed CIDR slice (/24) by Azure. This decouples pod networking from the VNet address space entirely because pods receive addresses from a private CIDR that is separate from the VNet.

By default, Azure CNI Overlay uses a pod CIDR of 10.244.0.0/16 which provides 65,536 addresses. Since each node consumes 256 addresses from the /24 slice, the default cluster has a node scaling limit of 65,536 divided by 256, or 256 nodes. Choosing a pod CIDR at cluster creation effectively sets an upper bound on how many nodes the cluster can accommodate.

Pod CIDR	Per-Node Block	Max Nodes Supported
/16	/24	256
/15	/24	512
/14	/24	1,024

What does Pod CIDR Expansion enable?

Even with careful upfront planning, long-lived clusters grow in ways that are difficult to anticipate. For organizations using Azure CNI Overlay, this previous represents a difficult migration without meticulous IP planning.

Pod CIDR expansion allows you to expand the existing CIDR without downtime or node reimaging. Instead of being locked to the range chosen at cluster creation, operators can expand the available pod address space with minimal operational burden.

Choosing a Pod CIDR

In addition to node scaling limits, there are other considerations for pod CIDR planning:

Overlapping pod CIDRs across clusters – even though pod IPs are not directly routable between clusters, overlapping CIDRs can cause problems with observability tooling or cross-cluster networking on top of the overlay. Careful planning can prevent having to recreate the cluster down the road.
Accounting for system node pools – each system node also consumes a /24 block. IP address planning should factor nodes running cluster control plane components in addition to existing workloads.

Learn More

Simplify Virtual WAN Spoke Connectivity at Scale with Azure Virtual Network Manager

Jay-Li — Tue, 26 May 2026 20:44:54 GMT

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

Summarized Gateway Prefixes for Route Advertisement in Azure Virtual Networks

Jay-Li — Wed, 20 May 2026 19:10:30 GMT

Background

Many Azure deployments follow a hub-and-spoke topology: one VNet is designated as the hub and holds the connection to on-premises (via ExpressRoute Gateway, VPN Gateway, or both), and workload VNets — the spokes — peer to the hub to reach on-premises and shared services. This centralizes gateway connectivity so many workloads can share a single ExpressRoute or VPN Gateway.

However, in large hub-and-spoke topologies, ExpressRoute and VPN Gateway limits on advertised prefixes (for example, 1,000 IPv4 and 100 IPv6 prefixes) can be reached. Because each spoke adds its own address prefixes to that count, these limits are approached quickly, constraining how far the topology can scale.

What's New

With Summarized Gateway Prefixes, customers can now advertise a single covering prefix (for example, 10.0.0.0/16) instead of many smaller CIDRs (for example, multiple /24s) – dramatically reducing advertised route count and enabling larger-scale Azure environments.

A new property, summarizedGatewayPrefixes, is now available on the Virtual Network resource in public preview. When configured on a hub VNet, it controls what your ExpressRoute Gateway and VPN Gateway advertise to on-premises, replacing the default behavior of advertising all individual hub and spoke VNet CIDRs with a set of aggregated prefixes you define.

For example, instead of advertising 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on for each spoke, you can advertise a single 10.0.0.0/16.

Key Benefits

Fewer advertised routes — Replace hundreds of individual spoke CIDRs with a small set of summarized prefixes.
Scales with your topology — Supports deployments with 500+ spokes without requiring address plan redesigns or VNet splits.
IPv4 and IPv6 — Summarize both address families.
Works with both gateway types — Supported on ExpressRoute Gateway and VPN Gateway.
Simple configuration — A single property on the VNet resource. No additional services or dependencies.
Backward compatible — If the property is left empty, behavior is unchanged: all hub and peered spoke address spaces are advertised as before.

How It Works

Default behavior

ExpressRoute Gateway and VPN Gateway advertise all address spaces of the hub VNet and all address spaces of peered spoke VNets to on-premises.

With summarizedGatewayPrefixes configured

The gateways advertise the summarized prefixes instead of the hub VNet's individual address spaces.
For each peered spoke, if the spoke's address space falls within a summarized prefix, the spoke's individual CIDRs are suppressed from advertisement.

Spoke address spaces not covered by a summarized prefix continue to be advertised individually.

Example:

Without Summarization	With Summarization
10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, …	10.0.0.0/16
Hundreds of prefixes	One prefix

Getting Started

Open the hub VNet (the VNet containing your GatewaySubnet) in the Azure portal.
Go to Address space → Advertised gateway prefixes.
Add one or more IPv4 or IPv6 CIDR prefixes that cover the address spaces you want to summarize.

Navigate to your virtual network and verify that the summarized prefixes appear.

Things to Know

The property is set on the hub VNet (the VNet with the GatewaySubnet).
The summarized prefixes list can include prefixes outside the VNet's own address space.
Avoid overlap among prefixes within the list, but overlap with peered VNet address spaces is expected in hub-and-spoke designs.
For dual-stack (IPv4 + IPv6) VNets, define both IPv4 and IPv6 summarized prefixes explicitly.

Deploy with Confidence: Using Rule Impact Analyzer in Azure Virtual Network Manager

Jay-Li — Fri, 22 May 2026 06:36:58 GMT

Introduction

In a previous blog post, we described how Azure Virtual Network Manager (AVNM) enables central teams to enforce security admin rules across hundreds of virtual networks—bring consistency and governance to complex enterprise environments.

But enforcement at scale introduces a new challenge: deployment confidence. Security admin rules take priority over NSG rules and can span subscriptions and management groups. That makes them powerful—but a single misconfigured rule can disrupt critical traffic across your entire network. Governance teams need a way to understand the real-world impact of a rule before it reaches production—not after.

This is exactly the problem Azure Virtual Network Manager now solves with the Rule Impact Analyzer—a capability that simulates proposed security admin rules against your real network traffic, so you can see exactly what will change, what won't, and deploy with confidence instead of guesswork.

The Challenge: Understanding Rule Impact Before Deployment

As enterprises scale up their use of security admin rules, a visibility gap emerges. Consider a common scenario: a central governance team needs to block high-risk ports across all production virtual networks. The rules are well-intentioned, but the team has no visibility into which existing traffic flows would be affected. Without a way to preview the impact, teams face an uncomfortable tradeoff—move quickly and risk disruption, or slow down manual review across every affected network.

The Rule Impact Analyzer is designed to close this gap—giving teams with a clear, data-driven view of what a rule of change will do before it reaches production.

What Is the Rule Impact Analyzer?

The Rule Impact Analyzer is a joint capability of Azure Virtual Network Manager and Azure Network Watcher. It lets you simulate proposed security admin rules against traffic data derived from virtual network (VNet) flow logs and Traffic Analytics in your environment.

Instead of relying on manual review, the analyzer evaluates proposed rules against observed traffic and classifies each flow:

Affected — The proposed rule would change the current evaluation outcome for this flow (e.g., traffic that is currently allowed would be blocked).
Not Affected — The flow would continue as-is; the rule does not apply.
Indeterminate — The flow cannot be conclusively evaluated (e.g., insufficient traffic data).

This gives governance teams and network administrators a clear, data-driven view of what a rule of change will do—before it reaches production.

Note: The analysis is based on traffic data available through flow logs and Traffic Analytics. Results reflect recorded traffic patterns; traffic that has not yet been observed will not appear in results.

The Customer Journey: From Rule Authoring to Validated Deployment

The Rule Impact Analyzer fits naturally into the lifecycle of security admin rule management:

This workflow lets teams author rules, simulate impact, review results, and refine policies before committing a single change to production. Teams can cycle through simulation as many times as needed.

Key Capabilities

Predicted Impact Visibility

See briefly how your proposed security admin rules would affect existing traffic flows. Results are based on Traffic Analytics data, helping teams make informed deployment decisions.

Flow-Level Drill-Down

Go beyond summary counts. Inspect specific source and destination paths, see which rule affects each flow, and identify legitimate traffic that would be unintentionally blocked. This makes it easy to pinpoint issues and refine your rules.

Configurable Scope

You don't have to analyze everything at once. Target your analysis to specific:

Rule collections or individual security admin rules
Network groups or specific virtual networks

This lets you focus on the areas that matter most, whether you're validating a single rule change or assessing a broad policy rollout.

Controlled Iteration

Modify your security admin rules, re-run the analysis, and repeat—as many times as you need. Deploy only when the simulated impact matches your intended connectivity outcome.

Inbound and Outbound Evaluation

The analyzer evaluates both inbound and outbound traffic directions, giving you full visibility into the rule's impact across your network.

Real-World Scenario: Locking Down Internet-Exposed Management Ports at Scale

Let’s look at a real-world scenario as an example. Your organization runs hundreds of VNets across multiple subscriptions. Over time, different teams have created NSG rules that allow inbound SSH (port 22) and RDP (port 3389) from broad source ranges — some even from 0.0.0.0/0. Your security team mandates: block all inbound management-port access except from trusted bastion subnets.

The challenge? You can't just flip a switch. Blocking the wrong traffic could be risky, and you want to know the impact of applying the security rules.

With Rule Impact Analyzer, you can:

Define the proposed security admin rule — deny inbound TCP 22/3389 from all sources except your bastion subnet prefix
Simulate before you commit — see exactly which VNets, subnets, and NICs currently have traffic matching the rule, and which existing NSG rules would be overridden
Identify conflicts — spot cases where a team's NSG "Allow" rule would be superseded by your new admin-level "Deny," so you can coordinate before deployment
Deploy with confidence — roll out the rule knowing the blast radius is fully understood, not guessed

Before Rule Impact Analyzer, this required manually auditing NSG rules across every subscription, cross-referencing with resource inventories, and hoping nothing was missed. Now, a single simulation gives you a complete picture in minutes — turning a week-long audit into a self-service workflow.

How It Works: Architecture and Design

Rule Impact Analyzer uses existing Azure networking telemetry and analytics components. It does not require a separate data collection pipeline.

The following diagram provides an interactive version of the architecture:

Step 1: Traffic Analytics as Ground Truth. The analyzer queries your existing VNet flow logs through Traffic Analytics. No new agents, log pipelines, or storage accounts are required.

Step 2: Log Analytics as the Query Engine. Traffic Analytics data resides in your Log Analytics workspace. The Rule Impact Analyzer runs Kusto Query Language (KQL) queries to retrieve the observed flows relevant to your analysis scope.

Step 3: AVNM Rule Evaluation Engine. The retrieved flows are evaluated using AVNM's own enforcement logic—the same priority ordering, allow/deny behavior, and scope resolution used in production. This ensures that what you see in the analyzer matches what would happen when rules are enforced.

Step 4: Results Correlation and Surfacing. Each flow is classified and surfaced in the Azure Portal with drill-down capabilities—from summary impact counts down to individual flow paths and the specific rules affecting them.

What Means for You

Uses existing infrastructure. If you already have Traffic Analytics enabled, there is nothing new to deploy.
No data duplication. Queries run in place within your existing Log Analytics workspace, under your existing RBAC and data retention policies.
Transparent costs. Only standard Log Analytics query costs apply—no hidden charges or separate billing.

Getting Started

You can access Rule Impact Analyzer from two entry points in the Azure Portal:

From Azure Virtual Network Manager: Navigate to your security admin configuration → select a rule collection → launch the Rule Impact Analyzer.
From Azure Network Watcher: Navigate to Monitoring → Traffic Analytics → Rule Analyzer.

Both paths lead to the same analysis experience, so you can start with whichever tool fits your workflow.

Prerequisites

Before using the Rule Impact Analyzer, ensure the following are in place:

VNet flow logs are enabled on the virtual networks you want to analyze.
Traffic Analytics is configured and sends data to a Log Analytics workspace.
You have the necessary RBAC permissions to access the AVNM security admin configuration and the Log Analytics workspace.

Steps

Enable VNet flow logs and Traffic Analytics on your target virtual networks. Learn more about Traffic Analytics.
Author or update your security admin rules in Azure Virtual Network Manager. Learn more about AVNM security admin rules.
Launch the Rule Impact Analyzer from either portal entry point, configure your scope (rule collections, network groups, or specific VNets), and run the analysis.
Review, refine, and deploy. Iterate your rules until the simulated impact matches your intended outcome, then deploy with confidence.

The screenshot below shows the Rule Impact Analyzer in the Azure Portal. After running a simulation, you can see a summary of predicted traffic impact—total paths analyzed, how many are affected or not affected—along with a detailed results table to drill into individual flows and identify which rule impacts each one.

Why It Matters

Outage Prevention

For organizations rolling out network isolation policies at scale, Rule Impact Analyzer acts as a safety net. By simulating rule impact against recorded traffic patterns, teams can catch misconfigurations before they reach production.

Faster Rule Adoption

Without the analyzer, deploying new admin rules often requires lengthy manual review cycles. With self-service impact analysis, governance teams can validate and deploy rules faster—without waiting for manual approval.

Aligning with Behavior

Security policies express intent—what traffic should or shouldn't be allowed. Rule Impact Analyzer validates whether a proposed rule achieves that intent against your observed traffic, closing the loop between policy design and operational behavior.

Conclusion

The AVNM Rule Impact Analyzer closes the gap between policy intent and deployment confidence. Simulating rules against observed traffic—with no additional infrastructure required—governance teams can validate impact before enforcement.

Enforcement without visibility is a risk. Visibility without enforcement is incomplete. This capability brings both together.

We welcome your feedback as you start using this capability. Share your experience through the Azure Portal feedback button or your Microsoft account team.

Learn more:

Authors:

Deepak Bansal, Corporate Vice President and Technical Fellow, Microsoft Azure, Xinyan Zan, Vice President, Ashish Bhargava, Principal Software Development Manager, and Jay Li, Senior Product Manager

Understanding and building an Azure Hybrid Meshed Hub-Spoke Topology

Svenbaeck — Mon, 18 May 2026 07:15:26 GMT

A meshed hybrid hub-spoke topology

Azure offers two main approaches to build network architectures. This article focuses on traditional networking (using VNets, peering, route tables, etc.), rather than Azure Virtual WAN.

Why a hub-spoke topology?

A hub‑spoke topology is the only way to control traffic flows while maintaining scalability, because it enforces a central point of connectivity and policy enforcement:

Centralized traffic control / inspection: All connectivity (to on‑premises, the internet, and between spokes) is anchored through the hub. The hub hosts shared services such as firewalls or NVAs, providing a single control point where traffic is inspected, filtered, and governed consistently.
Avoids uncontrolled lateral communication: Spokes do not connect arbitrarily to each other. All connectivity is routed through the hub, preventing uncontrolled east‑west communication and ensuring traffic follows defined security and routing policies.
Inherent scalability by design: New workloads are added by introducing additional spokes. The core network design remains unchanged, enabling linear scaling without the complexity of full-mesh connectivity.

In summary, the hub‑spoke model provides centralized control combined with scalable, decoupled workload networks—something that flat or full-mesh designs struggle to achieve.

From hub-spoke to meshed multi-region

In a hub‑spoke topology, it’s important to keep in mind that the hub is implemented as an Azure Virtual Network (VNet) and VNets are scoped to a single region. This means that in a multi‑region setup, you’ll always need at least one hub per region. Each of these hubs hosts shared services like firewalls, NVAs, and DNS, acting as the central point for connectivity and traffic control.

Extending dependencies across regions—for example by connecting spokes to a hub in another region—is generally not recommended. It creates tight coupling between regions, which goes against the goal of keeping regions independent. A well-designed multi‑region architecture aims for regional self‑containment to improve resilience and fault isolation. Relying on a remote hub can lead to issues like failure propagation between regions, higher latency for inspected traffic and more complex routing and operations. It can also introduce organizational challenges when different regions are managed by separate teams, reducing agility and increasing operational risk.

For this reason, meshed hub‑spoke architectures should use hubs that are deployed within each region. Connectivity between regions should be established directly between the hubs, not through spokes. In a meshed design, hubs are typically connected in a full‑mesh peering model, allowing for controlled and predictable inter‑region communication while still maintaining regional independence.

Within a single region, it can also make sense to deploy multiple hubs to create isolated environments. This is especially useful when you need to separate workloads based on security requirements, regulatory needs, or organizational boundaries. Each hub can then have its own dedicated set of connectivity and inspection services.

Finally, each spoke VNet connects to just one hub. This keeps routing simple and predictable, ensures that all traffic passes through the correct inspection and policy enforcement layers, and reinforces the hub’s role as the central control point for network traffic within the region.

Integrating hybrid connectivity

In most enterprise scenarios, Azure doesn’t operate in isolation—it needs to connect to external networks such as on‑premises datacenters or other cloud environments. This hybrid connectivity is typically set up using services like Azure ExpressRoute, Azure VPN Gateway or third‑party SD‑WAN solutions. In a (meshed) hub‑spoke topology, these connectivity components are best deployed in the hub VNet, since the hub acts as the central point where all inbound and outbound traffic comes together.

By centralizing external connectivity in the hub, all traffic—whether entering or leaving Azure—can be routed, inspected and governed in a consistent way using shared services like firewalls or NVAs. It also avoids the need to duplicate gateways and connectivity components across multiple spokes, which helps reduce cost and operational overhead.

This approach also simplifies routing and policy management. Spokes can rely on the hub’s shared connectivity instead of maintaining their own connections to external networks. Overall, this reinforces the hub’s role as the single, controlled integration point between Azure and the broader network landscape.

Implementation fundamentals

With the overall architecture in place, the next step is to understand how Azure actually handles routing and traffic control in this kind of design.

When working with a hub‑spoke topology in Azure, it’s important to realize that a virtual network (VNet) doesn’t behave like a traditional router. While you can associate Azure Route Tables with subnets, those routes only apply to traffic originating from within that subnet. Traffic entering the VNet from outside isn’t automatically re‑routed. This is also why VNet peering is non‑transitive by design: peered VNets can communicate directly, but they won’t forward traffic for other networks.

To enable controlled routing between spokes—and between Azure and external networks such as ExpressRoute or VPN—you need a component in the hub that can actively receive and forward traffic. In most cases, this is handled by an Azure Firewall or a network virtual appliance (NVA) deployed in the hub. These components act as an explicit routing hop: they receive traffic, inspect or process it based on defined policies and then send it back into the virtual network so Azure’s routing engine can continue forwarding it.

In a secure hub‑spoke design, the firewall plays a dual role. It not only provides centralized traffic inspection and enforces security policies, but also acts as the mechanism that enables transitive communication between spokes and external networks. This combination of control and connectivity is a key part of the architecture. Of course, this only works as intended if the firewall is configured with the right rules to allow or block traffic according to your security requirements.

While it’s technically possible to implement routing using a basic virtual machine or even a Virtual Network Gateway, these approaches don’t meet typical enterprise requirements. They lack built‑in capabilities like advanced traffic inspection, high availability, autoscaling and centralized policy management. Purpose‑built solutions such as Azure Firewall or mature third‑party NVAs are designed to provide not just routing, but also integrated security, consistency, and scalability. For that reason, they’re generally the only realistic choice for production‑grade hub‑spoke environments where both control and resilience matter.

Design principles for building the topology

The diagram below shows the topology for a hybrid meshed hub-spoke, with 2 hubs and an Azure Firewall (any other 3rd party Firewall could be used as well).

Ensuring correct connectivity in a hub-and-spoke topology may initially appear complex, but in practice it comes down to understanding and correctly applying four key design principles:

controlled routing in the GatewaySubnet
controlled routing in each spoke
proper peering of spokes to the hub
meshing the hubs.

Before looking at these in detail, it is important to understand a fundamental behavior of Azure Virtual Network (VNet) peering. When two VNets are peered, Azure automatically exchanges their address spaces (CIDR ranges) and injects these prefixes as system routes into the effective route tables of all subnets. As a result, resources in one VNet can communicate directly with resources in the other using private IP addressing, without any additional routing configuration. This built-in route propagation is what makes VNet peering an efficient and low-latency connectivity mechanism in Azure.

However, this default behavior is not always aligned with the requirements of a hub-and-spoke topology. In this model, network services such as firewalls, inspection and routing control are typically centralized in the hub VNet. If communication between spokes is allowed to follow the automatically injected system routes, traffic could bypass these centralized controls, which would undermine design objectives such as inspection, segmentation and governance.

For this reason, although VNet peering provides seamless connectivity by default, additional configuration is required in a hub-and-spoke architecture. This is usually achieved through Azure Route Tables, network virtual appliances (NVAs) or Azure Firewall, ensuring that traffic between spokes is routed through the hub as intended. This approach enables a controlled routing model that is essential for maintaining security and architectural consistency in enterprise-scale Azure environments.

Design principle 1: Controlled routing in the GatewaySubnet

In hybrid connectivity scenarios, traffic originating from on-premises environments over VPN or ExpressRoute is first terminated by the Azure Virtual Network Gateway. From there, the traffic is injected into the Azure network using the routing context of the GatewaySubnet. By default, this process relies on system routes that are automatically populated through VNet peering. As a result, when the destination resides in a spoke VNet, the traffic is forwarded directly to that spoke, since its address space has already been learned and installed as a system route. While this behavior is efficient, it also means that traffic will bypass centralized security controls in the hub, such as Azure Firewall.

To ensure that all incoming traffic is properly inspected, this default routing behavior needs to be adjusted. This is done by associating a custom Azure Route Table with the GatewaySubnet and defining user-defined routes for each spoke address range. These routes should point to the private IP address of the firewall as the next hop, effectively overriding the system routes created by VNet peering. Because Azure gives precedence to user-defined routes over system routes, traffic that would normally go directly to the spoke is instead redirected through the firewall before reaching its destination.

It is important that these user-defined routes precisely match the CIDR ranges defined for the spoke VNets! Any mismatch, such as using broader or more specific prefixes, can lead to unexpected routing behavior and may introduce issues such as asymmetric traffic flows or packet loss. For instance, if a spoke uses address spaces like 10.10.10.0/24 and 192.168.10.0/24, these exact prefixes must be reflected in the route table. Only by aligning the custom routes with the advertised address ranges can you ensure predictable routing and consistent inspection through the firewall.

If the hub VNet hosts additional resources beyond an Azure Firewall or third-party network virtual appliance that also require traffic inspection, the corresponding CIDR ranges—either for the specific subnets or for the entire hub VNet—should be included as routes in the route table associated with the GatewaySubnet. These routes should be configured in the same way as those for spoke VNets, ensuring that traffic destined for these resources is directed through the intended inspection point. A typical example is Azure DNS Private Resolver, which can include both inbound and outbound endpoints deployed in dedicated subnets. When such endpoints are present in the hub, their associated subnet address ranges must also be added to the route table for the GatewaySubnet. This ensures that traffic to and from these endpoints is routed through the designated inspection path, maintaining consistent enforcement of security controls.

Design principle 2: Controlled routing in every spoke

In a hub-and-spoke architecture, traffic flows should follow the intended security model. Workloads within the same spoke VNet are usually treated as part of the same trust boundary, so traffic between resources in that spoke can flow directly over the Azure backbone without needing to pass through centralized controls. Network Security Groups (NSGs) should still be used at the subnet level to provide granular, stateful filtering, but routing this traffic through a central firewall is typically not required.

The situation changes when traffic leaves the local VNet. As soon as traffic is destined for another spoke, the hub, or on-premises networks, it crosses a trust boundary and needs to be inspected centrally. To enforce this, Azure’s default routing behavior must be overridden by associating an Azure Route Table with each subnet in the spoke VNets.

In most cases, this route table can be kept simple by defining a single default route that sends all outbound, non-local traffic to the firewall in the hub:

Destination: 0.0.0.0/0
Next hop: Private IP address of the hub firewall (Virtual Appliance)

With this configuration in place, all traffic that is not local to the spoke is forced through the hub, ensuring that communication between VNets and towards external networks is inspected and controlled.

From a management perspective, the same route table can often be reused across multiple subnets or even multiple VNets within the same subscription, which helps keep the design consistent and easy to maintain. It’s worth noting, however, that Azure requires route tables and the subnets they’re associated with to be in the same subscription, as this association is enforced by the platform.

There is one additional setting that is often overlooked but plays an important role in getting routing right in a hub-and-spoke design. Azure route tables include an option called “Propagate gateway routes”, which controls whether routes learned by a Virtual Network Gateway are added to the effective routes of the associated subnets. By default, routes learned via BGP (for example from ExpressRoute or VPN) or defined through a Local Network Gateway are propagated not only within the hub VNet, but also across VNet peerings. This means that spoke VNets can automatically learn routes to on-premises or external networks and may send traffic directly to the gateway, bypassing the firewall in the hub.

To avoid this and keep traffic flowing through the centralized security controls, this setting should be disabled on the route tables used by the spoke subnets. When “Propagate gateway routes” is set to No, routes learned by the gateway are no longer injected into the spokes. As a result, traffic to those destinations cannot take a direct path and instead follows the user-defined default route (0.0.0.0/0) toward the hub firewall, where it can be properly inspected.

When combined with the default route to the firewall, this setup ensures that traffic—whether it is going to other VNets, on-premises environments, or external networks—always follows a controlled and predictable path through the hub. This helps maintain consistent security enforcement and avoids unexpected routing behavior in larger or hybrid deployments.

Design principle 3: Peering the spokes to the hub

Virtual Network (VNet) peering in Azure is often seen as a simple, single configuration, but in reality it is directional by design. To fully connect two VNets, you need two separate peering configurations—one in each direction—and both must be configured correctly to ensure not only connectivity, but also proper routing behavior. Each peering exposes four key settings and getting these right is especially important in a hub-and-spoke architecture.

For basic connectivity, the first two settings—“allow virtual network access” and “allow forwarded traffic”—should be enabled on both peerings. These ensure that traffic can flow between VNets and support scenarios where traffic is routed through a central component, such as a firewall in the hub. The other two settings depend on the direction of the peering. In a typical hub-and-spoke setup, the Virtual Network Gateway (or Azure Route Server) is deployed in the hub. This means the peering from the spoke to the hub must enable “use remote gateways”, while the peering from the hub to the spoke must enable “allow gateway transit.”

At first, this might seem to contradict the idea that spokes should not directly use the gateway. However, these settings influence control plane behavior and don't enable unrestricted traffic flow. They are required so the gateway can learn and advertise spoke address ranges via BGP to external networks, such as those connected over VPN or ExpressRoute. Whether those routes are actually used in the spokes is still controlled through the “propagate gateway routes” setting on the route tables, allowing you to enforce routing through the firewall as intended.

Even if you are not currently using BGP—for example, in environments relying on static routing—it is still a good practice to configure peerings this way. Doing so makes the design future-proof, allowing you to introduce dynamic routing later without changes to the peering model. This approach keeps the architecture consistent and avoids unnecessary rework as the environment evolves.

Design principle 4: Meshing the hubs

When you extend a hub-and-spoke design across multiple regions, you typically introduce multiple hubs, each managing its own regional spokes. In this setup, it becomes important to connect the hubs to each other, which is done by fully meshing the hub VNets using VNet peering. At the same time, a key principle remains unchanged: each spoke should connect to only one hub in the same region. This keeps the architecture simple, scalable and easier to reason about from a routing perspective.

When configuring connectivity between hubs, it’s important to note that VNet peering settings differ from the typical hub–spoke configuration. For inter-hub peerings, only “allow virtual network access” and “allow forwarded traffic” should be enabled. The remaining options—“allow gateway transit” and “use remote gateways”—should be left disabled, as gateway sharing is not required between hubs and would even be blocked in the configuration.

Just connecting the hubs with peering is not enough to guarantee correct traffic flow. To ensure traffic moves between regions in a controlled and secure way, you need additional routing logic. Each hub should have an Azure Route Table assigned to its FirewallSubnet (or the subnet hosting the 3rd party NVAs) defining how traffic towards other hub-and-spoke environments is handled. This ensures that inter-region traffic is always routed through the appropriate hub firewall, instead of flowing directly across the Azure backbone.

At this point, IP address planning becomes critical. Without a clear addressing strategy, routing quickly becomes complex and hard to maintain. A common best practice is to assign a single “master” CIDR range per region, and then allocate all VNets in that region—both hub and spokes—from that range. This creates a clean, hierarchical addressing model that simplifies routing decisions.

With this approach in place, route tables can remain relatively simple. Instead of adding routes for every individual spoke, you only need one route per remote region. The destination is the master CIDR range of that region and the next hop is the private IP of the firewall in the corresponding hub. Because all hubs are peered with each other, these address ranges and firewall endpoints are automatically known through peering, allowing for consistent and predictable routing.

Overall, this design keeps routing logic straightforward while ensuring that all inter-region traffic is inspected in the correct hub, preserving the security model and making it easy to scale as new regions are added.

Conclusion

When the four design principles described in this article are applied consistently, a hub-and-spoke architecture becomes a strong, scalable and easy-to-operate foundation for your network. By combining controlled routing, centralized inspection and clear traffic flows, the model delivers both solid security and predictable behavior, even in complex environments.

More importantly, the concepts covered here go beyond just one specific design. They represent the key building blocks of Azure networking, including routing, peering and traffic control. Understanding these fundamentals not only helps you implement hub-and-spoke topologies correctly, but also gives you a solid base for designing and running reliable, enterprise-grade network architectures in Azure.

To make this easier to apply in practice, the table below summarizes the main concepts from this article and how they translate into actual configuration. It can be useful both when setting up a hub-and-spoke topology and when troubleshooting existing environments.

Area	Configuration	Key Setting / Value	Purpose
Hub VNet	Deploy shared services	Azure Firewall or NVA in hub	Central inspection + routing
	Deploy connectivity	VPN Gateway / ExpressRoute in hub	Centralize hybrid connectivity
GatewaySubnet	Associate Route Table	UDRs for each spoke CIDR → Firewall IP	Force inbound traffic through firewall
Spoke Subnets	Associate Route Table	0.0.0.0/0 → Firewall (Virtual Appliance)	Force all outbound traffic via hub
	Route Table setting	Propagate gateway routes = Disabled	Prevent bypass of firewall via gateway
VNet Peering (Spoke → Hub)	Setting	Allow VNet access = Yes	Basic connectivity
	Setting	Allow forwarded traffic = Yes	Support transitive routing via firewall
	Setting	Allow gateway transit = Yes	Allow spoke to leverage hub gateway
	Setting	Use remote gateways = No	-
VNet Peering (Hub → Spoke)	Setting	Allow VNet access = Yes	Basic connectivity
	Setting	Allow forwarded traffic = Yes	Support routing through firewall
	Setting	Allow gateway transit = No	-
	Setting	Use remote gateways = Yes	Advertise spoke prefixes via hub gateway
VNet Peering (Hub→ Hub)	Setting	Allow VNet access = Yes	Basic connectivity
	Setting	Allow forwarded traffic = Yes	Support transitive routing via firewall
	Setting	Allow gateway transit = No	-
	Setting	Use remote gateways = No	-
Hub FirewallSubnet	Associate Route Table	Route remote region CIDR → remote hub firewall IP	Ensure inter-region/hub routing
Addressing strategy	CIDR planning	Assign master CIDR per region	Simplify routing and reduce UDR complexity
Spoke design rule	Peering constraint	Each spoke connected to one hub only	Prevent routing ambiguity

Metrics Filtering and Log Aggregation Now GA for Advanced Container Networking Services

chandanAggarwal — Tue, 19 May 2026 18:13:31 GMT

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

Private subnets by default in Azure Virtual Networks: What changed and how to use NAT Gateway

aimeelittleton — Wed, 22 Apr 2026 19:09:37 GMT

Azure is evolving to better support secure‑by‑default cloud architectures.

Starting with API version 2025‑07‑01 (released after March 31, 2026), newly created virtual networks now default to using private subnets. This change removes the long‑standing platform behavior of automatically enabling outbound internet access through implicit public IPs, also known as default outbound access (DOA).

As a result: newly deployed virtual machines will not have public outbound connectivity unless explicitly configured.

What changed?

Previously, Azure automatically assigned a hidden Microsoft‑owned public IP to virtual machines deployed without an explicit outbound method (such as NAT Gateway, Load Balancer outbound rules, or instance‑level public IPs). This allowed public outbound connectivity without requiring customer configuration.

While convenient, this model introduced challenges:

Security – Implicit internet access conflicts with Zero Trust principles.

Reliability – Platform‑managed outbound IPs can change unexpectedly.

Operational consistency – VMSS instances or multi‑NIC VMs may egress using different default outbound IPs.

With API version 2025‑07‑01 and later:

Subnets in newly created VNets are private by default.

The subnet property `defaultOutboundAccess` is set to false.

Azure no longer assigns implicit outbound public IPs.

This applies across deployment methods including Portal, ARM/Bicep, CLI, and PowerShell. Portal has started using the new model as of April 1, 2026.

Note: This change has not yet applied to Terraform.

Am I impacted by this change?

Deployment scenario	Behavior
Existing VNets or VMs using DOA	✅ Unchanged
New VMs in existing VNets	✅ Unchanged
Subnets already using explicit outbound	✅ Continue using configured outbound method
New VMs in new VNets (with subnets created using API 07-01-2025 or later)	🔒 Subnets private by default
New VMs in private subnets without explicit outbound configured	❌ No public outbound connectivity

Existing workloads are not impacted.

If required, you can still create new subnets without the private setting by choosing the appropriate configuration option during creation. See the FAQ section of this blog for more information. However, we strongly recommend transitioning to an explicit outbound method so that:

Your workloads won’t be affected by public IP address changes.

You have greater control over how your VMs connect to public endpoints.

Your VMs use traceable IP resources that you own.

When is outbound connectivity required?

If your virtual network contains virtual machines, you must configure explicit outbound connectivity. Here are common scenarios that require it:

Virtual machine operating system activation and updates, such as Windows or Linux.

Pulling container images from public registries (Docker Hub or Microsoft Container Registry).

Accessing 3rd party SaaS or public APIs

Virtual machine scale sets using flexible orchestration mode are always secure by default and therefore require an explicit outbound method.

Private subnets don’t apply to delegated or managed subnets that host PaaS services. In these cases, the service handles outbound connectivity—see the service-specific documentation for details.

Recommended outbound connectivity method: StandardV2 NAT Gateway

Azure now recommends using an explicit outbound connectivity method such as:

NAT Gateway

Load Balancer outbound rules

Public IP assigned to the VM

Network Virtual Appliance (NVA) / Firewall

Among these, Azure StandardV2 NAT Gateway is the recommended method for outbound connectivity for scalable and resilient outbound connectivity.

StandardV2 NAT Gateway:

Provides zone‑redundancy by default in supported regions

Supports up to 100 Gbps throughput

Provides dual-stack support with IPv4 and IPv6 public IPs

Uses customer‑owned static public IPs

Enables outbound connectivity without allowing inbound internet access

Requires no route table configuration when associated to a subnet

When configured, NAT Gateway automatically becomes the subnet’s default outbound path and takes precedence over:

Load Balancer outbound rules
VM instance‑level public IPs

Note: UDRs for 0.0.0.0/0 traffic directed to virtual appliances/Firewall takes precedence over NAT gateway.

Flow chart showing priority order for different outbound methods

Migrate from Default Outbound Access to NAT Gateway

To transition from DOA to Azure’s recommended method of outbound, StandardV2 NAT Gateway:

Go to your virtual network in the portal, and select the subnet you want to modify.
In the Edit subnet menu, select the ‘Enable private subnet’ checkbox under the Private subnet section

Enabling private subnet can also be done through other supported clients, below is an example for CLI, in which the default-outbound parameter is set to false:

az network vnet subnet update \ --resource-group rgname \ --name subnetname \ --vnet-name vnetname \ --default-outbound false

3. Deploy a StandardV2 NAT gateway resource.

4. Associate one or more StandardV2 public IP addresses or prefixes.

5. Attach the NAT gateway to the target subnet.

Once associated:

All new outbound traffic from that subnet uses NAT Gateway automatically

VM‑level public IPs are no longer required

Existing outbound connections are not interrupted

Note: Enabling private subnet on an existing subnet will not affect any VMs already using default outbound IPs. Private subnet ensures that only new VMs don’t receive a default outbound public IP.

For step-by-step guidance, see migrate default outbound access to NAT Gateway.

FAQ

1. Will my existing workloads lose outbound connectivity?

No. Workloads currently using default outbound IPs are not impacted by this change. The private subnet by default update only affects:

Newly created VNets

New subnets created using the updated API, 2025-07-01

New virtual machines deployed into those subnets using the updated API

VMs and subnets using an explicit outbound connectivity method like a NAT gateway, NVA / Firewall, a VM instance level public IP or Load balancer outbound rules is not impacted by this change.

2. Why can’t my new VM reach the internet or other public endpoints within Microsoft (e.g. VM activation, updates)?

New subnets are private by default. If your deployment does not include an explicit outbound method — such as a NAT Gateway, Public IP, Load Balancer outbound rule, or NVA/Firewall— outbound connectivity is not automatically enabled.

3. My workload has a dependency on default outbound IPs and isn’t ready to move to private subnets, what should I do?

You can opt-out of the default private subnet setting by disabling the private subnet feature. You can do this in the portal by unselecting the private subnet checkbox:

Disabling private subnet can also be done through other supported clients, below is an example for CLI, in which the default-outbound parameter is set to true:

az network vnet subnet update \ --resource-group rgname \ --name subnetname \ --vnet-name vnetname \ --default-outbound true

4. Why do I see an alert showing that I have a default outbound IP on my VM?

There's a NIC-level parameter `defaultOutboundConnectivityEnabled` that tracks whether a default outbound IP is allocated to a VM/Virtual Machine Scale Set instance. If detected, the Azure portal displays a notification banner and will generate Azure Advisor recommendations about disabling default outbound connectivity for your VMs / VMSS.

5. How do I clear this alert?

To remove the default outbound IP and clear the alert:

Configure a StandardV2 NAT gateway (or other explicit outbound method).
Set your subnet to be private or by setting the subnet property defaultOutboundAccess = false using one of the supported clients.
Stop and deallocate any applicable virtual machines (this will remove the default outbound IP currently associated with the VM).

6. I have a NAT gateway (or UDR pointing to an NVA) configured for my private subnet, why do I still see this alert?

In some cases, a default outbound IP is still assigned to virtual machines in a non-private subnet, even when an explicit outbound method—such as a NAT gateway or a UDR directing traffic to an NVA/firewall—is configured.

This does not mean that the default outbound IP is used for egress traffic.

To fully remove the assignment (and clear the alert):

Set the subnet to private

Stop and deallocate the affected virtual machines

Summary

The move to private subnets by default improves the security posture of Azure networking deployments by removing implicit outbound internet access.

Customers deploying new workloads must now explicitly configure outbound connectivity.
StandardV2 NAT Gateway provides a scalable, resilient method for enabling outbound internet access without exposing workloads to inbound connections or relying on platform‑managed IPs.

Learn more

Default Outbound Access

StandardV2 NAT Gateway

Migrate Default Outbound Access to StandardV2 NAT Gateway

Azure VNet Data Gateway for Secure Power BI & Power Platform Access in Enterprises

kirankumar_manchiwar04 — Wed, 22 Apr 2026 16:30:19 GMT

What Is a VNet data gateway?

The VNet data gateway is a Microsoft‑managed gateway service that runs inside a delegated subnet of an Azure Virtual Network. It allows supported Microsoft cloud services—such as Power BI, Power Platform dataflows, and Microsoft Fabric workloads—to securely connect to data sources that are protected using private networking.

Key characteristics:

No customer‑managed VM or container

No OS, patching, or gateway software upgrades

Gateway lifecycle fully managed by Microsoft

Traffic stays on the Azure backbone network

Works seamlessly with Private Endpoints

This makes it ideal for enterprise and regulated environments where security and operational efficiency are equally important.

Why Enterprises need VNet data gateway

Eliminates gateway infrastructure management

Traditional gateways require:

Virtual machines

High availability setup

OS patching and scaling

Monitoring and troubleshooting

With the VNet data gateway:

Microsoft manages compute lifecycle

No VM or gateway software to maintain

No HA or load balancer design needed

✅ Result: Significant reduction in operational and maintenance overhead for platform and infrastructure teams.

Secure access to private Azure resources

Most enterprise Azure environments use:

Private Endpoints

NSGs and route tables

Firewalls blocking public access

The VNet data gateway:

Is injected into a delegated subnet in your VNet

Uses private IP addressing

Enforces NSG and UDR rules

Communicates with Microsoft services over a Microsoft‑managed internal tunnel

✅ Result: Data sources remain fully private—no public endpoints or inbound ports required.

Designed for Power Platform & Power BI at Scale

The gateway supports secure access for:

Power BI semantic models

Power BI paginated reports

Microsoft Fabric Dataflow Gen2

Fabric pipelines and copy jobs

Because it’s cloud‑native and centrally managed, the VNet data gateway scales well in large enterprises standardizing on Power Platform and Fabric.

High‑level architecture overview

At runtime, the VNet data gateway works as follows:

A query is initiated from Power BI / Power Platform
Query details and credentials are sent to the Microsoft Power Platform VNet service
A containerized gateway instance is injected into the delegated subnet
The gateway connects to the private data source using private networking
Results are sent back to Power BI or Power Platform via a Microsoft‑managed internal tunnel

Key security highlights:

No inbound connectivity

No public IP exposure

Traffic remains on Azure backbone

Full enforcement of NSGs and routing rules

Key Enterprise benefits

Least management overhead – no gateway servers

Zero Trust aligned – private-only connectivity

Fully managed by Microsoft

Enterprise-grade security & governance

Works with Azure Private Endpoint architectures

When to Use VNet Data Gateway

Scenario	Recommendation
Azure private PaaS services	✅ VNet data gateway
Private Endpoint–only access	✅ VNet data gateway
Zero Trust network model	✅ VNet data gateway
Minimal ops & maintenance	✅ VNet data gateway
On‑prem only, no Azure	❌ Traditional gateway

Step‑by‑step configuration: VNet data gateway (Enterprise setup)

High‑level flow (What you will configure)

Register required Azure resource provider
Prepare Azure Virtual Network and subnet
Configure private connectivity to data source
Create the VNet data gateway
Create and bind data source connections
Validate with Power BI / Power Platform workloads

Step 1: Register Microsoft.PowerPlatform resource provider

Why this step is required

The VNet data gateway is a Microsoft‑managed service that is injected into your Azure VNet. Azure must explicitly allow Power Platform to deploy managed infrastructure into your subscription.

Configuration steps

Sign in to Azure portal
Navigate to Subscriptions
Select the subscription that hosts the target VNet
Go to Resource providers
Search for Microsoft.PowerPlatform
Click Register

✅ Status must show Registered

This step enables subnet delegation to Power Platform services.

Step 2: Prepare the Azure Virtual Network

Why this step is required

The gateway runs inside your VNet. It must be placed in a dedicated, delegated subnet to maintain isolation and security boundaries.

Requirements

VNet can be in any Azure region

Subnet must be exclusive to VNet data gateway

Subnet must have outbound connectivity to the data source

Configuration steps

Go to Azure portal → virtual networks
Select your existing VNet (or create one)
Navigate to Subnets → + Subnet
Configure:
- Subnet name: snet-vnet-datagateway
- Address range: /27 or larger (recommended)

- Subnet delegation:
  Microsoft.PowerPlatform/vnetaccesslinks
- Save the subnet

⚠️ Do not place any VMs, app gateway, or other workloads in this subnet.

Step 3: Configure private connectivity to the data source

Why this step is required

Enterprises typically block public access to PaaS services. The VNet data gateway is designed to work natively with private endpoints.

Example: Azure SQL / SQL Managed Instance

Create Private Endpoint for the data service
Attach it to the same VNet (can be different subnet)
Create or link a Private DNS Zone, for example:
privatelink.database.windows.net
Link the Private DNS Zone to the VNet
Ensure DNS resolution from the delegated subnet resolves to private IP

✅ This ensures all traffic remains private and internal.

Step 4: Create the VNet data gateway

Why this step is required

This is where the actual Microsoft‑managed gateway is logically created and associated with your VNet.

Configuration steps

You can do this from either Power BI Service or Power Platform Admin Center.

Using Power Platform Admin Center

Go to https://admin.powerplatform.microsoft.com

Select Data → Gateways

Click + New → Virtual network data gateway

Provide:

- Gateway name

- Azure subscription

- Resource group

- Virtual network

- Delegated subnet

1. Click Create

📌 Notes:

Gateway metadata is stored in Power BI tenant home region

Gateway runtime executes in the VNet region

No VM or scale settings are required

Step 5: Create and configure data source connections

Why this step is required

The gateway exists, but Power BI / Power Platform must know which data sources can be accessed via it.

Configuration steps (Power BI example)

Go to Power BI Service

- Navigate to Settings → Manage connections and gateways

- Select the newly created VNet data gateway

- Click + New connection

- Provide:

- - Data source type (Azure SQL, Storage, Databricks, etc.)

- - Server / endpoint name (private DNS name)

- - Authentication (SQL / Entra ID)
Save the connection
Assign users or security groups

✅ This step enables governance and access control.

Step 6: Use the gateway in Power BI / Power Platform

Power BI

Open dataset or semantic model settings
Under Gateway connection, select:
Use a data gateway

Choose the VNet data gateway
Apply changes
Refresh or run queries

Power Platform / Fabric

Select the same connection when configuring:

Dataflows Gen2

Fabric pipelines

Copy jobs

Step 7: Validate and test

Validation Checklist

✅ DNS resolves to private IP
✅ No public endpoint access enabled
✅ NSGs allow outbound traffic to data source
✅ Dataset refresh succeeds
✅ No gateway VM exists in subscription

Optional:

Enable logging and auditing from Power BI / Fabric

Monitor gateway health in Admin Center

Key Enterprise design guidance (Best practices)

Use one gateway per environment tier (Prod / Non‑Prod)

Use dedicated VNets for data access where possible

Use Private Endpoint only (avoid service endpoints)

Control access via AAD groups, not individuals

Avoid mixing gateway subnet with other workloads

Conclusion: For enterprises looking to consume Power Platform, Power BI, and Microsoft Fabric securely while keeping operational overhead close to zero, the VNet data gateway is the recommended approach.

It removes gateway infrastructure complexity, strengthens security posture, and aligns perfectly with modern Azure landing zone and Zero Trust architectures.

Introducing the Container Network Insights Agent for AKS: Now in Public Preview

chandanAggarwal — Thu, 16 Apr 2026 21:05:45 GMT

We are thrilled to announce public preview of Container Network Insights Agent - Agentic AI network troubleshooting for your workloads running in Azure Kubernetes Service (AKS).

The Challenge

AKS networking is layered by design. Azure CNI, eBPF, Cilium, CoreDNS, NetworkPolicy, CiliumNetworkPolicy, Hubble. Each layer contributes capabilities, and some of these can fail silently in ways the surrounding layers cannot observe.

When something breaks, the evidence usually exists. Operators already have the tools such as Azure Monitor for metrics, Container Insights for cluster health, Prometheus and Grafana for dashboarding, Cilium and Hubble for pod network observation, and Kubectl for direct inspection. However, correlating different signals and identifying the root cause takes time.

Imagine this scenario: An application performance alert fires. The on-call engineer checks dashboards, reviews events, inspects pod health. Each tool shows its own slice. But the root cause usually lives in the relationship between signals, not in any single tool. So the real work begins to manually cross-reference Hubble flows, NetworkPolicy specs, DNS state, node-level stats, and verdicts. Each check is a separate query, a separate context switch, a separate mental model of how the layers interact.

This process is manual, it is slow, needs domain knowledge, and does not scale. Mean time to resolution (MTTR) stays high not because engineers lack skill, but because the investigation surface is wide and the interactions between the layers are complex.

The solution: Container Network Insights Agent

Container Network Insights Agent is agentic AI to simplify and speed up AKS network troubleshooting

Rather than replacing your existing observability tools, the container network insights agent correlates signals on demand to help you quickly identify and resolve network issues. You describe a problem in natural language, and the agent runs a structured investigation across layers. It delivers a diagnosis with the evidence, the root cause, and the exact commands to fix it.

The container network insights agent gets its visibility through two data sources:

- AKS MCP server container network insight agent integrates with the AKS MCP (Model Context Protocol) server, a standardized and secure interface to kubectl, Cilium, and Hubble. Every diagnostic command runs through the same tools operators already use, via a well-defined protocol that enforces security boundaries. No ad-hoc scripts, no custom API integrations.

- Linux Networking plugin  For diagnostics that require visibility below the Kubernetes API layer, container network insights agent collects kernel-level telemetry directly from cluster nodes. This includes NIC ring buffer stats, kernel packet counters, SoftIRQ distribution, and socket buffer utilization. This is how it pinpoints packet drops and network saturation that surface-level metrics cannot explain.

When you describe a symptom, the container network insights agent:

- Classifies the issue and plans an investigation tailored to the symptom pattern

- Gathers evidence through the AKS MCP server and its Linux networking plugin across DNS, service routing, network policies, Cilium, and node-level statistics

- Reasons across layers to identify how a failure in one component manifests in another

- Delivers a structured report with pass/fail evidence, root cause analysis, and specific remediation guidance

The container network insight agent is scoped to AKS networking: DNS failures, packet drops, connectivity issues, policy conflicts, and Cilium dataplane health. It does not modify workloads or change configurations. All remediation guidance is advisory. The agent tells you what to run, and you decide whether to apply it.

What makes the container network insights agent different

Deep telemetry, not just surface metrics Most observability tools operate at the Kubernetes API level. container network insight agent goes deeper, collecting kernel-level network statistics, BPF program drop counters, and interface-level diagnostics that pinpoint exactly where packets are being lost and why. This is the difference between knowing something is wrong and knowing precisely what is causing it.

Cross-layer reasoning Networking incidents rarely have single-layer explanations. The container network insights agent correlates evidence from DNS, service routing, network policy, Cilium, and node-level statistics together. It surfaces causal relationships that span layers. For example: node-level RX drops caused by a Cilium policy denial triggered by a label mismatch after a routine Helm deployment, even though the pods themselves appear healthy.

Structured and auditable Every conclusion traces to a specific check, its output, and its pass/fail status. If all checks pass, container network insights agent reports no issue. It does not invent problems. Investigations are deterministic and reproducible. Results can be reviewed, shared, and rerun.

Guidance, not just findings The container network insights agent explains what the evidence means, identifies the root cause, and provides specific remediation commands. The analysis is done; the operator reviews and decides.

Where the container network insights agent fits

The container network insights agent is not another monitoring tool. It does not collect continuous metrics or replace dashboards. Your existing observability stack, including Azure Monitor, Prometheus, Grafana, Container Insights, and your log pipelines, keeps doing what it does. The agent complements those tools by adding an intelligence layer that turns fragmented signals into actionable diagnosis. Your alerting detects the problem; this agent helps you understand it.

Safe by Design

The container network insights agent is built for production clusters.

- Read-only access Minimal RBAC scoped to pods, services, endpoints, nodes, namespaces, network policies, and Cilium resources. container network insight agent deploys a temporary debug DaemonSet only for packet-drop diagnostics that require host-level stats.

- Advisory remediation only The container network insights agent tells you what to run. It never executes changes.

- Evidence-backed conclusions Every root cause traces to a specific failed check. No speculation.

- Scoped and enforced The agent handles AKS networking questions only. It does not respond to off-topic requests. Prompt injection defenses are built in.

- Credentials stay in the cluster The container network insights agent authenticates via managed identity with workload identity federation. No secrets, no static credentials. Only a session ID cookie reaches the browser.

Get Started

Container network insights agent is available in Public Preview in **Central US, East US, East US 2, UK South, and West US 2**.

The agent deploys as an AKS cluster extension and uses your own Azure OpenAI resource, giving you control over model configuration and data residency. Full capabilities require Cilium and Advanced Container Networking Services. DNS and packet drop diagnostics work on all supported AKS clusters.

To try it:

- Review the Container Network Insights Agent overview on Microsoft Learn 

https://learn.microsoft.com/en-us/azure/aks/container-network-insights-agent-overview 

- Follow the quickstart to deploy container network insights agent and run your first diagnostic

- Share feedback via the Azure feedback channel or the thumbs-up and thumbs-down feedback controls on each response

Your feedback shapes the roadmap. If the agent gets something wrong or misses a scenario you encounter, we want to hear about it.

Enabling fallback to internet for Azure Private DNS Zones in hybrid architectures

kirankumar_manchiwar04 — Wed, 15 Apr 2026 15:57:15 GMT

Introduction

Azure Private Endpoint enables secure connectivity to Azure PaaS services such as:

Azure SQL Managed Instance

Azure Container Registry

Azure Key Vault

Azure Storage Account

through private IP addresses within a virtual network.

When Private Endpoint is enabled for a service, Azure DNS automatically changes the name resolution path using

CNAME Redirection

Example:
myserver.database.windows.net 

↓

myserver.privatelink.database.windows.net

↓

Private IP

Azure Private DNS Zones are then used to resolve this Private Endpoint FQDN within the VNet.

However, this introduces a critical DNS limitation in:

Hybrid cloud architectures (AWS → Azure SQL MI)

Multiregion deployments (DR region access)

Crosstenant / Crosssubscription access

MultiVNet isolated networks

If the Private DNS zone does not contain a corresponding record, Azure DNS returns:

NXDOMAIN (NonExistent Domain)

When a DNS resolver receives a negative response (NXDOMAIN), it sends no DNS response to the DNS client and the query fails.

This results in:

❌ Application connectivity failure
❌ Database connection timeout
❌ AKS pod DNS resolution errors
❌ DR failover application outage

Problem statement

In traditional Private Endpoint DNS resolution:

DNS query is sent from the application.

Azure DNS checks linked Private DNS Zone.

If no matching record exists: NXDOMAIN returned

DNS queries for Azure Private Link and network isolation scenarios across different tenants and resource groups have unique name resolution paths which can affect the ability to reach Private Linkenabled resources outside a tenant's control.

Azure does not retry resolution using public DNS by default.

Therefore:

Public Endpoint resolution never occurs

DNS query fails permanently

Application cannot connect

Microsoft native solution

Fallback to internet (NxDomainRedirect)

Azure introduced a DNS resolution policy:

resolutionPolicy = NxDomainRedirect

This property enables public recursion via Azure’s recursive resolver fleet when an authoritative NXDOMAIN response is received for a Private Link zone.

When enabled:

✅ Azure DNS retries the query
✅ Public endpoint resolution occurs
✅ Application connectivity continues
✅ No custom DNS forwarder required

Fallback policy is configured at:

Private DNS Zone → virtualnetwork link

Resolution policy is enabled at the virtual network link level with the NxDomainRedirect setting.

In the Azure portal this appears as:

         Enable fallback to internet

How it works

Without fallback:

Application → Azure DNS

         → Private DNS Zone

         → Record missing

         → NXDOMAIN returned

         → Connection failure

With fallback enabled:

Application → Azure DNS

         → Private DNS Zone

         → Record missing

         → NXDOMAIN returned

         → Azure recursive resolver

         → Public DNS resolution

         → Public endpoint IP returned

         → Connection successful

Azure recursive resolver retries the query using the public endpoint QNAME each time NXDOMAIN is received from the private zone scope

Real world use case

AWS Application Connecting to Azure SQL Managed Instance

You are running:

SQL MI in Azure

Private Endpoint enabled

Private DNS Zone: privatelink.database.windows.net

AWS application tries to connect:

my-mi.database.windows.net

If DR region DNS record is not available:

Without fallback:

DNS query → NXDOMAIN → App failure

With fallback enabled:

DNS query → Retry public DNS → Connection success

Step-by-step configuration

Method 1 – Azure portal

Go to:

Private DNS Zones

Select your Private Link DNS Zone:

Example:

privatelink.database.windows.net

Select:

Virtual network links

Open your linked VNet

Enable:

✅ Enable fallback to internet

Click:

Save

Method 2 – Azure CLI

You can configure fallback policy using:

az network private-dns link vnet update \

      --resource-group RG-Network \

      --zone-name privatelink.database.windows.net \

      --name VNET-Link \

      --resolution-policy NxDomainRedirect

Validation steps

Run from Azure VM:

nslookup my-mi.database.windows.net

Expected:

✔ Private IP (if available)
✔ Public IP (if fallback triggered)

Security considerations

Fallback to internet:

✅ Does NOT expose data
✅ Only impacts DNS resolution
✅ Network traffic still governed by:

Azure Firewall

Service Endpoint Policies

DNS resolution fallback only triggers on NXDOMAIN and does not change networklevel firewall controls.

When should you enable this?

Recommended in:

Hybrid AWS → Azure connectivity

Multiregion DR deployments

AKS accessing Private Endpoint services

CrossTenant connectivity

Private Link + VPN / ExpressRoute scenarios

Conclusion

Fallback to Internet using NxDomainRedirect provides:

Seamless hybrid connectivity

Reduced DNS complexity

No custom forwarders

Improved application resilience

and simplifies DNS resolution for modern Private Endpointenabled architectures.

A demonstration of Virtual Network TAP

Marc de Droog — Wed, 15 Apr 2026 10:30:01 GMT

Azure Virtual Network Terminal Access Point (VTAP), at the time of writing in April 2026 in public preview in select regions, copies network traffic from source Virtual Machines to a collector or traffic analytics tool, running as a Network Virtual Appliance (NVA). VTAP creates a full copy of all traffic sent and received by Virtual Machine Network Interface Card(s) (NICs) designated as VTAP source(s). This includes packet payload content - in contrast to VNET Flow Logs, which only collect traffic meta data. Traffic collectors and analytics tools are 3rd party partner products, available from the Azure Marketplace, amongst which are the major Network Detection and Response solutions.

VTAP is an agentless, cloud-native traffic tap at the Azure network infrastructure level. It is entirely out-of-band; it has no impact on the source VM's network performance and the source VM is unaware of the tap. Tapped traffic is VXLAN-encapsulated and delivered to the collector NVA, in the same VNET as the source VMs, or in a peered VNET.

This post demonstrates the basic functionality of VTAP: copying traffic into and out of a source VM, to a destination VM.

The demo consists of 3 three Windows VMs in one VNET, each running a basic web server that responds with the VM's name. Another VNET contains the target - a Windows VM on which Wireshark is installed, to inspect traffic forwarded by VTAP. This demo does not use 3rd party VTAP partner solutions from the Marketplace.

The lab for this demonstration is available on Github: Virtual Network TAP.

The VTAP resource is configured with the target VM's NIC as the destination.

All traffic captured from sources is VXLAN-encapsulated and sent to the destination on UDP port 4789 (this cannot be changed).

We use a single source to easier inspect the traffic flows in Wireshark; we will see that communication from the other VMs to our source VM is captured and copied to the destination. In a real world scenario, multiple or all of the VMs in an environment could be set up as TAP sources.

The source VM, vm1, generates traffic through a script that continuously polls vm2 and vm3 on http://10.0.2.5 and http://10.0.2.6, and https://ipconfig.io.

On the destination VM, we use Wireshark to observe captured traffic.

The filter on UDP port 4789 causes Wireshark to only capture the VXLAN encapsulated traffic forwarded by VTAP.

Wireshark automatically decodes VXLAN and displays the actual traffic to and from vm1, which is set up as the (only) VTAP source. Wireshark's capture panel shows the decapsulated TCP and HTTP exchanges, including the TCP handshake, between vm1 and the other VMs, and https://ipconfig.io.

Expanding the lines in the detail panel below the capture panel shows the details of the VXLAN encapsulation. The outer IP packets, encapsulating the VXLAN frames in UDP, originate from the source VM's IP address, 10.0.2.4, and have the target VM's address, 10.1.1.4, as the destination.

The VXLAN frames contain all the details of the original Ethernet frames sent from and received by the source VM, and the IP packets within those. The Wireshark trace shows the full exchange between vm1 and the destinations it speaks with.

This brief demonstration uses Wireshark to simply visualize the operation of VTAP. The partner solutions available from the Azure Marketplace operate on the captured traffic to implement their specific functionality.

Connecting an ExpressRoute circuit to Megaport Virtual Edge

Marc de Droog — Mon, 13 Apr 2026 13:18:18 GMT

Megaport is an ExpressRoute partner in many locations.

The Megaport Cloud Router (MCR) allows ExpressRoute customers to connect leased lines to their on-premise locations, and to connect other Cloud Providers. MCR is easy to set up and operate, it even automatically configures the ExpressRoute Private Peering on both the Megaport and Azure sides, but it does not have a command line interface and does not permit advanced configuration.

For advanced scenario's, Megaport Virtual Edge (MVE) provides a platform to run fully configurable Network Virtual Appliances (NVAs) from a variety of vendors.

This post describes how to connect ExpressRoute to MVE running a Cisco 8000v NVA.

Create the Expressroute Circuit

In the Azure portal, create an ExpressRoute circuit with Standard Resiliency in a Peering location where Megaport is available.

When the circuit deployment is completed, copy the Service key.

Create MVE and ExpressRoute connections

Select Cisco C8000 as the Vendor / Product.

On the next screen:

Select the Location where the MVE is to be deployed - use the ExpressRoute peering location.
Select the MVE size.

On the following screen:

Select Autonomous under Appliance Mode.
Paste a 2048-bit RS SSH public key in the box.
Under Virtual Interfaces (vNICs), add vNICs as needed. One ExpressRoute circuit requires 2 vNICs, one for each path.
vNIC0 will be used to connect a Megaport Internet VXC for SSH access to the device.

On the following screen, give the MVE a name under Finalize Details in the left bar, verify the Summary, and and click Add MVE.

Clicking Create Megaport Internet in the pop up that now appears lets you directly to provision an internet VXC:

Select the location with the lowest latest latency to the MVE - this will be at the top of the list.

On the next screen:

Leave the name as proposed or change as needed.
Set Rate Limit to 20 Mbps (lowest possible, this is for SSH access only).
Leave A-vNIC set to vNIC-0.
Leave Preferred A-End VLAN at Untagged.

On the next screen verify the configuration and click Add VXC.

On the main Services page, the MVE and Internet VXC now show with the note "Order pending".

Click +Connection in the MVE box to connect a VXC to the ExpressRoute Circuit.

Under Choose Destination Type select Cloud.
Then select Microsoft Azure as the Provider.
Paste in the circuit's Service Key and select Port for the Primary path.
Click Next.

On the next screen:

Give the connection a name.
Leave the Rate Limit as proposed, this is set to the bandwidth of the circuit.
At A-end vNIC, select vNIC-1 (do not leave this at vNIC-0!).
At Preferred A-End VLAN, turn off Untag and enter a VLAN number. This will be used to set the sub-interface in the MVE configuration later.

Scroll down to Azure peering VLAN.

Leave Configure Azure Peering VLAN turned on.
Enter the same VLAN ID that will be used in the configuration of the Private Peering on the Azure end.
Click Next.

Verify the configuration summary and click Add VXC.

Repeat the process to add the Secondary path, terminating on vNIC-2. Enter a different VLAN ID for Preferred A-End VLAN. Enter the same VLAN ID that will be used in the Private Peering under Azure peering VLAN.

When the second ExpressRoute VXC is configured, click Review Order in the right hand bar of the Services screen.

When the validation completes, click Order Now.

This will provision the MVE and the VXC. It will take a few minutes for all services to come up.

In the Azure portal, the Provider Status of the ExpressRoute circuit will change to Provisioned.

Configure Private Peering

Go back to the ExpressRoute circuit in the Azure portal. The Provider Status will now be Provisioned, and the Private Peering can be enabled. Click on Peerings under Settings and then click Azure private.

Enter the Peer ASN and Primary and Secondary subnets. Under VLAN ID enter the same number as configured under Azure Peering VLAN in the Primary and Secondary VXC configurations in the Megaport portal.

Configure Cisco IOS

Establish an SSH session to the MVE. Use the public ip address from the internet VXC, and the private key that belongs with the public key used when deploying the MVE.

ssh -i <private-key-file> mveadmin@<public ip>

Configure interfaces:

interface GigabitEthernet2 no ip address no shutdown negotiation auto ! interface GigabitEthernet2.100 encapsulation dot1Q 100 ip address 192.168.0.1 255.255.255.252 ! interface GigabitEthernet3 no ip address no shutdown negotiation auto ! interface GigabitEthernet3.101 encapsulation dot1Q 101 ip address 192.168.0.5 255.255.255.252

Use the Preferred A-end VLAN values set in the primary and secondary VXCs to configure the encapsulation on the subinterfaces. Use the lower address of the /30 subnets configured on the Private Peering.

The higher IP addresses of the Private Peering should now respond to ping:

ping 192.168.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

If ping does not work there likely is an ARP resolution issue. Run `show arp` and `debug arp` and check the ARP table of the Private Peering.

Configure BGP:

router bgp 64000 bgp log-neighbor-changes neighbor 192.168.0.2 remote-as 12076 neighbor 192.168.0.2 soft-reconfiguration inbound neighbor 192.168.0.6 remote-as 12076 neighbor 192.168.0.6 soft-reconfiguration inbound

Verify both neighbors show BGP state = Established:

sh ip bgp neighbor 192.168.0.2 BGP neighbor is 192.168.0.2, remote AS 12076, external link BGP version 4, remote router ID 192.168.0.2 BGP state = Established, up for 1d21h ...

This completes the basic configuration of ExpressRoute to MVE.

Announcing public preview: Cilium mTLS encryption for Azure Kubernetes Service

chandanAggarwal — Mon, 23 Mar 2026 01:50:18 GMT

We are thrilled to announce the public preview of Cilium mTLS encryption in Azure Kubernetes Service (AKS), delivered as part of Advanced Container Networking Services and powered by the Azure CNI dataplane built on Cilium.

This capability is the result of a close engineering collaboration between Microsoft and Isovalent (now part of Cisco). It brings transparent, workload‑level mutual TLS (mTLS) to AKS without sidecars, without application changes, and without introducing a separate service mesh stack.

This public preview represents a major step forward in delivering secure, high‑performance, and operationally simple networking for AKS customers. In this post, we’ll walk through how Cilium mTLS works, when to use it, and how to get started.

Why Cilium mTLS encryption matters

Traditionally, teams looking to in-transit traffic encryption in Kubernetes have had two primary options:

Node-level encryption (for example, WireGuard or virtual network encryption), which secures traffic in transit but lacks workload identity and authentication.

Service meshes, which provide strong identity and mTLS guarantees but introduce operational complexity.

This trade‑off has become increasingly problematic, as many teams want workload‑level encryption and authentication, but without the cost, overhead, and architectural impact of deploying and operating a full-service mesh.

Cilium mTLS closes this gap directly in the dataplane. It delivers transparent, inline mTLS encryption and authentication for pod‑to‑pod TCP traffic, enforced below the application layer. And implemented natively in the Azure CNI dataplane built on Cilium, so customers gain workload‑level security without introducing a separate service mesh, resulting in a simpler architecture with lower operational overhead.

To see how this works under the hood, the next section breaks down the Cilium mTLS architecture and follows a pod‑to‑pod TCP flow from interception to authentication and encryption.

Architecture and design: How Cilium mTLS works

Cilium mTLS achieves workload‑level authentication and encryption by combining three key components, each responsible for a specific part of the authentication and encryption lifecycle.

Cilium agent: Transparent traffic interception and wiring

Cilium agent which already exists on any cluster running with Azure CNI powered by cilium, is responsible for making mTLS invisible to applications. When a namespace is labelled with “io.cilium/mtls-enabled=true”, The Cilium agent enrolls all pods in that namespace. It enters each pod's network namespace and installs iptables rules that redirect outbound traffic to ztunnel on port 15001.

It is also responsible for passing workload metadata (such as pod IP and namespace context) to ztunnel.

Ztunnel: Node‑level mTLS enforcement

Ztunnel is an open source, lightweight, node‑level Layer 4 proxy that was originally created by Istio. Ztunnel runs as a DaemonSet, on the source node it looks up the destination workload via XDS (streamed from the Cilium agent) and establishes mutually authenticated TLS 1.3 sessions between source and destination nodes. Connections are held inline until authentication is complete, ensuring that traffic is never sent in plaintext.

The destination ztunnel decrypts the traffic and delivers it into the target pod, bypassing the interception rules via an in-pod mark. The application sees a normal plaintext connection — it is completely unaware encryption happened.

SPIRE: Workload identity and trust

SPIRE (SPIFFE Runtime Environment) provides the identity foundation for Cilium mTLS. SPIRE acts as the cluster Certificate Authority, issuing short‑lived X.509 certificates (SVIDs) that are automatically rotated and validated.

This is a key design principle of Cilium mTLS - trust is based on workload identity, not network topology.

Each workload receives a cryptographic identity derived from:

Kubernetes namespace

Kubernetes ServiceAccount

These identities are issued and rotated automatically by SPIRE and validated on both sides of every connection. As a result:

Identity remains stable across pod restarts and rescheduling

Authentication is decoupled from IP addresses

Trust decisions align naturally with Kubernetes RBAC and namespace boundaries

This enables a zero‑trust networking model that fits cleanly into existing AKS security practices.

End‑to‑End workflow example

To see how these components work together, consider a simple pod‑to‑pod connection:

A pod initiates a TCP connection to another pod.

Traffic intercepted inside the pod network namespace and redirected to the local ztunnel instance.

ztunnel retrieves the workload identity using certificates issued by SPIRE.

ztunnel establishes a mutually authenticated TLS session with the destination node’s ztunnel.

Traffic is encrypted and sent between pods.

The destination ztunnel decrypts the traffic and delivers it to the target pod.

Every packet from an enrolled pod is encrypted. There is no plaintext window, and no dropped first packets. The connection is held inline by ztunnel until the mTLS tunnel is established, then traffic flows bidirectionally through an HBONE (HTTP/2 CONNECT) tunnel.

Workload enrolment and scope

Cilium mTLS in AKS is opt‑in and scoped at the namespace level.

Platform teams enable mTLS by applying a single label to a namespace. From that point on:

All pods in that namespace participate in mTLS

Authentication and encryption are mandatory between enrolled workloads

Non-enrolled namespaces continue to operate unchanged

Encryption is applied only when both pods are enrolled. Traffic between enrolled and non‑enrolled workloads continues in plaintext without causing connectivity issues or hard failures. This model enables gradual rollout, staged migrations, and low-risk adoption across environments.

Getting started in AKS

Cilium mTLS encryption is available in public preview for AKS clusters that use:

Azure CNI powered by Cilium

Advanced Container Networking Services

You can enable mTLS:

When creating a new cluster, or

On an existing cluster by updating the Advanced Container Networking Services configuration

Once enabled, enrolling workloads is as simple as labelling a namespace.

👉 Learn more

Concepts: How Cilium mTLS works, architecture, and trust boundaries

How-to guide: Step-by-step instructions to enable and verify mTLS in AKS

Looking ahead

This public preview represents an important step forward in simplifying network security for AKS and reflects a deep collaboration between Microsoft and Isovalent to bring open, standards‑based innovation into production‑ready cloud platforms. We’re continuing to work closely with the community to improve the feature and move it toward general availability.

If you’re looking for workload‑level encryption without the overhead of a traditional service mesh, we invite you to try Cilium mTLS in AKS and share your experience.

Azure Front Door: Resiliency Series – Part 2: Faster recovery (RTO)

AbhishekTiwari — Thu, 19 Mar 2026 17:00:54 GMT

In Part 1 of this blog series, we outlined our four‑pillar strategy for resiliency in Azure Front Door: configuration resiliency, data plane resiliency, tenant isolation, and accelerated Recovery Time Objective (RTO). Together, these pillars help Azure Front Door remain continuously available and resilient at global scale.

Part 1 focused on the first two pillars: configuration and data plane resiliency. Our goal is to make configuration propagation safer, so incompatible changes never escape pre‑production environments. We discussed how incompatible configurations are blocked early, and how data plane resiliency ensures the system continues serving traffic from a last‑known‑good (LKG) configuration even if a bad change manages to propagate. We also introduced ‘Food Taster’, a dedicated sacrificial process running in each edge server’s data plane, that pretests every configuration change in isolation, before it ever reaches the live data plane.

In this post, we turn to the recovery pillar. We describe how we have made key enhancements to the Azure Front Door recovery path so the system can return to full operation in a predictable and bounded timeframe. For a global service like Azure Front Door, serving hundreds of thousands of tenants across 210+ edge sites worldwide, we set an explicit target: to be able to recover any edge site – or all edge sites – within approximately 10 minutes, even in worst‑case scenarios. In typical data plane crash scenarios, we expect recovery in under a second.

Repair status

The first blog post in this series mentioned the two Azure Front Door incidents from October 2025 – learn more by watching our Azure Incident Retrospective session recordings for the October 9^th incident and/or the October 29^th incident. Before diving into our platform investments for improving our Recovery Time Objectives (RTO), we wanted to provide a quick update on the overall repair items from these incidents. We are pleased to report that the work on configuration propagation and data plane resiliency is now complete and fully deployed across the platform (in the table below, “Completed” means broadly deployed in production). With this, we have reduced configuration propagation latency from ~45 minutes to ~20 minutes. We anticipate reducing this even further – to ~15 minutes by the end of April 2026, while ensuring that platform stability remains our top priority.

Learning category	Goal	Repairs	Status
Safe customer configuration deployment	Incompatible configuration never propagates beyond ‘EUAP or canary regions’	Control plane and data plane defect fixes Forced synchronous configuration processing Additional stages with extended bake time Early detection of crash state	Completed
Data plane resiliency	Configuration processing cannot impact data plane availability	Manage data-plane lifecycle to prevent outages caused by configuration-processing defects.	Completed
Data plane resiliency		Isolated work-process in every data plane server to process and load the configuration.	Completed
100% Azure Front Door resiliency posture for Microsoft internal services	Microsoft operates an isolated, independent Active/Active fleet with automatic failover for critical Azure services	Phase 1: Onboarded critical services batch impacted on Oct 29^th outage running on a day old configuration	Completed
		Phase 2: Automation & hardening of operations, auto-failover and self-management of Azure Front Door onboarding for additional services	March 2026
Recovery improvements	Data plane crash recovery in under 10 minutes	Data plane boot-up time optimized via local cache (~1 hour)	Completed
Recovery improvements	Data plane crash recovery in under 10 minutes	Accelerate recovery time < 10 minutes	April 2026
Tenant isolation	No configuration or traffic regression can impact other tenants	Micro cellular Azure Front Door with ingress layered shards	June 2026

Why recovery at edge scale is deceptively hard

To understand why recovery took as long as it did, it helps to first understand how the Azure Front Door data plane processes configuration.

Azure Front Door operates in 210+ edge sites with multiple servers per site. The data plane of each edge server hosts multiple processes. A master process orchestrates the lifecycle of multiple worker processes, that serve customer traffic. A separate configuration translator process runs alongside the data plane processes, and is responsible for converting customer configuration bundles from the control plane into optimized binary FlatBuffer files. This translation step, covering hundreds of thousands of tenants, represents hours of cumulative computation. A per edge server cache is kept locally at each server level – to enable a fast recovery of the data plane, if needed.

Once the configuration translator process produces these FlatBuffer files, each worker processes them independently and memory-maps them for zero-copy access. Configuration updates flow through a two-phase commit: new FlatBuffers are first loaded into a staging area and validated, then atomically swapped into production maps. In-flight requests continue using the old configuration, until the last request referencing them completes.

The data process recovery is designed to be resilient to different failure modes. A failure or crash at the worker process level has a typical recovery time of less than one second. Since each server has multiple such worker processes which serve customer traffic, this type of crash has no impact on the data plane. In the case of a master process crash, the system automatically tries to recover using the local cache. When the local cache is reused, the system is able to recover quickly – in approximately 60 minutes – since most of the configurations in the cache were already loaded into the data plane before the crash. However, in certain cases if the cache becomes unavailable or must be invalidated because of corruption, the recovery time increases significantly.

During the October 29^th incident, a data plane crash triggered a complete recovery sequence that took approximately 4.5 hours. This was not because restarting a process is slow, it is because a defect in the recovery process invalidated the local cache, which meant that “restart” meant rebuilding everything from scratch. The configuration translator process then had to re-fetch and re-translate every one of the hundreds of thousands of customer configurations, before workers could memory-map them and begin serving traffic.

This experience has crystallized three fundamental learnings related to our recovery path:

Expensive rework: A subset of crashes discarded all previously translated FlatBuffer artifacts, forcing the configuration translator process to repeat hours of conversion work that had already been validated and stored.
High restart costs: Every worker on every node had to wait for the configuration translator process to complete the full translation, before it could memory-map any configuration and begin serving requests.
Unbounded recovery time: Recovery time grew linearly with total tenant footprint rather than with active traffic, creating a ‘scale penalty’ as more tenants onboarded to the system.

Separately and together, the insight was clear: recovery must stop being proportional to the total configuration size.

Persisting ‘validated configurations’ across restarts

One of the key recovery improvements was strengthening how validated customer configurations are cached and reused across failures, rather than rebuilding configuration states from scratch during recovery. Azure Front Door already cached customer configurations on host‑mounted storage prior to the October incident. The platform enhancements post outage focused on making the local configuration cache resilient to crashes, partial failures, and bad tenant inputs.

Our goal was to ensure that recovery behavior is dominated by serving traffic safely, not by reconstructing configuration state. This led us to two explicit design goals…

Design goals

No category of crash should invalidate the configuration cache: Configuration cache invalidation must never be the default response to failures. Whether the failure is a worker crash, master crash, data plane restart, or coordinated recovery action, previously validated customer configurations should remain usable—unless there is a proven reason to discard it.
Bad tenant configuration must not poison the entire cache: A single faulty or incompatible tenant configuration should result in targeted eviction of that tenant’s configuration only—not wholesale cache invalidation across all tenants.

Platform enhancements

Previously, customer configurations persisted to host‑mounted storage, but certain failure paths treated the cache as unsafe and invalidated it entirely. In those cases, recovery implicitly meant reloading and reprocessing configuration for hundreds of thousands of tenants before traffic could resume, even though the vast majority of cached data was still valid.

We changed the recovery model to avoid invalidating customer configurations, with strict scoping around when and how cached entries are discarded:

Cached configurations are no longer invalidated based on crash type. Failures are assumed to be orthogonal to configuration correctness unless explicitly proven otherwise.
Cache eviction is granular and tenant‑scoped. If a cached configuration fails validation or load checks, only that tenant’s configuration is discarded and reloaded. All other tenant configurations remain available.

This ensures that recovery does not regress into a fleet‑wide rebuild due to localized or unrelated faults.

Safety and correctness

Durability is paired with strong correctness controls, to prevent unsafe configurations from being served:

Per‑tenant validation on load: Each cached tenant configuration is validated during the ‘load and verification’ phase, before being promoted for traffic serving. Therefore, failures are contained to that tenant.
Targeted re‑translation: When validation fails, only the affected tenant’s configuration is reloaded or reprocessed. Therefore, the cache for other tenants is left untouched.
Operational escape hatch: Operators retain the ability to explicitly instruct a clean rebuild of the configuration cache (with proper authorization), preserving control without compromising the default fast‑recovery path.

Resulting behavior

With these changes, recovery behavior now aligns with real‑world traffic patterns - configuration defects impact tenants locally and predictably, rather than globally. The system now prefers isolated tenant impact, and continued service using last-known-good over aggressive invalidation, both of which are critical for predictable recovery at the scale of Azure Front Door.

Making recovery scale with active traffic, not total tenants

Reusing configuration cache solves the problem of rebuilding configuration in its entirety, but even with a warm cache, the original startup path had a second bottleneck: eagerly loading a large volume of tenant configurations into memory before serving any traffic. At our scale, memory-mapping, parsing hundreds of thousands of FlatBuffers, constructing internal lookup maps, adding Transport Layer Security (TLS) certificates and configuration blocks for each tenant, collectively added almost an hour to startup time. This was the case even when a majority of those tenants had no active traffic at that moment.

We addressed this by fundamentally changing when configuration is loaded into workers. Rather than eagerly loading most of the tenants at startup across all edge locations, Azure Front Door now uses an Machine Learning (ML)-optimized lazy loading model.

In the new architecture, instead of loading a large number of tenant configurations, we only load a small subset of tenants that are known to be historically active in a given site, we call this the “warm tenants” list. The warm tenants list per edge site is created through a sophisticated traffic analysis pipeline that leverages ML. However, loading the warm tenants is not good enough, because when a request arrives and we don’t have the configuration in memory, we need to know two things. Firstly, is this a request from a real Azure Front Door tenant – and, if it is, where can I find the configuration?

To answer these questions, each worker maintains a hostmap that tracks the state of each tenant’s configuration. This hostmap is constructed during startup, as we process each tenant configuration – if the tenant is in the warm list, we will process and load their configuration fully; if not, then we will just add an entry into the hostmap where all their domain names are mapped to the configuration path location. When a request arrives for one of these tenants, the worker loads and validates that tenant’s configuration on demand, and immediately begins serving traffic. This allows a node to start serving its busiest tenants within a few minutes of startup, while additional tenants are loaded incrementally only when traffic actually arrives—allowing the system to progressively absorb cold tenants as demand increases.

The effect on recovery is transformative. Instead of recovery time scaling with the total number of tenants configured on a server, it scales with the number of tenants actively receiving traffic. In practice, even at our busiest edge sites, the active tenant set is a small fraction of the total.

Just as importantly, this modified form of lazy loading provides a natural failure isolation boundary. Most Edge sites won’t ever load a faulty configuration of an inactive tenant. When a request for an inactive tenant with an incompatible configuration arrives, impact is contained to a single worker.

The configuration load architecture now prefers serving as many customers as quickly as possible, rather than waiting until everything is ready before serving anyone. The above changes are slated to complete in April 2026 and will bring our RTO from the current ~1 hour to under 10 minutes – for complete recovery from a worst case scenario.

Continuous validation through Game Days

A critical element of our recovery confidence comes from GameDay fault-injection testing. We don’t simply design recovery mechanisms and assume they work—we break the system deliberately and observe how it responds. Since late 2025, we have conducted recurring GameDay drills that simulate the exact failure scenarios we are defending against:

Food Taster crash scenarios: Injecting deliberately faulty tenant configurations, to verify that they are caught and isolated with zero impact on live traffic. In our January 2026 GameDay, the Food Taster process crashed as expected, the system halted the update within approximately 5 seconds, and no customer traffic was affected.
Master process crash scenarios: Triggering master process crashes across test environments to verify that workers continue serving traffic, that the Local Config Shield engages within 10 seconds, and that the coordinated recovery tool restores full operation within the expected timeframe.
Multi-region failure drills: Simulating simultaneous failures across multiple regions to validate that global Config Shield mechanisms engage correctly, and that recovery procedures scale without requiring manual per-region intervention.
Fallback test drills for critical Azure services running behind Azure Front Door: In our February 2026 GameDay, we simulated the complete unavailability of Azure Front Door, and successfully validated failover for critical Azure services with no impact to traffic.

These drills have both surfaced corner cases and built operational confidence. They have transformed recovery from a theoretical plan into tested, repeatable muscle memory. As we noted in an internal communication to our team: “Game day testing is a deliberate shift from assuming resilience to actively proving it—turning reliability into an observed and repeatable outcome.”

Closing

Part 1 of this series emphasized preventing unsafe configurations from reaching the data plane, and data plane resiliency in case an incompatible configuration reaches production. This post has shown that prevention alone is not enough—when failures do occur, recovery must be fast, predictable, and bounded. By ensuring that the FlatBuffer cache is never invalidated, by loading only active tenants, and by building safe coordinated recovery tooling, we have transformed failure handling from a fleet-wide crisis into a controlled operation.

These recovery investments work in concert with the prevention mechanisms described in Part 1. Together, they ensure that the path from incident detection to full service restoration is measured in minutes, with customer traffic protected at every step.

In the next post of this series, we will cover the third pillar of our resiliency strategy: tenant isolation—how micro-cellular architecture and ingress-layered sharding can reduce the blast radius of any failure to a small subset, ensuring that one customer’s configuration or traffic anomaly never becomes everyone’s problem.

We deeply value our customers’ trust in Azure Front Door. We are committed to transparently sharing our progress on these resiliency investments, and to exceed expectations for safety, reliability, and operational readiness.

ExpressRoute Gateway Microsoft initiated migration

MekaylaMoore — Mon, 30 Mar 2026 18:20:25 GMT

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.

Unlock outbound traffic insights with Azure StandardV2 NAT Gateway flow logs

cozhang — Fri, 06 Feb 2026 16:07:33 GMT

Recommended Outbound Connectivity

StandardV2 NAT Gateway is the next evolution of outbound connectivity in Azure. As the recommended solution for providing secure, reliable outbound Internet access, NAT Gateway continues to be the default choice for modern Azure deployments. With the highly anticipated general availability of the new StandardV2 SKU, customers gain access to the following highly requested upgrades:

Zone-redundancy: Automatically maintains outbound connectivity during single‑zone failures in AZ-enabled regions.
Enhanced performance: Up to 100 Gbps of throughput and 10 million packets per second - double the Standard SKU capacity.
Dual-stack support: Attach up to 16 IPv6 and 16 IPv4 public IP addresses for future ready connectivity.
Flow logs: Access historical logs of connections being established through your NAT gateway.

This blog will focus on how enabling StandardV2 NAT Gateway flow logs can be beneficial for your team along with some tips to get the most out of the data.

What are flow logs?

StandardV2 NAT Gateway flow logs are enabled through Diagnostic settings on your NAT gateway resource where the log data can be sent to Log Analytics, a storage account, or Event hub destination. “NatGatewayFlowlogV1” is the released log category, and it provides IP level information on traffic flowing through your StandardV2 NAT gateway.

Enable NATGateway Flow Logs through Diagnostics setting on your StandardV2 NAT gateway resource.

Schema output as seen on Log Analytics for a NAT gateway traffic flow.

Why should I use flow logs?

Security and compliance visibility

Prior to NAT gateway flow logs, customers could not see NAT gateway information when their virtual machines connect outbound. This made it difficult to:

Validate that only approved destinations were being accessed
Audit suspicious or unexpected outbound patterns
Satisfy compliance requirements that mandate traffic recording

Flow logs now provide visibility to the source IP -> NAT gateway outbound IP -> destination IP, along with details on sent/dropped packets and bytes.

Usage analytics

Flow logs allow you to answer usage questions such as:

Which VMs are generating the most outbound requests?
Which destinations receive the most traffic?
Is throughput growth caused by a specific workload pattern?

This level of insight is especially useful when debugging unexpected throughput increases, billing spikes, and connection bottlenecks.

To note: Flow logs only capture established connections. This means the TCP 3‑way handshake (SYN → SYN/ACK → ACK) or the UDP ephemeral session setup must complete. If a connection never establishes, for example due to NSG denial, routing mismatch, or SNAT exhaustion, it will not appear in flow logs.

Workflow of troubleshooting with flow logs

Let's walk through how you can leverage flow logs to troubleshoot a scenario where you are seeing intermittent connection drops.

Scenario: You have VMs that use a StandardV2 NAT gateway to reach the Internet. However, your VMs intermittently fail to reach github.com.

Step 1: Check NAT gateway health

Start with the datapath availability metric, which reflects the NAT gateway's overall health.

If metric > 90%, this confirms NAT gateway is healthy and is working as expected to send outbound traffic to the internet. Continue to Step 2.
If metric is lower, visit Troubleshoot Azure NAT Gateway connectivity - Azure NAT Gateway | Microsoft Learn for troubleshooting tips.

Step 2: Enable StandardV2 NAT Gateway Flow Logs

To further investigate the root cause, Enable StandardV2 NAT Gateway Flow Logs (NatGatewayFlowLogsV1 log category in Diagnostics Setting) for the NAT gateway resource providing outbound connectivity for the impacted VMs. It is recommended to enable Log Analytics as a destination as it allows you to easily query the data. For the detailed steps, visit Monitor with StandardV2 NAT Gateway Flow Logs - Azure NAT Gateway | Microsoft Learn.

Tip: You may enable flow logs even when not troubleshooting to ensure you’ll have historical data to reference when issues occur.

Step 3: Confirm whether the connection was established

Use Log Analytics to query for flows with source IP == VM private IP and destination IP == IP address(es) of github.com. The following query will generate a table and chart of the total packets sent per minute from your source IP to the destination IP through your NAT gateway in the last 24 hours.NatGatewayFlowlogsV1 | where TimeGenerated > ago(1d) | where SourceIP == '10.0.0.4' //and DestinationIP == <"github.com IP"> | summarize TotalPacketsSent = sum(PacketsSent) by TimeGenerated = bin(TimeGenerated, 1m), SourceIP, DestinationIP | order by TimeGenerated asc
If there are no records of this connection, it is likely an issue with establishing the connection because flow logs will only capture records of established connections. Take a look at SNAT connection metrics to determine whether it may be a SNAT port exhaustion issue or NSGs/UDRs that may be blocking the traffic.
If there are records of the connection, proceed with the next step.

Step 4: Check if there are any packets dropped

In Log Analytics, query for the total "PacketsSentDropped" and "PacketsReceivedDropped" per source/outbound/destination IP connection.

If "PacketsSentDropped" > 0 - NAT gateway dropped traffic sent from your VM.
If "PacketsReceivedDropped" > 0, NAT gateway dropped traffic received from destination IP, github.com in this case.
In both instances, it typically means the either the client or server is pushing more traffic through a single connection than is optimal, causing connection-level rate limiting.
To mitigate:

- Avoid relying on one connection and instead use multiple connections.
- Distribute traffic across multiple outbound IP addresses by assigning more public IP addresses to the NAT gateway resource.

Conclusion

StandardV2 NAT Gateway Flow Logs unlock a powerful new dimension of outbound visibility and they can help you:

Validate cybersecurity readiness
Audit outbound flows
Diagnose intermittent connectivity issues
Understand traffic patterns and optimize architecture

We are excited to see how you leverage this new capability with your StandardV2 NAT gateways!

Have more questions?

As always, for any feedback, please feel free to reach us by submitting your feedback. We look forward to hearing your thoughts and hope this announcement helps you build more resilient applications in Azure.

For more information on StandardV2 NAT Gateway Flow Logs and how to enable it, visit:

Manage StandardV2 NAT Gateway Flow Logs - Azure NAT Gateway | Microsoft Learn

Monitor with StandardV2 NAT Gateway Flow Logs - Azure NAT Gateway | Microsoft Learn

To see the most up-to-date pricing for flow logs, visit Azure NAT Gateway - Pricing | Microsoft Azure.

To learn more about StandardV2 NAT Gateway, visit What is Azure NAT Gateway? | Microsoft Learn.

Data Center Quantized Congestion Notification: Scaling congestion control for RoCE RDMA in Azure

VamsiVadlamuri — Tue, 13 Jan 2026 22:35:21 GMT

As cloud storage demands continue to grow, the need for ultra-fast, reliable networking becomes ever more critical. Microsoft Azure’s journey to empower its storage infrastructure with RDMA (Remote Direct Memory Access) has been transformative, but it’s not without challenges—especially when it comes to congestion control at scale. Azure’s deployment of RDMA at regional scale relies on DCQCN (Data Center Quantized Congestion Notification), a protocol that’s become central to Azure’s ability to deliver high-throughput, low-latency storage services across vast, heterogeneous data center regions.

Why congestion control matters in RDMA networks

RDMA offloads the network stack to NIC hardware, reducing CPU overhead and enabling near line-rate performance. However, as Azure scaled RDMA across clusters and regions, it faced new challenges:

Heterogeneous hardware: Different generations of RDMA NICs (Network Interface Cards) and switches, each with their own quirks.
Variable latency: Long-haul links between datacenters introduce large round-trip time (RTT) variations.
Congestion risks: High-speed, incast-like traffic patterns can easily overwhelm buffers, leading to packet loss and degraded performance.

To address these, Azure needed a congestion control protocol that could operate reliably across diverse hardware and network conditions. Traditional TCP congestion control mechanisms don’t apply here, so Azure leverages DCQCN combined with Priority Flow Control (PFC) to maintain high throughput, low latency, and near-zero packet loss.

How DCQCN works

DCQCN coordinates congestion control using three main entities:

Reaction point (RP): The sender adjusts its rate based on feedback.
Congestion point (CP): Switches mark packets using ECN when queues exceed thresholds.
Notification point (NP): The receiver sends Congestion Notification Packets (CNPs) upon receiving ECN-marked packets.

This feedback loop allows RDMA flows to dynamically adapt their sending rates, preventing congestion collapse while maintaining fairness.

When the switch detects congestion, it marks packets with ECN.
The receiver NIC (NP) observes ECN marks and sends CNPs to the sender.
The sender NIC (RP) reduces its sending rate upon receiving CNPs; otherwise, it increases the rate gradually.

Interoperability challenges across different hardware generations

Cloud infrastructure evolves incrementally, typically at the level of individual clusters or racks, as newer server hardware generations are introduced. Within a single region, clusters often differ in their NIC configurations. Our deployment includes three generations of commodity RDMA NICs—Gen1, Gen2, and Gen3—each implementing DCQCN with distinct design variations. These discrepancies create complex and often problematic interactions when NICs from different generations interoperate.

Gen1 NICs: Firmware-based DCQCN, NP-side CNP coalescing, burst-based rate limiting.
Gen2/Gen3 NICs: Hardware-based DCQCN, RP-side CNP coalescing, per-packet rate limiting.

Problem:

Gen2/Gen3 NICs sending to Gen1 can trigger excessive cache misses, slowing down Gen1’s receiver pipeline.
Gen1 sending to Gen2/Gen3 can cause excessive rate reductions due to frequent CNPs.

Azure’s solution:

Move CNP coalescing to NP side for Gen2/Gen3.
Implement per-QP CNP rate limiting, matching Gen1’s timer.
Enable per-burst rate limiting on Gen2/Gen3 to reduce cache pressure.

DCQCN tuning: Achieving fairness and performance

DCQCN is inherently RTT-fair—its rate adjustment is independent of round-trip time, making it suitable for Azure’s regional networks with RTTs ranging from microseconds to milliseconds.

Key Tuning Strategies:

Sparse ECN marking: Use large ECN marking thresholds (K_max - K_min) and low marking probabilities (P_max) for flows with large RTTs.
Joint buffer and DCQCN tuning: Tune switch buffer thresholds and DCQCN parameters together to avoid premature congestion signals and optimize throughput.
Global parameter settings: Azure’s NICs support only global DCQCN settings, so parameters must work well across all traffic types and RTTs.

Real-world results

High throughput & low latency:
- RDMA traffic runs at line rate with near-zero packet loss.
CPU savings:
- Freed CPU cores can be repurposed for customer VMs or application logic.
Performance metrics:
- RDMA reduces CPU utilization by up to 34.5% compared to TCP for storage frontend traffic.
- Large I/O requests (1 MB) see up to 23.8% latency reduction for reads and 15.6% for writes.
Scalability:
- As of November 2025, ~85% of Azure’s traffic is RDMA, supported in all public regions.

Conclusion

DCQCN is a cornerstone of Azure’s RDMA-enabled storage infrastructure, enabling reliable, high-performance cloud storage at scale. By combining ECN-based signaling with dynamic rate adjustments, DCQCN ensures high throughput, low latency, and near-zero packet loss—even across heterogeneous hardware and long-haul links. Its interoperability fixes and careful tuning make it a critical enabler for RDMA adoption in modern data centers, paving the way for efficient, scalable, and resilient cloud storage.

Azure Front Door: Implementing lessons learned following October outages

AbhishekTiwari — Fri, 19 Dec 2025 16:43:31 GMT

Abhishek Tiwari, Vice President of Engineering, Azure Networking
Amit Srivastava, Principal PM Manager, Azure Networking
Varun Chawla, Partner Director of Engineering

Introduction

Azure Front Door is Microsoft's advanced edge delivery platform encompassing Content Delivery Network (CDN), global security and traffic distribution into a single unified offering. By using Microsoft's extensive global edge network, Azure Front Door ensures efficient content delivery and advanced security through 210+ global and local points of presence (PoPs) strategically positioned closely to both end users and applications.

As the central global entry point from the internet onto customer applications, we power mission critical customer applications as well as many of Microsoft’s internal services. We have a highly distributed resilient architecture, which protects against failures at the server, rack, site and even at the regional level. This resiliency is achieved by the use of our intelligent traffic management layer which monitors failures and load balances traffic at server, rack or edge sites level within the primary ring, supplemented by a secondary-fallback ring which accepts traffic in case of primary traffic overflow or broad regional failures. We also deploy a traffic shield as a terminal safety net to ensure that in the event of a managed or unmanaged edge site going offline, end user traffic continues to flow to the next available edge site.

Like any large-scale CDN, we deploy each customer configuration across a globally distributed edge fleet, densely shared with thousands of other tenants. While this architecture enables global scale, it carries the risk that certain incompatible configurations, if not contained, can propagate broadly and quickly which can result in a large blast radius of impact. Here we describe how the two recent service incidents impacting Azure Front Door have reinforced the need to accelerate ongoing investments in hardening our resiliency, and tenant isolation strategy to mitigate likelihood and the scale of impact from this class of risk.

October incidents: recap and key learnings

Azure Front Door experienced two service incidents; on October 9^th and October 29^th, both with customer-impacting service degradation.

On October 9^th: A manual cleanup of stuck tenant metadata bypassed our configuration protection layer, allowing incompatible metadata to propagate beyond our canary edge sites. This metadata was created on October 7^th, from a control-plane defect triggered by a customer configuration change. While the protection system initially blocked the propagation, the manual override operation bypassed our safeguards. This incompatible configuration reached the next stage and activated a latent data-plane defect in a subset of edge sites, causing availability impact primarily across Europe (~6%) and Africa (~16%). You can learn more about this issue in detail at https://aka.ms/AIR/QNBQ-5W8

On October 29^th: A different sequence of configuration changes across two control-plane versions produced incompatible metadata. Because the failure mode in the data-plane was asynchronous, the health checks validations embedded in our protection systems were all passed during the rollout. The incompatible customer configuration metadata successfully propagated globally through a staged rollout and also updated the “last known good” (LKG) snapshot. Following this global rollout, the asynchronous process in data-plane exposed another defect which caused crashes. This impacted connectivity and DNS resolutions for all applications onboarded to our platform. Extended recovery time amplified impact on customer applications and Microsoft services. You can learn more about this issue in detail at https://aka.ms/AIR/YKYN-BWZ

We took away a number of clear and actionable lessons from these incidents, which are applicable not just to our service, but to any multi-tenant, high-density, globally distributed system.

Configuration resiliency – Valid configuration updates should propagate safely, consistently, and predictably across our global edge, while ensuring that incompatible or erroneous configuration never propagate beyond canary environments.
Data plane resiliency - Additionally, configuration processing in the data plane must not cause availability impact to any customer.
Tenant isolation – Traditional isolation techniques such as hardware partitioning and virtualization are impractical at edge sites. This requires innovative sharding techniques to ensure single tenant-level isolation – a must-have to reduce potential blast radius.
Accelerated and automated recovery time objective (RTO) – System should be able to automatically revert to last known good configuration in an acceptable RTO. In case of a service like Azure Front Door, we deem ~10 mins to be a practical RTO for our hundreds of thousands of customers at every edge site.

Post outage, given the severity of impact which allowed an incompatible configuration to propagate globally, we made the difficult decision to temporarily block configuration changes in order to expedite rollout of additional safeguards. Between October 29^th to November 5^th, we prioritized and deployed immediate hardening steps before opening up the configuration change. We are confident that the system is stable, and we are continuing to invest in additional safeguards to further strengthen the platform's resiliency.

Learning category	Goal	Repairs	Status
Safe customer configuration deployment	Incompatible configuration never propagates beyond Canary	· Control plane and data plane defect fixes · Forced synchronous configuration processing · Additional stages with extended bake time · Early detection of crash state	Completed
Data plane resiliency	Configuration processing cannot impact data plane availability	Manage data-plane lifecycle to prevent outages caused by configuration-processing defects.	Completed
Data plane resiliency		Isolated work-process in every data plane server to process and load the configuration.	January 2026
100% Azure Front Door resiliency posture for Microsoft internal services	Microsoft operates an isolated, independent Active/Active fleet with automatic failover for critical Azure services	Phase 1: Onboarded critical services batch impacted on Oct 29^th outage running on a day old configuration	Completed
		Phase 2: Automation & hardening of operations, auto-failover and self-management of Azure Front Door onboarding for additional services	March 2026
Recovery improvements	Data plane crash recovery in under 10 minutes	Data plane boot-up time optimized via local cache (~1 hour)	Completed
Recovery improvements	Data plane crash recovery in under 10 minutes	Accelerate recovery time < 10 minutes	March 2026
Tenant isolation	No configuration or traffic regression can impact other tenants	Micro cellular Azure Front Door with ingress layered shards	June 2026

This blog is the first in a multi-part series on Azure Front Door resiliency. In this blog, we will focus on configuration resiliency—how we are making the configuration pipeline safer and more robust. Subsequent blogs will cover tenant isolation and recovery improvements.

How our configuration propagation works

Azure Front Door configuration changes can be broadly classified into three distinct categories.

Service code & data – these include all aspects of Azure Front Door service like management plane, control plane, data plane, configuration propagation system. Azure Front Door follows a safe deployment practice (SDP) process to roll out newer versions of management, control or data plane over a period of approximately 2-3 weeks. This ensures that any regression in software does not have a global impact. However, latent bugs that escape pre-validation and SDP rollout can remain undetected until a specific combination of customer traffic patterns or configuration changes trigger the issue.
Web Application Firewall (WAF) & L7 DDoS platform data – These datasets are used by Azure Front Door to deliver security and load-balancing capabilities. Examples include GeoIP data, malicious attack signatures, and IP reputation signatures. Updates to these datasets occur daily through multiple SDP stages with an extended bake time of over 12 hours to minimize the risk of global impact during rollout. This dataset is shared across all customers and the platform, and it is validated immediately since it does not depend on variations in customer traffic or configuration steps.
Customer configuration data – Examples of these are any customer configuration change—whether a routing rule update, backend pool modification, WAF rule change, or security policy change. Due to the nature of these changes, it is expected across the edge delivery / CDN industry to propagate these changes globally in 5-10 mins. Both outages stemmed from issues within this category.

All configuration changes, including customer configuration data, are processed through a multi-stage pipeline designed to ensure correctness before global rollout across Azure Front Door’s 200+ edge locations. At a high level, Azure Front Door’s configuration propagation system has two distinct components -

Control plane – Accepts customer API/portal changes (create/update/delete for profiles, routes, WAF policies, origins, etc.) and translates them into internal configuration metadata which the data plane can understand.

Data plane – Globally distributed edge servers that terminate client traffic, apply routing/WAF logic, and proxy to origins using the configuration produced by the control plane.

Between these two halves sits a multi-stage configuration rollout pipeline with a dedicated protection system (known as ConfigShield):

Changes flow through multiple stages (pre-canary, canary, expanding waves to production) rather than going global at once.
Each stage is health-gated: the data plane must remain within strict error and latency thresholds before proceeding. Each stage’s health check also rechecks previous stage’s health for any regressions.
A successfully completed rollout updates a last known good (LKG) snapshot used for automated rollback.
Historically, rollout targeted global completion in roughly 5–10 minutes, in line with industry standards.

Customer configuration processing in Azure Front Door data plane stack

Customer configuration changes in Azure Front Door traverse multiple layers—from the control plane through the deployment system—before being converted into FlatBuffers at each Azure Front Door node. These FlatBuffers are then loaded by the Azure Front Door data plane stack, which runs as Kubernetes pods on every node.

FlatBuffer Composition: Each FlatBuffer references several sub-resources such as WAF and Rules Engine schematic files, SSL certificate objects, and URL signing secrets.
Data plane architecture:
o Master process: Accepts configuration changes (memory-mapped files with references) and manages the lifecycle of worker processes. o Workers: L7 proxy processes that serve customer traffic using the applied configuration.

Processing flow for each configuration update:

Load and apply in master: The transformed configuration is loaded and applied in the master process. Cleanup of unused references occurs synchronously except for certain categories à October 9 outage occurred during this step due to a crash triggered by incompatible metadata.
Apply to workers: Configuration is applied to all worker processes without memory overhead (FlatBuffers are memory-mapped).
Serve traffic: Workers start consuming new FlatBuffers for new requests; in-flight requests continue using old buffers. Old buffers are queued for cleanup post-completion.
Feedback to deployment service: Positive feedback signals readiness for rollout.Cleanup: FlatBuffers are freed asynchronously by the master process after all workers load updates à October 29 outage occurred during this step due to a latent bug in reference counting logic.

The October incidents showed we needed to strengthen key aspects of configuration validation, propagation safeguards, and runtime behavior. During the Azure Front Door incident on October 9^th, that protection system worked as intended but was later bypassed by our engineering team during a manual cleanup operation. During this Azure Front Door incident on October 29^th, the incompatible customer configuration metadata progressed through the protection system, before the delayed asynchronous processing task resulted in the crash.

Configuration propagation safeguards

Based on learnings from the incidents, we are implementing a comprehensive set of configuration resiliency improvements. These changes aim to guarantee that any sequence of configuration changes cannot trigger instability in the data plane, and to ensure quicker recovery in the event of anomalies.

Strengthening configuration generation safety

This improvement pivots on a ‘shift-left’ strategy where we want to ensure that we catch regression early before they propagate to production. It also includes fixing the latent defects which were the proximate cause of the outage.

Fixing outage specific defects - We have fixed the control-plane defects that could generate incompatible tenant metadata under specific operation sequences. We have also remediated the associated data-plane defects.
Stronger cross-version validation - We are expanding our test and validation suite to account for changes across multiple control plane build versions. This is expected to be fully completed by February 2026.
Fuzz testing - Automated fuzzing and testing of metadata generation contract between the control plane and the data plane. This allows us to generate an expanded set of invalid/unexpected configuration combinations which might not be achievable by traditional test cases alone. This is expected to be fully completed by February 2026.

Preventing incompatible configurations from being propagated

This segment of the resiliency strategy strives to ensure that a potentially dangerous configuration change never propagates beyond canary stage.

Protection system is “always-on” - Enhancements to operational procedures and tooling prevent bypass in all scenarios (including internal cleanup/maintenance), and any cleanup must flow through the same guarded stages and health checks as standard configuration changes. This is completed.
Making rollout behavior more predictable and conservative - Configuration processing in the data plane is now fully synchronous. Every data plane issue due to incompatible meta data can be detected withing 10 seconds at every stage. This is completed.
Enhancement to deployment pipeline - Additional stages during roll-out and extended bake time between stages serve as an additional safeguard during configuration propagation. This is completed.
Recovery tool improvements now make it easier to revert to any previous version of LKG with a single click. This is completed.

These changes significantly improve system safety. Post-outage we have increased the configuration propagation time to approximately 45 minutes. We are working towards reducing configuration propagation time closer to pre-incident levels once additional safeguards covered in the Data plane resiliency section below are completed by mid-January, 2026.

Data plane resiliency

The data plane recovery was the toughest part of recovery efforts during the October incidents. We must ensure fast recovery as well as resilience to configuration processing related issues for the data plane. To address this, we implemented changes that decouple the data plane from incompatible configuration changes. With these enhancements, the data plane continues operating on the last known good configuration—even if the configuration pipeline safeguards fail to protect as intended.

Decoupling data plane from configuration changes

Each server’s data plane consists of a master process which accepts configuration changes and manages lifecycle of multiple worker processes which serve customer traffic. One of the critical reasons for the prolonged outage in October was that due to latent defects in the data plane, when presented with a bad configuration the master process crashed. The master is a critical command-and-control process and when it crashes it takes down the entire data plane, in that node. Recovery of the master process involves reloading hundreds of thousands of configurations from scratch and took approximately 4.5 hours.

We have since made changes to the system to ensure that even in the event of the master process crash due to any reason - including incompatible configuration data being presented - the workers remain healthy and able to serve traffic. During such an event, the workers would not be able to accept new configuration changes but will continue to serve customer traffic using the last known good configuration. This work is completed.

Introducing Food Taster: strengthening config propagation resiliency

In our efforts to further strengthen Azure Front Door’s configuration propagation system, we are introducing an additional configuration safeguard known internally as Food Taster which protects the master and worker processes from any configuration change related incidents, thereby ensuring data plane resiliency.

The principle is simple: every data-plane server will have a redundant and isolated process – the Food Taster – whose only job is to ingest and process new configuration metadata first and then pass validated configuration changes to active data plane. This redundant worker does not accept any customer traffic.

All configuration processing in this Food Taster is fully synchronous. That means we do all parsing, validation, and any expensive or risky work up front, and we do not move on until the Food Taster has either proven the configuration is safe or rejected it. Only when the Food Taster successfully loads the configuration and returns “Config OK” does the master process proceed to load the same config and then instruct the worker processes to do the same. If anything goes wrong in the Food Taster, the failure is contained to that isolated worker; the master and traffic-serving workers never see that invalid configuration.

We expect this safeguard to reach production globally in January 2026 timeframe. Introduction of this component will also allow us to return closer to pre-incident level of configuration propagation while ensuring data plane safety.

Closing

This is the first in a series of planned blogs on Azure Front Door resiliency enhancements. We are continuously improving platform safety and reliability and will transparently share updates through this series. Upcoming posts will cover advancements in tenant isolation and improvements to recovery time objectives (RTO).

We deeply value our customers’ trust in Azure Front Door. The October incidents reinforced how critical configuration resiliency is, and we are committed to exceeding industry expectations for safety, reliability, and transparency. By hardening our configuration pipeline, strengthening safety gates, and reinforcing isolation boundaries, we’re making Azure Front Door even more resilient so your applications can be too.

Azure Networking 2025: Powering cloud innovation and AI at global scale

Sudha_Mahajan — Thu, 18 Dec 2025 23:20:29 GMT

In 2025, Azure’s networking platform proved itself as the invisible engine driving the cloud’s most transformative innovations. Consider the construction of Microsoft’s new Fairwater AI datacenter in Wisconsin – a 315-acre campus housing hundreds of thousands of GPUs. To operate as one giant AI supercomputer, Fairwater required a single flat, ultra-fast network interconnecting every GPU. Azure’s networking team delivered: the facility’s network fabric links GPUs at 800 Gbps speeds in a non-blocking architecture, enabling 10× the performance of the world’s fastest supercomputer. This feat showcases how fundamental networking is to cloud innovation. Whether it’s uniting massive AI clusters or connecting millions of everyday users, Azure’s globally distributed network is the foundation upon which new breakthroughs are built.

In 2025, the surge of AI workloads, data-driven applications, and hybrid cloud adoption put unprecedented demands on this foundation. We responded with bold network investments and innovations. Each new networking feature delivered in 2025, from smarter routing to faster gateways, was not just a technical upgrade but an innovation enabling customers to achieve more. Recapping the year’s major releases across Azure Networking services and key highlights how AI both drive and benefit from these advancements.

Unprecedented connectivity for a hybrid and AI era

Hybrid connectivity at scale: Azure’s network enhancements in 2025 focused on making global and hybrid connectivity faster, simpler, and ready for the next wave of AI-driven traffic. For enterprises extending on-premises infrastructure to Azure, Azure ExpressRoute private connectivity saw a major leap in capacity: Microsoft announced support for 400 Gbps ExpressRoute Direct ports (available in 2026) to meet the needs of AI supercomputing and massive data volumes. These high-speed ports – which can be aggregated into multi-terabit links – ensure that even the largest enterprises or HPC clusters can transfer data to Azure with dedicated, low-latency links. In parallel, Azure VPN Gateway performance reached new highs, with a generally available upgrade that delivers up to 20 Gbps aggregate throughput per gateway and 5 Gbps per individual tunnel. This is a 3× increase over previous limits, enabling branch offices and remote sites to connect to Azure even more seamlessly without bandwidth bottlenecks. Together, the ExpressRoute and VPN improvements give customers a spectrum of high-performance options for hybrid networking – from offices and datacenters to the cloud – supporting scenarios like large-scale data migrations, resilient multi-site architectures, and hybrid AI processing.

Simplified global networking: Azure Virtual WAN (vWAN) continued to mature as the one-stop solution for managing global connectivity. Virtual WAN introduced forced tunneling for Secure Virtual Hubs (now in preview), which allows organizations to route all Internet-bound traffic from branch offices or virtual networks back to a central hub for inspection. This capability simplifies the implementation of a “backhaul to hub” security model – for example, forcing branches to use a central firewall or security appliance – without complex user-defined routing.

Empowering multicloud and NVA integration: Azure recognizes that enterprise networks are diverse. Azure Route Server improvements enhanced interoperability with customer equipment and third-party network virtual appliances (NVAs). Notably, Azure Route Server now supports up to 500 virtual network connections (spokes) per route server, a significant scale boost that enables larger hub-and-spoke topologies and simplified Border Gateway Protocol (BGP) route exchange even in very large environments. This helps customers using SD-WAN appliances or custom firewalls in Azure to seamlessly learn routes from hundreds of VNet spokes – maintaining central routing control without manual configuration. Additionally, Azure Route Server introduced a preview of hub routing preference, giving admins the ability to influence BGP route selection (for example, preferring ExpressRoute over a VPN path, or vice versa). This fine-grained control means hybrid networks can be tuned for optimal performance and cost.

Resilience and reliability by design

Azure’s growth has been underpinned by making the network “resilient by default.”

We shipped tools to help validate and improve network resiliency. ExpressRoute Resiliency Insights was released for general availability – delivering an intelligent assessment of an enterprise’s ExpressRoute setup. This feature evaluates how well your ExpressRoute circuits and gateways are architected for high availability (for example, using dual circuits in diverse locations, zone-redundant gateways, etc.) and assigns a resiliency index score as a percentage. It will highlight suboptimal configurations – such as routes advertised on only one circuit, or a gateway that isn’t zone-redundant – and provide recommendations for improvement. Moreover, Resiliency Insights includes a failover simulation tool that can test circuit redundancy by mimicking failures, so you can verify that your connections will survive real-world incidents. By proactively monitoring and testing resilience, Azure is helping customers achieve “always-on” connectivity even in the face of fiber cuts, hardware faults, or other disruptions.

Security, governance, and trust in the network

As enterprises entrust more core business to Azure, the platform’s networking services advanced on security and governance – helping customers achieve Zero Trust networks and high compliance with minimal complexity. Azure DNS now offers DNS Security Policies with Threat Intelligence feeds (GA). This capability allows organizations to protect their DNS queries from known malicious domains by leveraging continuously updated threat intel. For example, if a known phishing domain or C2 (command-and-control) hostname appears in DNS queries from your environment, Azure DNS can automatically block or redirect those requests. Because DNS is often the first line of detection for malware and phishing activities, this built-in filtering provides a powerful layer of defense that’s fully managed by Azure. It’s essentially a cloud-delivered DNS firewall using Microsoft’s vast threat intelligence – enabling all Azure customers to benefit from enterprise-grade security without deploying additional appliances.

Network traffic governance was another focus. The introduction of forced tunneling in Azure Virtual WAN hubs (preview) shared above is a prime example where networking meets security compliance.

Optimizing cloud-native and edge networks

We previewed DNS intelligent traffic control features – such as filtering DNS queries to prevent data exfiltration and applying flexible recursion policies – which complement the DNS Security offering in safeguarding name resolution. Meanwhile, for load balancing across regions, Azure Traffic Manager’s behind-the-scenes upgrades (as noted earlier) improved reliability, and it’s evolving to integrate with modern container-based apps and edge scenarios.

AI-powered networking: Both enabling and enabled by AI

We are infusing AI into networking to make management and troubleshooting more intelligent. Networking functionality in Azure Copilot accelerates tasks like never before: it outlines the best practices instantly and troubleshooting that once required combing through docs and logs can be conversational. It effectively democratizes networking expertise, helping even smaller IT teams manage sophisticated networks by leveraging AI recommendations.

The future of cloud networking in an AI world

As we close out 2025, one message is clear: networking is strategic. The network is no longer a static utility – it is the adaptive circulatory system of the cloud, determining how far and fast customers can go. By delivering higher speeds, greater reliability, tighter security, and easier management, Azure Networking has empowered businesses to connect everything to anything, anywhere – securely and at scale. These advances unlock new scenarios: global supply chains running in real-time over a trusted network, multi-player AR/VR and gaming experiences delivered without lag, and AI models trained across continents.

Looking ahead, AI-powered networking will become the norm. The convergence of AI and network tech means we will see more self-optimizing networks that can heal, defend, and tune themselves with minimal human intervention.

Network Detection and Response (NDR) in Financial Services

Marc de Droog — Thu, 18 Dec 2025 08:31:59 GMT

Organizations in the Financial Services industry handling sensitive account holder information must comply with the Payment Card Industry Data Security Standard (PCI DSS). The latest version, PCI DSS v4.0.1 of June 2024, reinforces the requirements for network security monitoring.

Traditional network security tools, such as firewalls and Intrusion Detection and Prevention Systems (IDPS), struggle to meet these requirements because they either lack deep visibility or generate too many false positives. This is where Network Detection and Response (NDR) comes in. NDR solutions look at the network traffic within the Cardholder Data Environment (CDE) and use advanced methods (behavioral analytics, machine learning, threat intel) to detect anomalies or attacks in real-time, and facilitate quick responses.

This post explains how NDR supports PCI DSS v4.0.1 compliance, with a focus on deployments in Azure. We will map NDR capabilities to key PCI requirements, describe how Azure’s native tools (Azure Virtual Network TAP, VNET Flow Logs, Traffic Analytics) enable an NDR solution by capturing network data, and discuss third-party NDR tools that analyze this data for threats.

We will also evaluate Microsoft Sentinel’s role as a partial NDR solution, and highlight how Microsoft Defender for Cloud contributes to PCI compliance.

The role of NDR in PCI DSS Compliance

PCI DSS v4.0.1 is organized into 12 main requirement areas. NDR technology primarily supports the control objectives in Requirement 10 (“Log and Monitor All Access to System Components and Cardholder Data”) and Requirement 11 (“Test Security of Systems and Networks Regularly”) , while also aiding in demonstrating compliance with Requirement 4 ("Protect Cardholder Data with Strong Cryptography ...") and Requirement 12 ("Support Information Security with Organizational Policies and Programs").

Below is how NDR aids in building compliance with these controls:

Logging & Monitoring

Organizations are required to “log and monitor all access to system components and cardholder data”. Requirement 10.4.1 calls for automated mechanisms to perform log reviews and detect anomalies at least daily. An NDR solution addresses this by automatically analyzing network traffic logs and generating alerts for suspicious behavior. Every connection or data transfer involving cardholder systems is continuously scrutinized.

For example, if a database containing card data suddenly starts sending large amounts of data to an unfamiliar server, NDR will log that event and flag it for investigation immediately. This satisfies the intent of Requirement 10 by ensuring that not only are network events being recorded, but they are also under active surveillance at all times. NDR essentially serves as an automated network log reviewer, catching things a manual review might miss. This helps meet Requirement 10’s mandate for timely review so that "... incidents can be quickly identified and proactively addresses."

Intrusion Detection

Requirement 11.5 requires the use of intrusion-detection and/or prevention systems (IDS/IPS) at the perimeter of, and at critical points within the CDE. Additionally, 11.5.1.1 requires service providers to employ IDS to detect covert communication attempts, such as malware trying to reach a command-and-control server.

NDR solutions fulfill the role of an IDS by continuously inspecting network traffic for attack signatures and unusual patterns. But NDR goes beyond a legacy IDS: instead of only matching known signatures, it also uses behavior analysis to catch “zero-day” or insider threats (for example, an NDR might detect lateral movement within the network based on abnormal access patterns, even if no signature exists for that behavior). All traffic inbound to, outbound from, and within the CDE is watched and any suspect activity is alerted on.

Showing an NDR solution is in place will satisfy auditors that “Intrusion-detection and/or intrusion prevention techniques are used to detect and/or prevent intrusions into the network”. The high fidelity of NDR alerts (versus older IDS with many false positives) also means the organization is more likely to respond to real incidents – aligning with PCI’s push for effective, risk-based security.

Network Segmentation and Scope Reduction

While not a direct requirement but rather guidance to Requirement 12.5, network segmentation of the Cardholder Data Environment is encouraged to reduce scope - i.e. the sections of the entire environment that are subject to compliance with PCI DSS.

If segmentation is used, it must be monitored. NDR assists here by monitoring the network boundaries of the CDE. It can verify that only allowed communications occur across segments. For instance, if the CDE is isolated such that only a particular jump server should access it, and somehow a developer’s workstation tries to directly communicate with a CDE database, NDR would spot that anomaly. That alert would indicate a segmentation failure or misconfiguration that needs fixing. This continuous oversight helps prove that segmentation is effective (PCI assessors may ask for evidence that the segmentation was tested; NDR alerts or logs showing no unauthorized access attempts over months is strong evidence).

Secure Network Traffic and Encryption

Requirement 4.2 requires that cardholder data sent over networks is encrypted with strong cryptography. NDR tools can help enforce this by detecting unencrypted sensitive traffic or usage of weak protocols. Many NDR solutions will recognize when Primary Account Numbers (PANs) or Sensitive Authentication Data (SAD) appear in plaintext in network traffic and raise an alert. They also often track the SSL/TLS versions and cipher suites used in connections. For example, an NDR can alert if a server in the CDE is accepting TLS 1.0 or if any data is transmitted without encryption where encryption is expected.

Azure VNET Flow Logs provide an “encryption flag” for flows when VNET Encryption is used, which NDR or analytics can use to quickly identify non-encrypted channels. While the primary responsibility for encryption lies in configuration (enabling encryption at the application- (TLS) and infrastructure (VNET Encryption) layers), NDR provides verification. It detects PAN or SAD sent in the clear, and thus supports compliance with Requirement 4. If the NDR never or rarely alerts on cleartext, that’s evidence encryption is consistently applied; if it does alert, it allows quick remediation.

Incident Detection and Response

An incident response plan and processes for reacting to security events must be in place per Requirement 12.5. NDR significantly enhances an organization’s ability to detect and respond to incidents in a timely manner. By providing real-time alerts with rich context (like packet captures or detailed flow info), NDR ensures that when an intrusion or suspicious event happens, the security team is immediately notified with the information needed to act. With NDR integrated to alerting systems, companies can demonstrate that network alerts are automatically generated and investigated as part of their incident response program.

For example, if NDR generates an alert about malware beaconing from a server, the analyst can respond via playbooks (possibly automated, as we’ll discuss with Sentinel) to isolate that server, and later documentation will show the alert and response timeline. This satisfies PCI’s expectation that you not only have monitoring (Req.10/11) but also act on it swiftly (Req. 12.10.5, which expects alerts to trigger the incident response process). Furthermore, the forensic data from NDR (like packet logs) will help in the investigation phase of incident response – determine what data might have been accessed, which systems were affected, etc., which is crucial for PCI breach reporting.

NDR is a key sensor feeding the incident response process, and having it in place with documented procedures closes the loop on several PCI requirements (monitor, detect, respond).

Azure Native Tools for Enabling NDR

In Azure, implementing NDR starts with capturing the right data. Azure provides native tools to mirror network traffic and collect flow information, which NDR systems (or Azure’s own analytics) can then analyze. Key Azure-native components are Azure Virtual Network TAP, Virtual Network (VNET) Flow Logs, and Traffic Analytics.

Azure Virtual Network TAP

Virtual Network TAP (Terminal Access Point) (VTAP) copies network traffic from source Virtual Machines to a collector or traffic analytics tool, running as a Network Virtual Appliance (NVA). VTAP creates a full copy of the traffic, including packet payload content. Traffic collectors and analytics tools are 3rd party partner products, amongst which are the major NDR solutions. VTAP is an agentless, cloud-native traffic tap at the Azure network infrastructure level. It is entirely out-of-band; it has no impact on the source VM's network performance and the source VM is unaware of the tap. Tapped traffic is VXLAN-encapsulated and delivered to the collector NVA, either in the same or a peered VNET as the source VMs.

VTAP is crucial to building a PCI DSS compliant CDE in Azure: full visibility of all network traffic enables implementation of the IDS functionality specified in Requirement 11.5. All traffic involving cardholder data systems can be monitored: not only traffic to/from the internet, but also East-West traffic between VMs. By deploying VTAP on the subnets that make up the CDE, anything suspicious on those networks is seen. This helps meet the requirements of monitoring " ... at the perimeter of the CDE" and “ ... at critical points inside the CDE”, without needing agents on each VM.

Azure VTAP provides the raw network data pipeline needed for NDR. In a PCI audit, citing the use of VTAP plus an NDR appliance as evidence that “all network traffic is being captured and analyzed” is a strong compliance position.

Virtual Network Flow Logs

Virtual Network Flow Logs (VNET Flow Logs) capture IP traffic flow metadata of traffic in a virtual network, which includes source- and destination IP addresses, Layer 4 (transport) protocol and port numbers, flow direction and state, and encryption status. Flow Logs also show whether the flow was allowed or denied by a Network Security Group (NSG) or a Security Admin Rule. VNET Flow Logs do not capture traffic content - they record who talks to whom, with all the details, but not what is said. Log records are written to a storage account in JSON format, and from there can be read for analysis by Azure Traffic Analytics and 3rd party analytics tools such as Security Information and Event Management (SIEM) and NDR solutions.

From a PCI perspective, VNET Flow Logs serve as a comprehensive audit trail of network activity. They show every connection to and from systems in the CDE including source, destination, and whether it was permitted or blocked. This supports Requirement 10 (Log and Monitor All Access) – retain these logs for the required 12 months as evidence all network access attempts are logged.

During daily monitoring, these logs can be queried to find anomalies through Traffic Analytics or a SIEM. For example, a regular query would be: “show any flows from CDE subnet to external IPs not on the whitelist” – any results would indicate a potential policy violation or compromise. If NDR is the heart of real-time detection, flow logs are the record-keeper that ensures nothing slips by unrecorded. Even if an attacker stays under the radar of detection, flow logs later allow forensic analysis to trace their actions. Azure’s VNET flow logs being ubiquitous and simple to enable means organizations have little reason not to log all network traffic. It is a baseline best practice that also satisfies the PCI DSS logging mandate. Enabling flow logs and keeping them in Azure Storage with access controls fulfills PCI requirements around log integrity and access control. They essentially answer, “If an auditor asks to see who communicated with the DB server on June 1 at 3PM, can you show that?” – with flow logs, yes, you can.

Traffic Analytics

Traffic Analytics is an Azure service that processes Flow Logs to provide insights and visualizations. Once VNET Flow Logs are enabled, Traffic Analytics can read the raw logs at 10 minute- or hourly intervals and process them into insightful information. This information is stored in a Azure Log Analytics workspace for further evaluation. Traffic Analytics includes ready-made dashboards in the Azure Portal and its consolidated flow information is available for evaluation through Kusto queries, and tools such as Azure Sentinel and third party SIEMs.

Traffic Analytics will aggregate flows and show things like top talkers (top source/destination IPs), traffic distribution (ports, protocols), and importantly, flagged security issues. For example, it can identify if a VM has an open port to the internet that is unusual, or if there is traffic to an IP address that Microsoft Threat Intelligence marks as malicious (these show up as “MaliciousFlow” in the output). It can also highlight sudden changes in traffic volume or a high number of denied flows (potential port scan or attack attempts).

Think of Traffic Analytics as a built-in basic NDR-lite or network SIEM for Azure: it won’t catch advanced threats, but it will definitely surface misconfigurations and obvious red flags. From a compliance standpoint, Traffic Analytics is useful for demonstrating proactive monitoring. Instead of showing an auditor raw JSON logs, demonstrate Traffic Analytics: e.g., “In the last week, these were the only external connections and all were expected, and no malicious IPs contacted.” It helps satisfy the requirement that logs and network events are reviewed daily, by providing an easy to interpret summary that can be checked at a glance. If something is noted (like an unexpected open port), this can be remediated as part of security operations, showing the auditor that not only do traffic is logged, it is analyzed and acted upon.

It is important to note Traffic Analytics is not a full threat detection system – it is rule-based and limited to what can be inferred from flow records (Layer 3/4 info). It does not inspect payloads (no Layer 7 analysis) and it may not catch subtler anomalies (e.g., data exfiltration hiding in allowed HTTPS traffic might not trigger any obvious threshold in flow stats). Therefore, while it is a great native feature and certainly helps with compliance reporting, for robust NDR one would use Traffic Analytics as a supplement to, not a replacement for, an advanced NDR platform. In Azure, many customers use Traffic Analytics for general network hygiene monitoring and feed its findings into Sentinel or a SIEM for follow-up.

In summary, Azure’s native network monitoring tools lay the groundwork for NDR by capturing the necessary data:
• Azure VTAP provides full-fidelity packet capture (the raw material for deep detection).
• VNET Flow Logs provide broad coverage of who talked to whom and when (excellent for audit and pattern analysis).
• Traffic Analytics provides immediate insights from those logs (great for compliance checks and basic anomaly spotting).

The next step is feeding this data to powerful analytics engines to actually perform the “detection and response” – that’s where third-party NDR or advanced Azure services come into play.

Advanced Analysis with Third-Party NDR Solutions

Azure’s native capabilities collect the raw data, but effective threat detection requires specialized analytics beyond what Azure provides. This is where third-party NDR solutions are indispensable. These solutions ingest the packet or flow data and use their own engines to detect threats like intrusions, malware traffic, or policy violations in real time.

Third-party NDR platforms bring mature, cutting-edge detection algorithms that have been refined on large datasets and numerous environments. They often use a combination of machine learning (for anomaly detection) and signature/threat intelligence (for known threat detection). Azure’s Traffic Analytics or basic Defender for Cloud alerts might report, for instance, that a VM made an outbound connection on an unusual port, but a third-party NDR could dig deeper and say “that connection contained data patterns consistent with credit card numbers in clear text” or “this series of packets matches the behavior of the Cobalt Strike beacon malware.”

NDR solutions do deep packet inspection (DPI) and behavioral analysis to catch subtle threats and minimize false positives. For organizations in Financial Services, targeted by Advanced Persistent Threats and sophisticated attackers, this level of insight is crucial. It is also necessary for meeting the spirit of PCI’s IDS requirement – a smarter IDS means fewer missed intrusions. Many third-party NDRs also come with features like user/device identification, threat chain visualization, and built-in compliance reporting specific to PCI or other standards.

Microsoft has worked with numerous security vendors to ensure their NDR solutions work seamlessly in Azure. The Virtual Network TAP partner list includes vendors in two broad categories: network packet brokers and security analytics/NDR solutions.

Network Packet Brokers (e.g., Gigamon, Keysight): These tools focus on aggregating, filtering, and distributing the tapped traffic. Their strength is handling large volumes of data and directing it efficiently to multiple analysis tools. For instance, Gigamon’s GigaVUE for Azure can take the VTAP stream, filter out irrelevant traffic, and feed it to both an NDR and a performance monitoring tool simultaneously. The advantage is scalability and flexibility; the limitation is that packet brokers themselves typically don’t do deep threat analysis – they are complementary infrastructure.
Security Analytics / NDR Platforms (e.g., Darktrace, Vectra, ExtraHop, Corelight, Fortinet, Netscout, Trend Micro, Arista, etc.): These are the actual brains performing threat detection. Each has its strengths:

o AI-Driven NDR: Solutions like Darktrace and Vectra AI emphasize machine learning to establish a baseline of normal network behavior and then detect anomalies. Darktrace, for example, uses unsupervised AI to identify subtle deviations that could indicate a threat (like a device that suddenly starts connecting to a new domain at odd hours). These are good at catching novel or insider threats. They often come with insightful visualization of network patterns. A possible limitation is they can sometimes produce alerts that require expert interpretation (why did the AI flag this?), but vendors have improved in providing explainability.

o Protocol/Behavioral NDR: ExtraHop Reveal(x), Corelight (Zeek) and Netscout Omnis focus on deep packet and protocol analysis. ExtraHop decodes dozens of protocols (DNS, database protocols, cloud service APIs) in real-time and can detect specific issues like database exfiltration or use of deprecated TLS versions. It was even audited to exceed PCI IDS requirements by using behavior-based detections. Corelight uses the open-source Zeek (Bro) engine to log detailed metadata about traffic, which can be incredibly rich for investigation and custom detection scripts. Strength: very detailed, low false positives when tuned; limitation: may require more tuning or skilled users to get the most out of raw data (Corelight, for example, gives you great data but you might still need a SIEM or Splunk queries to raise the alerts).

o Integrated Ecosystem Solutions: Fortinet and Arista are examples where NDR is part of a broader security ecosystem. Fortinet’s FortiNDR is attractive if you already use Fortinet, as the logs and management tie into FortiAnalyzer and you can leverage FortiGuard threat intel. A FortiGate VM can receive mirrored traffic and apply its IPS/IDS signatures and even ML-based detections. Arista Networks (which acquired Awake Security) offers Arista NDR that’s known for entity-centric threat hunting – it builds profiles of devices on the network and can identify rogue or compromised systems by their traffic patterns. These integrated solutions often pair well with their own hardware or cloud frameworks (Fortinet with its firewalls, Arista with its switches), and can sometimes take automated actions (e.g., instruct a FortiGate to block an IP upon detection).

o Managed NDR Services: eSentire MDR for example provides technology plus a 24/7 human SOC. They deploy sensors that leverage VTAP (they are a VTAP partner) and their analysts review and respond to every alert. The strength is that you get expert eyes on everything (great for meeting PCI’s requirement that alerts are promptly addressed), and the weakness is relying on a third-party – though for many, outsourcing this is prudent.

In practice, an organization in the Financial Services Industry will choose a combination of these based on the specifics of their environment, their compliance needs and existing tools and capabilities. Some might use a packet broker and an NDR together (e.g., Gigamon to optimize traffic flow and ExtraHop to analyze it). Others might use an all-in-one virtual appliance from a vendor like Vectra that directly handles ingestion and analysis.

Sentinel: Complimentary to NDR

Microsoft Sentinel is Azure’s native Security Information and Event Management (SIEM) and orchestration platform. It aggregates logs from many sources runs analytics on them. It is a powerful tool for security monitoring, but it is not specialized for network traffic analysis in the way NDR solutions are.

Let's look at how Sentinel factors into the NDR/compliance equation:

Log Centralization and Correlation: Sentinel ingests Azure VNET Flow Logs and Azure Firewall- and third party firewall logs, as well as alerts from NDR platforms, and any other relevant data (event logs from servers, Azure AD logs, etc.), and aggregates and correlates these events. This is very valuable in daily operations and in investigations - it suppresses the noise, surfacing meaningful, actionable events to security staff. For PCI DSS compliance, having a central SIEM like Sentinel helps satisfy the requirement that logged events are aggregated and reviewed.
Built-in Analytics for Network Events: Sentinel provides default analytics rules and allows custom rule creation using Kusto Query Language (KQL). For network monitoring, one could create rules such as:

o “Alert if more than 50 denied flows hit a CDE server in 5 minutes” (indicating a possible attack).

o “Alert if any flow originates from an IP known in Threat Intelligence to be malicious” (Sentinel integrates threat intel feeds).

o “Alert if a normally internal-only VM initiates outbound traffic” (indicating a potentially compromised server).

These can catch some intrusion attempts. However, setting up robust network anomaly detection in Sentinel requires effort and expertise. Out-of-the-box, Sentinel does not come with a comprehensive library of network threat detection rules – it might have a few (like detecting port scan patterns or spikes in traffic) but not the depth of an NDR product.

No Deep Packet Inspection: Sentinel cannot analyze raw packet payloads or protocol details beyond what is in logs. It relies on sources like flow logs which only have IP/port info, or on other products (like an NDR or IDS) to generate an alert that Sentinel then ingests. This is a fundamental limitation – for example, Sentinel by itself would not be able to detect that an SQL query contained a suspicious UNION SELECT (something an NDR inspecting the SQL protocol might catch). Therefore, Sentinel alone, without something feeding it detailed alerts, would likely miss many attack techniques that do not manifest in log data.
Alert Fatigue and Tuning: If one tried to use Sentinel as the primary IDS by writing custom rules on flow logs, one might end up with a lot of false positives or noise that needs tuning. NDR vendors invest heavily in fine-tuning detections to be as accurate as possible in network context (for example, distinguishing a legitimate network scan by a vulnerability management tool from a malicious scan by an attacker). With Sentinel, that tuning burden falls on the security team. While Sentinel’s analytics can be quite sophisticated, practically, in-house development of NDR logic in Sentinel is reinventing the wheel.
Compliance Sufficiency: Could Sentinel alone satisfy PCI DSS requirements for IDS? In theory, if configured to ingest all relevant logs and set up with analytics to alert on suspicious network events, Sentinel might convince an assessor. For example, using Azure Firewall or a third-party firewall that outputs logs to Sentinel, and Sentinel alerting on those logs (like on intrusion signatures those firewalls catch), might tick the box. However, most auditors expect a dedicated IDS/IPS or NDR technology rather than a custom SIEM query solution. The PCI DSS 4.0.1 guidance explicitly talks about IDS/IPS having up-to-date signatures or detection capabilities for common threats – Sentinel by itself doesn’t maintain a library of network attack signatures; that’s not its function. Moreover, Requirement 11.5.1 basically assumes a distinct IDS/IPS tool. Sentinel would likely be viewed as supplemental – great for aggregating alerts, but not the generator of those alerts.
Incident Response Automation: Sentinel is extremely valuable in orchestrating responses. It can trigger playbooks (with Logic Apps) based on alerts. If an NDR alert comes in (or a custom Sentinel alert triggers), Sentinel can automate actions: isolate a VM by applying a new NSG, disable a user account in Azure AD, send notifications to the team. Sentinel can log the whole process for audit. Having such automation shows you not only detect, but respond swiftly and consistently – aligning with PCI’s incident response testing requirements. Sentinel also retains incident history, which helps in the PCI requirement for reviewing security incidents and responses as part of annual processes.

In conclusion, Sentinel is best seen as complimentary to NDR rather than as a complete NDR solution in itself.

It is excellent in terms of log management and initiating responses (covering aspects of Requirements 10 and 12), but on its own it doesn’t fulfill the technical depth of Requirement 11’s intrusion detection. It’s best thought of as the “nerve center” that an NDR (the “sensory organ”) feeds into. In an ideal Azure PCI deployment, you would use Sentinel alongside an NDR: the NDR detects the nuanced network threats and sends alerts to Sentinel; Sentinel then correlates those with other info and kicks off response actions.

Microsoft Defender for Cloud and PCI DSS Compliance

Defender for Cloud is Azure’s Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platform (CWPP). It continuously assesses your Azure (and multi-cloud) resources against security best practices and provides threat protection via various “Defender” plans (for VMs, databases, storage, etc.). When it comes to PCI DSS compliance, Defender for Cloud is a useful service because it can map your Azure environment to PCI requirements and help automate compliance checking.

Here’s how Defender for Cloud contributes:

Regulatory Compliance Dashboard – Defender for Cloud has a built-in compliance dashboard where you can enable the PCI DSS v4.0.1 standard for your Azure environment, which can span multiple subscriptions. It shows a control-by-control assessment of compliance, based on Azure Policy and Defender scans. For example, it will check that VMs have disk encryption enabled, that Key Vaults have soft delete enabled, that network watchers are enabled, etc., mapping to various PCI controls. It won’t automatically check every single PCI requirement (some require manual processes), but it covers those that can be programmatically assessed. This is extremely helpful for preparing for an audit – you get a compliance score, see where gaps are, then remediate them. The dashboard essentially translates Azure’s security state into PCI language, saving a lot of manual effort. A practical example: for network-specific controls, it might check that NSGs are present on subnets, or that flow logging is enabled (to meet monitoring requirements).
Continuous Configuration Monitoring – Many PCI requirements are about having proper configurations (e.g., secure configurations for systems, firewalls in place, no default passwords). Defender for Cloud continuously monitors Azure resources and generates security recommendations when something deviates from best practice (many of which align with PCI controls). For instance, if a critical VM in the CDE is missing an NSG or has a rule allowing “Any” source, Defender for Cloud will flag that as a recommendation to fix – effectively catching a potential PCI violation early. It also checks for things like missing vulnerability assessments on SQL, or unencrypted traffic on storage, etc. By following Defender’s recommendations, you inherently move toward PCI compliance. This addresses the preventive side of PCI – e.g., Requirement 1 (firewall configuration) and Requirement 2 (secure system configurations) are supported by these continuous assessments.
Threat Detection and Alerts: Defender for Cloud includes Defender plans for various resources that provide threat detection. For example, Defender for Servers monitors VMs for suspicious processes, malware, and also does file integrity monitoring (FIM). FIM is actually a PCI Requirement (11.5) – you must monitor critical system files for changes. By enabling Defender for Servers on your Azure VMs, you fulfill this, as it uses the Defender for Endpoint agent to track file changes and generate alerts if, say, system binaries are modified unexpectedly. Additionally, Defender for Servers and other plans generate network-related security alerts: e.g., “Potential malicious outbound connection from VM” or “Port scanning activity detected from VM.” These come from analyzing the VM’s telemetry and network flows. While not as comprehensive as a dedicated NDR, these built-in alerts offer a baseline IDS capability. For example, if a VM in the CDE starts port scanning others, Defender for Cloud will flag it, which covers the requirement that you should detect internal reconnaissance. There are also alerts like “Suspicious SQL query activity” for Azure SQL or “Anomalous access pattern” for storage accounts. All Defender for Cloud alerts appear in its Security Alerts blade, and can be forwarded to Sentinel. From a PCI perspective, having these alerts means you have multiple layers of monitoring (host-level and network-level), which is ideal. It demonstrates that even if an attack doesn’t trigger an NDR network alert, it might trigger a host alert that you’re also watching.
Adaptive Network Hardening: This feature of Defender for Cloud looks at your NSG rules and actual traffic and recommends hardening (like “these IPs are the only ones seen accessing your VM, consider tightening NSG to only those”). By following these, you reduce your attack surface, which indirectly helps comply with PCI network access restrictions. It is not a mandated control, but it’s a good practice.
Vulnerability Management: Though not directly NDR, Defender for Cloud’s integrated vulnerability scanning (through Qualys or Defender’s scanner) helps satisfy PCI Requirement 11.3 (regular vulnerability scans) and Requirement 6 (address vulnerabilities). This is complementary to NDR – one stops attacks, the other prevents them by patching. It’s worth noting in compliance documentation that you use these Azure-native capabilities to meet various requirements.

In summary, Defender for Cloud acts as a compliance and security safety net. It ensures you have the right security controls configured (so that your NDR has a solid foundation to monitor), and it provides additional threat detection on Azure resources. For PCI DSS 4.0.1, which has many controls beyond just network monitoring, Defender for Cloud helps with:

Requirement 5 (anti-malware) by monitoring for malware on VMs.
Requirement 6/11 (vulnerability management and scanning) via its vulnerability assessments.
Requirement 10 (log retention) by advising enabling of diagnostic logs and storing them; and it keeps its alerts logs.
Requirement 11.5 (change detection) via File Integrity Monitoring on servers.
Requirement 8 (MFA, principle of least privilege) through Azure AD and Identity recommendations.
Requirement 12 (security policy and monitoring) by giving a centralized compliance view and integrating with incident workflows.

However, like Sentinel, Defender for Cloud is not a specialized NDR. Its network alerts are generally simpler (e.g., known malicious IP or basic port scan detection) and should not be solely relied on to meet the IDS requirement. They complement a true NDR or firewall IDS. A strong strategy is: use Defender for Cloud to get your Azure environment in a secure, compliant state (so all baseline controls are green), and use NDR to actively monitor and defend that environment from sophisticated attacks. The synergy of the two covers a vast swath of PCI requirements in a largely automated fashion.

Bringing it all together

The Financial Services Industry operates under intense security scrutiny, and PCI DSS v4.0.1 raises the bar further by requiring proactive and continuous network monitoring. Network Detection and Response (NDR) is a key technology that helps meet these challenges by providing advanced intrusion detection and full visibility into network traffic.

In the context of PCI DSS:

NDR ensures that all access to networks carrying cardholder data is monitored in real-time (fulfilling Requirement 10’s logging/monitoring mandate with automation).
It serves as the IDS/IPS required to detect malicious network activity (addressing Requirement 11’s call for intrusion detection).
It supports network segmentation by verifying that segmentation is not breached and alerting on any anomalous connection (thereby underpinning the isolation that PCI strongly recommends for scope reduction).
It feeds into a robust incident response workflow, enabling the organization to react swiftly to suspected breaches (covering the intent of Requirement 12.10 on incident response).

In Azure, achieving a PCI-compliant NDR setup is very feasible using a combination of Azure’s native capabilities and partner solutions. Azure provides the plumbing (VTAP for full packet mirror, VNET Flow Logs for thorough logging, Traffic Analytics for basic analysis) and the integration points (connecting to Sentinel, Defender for Cloud, etc.). Third-party NDR platforms bring in the sophisticated analysis that can identify threats with high accuracy, something that Azure’s basic tools alone might not catch. By leveraging both, organizations in Financial Services can create a layered defense:

Azure Defender for Cloud to maintain strong security posture and baseline compliance (it makes sure configurations are correct and provides some threat detection and compliance mapping).
Azure vTAP + Flow Logs to ensure no network activity goes unnoticed.
Advanced NDR to actually inspect traffic deeply and spot intrusions or policy violations in real-time.
Microsoft Sentinel to unify the monitoring, correlate across sources, and automate response, serving as the command center that ensures every alert is handled (thus meeting PCI’s expectation of prompt action and thorough monitoring records).

This layered approach not only checks the compliance boxes but also materially improves security. It demonstrates the principle that “compliance is the floor, not the ceiling” – the organization implements NDR not just to satisfy PCI requirements but to actively protect critical data.

For auditors and stakeholders, the combination of evidence from NDR, Azure logs, and Defender for Cloud provides confidence that the network is secure.

In conclusion, NDR is important in the financial sector for both security and compliance. PCI DSS 4.0.1 explicitly or implicitly requires capabilities that an NDR delivers (continuous monitoring, intelligent alerting, quick incident containment). Implementing NDR in Azure using the described architecture enables organizations in Financial Services to meet those requirements effectively. They gain peace of mind that their cloud cardholder data environment is under vigilant watch, and they stand on solid ground when undergoing PCI assessments. As threats are evolving and compliance standards are tightening, this blend of Azure technology and NDR solutions exemplifies best practice: using the full power of cloud and AI-driven security to protect sensitive financial data and maintain customer trust.