Azure Networking Blog articles

Route summarization in Azure Route Server

Fabrizio-Ferri — Wed, 04 Nov 2026 22:57:47 GMT

Why hybrid networks need native routing policy

Hybrid networks connect remote sites across multiple routing domains to an Azure Virtual Network (VNet). As these environments grow, you need a consistent way to control which routes Azure Route Server learns and advertises at the VNet boundary. That control matters wherever Azure Route Server exchanges routes with hybrid connections:

ExpressRoute and Azure VPN gateways: exchanged routes between Azure VNets and your on-premises networks.
Software-defined WAN (SD-WAN): manage routing across distributed branches and appliances.
Network virtual appliances (NVAs): control learned and advertised routes from remote sites or other clouds.

Without a native policy layer, your options for route control are limited, and they get harder to manage as the network grows.

This need becomes more urgent when branch-to-branch connectivity is enabled in Azure Route Server because routes can propagate across all connected networks. Production architectures, however, often require selective filtering, route summarization, segmentation, and predictable primary and backup paths.

Operational challenges without route maps

Without route maps, growing hybrid networks can become difficult to scale, secure, and operate. The main challenges include:

Route scale: Without inbound or outbound summarization, every specific prefix must be carried across the hybrid environment. Large deployments can approach or exceed Azure platform route limits, making routing tables harder to manage and troubleshoot. For example, if a VNet advertises more than 1,000 prefixes to an ExpressRoute circuit, the route limit is exceeded and the BGP session between the ExpressRoute gateway and the circuit is disconnected.
Path selection: When multiple connections reach the same remote site, customers need a straightforward way to define a preferred path and a backup path.
Network isolation: Unrestricted route propagation among SD-WAN, VPN, ExpressRoute, and NVA connections can expose segments to networks that should remain isolated.
Operational complexity in SD-WAN: Large SD-WAN deployments may require multiple NVAs for capacity and resiliency. Each appliance exchanges routes with the VNet, increasing the number of IP routes that operators must configure, monitor, and troubleshoot.

How route maps addresses these challenges

Route maps in Azure Route Server provide a native Azure policy layer for controlling the routes that enter and leave the VNet. They address the main operational challenges in the following ways:

Reduce route count: Summarize prefixes before they cross connection boundaries, reducing the number of propagated routes and helping limit routing-table growth.
Control path selection: Modify AS-PATH attributes to influence primary and backup path selection across hybrid connections.
Strengthen network isolation: Apply independent inbound and outbound policies to limit route exchange among SD-WAN, VPN, ExpressRoute, and NVA domains.
Simplify SD-WAN interoperability: Use BGP attribute manipulation to streamline route exchange with existing SD-WAN environments.
Enable downstream policy enforcement: Attach BGP communities that downstream devices can use to apply additional routing policies.

How route maps work

Route maps in Azure Route Server provide granular control over routes received from and advertised to hybrid networks.

You can apply route maps to the following connection types:

BGP peerings with a network virtual appliance (NVA) deployed in the virtual hub
ExpressRoute gateway connections
VPN gateway connections

If the NVA is deployed in a spoke virtual network, apply the route map to the hub's virtual network connection to that spoke.

An inbound route map processes routes as Azure Route Server learns them, whereas an outbound route map processes routes before Azure Route Server advertises them. Each route-map rule evaluates its configured match conditions and can modify route attributes, permit the route, or deny it. The following diagram illustrates this policy flow.

Core capabilities and supported connections

Route maps support route summarization, route filtering, path selection, and route tagging with BGP communities. They can advertise aggregate prefixes, control which routes enter or leave an Azure Route Server deployment, modify AS-PATH to influence preference, and attach BGP communities that downstream devices can use when applying routing policy.

You can apply route maps to BGP peerings with NVAs, ExpressRoute gateway connections, and Azure VPN gateway connections. Policies can be associated independently in the inbound and outbound directions, allowing the same connection to use different controls for received and advertised routes.

The following diagram shows three route maps, route-map1, route-map2, and route-map3, applied to an NVA peering, an Azure VPN gateway connections, and an ExpressRoute gateway connection, respectively.

With these capabilities in mind, consider a common use case: summarizing spoke VNet prefixes before advertising them to on-premises networks over ExpressRoute private peering.

Summarize spoke VNet prefixes for an ExpressRoute connection

For this walkthrough, consider a hub-and-spoke topology with 50 spoke VNets. The hub VNet contains an ExpressRoute gateway named er-gw and an Azure Route Server named rs1.

Each of the 50 spoke VNets uses two /24 prefixes, resulting in 100 individual routes. The first two spokes and the final spoke in the address range are shown below.

Spoke 1: 10.90.0.0/24 and 10.90.1.0/24

Spoke 2: 10.90.2.0/24 and 10.90.3.0/24

…

Spoke 50: 10.90.98.0/24 and 10.90.99.0/24

The spoke-to-hub and hub-to-spoke peerings are configured with the following settings:

Spoke-side virtual network peering setting
"allowVirtualNetworkAccess"	true
"allowForwardedTraffic"	true
"allowGatewayTransit"	false
"useRemoteGateways"	true
Hub-side virtual network peering setting
"allowVirtualNetworkAccess"	true
"allowForwardedTraffic"	true
"allowGatewayTransit"	true
"useRemoteGateways"	false

With the ExpressRoute gateway deployed in the hub, the spoke prefixes can be advertised to the connected on-premises network.

Before the route map is applied, the Azure Route Server Effective Routes include every individual spoke prefix.

The Azure private peering route table likewise lists the individual spoke prefixes advertised by autonomous system 65515. The following excerpt from the primary ExpressRoute connection’s routing table shows the routes before summarization is applied.

Because the spoke address spaces form a contiguous range from 10.90.0.0 through 10.90.99.255, the 100 /24 prefixes can be represented by three aggregate prefixes:

Subnet	Range	Addresses
10.90.0.0/18	10.90.0.0–10.90.63.255	16,384
10.90.64.0/19	10.90.64.0–10.90.95.255	8,192
10.90.96.0/22	10.90.96.0–10.90.99.255	1,024

Instead of advertising all 100 spoke prefixes to the on-premises network, an outbound route map can advertise only 10.90.0.0/18, 10.90.64.0/19, and 10.90.96.0/22. This substantially reduces the number of advertised routes while preserving reachability across the complete spoke address range.

The next step is to create an outbound route map named summarization1 in the Azure portal.

Open the Azure Route Server resource, select Routing > Route Maps, and then select Add Route-map.
On the Create Route-map page, enter the route map name, and then select Add Route-map rule.

Create three rules, one for each aggregate prefix. Together, these rules replace the more-specific spoke advertisements with the three summarized routes.

After all three rules are added, review the route map and confirm that each aggregate is represented.

Select Save to commit the configuration.

After the route map is saved, apply it to the ExpressRoute connection in the outbound direction.

In Apply Route-maps to connections, select the ExpressRoute connection er-conn, and then apply summarization1 in the outbound direction. Azure Route Server will advertise the three aggregate prefixes instead of the more-specific spoke routes.

Wait for deployment to complete and verify that the provisioning state is Succeeded.

Use the Azure Route Server Connection Dashboard to inspect the routes advertised to the ExpressRoute connection. Select er-conn and review the outbound direction. The advertised routes should now contain only the three aggregate prefixes.

To confirm that the outbound summarization policy has not changed the routes received from on-premises, switch to the inbound direction and review the routes advertised by the customer edge toward the Azure VNet.

The network 10.1.11.0/25 is the on-premises network advertised from the customer's edge routers to the ExpressRoute private peering.

As a final validation, inspect the routing table for the primary connection in the ExpressRoute circuit private peering.

The ExpressRoute circuit now receives only the three configured aggregate spoke prefixes: 10.90.0.0/18, 10.90.64.0/19, and 10.90.96.0/22. The routing table also includes 10.1.0.0/25 for the on-premises network and 10.99.0.0/24 for the hub VNet address space.

Conclusion

Route maps are a significant step forward for Azure Route Server, adding a native routing policy layer that strengthens governance and control over route exchange across hybrid connectivity and Azure VNets. In this scenario, an outbound route map summarizes 100 spoke prefixes into three aggregate routes, reducing routing-table growth while preserving reachability across the complete spoke address range. The same policy model supports filtering, path selection, and BGP community tagging, helping customers control route propagation and operate growing hub-and-spoke environments more predictably.

What if your Azure Databricks workspaces have overlapping CIDRs?

vamsiboya_microsoft — Tue, 03 Nov 2026 17:41:11 GMT

Consider a common enterprise networking challenge:

You have three Azure Databricks workspaces. Each workspace uses classic VNet-injected compute, and each compute VNet uses the same address space:

10.100.0.0/20

Your networking team immediately sees the problem:

If multiple networks advertise 10.100.0.0/20, which workspace should traffic for that prefix reach?

At first glance, this looks like an IP-renumbering problem.

But there is another question worth asking first:

Do enterprise users actually need network access to the Databricks compute subnets, or do they only need private access to the Databricks workspace service?

For standard workspace web UI and REST API access, that distinction can fundamentally change the architecture.

The key design principle is:

Route to uniquely addressed private endpoints, not to the overlapping compute networks.

The architecture challenge

RFC1918 address space may be private, but in large enterprises it is often far from unlimited.

Acquisitions, independently designed environments, large historical reservations, and decentralized networking can result in multiple environments using the same address ranges.

Imagine this deployment:

Three Azure Databricks workspaces: A, B, and C
Three isolated VNet-injected compute VNets
Each compute VNet uses 10.100.0.0/20
Enterprise users require private access to all three workspaces
Enterprise connectivity arrives through ExpressRoute private peering or VPN

Directly exposing all three compute VNets to a shared routing domain creates an obvious ambiguity because the same prefix exists three times.

Fortunately, workspace service access does not require enterprise clients to route directly into those compute networks.

Service access is different from compute-network access

Azure Databricks distinguishes between front-end Private Link, classic compute back-end Private Link, and serverless outbound connectivity.

For front-end access, private endpoints can provide connectivity to the Databricks workspace web application and REST APIs without requiring enterprise clients to route into the workspace compute VNet.

That separation gives us the basis for this design.

Instead of importing the overlapping compute prefixes into the enterprise network:

Create a uniquely addressed Transit VNet.
Place the Databricks front-end private endpoints in that Transit VNet.
Make the Transit VNet reachable from the enterprise connectivity hub.
Keep each overlapping compute VNet in its own isolated routing domain.

The enterprise network then routes only to addresses that are unique.

Important: This does not make overlapping VNets routable to one another. It avoids adding those overlapping prefixes to the common enterprise routing domain.

Compute still requires its own control-plane connectivity, data access, and egress design. Those paths need to be considered independently.

Example topology

Consider the following illustrative single-region deployment.

Databricks compute networks

Workspace A VNet: 10.100.0.0/20
Workspace B VNet: 10.100.0.0/20
Workspace C VNet: 10.100.0.0/20

Enterprise-reachable Transit VNet

Transit VNet: 10.200.0.0/16
Private endpoint subnet: 10.200.10.0/24

Example private endpoint addresses

Private endpoint	Example IP	Purpose
PE-A	10.200.10.10	Workspace A databricks_ui_api
PE-B	10.200.10.11	Workspace B databricks_ui_api
PE-C	10.200.10.12	Workspace C databricks_ui_api
Browser-auth PE	10.200.10.20	Shared regional browser_authentication

These addresses are examples only and are not production sizing recommendations.

The enterprise network connects to either:

a conventional connectivity hub, or
an Azure Virtual WAN hub.

The example does not require chaining both hub models together.

Enterprise connectivity reaches the selected hub through ExpressRoute private peering or VPN, and the Transit VNet connects using the appropriate mechanism for that topology.

Architecture diagram

Figure 1. Enterprise routes terminate at uniquely addressed Transit VNet private endpoints for Databricks workspace services. The overlapping compute networks remain outside the enterprise routing domain.

The important part is what is not connected.

The three compute VNets are not:

peered to the enterprise-connected Transit VNet,
peered to the conventional enterprise hub,
attached to the Azure Virtual WAN hub, or
advertised into enterprise routing.

Therefore, the three instances of 10.100.0.0/20 never compete in the same enterprise routing table.

The address-space benefit is quite specific:

Enterprise routing consumes a unique ingress range rather than requiring three unique enterprise-visible compute ranges.

Each Databricks workspace still consumes its own subnet address space locally.

How the private service path works

Suppose a user wants to open Workspace B.

The flow is conceptually:

Client → enterprise connectivity → hub → Transit VNet → PE-B → Databricks workspace service

The user accesses the normal workspace hostname.

DNS resolves that hostname to the appropriate private endpoint address in the Transit VNet. Enterprise routing carries the traffic to that address, and Azure Private Link provides connectivity from the endpoint to the corresponding Databricks workspace service.

The association remains deterministic:

PE-A → Workspace A
PE-B → Workspace B
PE-C → Workspace C

This is service-specific private connectivity.

It is not a routed entrance into Workspace A, B, or C's compute subnet.

Applications and users should also continue to use the standard Databricks workspace hostname, rather than configuring private endpoint IP addresses directly in browsers or API clients.

Don't forget browser authentication

There is another dependency that deserves special attention.

The databricks_ui_api endpoint provides workspace UI and REST API connectivity.

The browser_authentication endpoint has a different purpose: browser single sign-on callbacks.

It is not the authentication endpoint used for REST API requests.

Microsoft documents a browser-authentication endpoint per Azure region and private DNS zone that can be shared by workspaces in that region that use the same DNS configuration.

Microsoft also recommends using a separate production web-auth workspace that:

has no compute workloads,
does not have a databricks_ui_api private endpoint on that host, and
is treated as a shared infrastructure dependency.

This dependency matters operationally because removing the workspace that hosts the browser-authentication endpoint can break browser authentication for dependent workspaces.

Design note: This example is intentionally region-local. It should not be interpreted as a single global browser-authentication endpoint design.

Other Databricks access scenarios may also use endpoints such as general_access or service_direct. Those scenarios should be evaluated separately against the current Azure Databricks documentation.

DNS is as important as routing

A route to PE-B does not help if the Workspace B hostname resolves somewhere else.

For hybrid clients, the DNS design should make the normal Databricks workspace hostname resolve to the private endpoint that the client can actually reach.

Microsoft's hybrid Private Endpoint DNS guidance recommends conditionally forwarding the relevant public service suffix to a reachable Azure DNS Private Resolver inbound endpoint.

For Azure Databricks, that means forwarding:

azuredatabricks.net

rather than designing the hybrid forwarding path around only:

privatelink.azuredatabricks.net

On-premises DNS should also not query Azure's 168.63.129.16 virtual IP directly.

The resolver VNet context should be linked to the central:

privatelink.azuredatabricks.net

private DNS zone.

Azure-provided DNS can then process the normal workspace hostname through the service DNS chain and private-zone lookup so that the client ultimately receives the appropriate Transit private endpoint address.

An outbound Private Resolver endpoint is not required solely for servicing these inbound queries.

DNS architecture

Figure 2. DNS resolution and HTTPS traffic are separate paths. DNS returns the reachable Transit private endpoint address; the private DNS zone itself is not part of the HTTPS routing path.

Private Endpoint DNS zone groups should be used to maintain the service mappings instead of manually guessing record names.

A subtle DNS trap with front-end and back-end Private Link

There is an important architectural trap when both front-end and back-end private endpoints exist.

Your enterprise clients need DNS to return the front-end Transit endpoint they can reach.

Compute environments using back-end connectivity may require a different DNS view that returns endpoints reachable from those networks.

If both endpoint types compete to update the same records in the same shared private DNS zone, name resolution may succeed while returning an endpoint that the client cannot reach.

That leads to a useful design principle:

DNS visibility should follow network reachability.

Keep the central front-end DNS view populated with the Transit endpoints.

Where isolated compute environments also require back-end private endpoints, design an appropriate reachable DNS view for those environments instead of peering overlapping VNets merely to solve DNS.

And remember: DNS is not an access-control mechanism. Hiding a DNS record does not replace network or identity controls.

Private access does not automatically mean private-only

This is one of the most important distinctions in the design.

Creating front-end private endpoints establishes a private access path.

It does not, by itself, guarantee that public workspace access has been disabled.

Microsoft distinguishes an inbound-only configuration from a complete private-isolation configuration.

Complete private isolation introduces additional requirements, including back-end Private Link connectivity and the corresponding workspace networking configuration.

Therefore:

Do not disable public network access on workload workspaces simply because the front-end Transit private endpoints are working.

First validate the required back-end/control-plane path, compute connectivity, data dependencies, and egress requirements against the complete-isolation guidance.

Otherwise, a successful browser test could hide a broken compute environment.

The dedicated browser-authentication workspace is also configured differently from workload workspaces. Its configuration should not be copied indiscriminately to the compute workspaces.

What this pattern solves

This design is useful when:

multiple classic VNet-injected Databricks environments use overlapping compute address spaces,
those compute networks can remain isolated,
enterprise users need private UI access,
applications need private REST API access, and
the organization has a uniquely addressed enterprise-reachable Transit VNet.

It reduces the requirement for unique enterprise-visible compute prefixes.

It does not reduce the local address consumption of each Databricks workspace.

What this pattern does not solve

This design is not a general solution for overlapping networks.

It does not make the overlapping compute VNets mutually routable.

It also does not replace the design for:

storage connectivity,
data-service private endpoints,
compute-to-control-plane connectivity,
outbound/egress controls,
direct cross-workspace compute communication, or
serverless outbound networking.

If workloads in Workspace A must communicate directly with workloads in Workspace B, and both networks use 10.100.0.0/20, you have returned to an address-ambiguity problem.

That requirement needs a separate connectivity and addressing strategy.

Operational considerations

Before adopting this architecture, review the documented Azure Databricks Private Link prerequisites.

These include considerations around:

Premium workspaces,
VNet injection,
Secure Cluster Connectivity / No Public IP,
configuration permissions,
regional placement requirements, and
potential downtime when retrofitting existing workspaces.

Also consider the following operational areas.

Address capacity and cost

Plan enough space for private endpoints, subnet reservations, future endpoints, DNS infrastructure, and applicable platform limits.

Private Endpoint, DNS Private Resolver, ExpressRoute/VPN, and the selected hub architecture also have associated costs.

Reusing compute CIDRs does not mean the connectivity layer is free.

Network controls

When private endpoint network policies and NSG controls are applicable, validate the current documented service flows.

Azure Databricks documentation currently lists inbound TCP requirements including:

443
6666
3306
8443-8451

Use appropriately scoped rules based on the current service requirements rather than assuming that allowing only TCP 443 is sufficient.

Traffic inspection

A centralized private endpoint does not automatically imply centralized firewall inspection.

Verify:

effective routes,
the selected hub topology,
firewall traversal where required, and
the actual data path.

Validation checklist

Before declaring the design operational, validate it from each relevant network.

DNS

[ ] Resolve every standard Databricks workspace hostname.
[ ] Confirm that each hostname returns its expected Transit private endpoint IP.
[ ] Validate browser-authentication DNS resolution.
[ ] Confirm that isolated compute environments receive only endpoints they can reach.

Workspace connectivity

[ ] Open each workspace using its standard hostname.
[ ] Verify connectivity follows the intended private path.
[ ] Complete browser sign-in.
[ ] Test an authenticated REST API request to each workspace.

Security

[ ] Verify unauthorized network sources are denied by the intended network controls.
[ ] Verify unauthorized identities cannot access workspace resources.
[ ] If complete private isolation is required, confirm public UI/API access is unavailable from outside the approved private path.

Compute

[ ] Start representative classic compute.
[ ] Validate control-plane connectivity independently.
[ ] Validate storage and data-service access.
[ ] Validate required outbound/egress connectivity.

These are proposed architectural validation checks, not reported results from a deployed test environment.

Key takeaway

Overlapping prefixes appear to be the central problem only if enterprise clients need to route directly into those prefixes.

For standard Azure Databricks workspace UI and REST API ingress, they do not.

Instead:

Give each workspace service a unique private endpoint in an enterprise-reachable Transit VNet, route enterprise clients to those endpoints, and keep the overlapping compute networks out of the shared routing domain.

Then make DNS return the endpoint the client can actually reach.

Finally, treat compute networking, back-end Private Link, data dependencies, egress, public exposure, and serverless networking as separate design decisions.

The goal is not to make overlapping networks routable.

The goal is to solve the service-access requirement without importing the overlapping routes in the first place.

References

Architecture scope: This article presents an architectural pattern using illustrative single-region addressing. Microsoft documentation covers the individual Azure and Azure Databricks components referenced here. The composition for overlapping compute CIDRs described in this article is an architectural inference based on keeping the overlapping networks in separate routing domains; it should not be interpreted as a Microsoft-certified or independently validated reference architecture. No deployment or sandbox testing is claimed.

Multi-NIC Support on AKS powered by DRANET – Now in Public Preview

chandanAggarwal — Fri, 09 Oct 2026 18:24:27 GMT

Kubernetes was designed around a simple networking model, every pod gets one network interface, and every pod on a node shares the same flat network. For most stateless microservices, this works well as it keeps the model simple and the platform portable.

But a large class of workloads don't fit that shape. Some need network separation, with management, control, and data traffic on separate and isolated networks rather than multiplexed over one interface. Other workloads need predictable performance, a dedicated path for high-throughput or latency-sensitive traffic. Until now, meeting these requirements on Kubernetes meant adding and manually integrating multiple components, or keeping the workload on VMs.

Today we're announcing the public preview of multi-NIC support for pods on AKS, powered by the AKS managed DRANET driver. You can now provision worker nodes with multiple network interfaces connected to different subnets, and attach a dedicated interface directly to a pod using standard upstream Kubernetes APIs, with no Multus, no custom CNI extensions, and no manual interface wiring.

Two ways to use multi-NIC on AKS

Use case 1: A dedicated NIC attached directly to a pod

“As a networking engineer, I want to attach a dedicated network interface directly to a Kubernetes pod so the workload can connect to different networks and route traffic natively, without relying on host-level DPDK/VPP forwarding, custom routing rules, or gateway-based NAT.”
“I also want the secondary interface on my pod to send and receive traffic on a specific, known public IP address, so that downstream partners can allow-list my traffic by IP and no NAT hop adds latency to time-sensitive streams."

This is the pattern where the workload itself expects to see multiple interfaces. The pod asks for a network device the same way it would ask for any other resource, and the interface shows up inside the container alongside the standard CNI interface. No host-level forwarding layer, no NAT gateway in the middle.

What you get

The DRANET driver is deployed automatically. Once a node pool is configured with secondary interfaces, AKS installs and manages the driver for you; there is no add-on to install and no CRDs to author by hand.
Declarative, scheduler-aware requests. Interfaces are advertised to Kubernetes as allocatable devices, so a pod that asks for one is placed on a node that can actually provide it, using standard Dynamic Resource Allocation (DRA) objects rather than vendor-specific annotations.
A predictable interface lifecycle. The driver handles attach, release, and recovery as pods are rescheduled or restarted.
A public IP address can be assigned directly to a secondary interface, configured at node pool creation time using IP tags. The pod's secondary interface talks to the outside world without going through the load balancer or any address translation layer.
Both IPv4 and IPv6 addresses are supported on the secondary interface.

What to plan around

Interfaces are dedicated, not shared. When a NIC is attached to a pod, it moves into that pod's network namespace and is no longer available to the node or to any other pod. Sharing a secondary NIC across pods isn't supported in this release.
Because of that, pod density on a multi-NIC node pool is bounded by the number of interfaces on the node.
All interfaces must be attached to the same virtual network as the primary NIC. On a bring-your-own VNet cluster, different subnets within that VNet are supported, but different VNets are not, in this preview. On an AKS-managed VNet, secondary interfaces are currently limited to the same subnet as the primary NIC , since creating a new subnet on a managed VNet isn't supported yet.
Each pod's secondary interface gets its own dedicated public IP, so plan node pool sizing around how many pods need a tagged public IP of their own. Public IP assignment is configured at node pool creation time through IP tags, so decide your IP range and tagging strategy before you provision the node pool.
Kubernetes network policy is enforced on the primary interface only. Plan isolation for secondary interfaces at the subnet and NSG layer.

Use Case 2: Multi-NIC nodes with your own NIC management

“As a platform/networking engineer, I want to provision Kubernetes worker nodes with multiple network interfaces connected to different networks and use my own VPP, DPDK, or any custom routing logic to steer traffic at the node level, without attaching additional interfaces to pods.”

This is the pattern for teams who already own their dataplane. The node is multi-homed, each interface lands on its own subnet, and your own software decides which traffic goes where. Pods keep a single CNI-assigned interface and stay unaware of the underlying topology.

What you get

Depending on the selected SKU size, you can configure nodes with multiple network interfaces.
Full control, and full ownership of the additional nics. AKS provisions the interfaces and keeps them attached to the node. How traffic is steered across them is entirely yours to design, configure, operate, and support. That includes your routing rules, your userspace dataplane, and any troubleshooting of the forwarding path itself.
The same-VNet constraint applies here too, secondary interfaces can span subnets, but not virtual networks. This applies to bring-your-own VNet clusters. On an AKS-managed VNet, secondary interfaces are restricted to the primary NIC's subnet for now.

Both patterns start from the same node pool configuration. The difference is whether you stop there and manage the interfaces yourself, or let the DRANET hand them to your pods.

How it works

Multi-NIC on AKS starts with a single configuration step: you add secondary network interfaces to a node pool. AKS provisions the NICs on every VM in the pool and installs the DRANET driver alongside them. From there, what happens to those NICs depends on your workload. Reference a resource claim in your pod spec, and DRANET moves an interface into the pod Or Leave them on the node and steer traffic yourself with VPP, DPDK, or custom routing.

Step 1: Provision the node pools with secondary NICs

Secondary interfaces are declared when you create the node pool. The agent pool's network profile carries a secondaryNetworkInterfaces array, and each entry points at a subnet in the same virtual network as the primary NIC:

"networkProfile": { "secondaryNetworkInterfaces": [ { "type": "Standard", "vnetSubnetId": "<VNET_SUBNET_ID>" } { "type": "Standard", "vnetSubnetId": "<VNET_SUBNET_ID>" } ] }

AKS extends VMSS provisioning to attach those NICs to every VM in the pool. Add more entries for more interfaces, up to what the VM SKU allows. The array length is validated against the SKU at creation time, so a pool with mixed sizes has to be planned around the smallest one.

The node is now multi-homed and the interfaces are visible on the host. If you are building for use case 2, this is where you stop. AKS provisions and keeps the interfaces attached to the node, and how traffic is steered across them, the routing rules, the userspace dataplane, the troubleshooting of the forwarding path, is yours to design, operate, and support.

Step 2: Using AKS managed DRANET driver to hand an interface to the pod

Once a node pool has secondary interfaces configured, and the cluster is using AKS-managed CNI (Azure CNI or Azure CNI Powered by Cilium), AKS automatically installs the DRANET driver as a DaemonSet, packaged and delivered through an AKS-managed Helm chart. There is nothing to deploy yourself and no CRDs to author by hand.
If you're running a BYO CNI cluster, AKS still provisions the secondary NICs, but you're responsible for deploying DRANET (or your own driver of choice) yourself.

The driver does three things:

Discovers the additional interfaces present on each node.
Advertises them to Kubernetes as allocatable DRA devices, published in a ResourceSlice.
Manages the lifecycle: exclusive per-pod allocation, attachment, release, and recovery as pods move or restart.

Inspect the DRANET deamonset, pods, and deviceclass using the following commands:

kubectl get deviceclasses kubectl get daemonset -A kubectl get pods -A -o wide

Now you can create a “ResourceClaimTemplate” that defines how each pod requests a device.

apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: nic-dev-template spec: spec: devices: requests: - name: nic exactly: deviceClassName: standard-secondary-nic allocationMode: ExactCount count: 1

Configure the pod references the template, and the scheduler places it on a node that has a matching NIC available:

apiVersion: v1 kind: Pod metadata: name: multi-nic-test spec: containers: - name: multi-nic image: nicolaka/netshoot resources: claims: - name: nic resourceClaims: - name: nic resourceClaimTemplateName: nic-dev-template

A pod referencing a claim comes up with its usual CNI-assigned eth0 plus the allocated secondary interface, and you can confirm both from inside the container.

When DRANET attaches a secondary NIC to a pod, that interface moves into the pod's network namespace and is no longer available on the node or to any other pod. It returns to the node's pool of available devices when the pod terminates. That gives you a clean isolation boundary and deterministic performance, with the trade-off that pod density on a multi-NIC pool is bounded by interface count, not just CPU and memory.

For the full walkthrough including feature flag registration, more examples visit https://aka.ms/aks/multi-nic.

Try it now

Multi-NIC support for pods on AKS is available now in public preview. Start with the documentation for the full walkthrough: provisioning a node pool with secondary interfaces, defining a resource claim, and validating that both interfaces appear inside the pod.

Documentation: https://aka.ms/aks/multi-nic
Upstream project: DRANET on GitHub

Preview is when your input can actually shape the feature. If you hit a limitation or have a use case we haven’t covered, comment below and share your feedback.

Proactively monitor Azure VPN Gateway tunnel disconnections

shyambasnet — Tue, 06 Oct 2026 16:47:21 GMT

Site-to-Site (S2S) VPN connections are a critical component of hybrid connectivity between Azure and on-premises environments. A tunnel outage can impact applications, user access, and business operations. Although Azure VPN Gateway automatically attempts to re-establish a tunnel when connectivity is restored, administrators should be notified immediately when a tunnel disconnects so they can quickly investigate and mitigate the issue.

In this article, you'll learn how to configure an Azure Monitor alert that automatically notifies administrators whenever an Azure VPN Gateway tunnel enters a disconnected state.

Why monitor VPN tunnel status?

VPN tunnels can disconnect for a variety of reasons, including:

Internet connectivity issues
On-premises VPN device failures
IPSec/IKE negotiation issues
Network maintenance activities
Device reboots or software upgrades

By implementing proactive monitoring, organizations can:

Reduce Mean Time to Detection (MTTD)
Improve network availability
Receive automated notifications

Step 1: Enable VPN Gateway diagnostic logs

Before creating an alert rule, ensure that diagnostic logging is enabled for your VPN Gateway.

Navigate to Azure Monitor in the Azure portal.
Under Settings, select Diagnostic settings.
Select the appropriate Subscription, Resource Group, and Resource Type, then choose your VPN Gateway resource.
Click Add diagnostic setting.
Provide a name for the diagnostic setting and select AllLogs (or at minimum TunnelDiagnosticLog).
Choose Send to Log Analytics Workspace (or Event Hub / Storage Account, as required).
Click Save to apply the diagnostic setting.

Step 2: Create an alert rule

After enabling diagnostics, navigate to Azure Portal > Monitor > Alerts, and select Create > Alert Rule.

Scope

Select Scope and click Select scope. In the resource selection pane, choose your Virtual Network Gateway (VPN Gateway) resource and click Apply. This sets the VPN Gateway as the target resource for the alert rule.

Condition

On the Condition tab, select Custom log search as the signal name and choose Aggregated logs as the query type.

Enter the following KQL query to identify VPN tunnel disconnection events during the last 10 minutes:

AzureDiagnostics

| where TimeGenerated > ago(10m)

| where Category == "TunnelDiagnosticLog"

| where status_s == "Disconnected"

| project TimeGenerated, Resource, status_s

Configure the measurement settings as follows:

Measure: Table rows
Aggregation type: Count
Aggregation granularity: 5 minutes
Threshold type: Static
Operator: Greater than
Threshold value: 0

This configuration triggers an alert whenever one or more tunnel disconnection events are detected.

Actions

On the Actions tab, select Use action groups and either choose an existing action group or create a new one. Configure the action group to send notifications through email, SMS, webhook, or other supported notification channels when a VPN tunnel disconnection event is detected. You can also customize the email subject to make alert notifications easier to identify and manage.

Details

On the Details tab, provide a meaningful Alert Rule Name, select the appropriate Severity, and add a brief description of the alert. This information will help operations teams quickly understand the purpose and importance of the alert when it is triggered.

Review + create

Review all configuration settings to ensure they are correct, then select Create to deploy the alert rule. Azure Monitor will begin evaluating the configured query and automatically notify the specified recipients whenever a VPN tunnel enters a disconnected state.

Summary

By combining Azure VPN Gateway diagnostic logs with Azure Monitor alert rules, organizations can proactively monitor VPN tunnel health and receive near real-time notifications when a tunnel disconnects. This approach improves operational visibility, reduces troubleshooting time, and helps maintain reliable hybrid connectivity between Azure and on-premises networks.

Network security perimeter metrics are now generally available in Public Cloud

shashankamalladi — Wed, 30 Sep 2026 19:35:03 GMT

We are excited to announce the general availability (GA) of network security perimeter metrics, a capability that helps administrators monitor network access patterns, understand the impact of the access rules, and identify unexpected traffic behaviour across protected resources. These metrics are available through Azure Monitor and can be used to create dashboards, alerts, and operational monitoring experiences.

Why use network security perimeter metrics?

Network security perimeter metrics capture access requests evaluated by the data plane and provide visibility into network activity associated with the perimeter-protected resources. Metrics enable monitoring scenarios such as:

Tracking approved and denied access requests.
Monitoring inbound and outbound access activity.
Understanding traffic patterns across protected resources, profiles, access modes and access rule versions.
Detecting unexpected access attempts.
Validating the impact of access rules’ changes.
Establishing a baseline before moving a perimeter from Transition mode to Enforced mode.

Network security perimeter metrics render aggregated time-series data that is optimized for monitoring, alerting, and trend analysis.

Accessing network security perimeter metrics

Network security perimeter metrics are available through Azure Monitor.

In the Azure portal, navigate to your network security perimeter resource.
Select Metrics under the Monitoring section.
‘Add Metric’
Choose the ‘NSP access metrics’ namespace.
Select a metric and configure filters, splitting as needed.
Use Azure Monitor features to build charts, dashboards, workbooks, and metric alerts.
Multiple charts may be created for different metrics that are intended to be monitored.

Regular Azure Monitor features like drilling into the logs, saving the chart as a dashboard or exporting it to a workbook can also be performed.

Metrics vs diagnostic logs

While metrics and diagnostic logs are complementary monitoring tools, metrics provide a high-level operational view and support alerting, while diagnostic logs provide detailed event data for troubleshooting and investigation. Table below gives a high-level differentiation view of one over the other.

Capability	Metrics	Diagnostic logs
Trend analysis	Yes	Limited
Dashboards and visualizations	Yes	Requires log queries
Azure Monitor metric alerts	Yes	No
Detailed request information	No	Yes
Forensic investigations	No	Yes
Operational monitoring	Yes	Yes
Readibility	Instant	Destination needed
Cost implications	Free	Chargeable destinations

Reach-out to mailto:nsppmvteam@microsoft.com for any questions.

Change Analysis in Azure Resource Graph: Your first stop for “What changed?”

shyambasnet — Tue, 22 Sep 2026 17:57:34 GMT

Introduction

One of the most common questions during Azure networking troubleshooting is:

“Did anything change before the issue started?”

Whether we are investigating VPN/, connectivity problems, Azure Firewall behavior changes, VM outages, routing issues, or application failures, identifying recent configuration changes is often the fastest way to determine the root cause.

Change Analysis is a powerful capability built on Azure Resource Graph that allows engineers and administrators to quickly see:

What changed
When the change occurred
Who made the change
Which client or tool performed the change
The exact configuration differences before and after the change

What is Change Analysis?

Azure resources are constantly being modified through:

Azure portal
Azure CLI
PowerShell
ARM/Bicep deployments
Terraform
Azure Policy remediation
Automation runbooks
CI/CD pipelines

In many organizations, multiple administrators and engineers have access to the same Azure tenant and subscriptions. Because teams often work across different regions and time zones, it can be difficult to determine who made a change and to quickly contact the responsible person when an issue occurs. While most changes are intentional and necessary for daily operations, some modifications can unintentionally introduce outages, connectivity issues, or performance problems. Azure Change Analysis provides a centralized view of resource changes and helps organizations quickly answer critical troubleshooting questions such as: Who changed a setting? Was a route table updated before traffic stopped flowing? Did someone modify an NSG rule? Was the Azure Firewall configuration changed? When was a virtual machine resized? By showing what changed, when it changed, and who made the change, Change Analysis significantly reduces troubleshooting time and helps accelerate root cause analysis.

How Change Analysis works

When an Azure resource is:

Created
Updated
Deleted

Azure Resource Graph captures change information and stores snapshots that can later be queried.

The platform records:

Attribute	Description
Resource	Azure resource affected
Change Type	Create, Update, Delete
Timestamp	When the change occurred
Changed By	User, service principal, or system
Client Type	Portal, CLI, ARM template, etc.
Operation	Azure operation executed
Property Changes	Before and after values

This dramatically reduces troubleshooting time because engineers can immediately identify configuration drift or recent modifications.

Accessing Change Analysis in Azure portal

As shown in the screenshot, Change Analysis can be accessed directly from the Azure portal.

Navigation options

Global Change Analysis view

Open Azure portal
Search for Change Analysis
Select Change Analysis

This approach is particularly useful when troubleshooting a specific service such as:

VPN Gateway
Azure Firewall
Virtual Machine
Load Balancer
Application Gateway
Network security group (NSG)

Compare old and new configuration

View the exact configuration changes made to a resource.
Compare Old Configuration (left panel) with New Configuration (right panel).
Identify added, removed, or modified properties.
Review configuration differences at the property level.
Quickly determine what changed during the incident timeframe.
Useful for analyzing:

NSG rule additions or deletions
Route table modifications
Azure Firewall rule changes
VPN Gateway configuration updates
Public IP changes
Resource property updates

Example: In the screenshot above, Change Analysis clearly shows the previous NSG rule configuration on the left and the updated configuration on the right, making it easy to identify exactly which rule was added, modified, or removed. This helps engineers quickly correlate configuration changes with service disruptions and accelerate root cause analysis.

Common Azure networking use cases

As an Azure networking some practical scenarios include:

VPN Gateway troubleshooting

VPN down

Modified Local Network Gateway prefixes
BGP ASN changes
Tunnel configuration updates
Public IP changes
IKE parameter

Azure Firewall investigation

A workload suddenly loses connectivity.

Change Analysis may show:

DNAT rule modification
Network Rule change
Application Rule update

NSG connectivity problems

When VM traffic is blocked unexpectedly, Change Analysis can identify:

Newly added deny rules
Priority changes
Rule deletions

Route table changes

Change Analysis quickly exposes:

Next-hop modifications
UDR updates
Route propagation changes

Querying changes using Azure Resource Graph

Azure Portal → Monitor → Change Analysis →Open query →Azure Resource Graph Explorer.

resourcechanges

|extend timestamp = todatetime(properties.changeAttributes.timestamp)

|where timestamp > ago(24h)

|extend resourceType = properties.targetResourceType

|extend resourceId = properties.targetResourceId

|extend changeType = properties.changeType

|extend changeAttributes = parse_json(properties.changeAttributes)

|where resourceId in ('-----------')

|project id, timestamp, subscriptionId, resourceGroup, resourceId, resourceType, changeType, changeAttributes

|order by timestamp desc

Conclusion

Change Analysis has become one of the most valuable troubleshooting tools available in Azure. By providing visibility into who changed what and when, it helps engineers quickly identify configuration drift, reduce mean time to resolution, and accelerate root cause analysis.

For Azure networking scenarios such as VPN Gateway, ExpressRoute, Azure Firewall, Route Tables, and NSGs, Change Analysis should be one of the very first tools consulted when investigating unexpected behavior.

As every Azure support engineer knows, solving an incident often starts with a simple question:

“What changed?”

Change Analysis helps answer that question in seconds

Adding network intelligence into a network-ready Azure migration plan

Sudha_Mahajan — Wed, 09 Sep 2026 18:01:43 GMT

Sudha Mahajan, Partner PM Azure Networking, Vijay Mamtani, CVP Azure Networking | September 2026

Lift-and-shift succeeds when the network moves with the application

For many VMware customers, the immediate migration goal is practical: move workloads to Azure quickly, preserve application behavior and connectivity, reduce execution risk, keep it secure, and build a costed plan that leaders can approve. Compute and storage sizing are necessary, but it is not the whole migration plan. Applications depend on IP prefixes, network paths, security policies, load-balancing behavior, shared services, and connections to systems that may move at different times.

Azure Migrate is critical to making this work manageable. It provides the foundation for discovering the estate, assessing migration readiness, developing the business case, and translating collected evidence into a plan. With Network Planning, that foundation becomes network-aware, combining server inventory with insights into how application connectivity can be represented in Azure.

Networking is the hidden critical path

Network planning often begins late. A team may group and size virtual machines, then assume the target network can be designed near cutover. That approach overlooks the dependencies that determine whether an application will function after migration.

The required information for networking is fragmented. Workload inventory may sit in vCenter; network constructs and flows may be reflected in NSX; policy intent may be distributed across firewalls; application delivery may depend on load balancers; address constraints may live in spreadsheets; and operational knowledge may be divided among application, infrastructure, security, and network teams. Each system provides part of the answer, but no single view naturally explains what an application needs in Azure.

Common mistakes follow - planning by individual servers rather than application, missing dependencies, carrying forward rules without understanding their intent, overlooking shared services, estimating compute while omitting network costs, or designing target topology before the source environment is fully understood. These gaps create additional analysis, redesign, stakeholder review iterations, and cutover uncertainty. Networking becomes the hidden critical path - not because teams lack expertise, but because the evidence needed for decisions is incomplete and disconnected.

Network planning bridges discovery and decisions

Network planning is designed to close that gap within the Azure Migrate. Its purpose is to turn discovered network evidence and customer migration intent into an actionable, Azure-oriented planning view.

Beginning September, Azure migrate enters public preview with network-aware assessment and networking incorporated into business-case and assessment functionality.

Visualize and validate source network resources: Discovered VMware network information provides context for workload placement, connectivity, dependencies, and applicable destination constructs.

Azure-native recommendations: Network Planning translates source findings into recommended Azure networking building blocks and guidance, including topology considerations (hub-and-spoke), security intent considerations (mapping on-prem firewall rules to NSG and Azure FW) and application delivery considerations (Application load balancing and WAF rules), instead of requiring customers to manually map every source construct.

Readiness and issue visibility: Assessments surface network-related readiness considerations and planning issues that require attention before migration, allowing teams to separate straightforward moves from items needing design decisions or remediation.

Networking in the business case: Network-cost estimates are included alongside the broader migration analysis, helping decision-makers evaluate a more complete cost picture.

Security-rule planning context: Where source data supports it, translated security-rule information can help teams reason about security requirements and prepare for target policy design and validation.

FROM DISCOVERY TO A NETWORK-READY MIGRATION PLAN

Discover
VMware estate

Scope
Applications

Assess
Readiness

Recommend
Azure network

Plan
Costs and migration

What changes for customers and partners

Network planning does not eliminate the need for engineering judgment or automate network design. Its value is a more structured starting point, grounded in discovered data and presented in the same Azure Migrate workflow used for assessment and business-case development.

Customers can bring application, network, security, and migration stakeholders to a shared planning view. They can identify missing information sooner, connect network requirements to migration groups, review readiness before cutover planning, and include network considerations in financial discussions. Partners can use the same evidence to guide workshops, validate assumptions, focus design effort on exceptions, and produce a plan that is easier for customer teams to review.

The result is a more practical migration conversation: not simply "Which virtual machines can move?" but "What does this application require, what must be addressed, what Azure is the recommended network approach , and what should be included in the costed plan?"

Launch scope first, roadmap second

The August preview of network planning in Azure Migrate is intentionally focused on the lift-and-shift planning path. Items such as application modernization, third-party virtual appliances, advanced topologies, infrastructure-as-code generation, and IP-retention scenarios remain future roadmap areas. Keeping that boundary clear allows customers to evaluate the preview for what it delivers now while Microsoft continues to shape later capabilities from feedback.

Key takeaway

For customers preparing VMware lift-and-shift migrations, begin by enabling and validating discovery in Azure Migrate, then choose a representative application or migration group. Review its workloads, dependencies, source network context, readiness findings, Azure recommendations, and estimated network costs with the teams responsible for application ownership, networking, security, and migration execution.

For partners, use Network planning to anchor planning conversations in evidence rather than assumptions and to connect technical findings directly to the business case.

A successful migration plan should describe more than where servers will run. It should explain how applications will remain connected, what issues must be resolved, what the target approach will require, and what it is expected to cost. Network planning brings those networks decisions into Azure Migrate - where lift-and-shift planning already begins.

For further reference- you can refer to our website.

What’s new in Azure Firewall: Recent innovations

devanshirastogi — Fri, 04 Sep 2026 15:48:26 GMT

Organizations are modernizing their networks while managing a growing mix of applications, protocols, and security requirements.

Recent Azure Firewall releases strengthen this journey with simpler traffic routing, expanded protocol support, more flexible application controls, improved health visibility, and higher intrusion-detection performance. This roundup highlights five recent capabilities now available in general availability or public preview.

In this update: Explicit proxy, IPv6 support, HTTP header insertion, auto-learn SNAT routes, and IDPS performance improvements.

Explicit proxy is now generally available

Explicit proxy enables clients and applications to send HTTP and HTTPS traffic directly to Azure Firewall by configuring the firewall as their proxy. Instead of relying only on route-based traffic steering, organizations can use familiar proxy settings to centralize outbound web access through Azure Firewall.

This release provides a simpler way to use Azure Firewall as a managed forward proxy. It can help teams consolidate web egress controls, support workloads that natively understand proxy configuration, and transition from traditional proxy appliances without introducing another infrastructure layer.

Direct proxy configuration: Configure supported clients and applications to use Azure Firewall for HTTP and HTTPS traffic.

Centralized web controls: Apply Azure Firewall policy and application rules to proxied traffic.

Operational simplicity: Use a managed Azure service instead of deploying and maintaining separate proxy infrastructure.

Migration flexibility: Support environments that already use proxy-aware applications or proxy auto-configuration workflows.

For more details, visit - Azure Firewall explicit proxy | Microsoft Learn

IPv6 support is now in public preview

As address requirements grow and organizations adopt dual-stack architectures, IPv6 support is becoming an important part of cloud network design. Azure Firewall IPv6 support, now in public preview, extends centralized traffic filtering to IPv6 scenarios and helps customers protect applications and networks as they introduce IPv6 connectivity.

With this preview, teams can evolve IPv4-only environments toward dual-stack networking while continuing to use Azure Firewall as a central enforcement point. This reduces the need to maintain separate security architectures for IPv4 and IPv6 traffic and provides a more consistent policy and operational model.

Secure IPv6 traffic across hybrid environments: Filter east-west and hybrid IPv6 traffic across Azure and on-premises networks.

Works seamlessly with IPv6-enabled Azure services: Integrate Azure Firewall into end-to-end IPv6 architectures alongside services like ExpressRoute and Virtual Network.

Prepare for the future of networking: Build and secure dual-stack environments today while accelerating your IPv6 adoption journey.

For more details, visit -Deploy Azure Firewall in dual stack mode (preview) | Microsoft Learn

HTTP header insertion is now generally available

HTTP header insertion enables Azure Firewall to add configured headers to HTTP requests that match application rules. This gives security and network teams an additional policy control for communicating trusted context to downstream services without requiring every client or application to add the header itself.

The capability can support scenarios where applications use headers to enforce organization-specific access requirements, identify traffic handled by a trusted network path, or apply downstream controls. Because configuration is centralized in Azure Firewall policy, teams can apply the behavior consistently across matching traffic and reduce application-side changes.

Tenant restriction enforcement: Organizations can inject tenant restriction headers into traffic destined for Microsoft Entra ID, helping prevent users from authenticating unauthorized tenants and strengthening identity governance controls.

Secure egress for AVD and enterprise workloads: Support AVD, VDI, and enterprise egress scenarios where organizations need web traffic to carry approved tenant or context headers.
Security and Compliance Enforcement: Administrators can add organization-specific headers to web traffic to support security policies, compliance requirements, and backend validation workflows. This helps ensure that only approved applications, tenants, or services are accessed through corporate environments.

Operational Efficiency: Customers no longer need dedicated proxy devices solely for HTTP header injection. Azure Firewall can now perform header insertion natively as part of the application rule, reducing operational complexity and infrastructure costs.

For more details, visit - Azure Firewall HTTP Header Insertion Configuration | Microsoft Learn

Auto-learn SNAT routes is now generally available

Source network address translation behavior depends on whether Azure Firewall treats a destination as private or public. In complex enterprise and hybrid networks, manually maintaining the private address ranges that should not be source-NATed can become time-consuming and error-prone as the environment changes.

Auto-learn SNAT routes simplifies this process by dynamically learning relevant routes through Azure Route Server and using them to update the firewall’s private IP range configuration. This helps Azure Firewall preserve original source addresses for traffic destined to learned private networks while reducing ongoing configuration maintenance.

Reduce manual SNAT management : Automatically learn private and registered routes through Azure Route Server, eliminating the need to manually maintain large No-SNAT prefix lists.

Preserve source IPs across hybrid networks : Automatically apply learned routes as No-SNAT destinations, helping maintain source IP visibility and predictable routing for internal traffic.

For more details, visit- Azure Firewall SNAT private IP address ranges | Microsoft Learn

IDPS performance improvements are now generally available

Azure Firewall Premium includes signature-based intrusion detection and prevention to identify and block malicious network activity. The latest IDPS performance improvements increase the amount of protected traffic that Azure Firewall Premium can process, helping organizations apply advanced inspection to demanding production workloads.

Azure Firewall Premium now supports up to 22 Gbps with TLS inspection and IDPS in Deny mode, and up to 600 Mbps for a single TCP connection when IDPS is enabled in Alert or Deny mode. Actual performance depends on traffic characteristics, rule configuration, enabled features, and deployment conditions.

Higher aggregate throughput: Protect larger traffic volumes while using advanced inspection capabilities.

Improved single-flow performance: Better support applications that rely on high-throughput TCP connections.

Strong prevention posture: Use IDPS Deny mode to actively block matching malicious traffic.

Premium-scale security: Apply TLS inspection and IDPS to more bandwidth-intensive enterprise workloads

For more details, visit - Azure Firewall performance | Microsoft Learn

Building an advanced, more capable cloud firewall

Together, these releases expand how Azure Firewall can protect modern networks. Explicit proxy and HTTP header insertion provide more flexible application-layer controls; IPv6 support helps customers evolve toward dual-stack architectures; Auto-learn SNAT routes reduces operational overhead in dynamic and hybrid environments; and IDPS performance improvements extend advanced threat prevention to higher-throughput workloads.

Explore these capabilities in Azure Firewall and review the applicable Azure documentation for configuration requirements, supported scenarios, regional availability, and preview terms before enabling them in production environments.

Azure Firewall explicit proxy is now generally available

devanshirastogi — Wed, 02 Sep 2026 15:40:04 GMT

We are excited to announce the general availability of explicit proxy in Azure Firewall. This capability brings the familiar explicit proxy configuration model natively to Azure Firewall, enabling applications and browsers to send outbound HTTP and HTTPS traffic directly to the firewall through standard proxy settings. Customers can now gain centralized policy enforcement and visibility while reducing their dependence on self-managed forward proxy appliances.

Proxy the traffic you choose—not the entire subnet

Traditional route-based steering can require all traffic from a subnet to traverse a firewall. Explicit proxy offers a more targeted model: configure selected applications or browsers to use the Azure Firewall private IP and proxy port, while other traffic continues on its existing route. This application-level control can simplify migrations, reduce unnecessary routing changes, and help teams apply inspection where it matters most.

What’s new for general availability

A simpler single-port experience: Serve both HTTP and HTTPS destinations through one HTTP explicit proxy endpoint port, reducing client configuration complexity.

More secure PAC file access: Retrieve customer-owned proxy auto-configuration files from Azure Blob Storage using a managed identity. PAC files can be up to 256 KB.

A streamlined portal workflow: Enable Explicit proxy when creating a Firewall Policy, with added guidance and validation to help prevent common configuration errors.

Built for real-world modernization

Modernize legacy proxy infrastructure. Use Azure Firewall as the forward proxy endpoint while retaining the explicit proxy model already configured in applications and browsers. This can help organizations consolidate infrastructure and reduce operational overhead associated with self-hosted proxy appliances.

Apply selective application-level steering. Direct only the workloads that require centralized inspection through Azure Firewall, without forcing every flow on a subnet through the same path.

Secure Azure Arc connectivity in hybrid environments. Organizations using ExpressRoute or VPN can configure Azure Firewall as a forward proxy for Azure Arc-enabled servers, providing an inspected, policy-controlled outbound path to required Azure services without opening direct internet access from corporate networks.

How it works

Enable explicit proxy in the Azure Firewall Policy and choose the HTTP proxy port used for both HTTP and HTTPS destinations.
Configure applications manually with the firewall’s private IP and proxy port or enable proxy auto-configuration.
If you use a PAC file, store it in Azure Blob Storage and configure the required managed identity and access permissions.
Create an application rule in the Firewall Policy to allow the intended outbound destinations.

Get started today

Ready to simplify outbound web traffic steering? Explore the Azure Firewall explicit proxy documentation for prerequisites, portal and API configuration steps, PAC file guidance, and supported scenarios.

With explicit proxy now generally available, Azure Firewall gives organizations another flexible path to modernize secure egress—combining a familiar proxy model with the simplicity, scale, and centralized management of a cloud-native service.

Advertised gateway prefixes in Azure

erikbailey — Fri, 28 Aug 2026 20:09:00 GMT

Introduction

Large Azure hub-and-spoke environments can advertise a significant number of routes toward on-premises networks. By default, Azure VPN Gateway and ExpressRoute Gateway advertise the address spaces of the hub virtual network and the address spaces of peered spoke virtual networks that use gateway transit. As the number of spokes and address spaces grows, the border gateway protocol (BGP) route table grows as well.

Advertised gateway prefixes provide a native way to summarize those Azure-side routes. The feature is configured on the hub virtual network through the summarizedGatewayPrefixes property, which is exposed in the Azure portal as Advertised gateway prefixes.

Fewer BGP prefixes

Replace many individual networks with one or more aggregated CIDRs.

Better scale management

Help large hub-and-spoke designs stay within advertised-prefix limits.

Cleaner route visibility

Make the intended Azure address plan easier to recognize on provider and on-premises route views.

In this blog we will demonstrate leveraging Advertised gateway prefixes to summarize many Azure advertised prefixes into one.

What are advertised gateway prefixes?

Advertised gateway prefixes are summarized CIDR blocks that an Azure hybrid gateway advertises toward on-premises instead of advertising every covered hub and spoke address space individually. The configuration belongs on the gateway virtual network, usually the hub VNet that contains GatewaySubnet and the ExpressRoute or VPN gateway.

How the route advertisement changes

Default behavior	With advertised gateway prefixes
Hub: 10.27.0.0/24 Spoke 1: 10.27.1.0/24 Spoke 2: 10.27.2.0/24 Spoke 3: 10.27.3.0/24	Summary: 10.27.0.0/22
Four individual prefixes are advertised.	One summary prefix is advertised.
A spoke outside the summary is still advertised separately.	Example: 172.16.1.0/24 remains visible if it is not covered by 10.27.0.0/22.

When should you use it?

You use a hub-and-spoke topology with gateway transit and many spoke address spaces.
You want to advertise a covering prefix, such as a /16, instead of many smaller prefixes, such as multiple /24 networks.
You are approaching ExpressRoute advertised-prefix limits or want to reduce route-table growth before scale becomes a problem.
Your Azure address plan is sufficiently structured to create safe, intentional summary ranges.

Note: ExpressRoute scale context: Microsoft documentation lists a maximum of 1,000 IPv4 prefixes and 100 IPv6 prefixes advertised from a virtual network to on-premises on a single ExpressRoute connection through private peering. Exceeding the connection prefix limit can cause the connection between the circuit and gateway to disconnect until the prefix count is reduced.

Prerequisites

A hub virtual network with GatewaySubnet.
An ExpressRoute gateway or VPN gateway deployed in the hub virtual network.
One or more peered spoke virtual networks if you want to demonstrate route summarization across spokes.
A planned IPv4 and, when applicable, IPv6 summary that covers the intended hub and spoke address spaces.
Access to the provider or on-premises BGP route view for validation. In this walkthrough, Megaport is used as the external verification point.

Configure advertised gateway prefixes in the Azure portal

The portal configuration is performed on the hub VNet, not on the ExpressRoute circuit and not on each spoke VNet.

In the Azure portal, search for Virtual networks and select the hub VNet that contains GatewaySubnet.

- Open the hub virtual network

Under Settings, select Address space.

- Open Address space

In Advertised gateway prefixes, select + Add prefix. Enter the covering CIDR, such as 10.0.0.0/22 for four contiguous /24 networks.

- Add the summarized prefix

For a dual-stack design, add IPv4 and IPv6 summarized prefixes explicitly.

- Add additional address families if needed

Select Save and confirm the summarized prefixes remain listed in the Advertised gateway prefixes section.

- Save the configuration

Validate the summarized route on routers or provider

After Azure applies the change and BGP converges, I’m using ExpressRoute and Megaport here for my example, you can either log in to your router directly or view the incoming BGP routes via your provider’s interface to confirm what routes are being received from Azure. We want to capture a view that displays the BGP prefixes learned from the Azure side.

Capture a baseline screenshot before enabling the feature, showing the individual hub and spoke prefixes.
After configuration, refresh the route view and locate the new summarized prefix.
Confirm that covered hub and spoke prefixes are no longer advertised individually.
Confirm that any address space outside the configured summary remains advertised separately.

Before:

After:

In my demo environment I have a hub and 20 spokes all within the 10.27.0.0/16 address prefix. We can see a successful implementation as before enabling the feature, I had a total of 21 prefixes being received at Megaport, after enabling the feature I have 1.

Important design considerations

Configure the hub, not the spokes: Only the virtual network containing the gateway subnet uses the summarizedGatewayPrefixes property for this behavior. A value placed on a spoke VNet is ignored.

Avoid overlap within the prefix list: Do not configure overlapping entries in the advertised gateway prefixes list.

Expect uncovered networks to remain visible: If a hub or spoke address space is not covered by a configured summary, the gateway continues to advertise it individually.

Plan dual-stack explicitly: IPv4 and IPv6 summaries must be added separately.

Removing all entries restores default behavior: When every advertised gateway prefix is removed, Azure returns to advertising hub and peered spoke address spaces individually.

Protect the on-premises edge: Use appropriate route policies so only expected prefixes are accepted. Summarization simplifies advertisements, but it does not replace routing governance.

Conclusion

Advertised gateway prefixes give Azure networking teams a straightforward, native method to control route scale from a gateway-enabled hub VNet. Instead of sending every hub and spoke prefix across ExpressRoute or VPN connections, the gateway can advertise a concise list of summarized prefixes. The result is a smaller and more intentional route advertisement, while uncovered address spaces remain visible for compatibility.

References

Simpler, private connectivity between Azure and AWS with Azure Multicloud Interconnect

Sudha_Mahajan — Mon, 31 Aug 2026 17:59:37 GMT

Multicloud is no longer the exception — it is how most enterprises operate. Teams run analytics in one cloud and applications in another, place workloads to meet data-residency requirements, and increasingly move large volumes of data between clouds to train and serve AI models. Yet the network that connects these environments has remained one of the hardest parts of a multicloud strategy to get right.

Connecting Azure and AWS privately has traditionally meant stitching together Azure ExpressRoute, AWS Direct Connect, a connectivity provider or colocation footprint, customer-managed routers, BGP sessions, and link-layer encryption — then owning the resiliency design and day-to-day operations across all of it. The result is often slow to deliver, difficult to troubleshoot, and inconsistent in performance.

Today, Microsoft and AWS are together introducing Azure Multicloud Interconnect, a jointly engineered, fully managed service that delivers private, high-throughput connectivity between Azure and AWS through a single logical resource. Both clouds coordinate provisioning, resiliency, encryption, and lifecycle operations, so the connection between your environments simply works — end to end.

The challenge with connecting clouds today

For most organizations, cross-cloud connectivity has been a build-it-yourself exercise. Establishing a private link between Azure and AWS typically requires provisioning an ExpressRoute circuit on one side and a Direct Connect circuit on the other, engaging a connectivity provider or securing space in a colocation facility to bridge them, and then configuring and maintaining the routers, BGP peering, and encryption that tie the two clouds together.

Each of those pieces is owned by a different team or vendor, which makes the end-to-end path only as reliable as its least-managed component. When something breaks, isolating the root cause means coordinating across Microsoft, AWS, a network provider, and your own operations team — and mean time to resolution suffers as a result. Capacity planning is equally difficult: bandwidth is often provisioned for peak demand and left underused, while scaling up to meet a new AI or data initiative can take weeks.

The outcome is a connectivity layer that is slow to stand up, expensive to operate, and hard to reason about — exactly the opposite of what a multicloud strategy is meant to deliver. Azure Multicloud Interconnect removes that complexity by turning cross-cloud connectivity into a managed service.

What is Azure Multicloud Interconnect?

Azure Multicloud Interconnect is a provider-managed, private intercloud connectivity service built on the proven foundations of Azure ExpressRoute and AWS Direct Connect. Instead of assembling and operating the underlying components yourself, you establish one interconnect resource and consume a private, dedicated path between your Azure and AWS environments.

Under the covers, Microsoft and AWS coordinate the circuits, routing, and encryption on your behalf. You get the outcome you want — a reliable private connection between clouds — without becoming the systems integrator for it. Because the service builds on ExpressRoute and Direct Connect, it fits naturally into the connectivity models, tooling, and operational practices your teams already use in each cloud.

One managed resource replaces a stack of circuits, routers, BGP sessions, and encryption you would otherwise build and operate yourself.

Figure 1. Azure Multicloud Interconnect provides a single, managed private path between Azure and AWS, built on ExpressRoute and Direct Connect with a quad-redundant, 400G-class design and MACsec encryption.

How it works

Azure Multicloud Interconnect is engineered for the performance and availability that production and AI-scale workloads demand:

A single logical connection. You provision and manage one interconnect resource. There are no customer-owned routers to rack, configure, or patch between the clouds.
Quad-redundant, multi-site design. The data path is built across redundant devices and diverse sites — four Azure Microsoft Enterprise Edge (MSEE) routers and four AWS routers — so there is no single point of failure.
High bandwidth backbone. A high-capacity LAG-based design provides the headroom needed for large-scale data movement and distributed AI traffic.
Elastic bandwidth. Scale capacity up or down as demand changes, rather than provisioning for peak and paying for it year-round.
Encryption by default. MACsec link-layer encryption is enabled automatically, so traffic between clouds is protected without extra configuration.
Enterprise-ready networking. The service is IPv6-ready, supports APIPA addressing, and targets a 99.99% availability SLA.

Routing and provisioning are coordinated by the platform, which removes the most common sources of cross-cloud connectivity errors — mismatched BGP configuration, inconsistent encryption settings, and asymmetric or fragile failover paths.

A foundation you can trust

Azure Multicloud Interconnect is not a new, unproven path — it extends two connectivity services that enterprises already rely on: Azure ExpressRoute and AWS Direct Connect. Both are private connectivity backbones trusted for mission-critical hybrid and cloud workloads, and the interconnect inherits their carrier-grade capacity, global edge presence, and operational maturity from day one.

It also means your teams do not have to learn a separate model. The interconnect appears as a first-class resource governed by the identity, access, and monitoring controls each cloud already provides, and it can be automated with the tooling you use today. Extending trusted services, rather than introducing a parallel one, is what allows Microsoft and AWS to offer intercloud connectivity as a managed experience with confidence.

Why this matters for your team

Azure Multicloud Interconnect is designed to change the economics and the experience of running across clouds.

Taken together, these benefits shift cross-cloud networking from a specialized, high-effort project to a repeatable, on-demand capability. Instead of dedicating senior engineers to build and babysit intercloud links, your team can direct that expertise toward the applications and data platforms that differentiate your business — while trusting that the connective tissue between clouds is reliable, secure, and ready to scale.

Faster time to value. Turn up private Azure–AWS connectivity through a guided, managed workflow instead of a multi-week integration project spanning several vendors.
Lower operational burden. Microsoft manages the infrastructure, resiliency, and lifecycle, so your networking team is freed from patching routers and diagnosing cross-cloud faults.
Predictable, high performance. A dedicated, private path with high capacity that delivers the consistent throughput and low latency that public-internet or VPN paths cannot guarantee.
Security you don’t have to assemble. Private connectivity plus default MACsec encryption keeps intercloud traffic off the public internet and protected in transit.
A consistent experience in both clouds. Provision, monitor, and manage the interconnect using the native constructs and tooling your teams already rely on in Azure and AWS alike.

Built for the way enterprises use multicloud

“I've heard a very consistent message across many years of customer engagements - we are multi-cloud enterprise by design. With this announcement we are taking a burden on connecting clouds away from the customers." Igor Sakhnov, CVP Azure Networking

Customers have told us where dedicated, managed intercloud connectivity makes the biggest difference. Azure Multicloud Interconnect is designed for scenarios such as:

Distributed AI workloads. Move training data and model outputs between clouds at high throughput to feed pipelines wherever the compute lives.
Large-scale data movement. Replicate datasets, back up across clouds, and support analytics that span Azure and AWS.
Cross-cloud disaster recovery. Use a second cloud as a resilient recovery target over a private, reliable link.
Hybrid and best-of-breed architectures. Run each application on the cloud that suits it best while keeping the connection between them private and performant.
Regulated and sovereign workloads. Keep intercloud traffic on a private path to help meet data-residency and compliance requirements.
Workload migration. Rehost or rebalance workloads between clouds without re-engineering connectivity for each move.

Availability and what’s next

Azure Multicloud Interconnect is launching first for Azure and AWS connectivity, the pairing customers ask about most often. Microsoft and AWS are starting with a preview so that you can validate the experience against your own architectures, with general availability to follow.

This is the beginning of a broader journey. Building on existing multicloud connectivity capabilities, we plan to extend the managed interconnect model to additional clouds — including Google Cloud (coming soon)— so that a consistent, provider-managed experience can span your entire multicloud estate. As always, the roadmap will be guided by customer demand and real-world use.

Our shared goal is simple: make the network the easiest part of your multicloud strategy, not the hardest. By delivering intercloud connectivity as a managed service, Microsoft and AWS want every organization — from a team moving its first dataset between clouds to an enterprise operating at AI scale — to connect Azure and AWS privately, securely, and with confidence, and to do it in minutes rather than months.

Get started

Learn more about Azure Multicloud Interconnect, Azure ExpressRoute, and AWS Direct Connect from Microsoft and AWS documentation, talk with your Microsoft or AWS account team about joining the preview, and tell us which cloud pairings and scenarios matter most for your organization. We are building this with your feedback.

Azure Multicloud Interconnect is jointly delivered by Microsoft and AWS, built on Azure ExpressRoute and AWS Direct Connect. Feature availability, performance targets, and timelines may evolve as the service moves from preview to general availability.

Azure DNS + Traffic Manager linked records

atiy — Wed, 26 Aug 2026 15:59:25 GMT

Introduction

Traffic Manager linked records creates a direct, managed link between an Azure DNS record set and a Traffic Manager profile. When a query arrives, Azure DNS evaluates the linked Traffic Manager profile internally and returns the appropriate endpoint response directly. For A and AAAA records, this means the client receives endpoint IP addresses without an intermediate CNAME response to trafficmanager.net.

This practical guide uses a small multi-region Contoso scenario to explain the architecture, configure the feature in the Azure portal, validate the DNS response, and demonstrate endpoint failover. The feature is currently in public preview, so the walkthrough should be tested in a non-production environment before broader adoption.

Note: DNS-based global routing is powerful, but the traditional integration between a custom domain and Traffic Manager adds an intermediate name that customers must understand, resolve, and govern.

The scenario and the problem

Contoso operates a public application across North America, Europe, and Asia. Users browse to contoso.com. Azure Traffic Manager monitors the regional endpoints and selects the preferred healthy destination according to the profile routing method.

Traditional CNAME integration can expose the intermediate trafficmanager.net name in the DNS response.
A CNAME cannot be placed at the zone of apex, which makes root-domain routing harder.
An unsigned intermediate DNS hop can interrupt end-to-end DNSSEC validation.
Operations teams must understand which system is authoritative for the customer zone, and which system makes the routing decision.

Design objective

Preserve Traffic Manager routing methods, endpoint health monitoring, and automatic failover while returning the effective endpoint answer directly from Azure DNS.

The solution: Traffic Manager linked records

Figure 1. Traditional CNAME resolution compared with Traffic Manager linked record.

As you see in figure 1 above, the left side shows the traditional path. The client queries the application name in Azure DNS, receives a CNAME that points to a trafficmanager.net profile name, and then performs another lookup before receiving the selected endpoint address. The right side shows the linked-record path. Azure DNS remains authoritative for the Contoso zone, consults the linked Traffic Manager profile internally, and returns the selected endpoint directly.

The key point is that the Traffic Manager still performs the routing decision and health evaluation. Linked records change the DNS integration and the answer returned to the client; they do not turn Traffic Manager into a reverse proxy or place it in the application's data path.

Reference architecture

Figure 2. Practical multi-region architecture for testing direct resolution and failover.

Reference architecture in figure 2 above shows the client queries contoso.com. Azure Public DNS hosts the authoritative zone and contains a record set linked to the tm-profile Traffic Manager profile. The profile uses a configured routing method and continuously evaluates the health of the regional endpoints. Azure DNS uses the Traffic Manager decision and returns the effective endpoint answer to the client.

For a simple lab, two endpoints are enough. Configure the first endpoint with priority 1 and the second with priority 2. The third regional endpoint in the diagram illustrates how the same design scales to additional regions. The record set can be created at the zone apex by leaving the record name empty, or for a subdomain such as www.

Note: Traffic Manager is DNS based. After name resolution, the client connects directly to the selected public endpoint. Application traffic does not pass through the Traffic Manager.

Prerequisites

An Azure subscription and permissions to create or update Azure DNS and Traffic Manager resources.
A public domain hosted in Azure DNS and delegated to the Azure DNS name servers.
Two public application endpoints that can return visibly different responses for failover testing.
The Microsoft.Network resource provider is registered in every subscription that contains the DNS zone or Traffic Manager profile.

Implementation in the Azure portal

The portal workflow has two main parts: create a strictly typed Traffic Manager profile, then create an Azure DNS record set that links to that profile.

Create the Traffic Manager profile

Step1: Open Traffic Manager profiles, select create.

Step 2: Configure the profile and instance details, fill out the subscription, resource group, name(tm-profile), routing method: priority, record type: A, and resource group location.

Step 3: Add endpoints (Add tmendpoint-1 as the public IP address and external endpoint type with priority 1.

Step 4: Repeat Step 3 to add the secondary endpoint (Add tmendpoint-2 as the public IP address and external endpoint type with priority 2)

Step 5: Confirm endpoint health (Wait until both endpoints report online before testing DNS behavior.)

Note: The record type selection creates a strictly typed profile. Select A for IPv4 answers, AAAA for IPv6 answers, or CNAME for canonical-name answers. The type is used to validate compatibility between the Traffic Manager profile and the linked DNS record.

Create the linked record in Azure DNS

Step 1: Open the Azure DNS zone, select the zone that hosts the application domain, for example contoso.com.

Step 2: Add DNS record sets, select + record set.

Step 3: Choose the record name, leave name empty for the zone apex or enter www for a subdomain.

Step 4: Choose the type, select the record type that matches the Traffic Manager profile, for example, A.

Step 5: Enable Traffic Management, select Enable Traffic Management (Preview).

Step 6: Select the profile, choose the profile subscription and tm-profile, then save the record set.

Note: The record set contains a managed association to the Traffic Manager profile. The linked record inherits its TTL from the Traffic Manager profile.

In the Azure DNS record list, the new record should appear as a linked record associated with the Traffic Manager profile. For an apex A record, the conceptual result is:

Validate the DNS response

Use both the Azure portal and direct DNS query. The portal confirms the resource association; the DNS query confirms the serving behavior.

Portal validation

The record exists in the expected Azure DNS zone.
The record type matches the strictly typed Traffic Manager profile.
The linked profile is tm-profile.
The Traffic Manager endpoints show their expected health state.

Command-line validation

A successful A-record test returns the selected healthy endpoint IP address and does not include a trafficmanager.net CNAME in the answer. Querying for an Azure DNS authoritative name server directly is useful during testing because it reduces ambiguity from local recursive resolver caches.

The specific endpoint returned depends on the routing method, endpoint health, source resolver location, and cached TTL behavior. Validate the result against the profile configuration rather than expecting one universal IP address.

Prove automatic failover

A practical demonstration should show that the linked record is not static. The returned answer continues to reflect Traffic Manager health decisions.

Step	Portal action	What to configure
1	Browse to contoso.com	Confirm the priority 1 endpoint serves the application.
2	Stop priority 1 endpoint	Uncheck the enable endpoint config in tm-profile or stop the VM
3	Monitor Traffic Manager	Wait until the endpoint status changes to unhealthy.
4	Clear local cache	On Windows, run ipconfig /flushdns before querying again.
5	Query or browse again	Confirm the priority 2 endpoint is now selected.
6	Restore the primary endpoint	Start the endpoint and confirm it returns to online.

Why this matters for real architecture

Cleaner DNS answers

The client receives the effective endpoint result directly instead of resolving an intermediate trafficmanager.net name.

Zone-apex routing

Linked records can be used at the root domain, where DNS standards do not allow a CNAME record.

DNSSEC compatibility

Keeping resolution inside Azure DNS removes the unsigned intermediate trafficmanager.net hop from the customer response chain.

Operational type safety

Strictly typed profiles help ensure that the linked DNS record type and Traffic Manager endpoint response type remain compatible.

Preserved routing intelligence

Traffic Manager routing methods, endpoint monitoring, and automatic failover continue to determine the selected endpoint.

Preview and operational considerations

Treat the feature as preview and review the Microsoft Azure preview supplemental terms before production use.
Confirm that the DNS zone and Traffic Manager profile subscriptions have the required resource provider registration.
Plan the record type before creating the Traffic Manager profile because the strictly typed profile value cannot be changed after creation.
Remember that the record TTL is inherited from the Traffic Manager profile.
Test routing, endpoint health, DNSSEC behavior, zone-apex resolution, and rollback in a controlled environment.
Document the previous DNS record so the change can be reversed if the validation plan fails.

Conclusion

Traffic Manager linked records is a focused DNS improvement with meaningful architectural impact.

The feature keeps Azure DNS authoritative for the customer domain, preserves Traffic Manager health-aware routing, and removes the need for the client to follow an intermediate trafficmanager.net hop. That creates a cleaner DNS response path and enables scenarios that were difficult with a traditional CNAME, especially zone-apex routing and DNSSEC-protected domains.

The strongest way to evaluate the feature is through a small, observable lab: create a strictly typed profile, link an Azure DNS record, query the authoritative DNS server, and deliberately fail the primary endpoint. When the DNS response changes to the secondary healthy destination without exposing an intermediate Traffic Manager name, the value becomes immediately clear.

Final takeaway

A small change in DNS integration can simplify the client experience without giving up Traffic Manager routing intelligence, monitoring, or failover.

I hope you enjoyed it!

References

Visual note: Figures in this document were generated with Microsoft Copilot for explanatory use.

Azure DNS Traffic Manager linked records are now generally available

samimodak — Thu, 05 Nov 2026 16:42:14 GMT

We're excited to announce the general availability of Azure Traffic Manager linked records, a new Azure DNS capability that enables customers to directly associate Azure Public DNS record sets with Azure Traffic Manager profiles without using a CNAME to trafficmanager.net.

With this capability, customers can use Traffic Manager's DNS-based load balancing capabilities without exposing the intermediate trafficmanager.net domain in DNS responses. Azure DNS and Traffic Manager now work together to provide a more seamless, integrated DNS experience for applications running across Azure, hybrid, and multi-cloud environments.

Simplifying DNS-based traffic routing

Traditionally, customers using Azure DNS with Traffic Manager relied on CNAME records that returned a Traffic Manager hostname. DNS clients would then perform an additional lookup to resolve that hostname before reaching the application endpoint.

Traffic Manager linked records simplifies this process by allowing Azure DNS to resolve Traffic Manager routing decisions internally and return the appropriate endpoint information directly to clients.

The result is a cleaner DNS resolution path while preserving all of Traffic Manager's existing routing methods, health monitoring, and failover capabilities.

Key benefits

Better integration between Azure DNS and Azure Traffic Manager

Traffic Manager linked records allow Azure DNS record sets to directly reference Traffic Manager profiles, including nested profile configurations.

This enables sophisticated traffic routing architectures without relying on intermediate CNAME records, making complex global deployments easier to build and manage.

Improved security and DNS hygiene

Because DNS responses no longer expose the intermediate trafficmanager.net domain, organizations can simplify firewall rules and reduce reliance on intermediate DNS names.

Traffic Manager linked records also help eliminate a common source of dangling subdomains caused by orphaned or misconfigured trafficmanager.net records, strengthening overall DNS hygiene and reducing operational risk.

DNSSEC for Traffic Manager

Traffic Manager routing decisions are now resolved within Azure DNS, If the DNS zone is a DNSSEC signed zone the answers supplied by linked Traffic Manager profiles are automatically signed as well. This enables customer to use Traffic Manager profiles with DNSSEC, unlike a CNAME to trafficmanager.net which would break the DNSSEC end to end validation chain as trafficmanager.net is not a signed zone.

Zone apex load balancing

Traffic Manager Linked Records enable DNS-based load balancing directly at the zone apex (for example, contoso.com), where traditional CNAME records are prohibited by DNS standards. Customers can now bring Traffic Manager routing to root domains without complex workarounds. This is similar to ALIAS records but with much better integration and scale.

Cleaner & faster DNS responses

Clients now receive the final endpoint directly from Azure DNS instead of first resolving a trafficmanager.net hostname. By removing an extra DNS lookup, applications can experience lower DNS resolution latency while benefiting from Traffic Manager's intelligent routing decisions.

Built-in operational safeguards with strictly typed profiles

Traffic Manager linked records integrate with strictly typed profiles in Azure Traffic Manager, providing validation that helps ensure DNS record types remain compatible with their associated Traffic Manager profiles. In simpler words, this feature ensures that type of response served by the traffic manager profile matches the type of DNS records it is linked to.

The feature also prevents accidental deletion of Traffic Manager profiles that are still referenced by Azure DNS records, reducing the risk of configuration errors and improving operational safety.

Getting started

Traffic Manager linked records are generally available today.

Following record types can be used with Traffic Manager Linked Records

A
AAAA
CNAME

Traffic Manager linked records are designed to make DNS-based load balancing simpler, faster, and more secure while preserving the flexibility and reliability customers expect from Azure Traffic Manager.

To learn more and start using Traffic Manager linked records today, see the DNS Traffic Management documentation.

Announcing Public Preview - Azure Private Link over IPv6

amitmishra — Wed, 05 Aug 2026 17:06:27 GMT

1. Overview

Private Link over IPv6 (PL IPv6) enables customers to securely access Azure PaaS services over IPv6-based connectivity.

This capability is critical for:

IPv6 based PE connectivity to PaaS resources
Enabling IPv6 in On-prem environments

This document is intended to serve as guide to setup and test the On-prem connectivity from IPv6 customer address to Azure PaaS resources over Express Route via Private link. (IPv6 PE connectivity)

Note: This feature is currently in public preview and is not recommended for production workloads.

2. Supported Scenarios

Scenario A: Native Azure (Azure VM → PaaS via IPv6 Private Endpoint)

IPv6 client VM in VNet → IPv6 Private Endpoint → Azure PaaS

Scenario B: OnPrem Access via ExpressRoute

On-prem IPv6 client → ExpressRoute → VNet Routing Appliance (VNRA) à IPv6 Private Endpoint → PaaS
Supported via ER Circuits

3. Prerequisites

3.1 Supported Regions (Preview Scope)

Limited preview regions

West Central US
East Asia
UK South
US Central
North Europe

3.2 Supported Services (Preview)

Azure Storage
Azure SQL
Azure Key Vault
Azure Data Explorer

3.3. Subscription registration

An Azure account with an active subscription. Create an account for free.

Your subscription must be registered for the Private Link over IPv6 preview. Registration is mandatory before you configure any resources. You can self-register the subscription by running the following commands:
az feature register --namespace Microsoft.Network --name SupportIPv6PrivateEndpoint --subscription <subscription-id>
az provider register --namespace Microsoft.Network

4. Configurations

4.1 Azure VNET level configurations

Please note that you will need to create:

Dual-stack IPv6-enabled Vnet with a VM that is assigned both IPv4 and IPv6 address. For on-prem connectivity, this is the same Vnet where ER Gateway is created.
Refer: Create an Azure virtual machine with a dual-stack network - Azure Virtual Network | Microsoft Learn
PL scale enabled on VNET via configuration flags (refer config flags mentioned further in this section and bolded flags in the code snippet)
Dual Stack (IPv4+ IPv6) Subnet
Private Endpoints with IPv6

Refer these flags for enabling VNET with PL scale:

Vnet level :
"privateEndpointVNetPolicies": "Basic",

Subnet level:
“privateEndpointNetworkPolicies": "RouteTableEnabled"

Refer Azure documentation for VNET creation: Quickstart: Create an Azure Virtual Network | Microsoft Learn

4.3 Private endpoint configuration:

With the Private Link IPv6 support, we have introduced a new parameter in PE creation API/CLI, ‘ip VersionType’. Please ensure that this is set to ‘IPv6’ for enabling PL IPv6 traffic.

Refer Azure documentation for PE creation: Quickstart: Create a private endpoint - Azure portal - Azure Private Link | Microsoft Learn

Reference CLI:

az network private-endpoint create \

--name <private-endpoint-name> \

--resource-group <resource-group-name> \

--vnet-name <vnet-name> \

--subnet <subnet-name> \

--private-connection-resource-id <resource-id-of-target-service> \

--group-id <group-id> \

--connection-name <connection-name> \

--location <region> \

--ip-version-type <Ipv4|Ipv6 >

4.4 DNS Configuration

Ensure these points for DNS configurations:

Create Private DNS Zone for each Service type
Attach the respective DNS zone to the Private Endpoints.
Ensure to check that after above steps completed PaaS FQDN resolves to PEIPv6 address.

Refer Azure documentation for On-prem access via Private Link:
Azure Private Endpoint DNS Integration Scenarios | Microsoft Learn

Native Azure Connectivity (Azure VM → PaaS via IPv6)

Validation:

Ensure the Storage Account FQDN resolves to the IPv6 Private Endpoint address.
Access the Storage Account using the standard service FQDN.

From the dual-stack VM:

nslookup <storageaccount>.blob.core.windows.net

Expected Result:

<storageaccount>.privatelink.blob.core.windows.net

AAAA: <Private Endpoint IPv6 Address>

Connectivity validation:

curl https://<storageaccount>.blob.core.windows.net

Test-NetConnection <storageaccount>.blob.core.windows.net -Port 443

Configurations specific to On-prem connectivity via ER circuit and Virtual Network Routing Appliance

On-premises IPv6 clients access IPv6 private endpoints over ExpressRoute through a Virtual Network Routing Appliance (VNRA). ExpressRoute forwards traffic from on-premises IPv6 clients to the VNRA, which then routes the traffic to the target IPv6 private endpoint that's hosted by the Azure PaaS service.

This connectivity requires the following components:

An ExpressRoute circuit with the appropriate gateway SKU for your connectivity type (FastPath or standard). For more information, see Create and modify an ExpressRoute circuit.

4.5 Virtual Network Routing Appliance (VNRA) configurations

To know more about VNRA, refer: Overview of Routing Appliances - Azure Virtual Network | Microsoft Learn

We are leveraging VNRA to facilitate PL IPv6 ER traffic forwarding. User would be required to create a VNRA in the VNet.
To facilitate the forwarding of PL IPv6 traffic via VNRA, a UDR would be required to be added in the gateway subnet with next hop as VNRA IPv6 address. Below are the guided steps to achieve all of this.

Step 1: Create a VNRA in the VNet

Create a VNRA in your resource group via Azure Preview portal.

Search for Azure Virtual Network routing appliance on the Azure portal search

Click on create:
In the above creation page, choose your subscription and resource group, enter name, region, capacity (10-200 Gbps) & the VNet.
Review and Create the VNRA.

Step 2: Create User Defined Route (UDR) to VNRA

The UDR will ensure ER PLIPv6 traffic is forwarded to VNRA which will further process & forward the traffic to the IPv6 Private Endpoint.

1.Create a new route table on Azure portal:

2. Choose the subscription, resource group and set ‘Gateway propagation’ as default (true)

3. Add a route in this route table to forward the on-prem PLIPv6 traffic to VNRA (for this please add route as shown in reference below) as per below details:

Enter ‘Destination type’ as ‘IP Address’
Enter ‘Destination IP addresses/CIDR Ranges’ as Private Endpoint IPv6 subnet range - This is the subnet on which your Private Endpoint resides to which the traffic would be sent
Enter ‘Next hop’ as “Virtual Appliance”,
Give the ‘Next hop address’ as the IPv6 address of VNRA

4.Attach this route table to the Gateway subnet

This completes the VNRA setup.

5. Validate Connectivity

After establishing configuration and deploying your setup, you can run following validations:

From OnPrem VM:

Perform DNS lookup on PaaS FQDN → confirm IPv6 PE resolution
Connect using PaaS FQDN

Validation Checks

VM → PE connectivity over IPv6
Data plane traffic successful

6. Preview Considerations

Limited regional availability (Check preview regions above)
Destination PaaS resource must be in the same region as the Private Endppint. Cross region connectivity is not supported in this release.
Limited PaaS onboarding (Azure Storage, Azure SQL, Azure Key Vault, Azure Data Explorer)
Current on-premises connectivity support is limited to ExpressRoute-based scenarios and does not currently include VPN, Virtual WAN (vWAN), or Network Virtual Appliances (NVAs).
In Private Link IPv6 scenarios, the original client IPv6 address is not preserved in downstream service logs. Due to implicit NAT translation, logs will display the VNet-side translated source IP address instead.

Link to Azure documentation: Configure Azure Private Link over IPv6 (Preview) - Azure Private Link | Microsoft Learn

Azure Virtual Network routing appliance is now generally available

Anshu_Verma — Tue, 04 Aug 2026 20:42:46 GMT

Modern cloud networks are evolving faster than ever.

Organizations are building larger AI platforms, connecting more services through private connectivity, adopting IPv6, and expanding applications across regions and business units. As these environments grow, the network becomes a critical foundation for delivering performance, resiliency, and operational simplicity.

Today, we're excited to announce the general availability of Azure Virtual Network routing appliance, a managed, platform-native routing service designed to provide high-performance connectivity across Azure virtual networks at cloud scale.

Virtual Network routing appliance brings together Azure-native operations, specialized networking infrastructure, built-in resiliency, and high-bandwidth forwarding to help organizations build the next generation of cloud network architectures.

Built for the era of AI infrastructure

AI is changing the scale at which networks operate.

Training clusters, inference services, analytics platforms, data processing pipelines, and distributed application environments generate unprecedented volumes of east-west traffic. These workloads require high-performance connectivity between services, networks, and regions while maintaining operational simplicity.

Virtual Network routing appliance provides a managed routing foundation for these environments, enabling organizations to scale network connectivity alongside their AI investments.

Instead of building and operating custom routing infrastructure, teams can focus on accelerating innovation, deploying new services, and delivering business outcomes.

Scale hub-and-spoke architectures

Hub-and-spoke remains one of the most widely adopted network architectures in Azure because it provides centralized governance, simplified operations, and efficient connectivity.

As organizations expand, however, these architectures often grow from a handful of virtual networks into hundreds or even thousands of connected environments.

Virtual Network routing appliance enables customers to scale these architectures while maintaining a consistent operational model. By providing a dedicated routing layer within the hub, Virtual Network routing appliance simplifies connectivity between applications, shared services, and business units while supporting the scale required by modern enterprise environments.

The result is a network architecture that remains manageable even as organizational growth accelerates.

Unlock large-scale private connectivity

Private connectivity has become the default connectivity model for modern cloud deployments.

Applications, databases, platforms, shared services, and partner solutions increasingly depend on private communication patterns across Azure environments.

Virtual Network routing appliance provides a centralized routing foundation that helps customers build and scale these architectures while maintaining a consistent private networking experience across their environments. Virtual Network routing appliance can also help scale Private Endpoint connectivity beyond the current 20,000-endpoint HSPE boundary. Looking ahead, it establishes a foundation for further accelerating private connectivity to on-premises environments, without introducing additional architectural specifics.

As organizations continue consolidating services onto private connectivity models, Virtual Network routing appliance provides the performance and scale needed to support long-term growth.

Accelerate your IPv6 journey

IPv6 adoption continues to grow across enterprise, telecommunications, and cloud environments.

Organizations increasingly need network architectures capable of supporting IPv4, IPv6, and dual-stack deployments while maintaining operational consistency.

Virtual Network routing appliance supports IPv4, IPv6, and dual-stack virtual networks, enabling customers to modernize network architectures and expand address space without introducing new operational complexity.

Whether organizations are beginning their IPv6 transition or building IPv6-first architectures, Virtual Network routing appliance provides a consistent routing foundation across both address families.

Simplify multi-region architectures

Modern applications rarely live within a single region.

Organizations increasingly deploy workloads globally to improve performance, resiliency, business continuity, and regulatory compliance.

These architectures require a networking foundation capable of supporting connectivity across regions while remaining simple to operate and govern.

Virtual Network routing appliance helps customers build scalable multi-region network architectures by providing a centralized, high-performance routing layer that integrates naturally into Azure networking designs.

This allows teams to focus on application architecture and customer experience rather than operational management of routing infrastructure.

Built for enterprise scale

As organizations continue to grow, networking teams face a common challenge: supporting increasing scale without increasing operational complexity.

Virtual Network routing appliance was designed to meet this challenge by combining:

High-performance routing using specialized Azure networking infrastructure
Built-in resiliency and availability zone support
Native Azure management and governance integration
Support for IPv4, IPv6, and dual-stack deployments
Integrated monitoring and observability through Azure Monitor metrics available
Configurable bandwidth tiers for production workloads
Future support for scaling Private Endpoints beyond 20,000

These capabilities allow customers to build large-scale networking architectures while maintaining a familiar Azure-native operational experience.

Learn more

Azure Virtual Network routing appliance is more than a new networking resource. It is a foundational building block for the next generation of Azure networking.

Organizations are continuing to build larger AI platforms, expand private connectivity, increase multi-region deployments, and modernize network architectures. These transformations require a routing foundation that can scale alongside them.

Virtual Network routing appliance provides that foundation, delivering the performance, scale, resiliency, and operational simplicity required for modern cloud networks.

Whether you're building an AI platform, expanding a hub-and-spoke architecture, scaling private connectivity, enabling IPv6, or designing a global application footprint, Azure Virtual Network routing appliance helps simplify networking so you can focus on what matters most: delivering innovation faster. Overview of Routing Appliances - Azure Virtual Network | Microsoft Learn

Scale limits in network security perimeter

shashankamalladi — Fri, 31 Jul 2026 17:24:48 GMT

Presently, network security perimeter functionality can be used to support deployments of PaaS resources with common public network controls with following scale limitations:

Limitation	Description
Number of network security perimeters	Supported up to 100 as recommended limit per subscription.
Profiles per network security perimeters	Supported up to 200 as recommended limit.
Number of rule elements per profile	Supported up to 200 for inbound and outbound each as hard limit.
Number of PaaS resources across subscriptions associated with the same network security perimeter	Supported up to 1000 as recommended limit.

These limits were deployed as soft limits. The updated limits will be as given in the table below and will now be implemented as hard limits

Limitation	Description
Number of network security perimeters	Supported up to 1000 as hard limit per subscription.
Profiles per network security perimeters	Supported up to 200 as hard limit.
Number of rule elements per profile	Supported up to 200 for inbound and outbound each as hard limit.
Number of PaaS resources across subscriptions associated with the same network security perimeter	Supported up to 2500 as hard limit.

What do the changes mean to users?

Rule elements' creation limit will be capped at 200 for new customers. (presently at 500)
Existing customers who have rule elements >200 per profile, will be allowed to continue above 200 with an option to replace/edit, decrease/reduce but not increase/add the current rule elements without any service interruption till 10/31/26.
1. For example, scenario(s): A user has a profile with rule elements = 400
  1. They cannot increase/add new rule elements and try to go above 400.
  2. They can replace/edit existing rule elements and continue at 400.
  3. They can decrease/reduce rule elements to anything till 200 and that will be their upper ceiling i.e. if they reduce to 250, that will be their new upper ceiling.
  4. If they decrease/reduce to <200, say 150, they can go till 200 but not back to the 400.
After 10/31/26, profiles with rule elements above 200 will be allowed to continue above 200 but only with an option to reduce. There will be no replace/edit and increase options.
1. For example, scenario(s): A user has a profile with rule elements = 400
  1. They cannot increase/add new rule elements and try to go above 400.
  2. They cannot replace/edit existing rule elements but can continue at 400 without touch the rule-elements.
  3. They can decrease/reduce rule elements to anything till 200 but cannot stop above 200 or maintain above 200.
  4. If they decrease/reduce to <200, say 150, they can go till 200 but not back to the 400.

For questions or clarifications, please reach out to nsppmvteam@microsoft.com

Simplify secure, zone-resilient outbound connectivity with Azure Firewall and StandardV2 NAT Gateway

aimeelittleton — Mon, 03 Aug 2026 18:17:01 GMT

As organizations modernize their applications in Azure, secure and resilient outbound connectivity has become just as critical as inbound security. Workloads need reliable access to external APIs, SaaS services, operating system updates, and partner endpoints, while still meeting strong security controls, predictable egress IPs, and high availability.

Achieving all of this consistently requires using the right networking services together.

To make this easier, we’ve updated the Azure Firewall create experience in the Azure portal to include StandardV2 NAT Gateway directly in the deployment flow. This new experience makes it quick and seamless to adopt a secure, scalable, and zone‑resilient outbound architecture from day one by using Azure Firewall and Azure NAT Gateway together.

In this post, we’ll cover:

Why pairing Azure Firewall with StandardV2 NAT Gateway is a recommended design

How this combination simplifies secure and resilient outbound connectivity

What’s new in the Azure Firewall portal experience and how to get started

Why Azure Firewall and StandardV2 NAT Gateway?

Azure Firewall and Azure NAT Gateway are designed to complement each other, each focusing on what they do best:

Azure NAT Gateway and Azure Firewall deployed in a hub and spoke architecture.

Azure Firewall provides centralized traffic inspection and policy enforcement, including IP address and FQDN filtering, threat intelligence, and logging.

StandardV2 NAT Gateway delivers high‑scale outbound SNAT, static egress IPs, and built‑in zone redundancy.

StandardV2 NAT Gateway is zone‑redundant by default, automatically spanning availability zones within a region. This means outbound connectivity remains available even during a zonal failure without requiring multiple zonal NAT gateways or additional routing configurations.

Together, this pairing cleanly separates:

Security policy and inspection handled by Azure Firewall

Outbound scale, resiliency, and IP predictability handled by NAT Gateway

This separation is key for modern, large‑scale cloud workloads.

A recommended outbound architecture

In a typical hub‑and‑spoke design:

Workloads in spoke virtual networks route outbound traffic to Azure Firewall in the hub
Firewall policies inspect and allow the traffic
StandardV2 NAT Gateway is attached to the AzureFirewallSubnet in the Hub
Approved traffic flows through StandardV2 NAT Gateway for SNAT
Traffic exits Azure using static, predictable public IPs

This approach provides several important benefits:

Scalable SNAT capacity for high‑connection workloads

Static outbound IPs for partner allow‑listing and compliance

Zone‑resilient outbound connectivity by default

For step-by-step architectural guidance, see Integrate NAT gateway with Azure Firewall in a hub and spoke architecture.

Built for secure and resilient Azure environments

As customers increasingly adopt availability zones, large‑scale VMSS or AKS deployments, and zero‑trust network models, outbound connectivity must be secure, predictable, and resilient.

By pairing Azure Firewall with StandardV2 NAT Gateway—and now surfacing this pairing directly in the portal create experience—customers can start with a production‑ready outbound architecture that scales with their environment.

What's new in the Azure Firewall create experience in the portal

When creating a new Azure Firewall in the portal, customers can now:

Select and associate a StandardV2 NAT Gateway during firewall deployment.

Reduce post‑deployment configuration and manual touches.

Start with a recommended zone-resilient outbound architecture by default.

By bringing NAT Gateway directly into the Firewall create flow, the portal helps guide customers toward a more secure and scalable outbound setup—without requiring them to stitch services together after the fact.

Get started

You can try the updated experience today by creating a new Azure Firewall in the Azure portal and selecting StandardV2 NAT Gateway during deployment.

With just a couple clicks of a button:

In the Basics tab, configure your Firewall settings (ex., SKU, policy, virtual network).
In the *new* Advanced tab, create a new or add an existing StandardV2 NAT gateway and associate StandardV2 public IP addresses or prefixes. The StandardV2 NAT gateway is automatically attached to the Firewall subnet—no additional routing or configuration required.
Review and Create.

Note: StandardV2 NAT Gateway is not yet available in all regions. If your selected region does not support StandardV2 NAT Gateway, the option to enable StandardV2 NAT gateway will not appear during Firewall creation. Refer to StandardV2 NAT Gateway limitations for more information.

For more details, see:

Azure Front Door edge actions: programmable compute for a secure, resilient, AI-ready edge

AbhishekTiwari — Thu, 30 Jul 2026 17:53:35 GMT

The need for secure edge programmability

As modern web applications increasingly move decision-making closer to users, programmable compute at the edge is becoming a foundational capability for delivering low-latency, personalized, and intelligent experiences. Azure Front Door edge actions introduces lightweight customer-defined logic that executes close to users at Microsoft's global edge (https://aka.ms/edgeactionsblog). The engineering challenge extends well beyond moving code closer to the request path. It is about enabling edge programmability while preserving the core guarantees customers expect from a global edge platform: hyperscale performance and acceleration, strong security and tenant isolation, resiliency, and fast, controlled recovery.

That sets up a much higher engineering bar than simply bringing a serverless runtime to the edge. Programmability introduces customer code, new execution paths, runtime dependencies, and additional failure modes directly into the critical request path. Architecture therefore must make flexibility a first-class capability without compromising the operational characteristics of a hyperscale edge platform.

Preserving performance at hyperscale

The first architectural challenge was preserving the performance characteristics of Azure Front Door while introducing programmable execution into the request path. Every additional execution step has the potential to increase latency, amplify failures, or reduce throughput at global scale. Edge actions was therefore designed to add programmability without changing the fundamental performance profile customers already expect from Azure Front Door.

At request time, Azure Front Door evaluates the request, determines whether an edge action should be executed based on the associated rule, invokes the edge actions runtime, and applies the result inline. Because the runtime sits directly in the request path, every design decision was guided by a common principle: keep execution local whenever possible, bound latency when dependencies degrade, and ensure optional compute never becomes a platform-wide latency amplifier.

Performance design principles

Node-local execution keeps request processing on the same machine whenever possible, minimizing cross-node communications and preserving low latency.
Minimized inter-node hops keep the common path compact while still enabling cluster-level fallback when local dependencies deteriorate.
Connection reuse through Edge Action Agent reduces gRPC invocation overhead and improves hot path efficiency.
Lightweight Hyperlight isolation provides strong tenant isolation with an execution model suitable for latency-sensitive edge workloads.
Fast-fail and circuit-breaker protects latency by bounding waits on degraded dependencies and preventing cascading pressure.

Together, these architectural choices introduce programmable compute without turning the Azure Front Door data plane into a distributed orchestration layer. The hot path remains local, predictable, and bounded, with fallback used only when necessary to preserve performance across the global edge.

Security and tenant isolation by design

Running customer-defined code on a shared global edge fundamentally changes the security model. Unlike traditional request processing, programmable execution introduces untrusted customer code directly into the request path, making strong isolation a foundational architectural requirement rather than an operational safeguard. For Azure Front Door edge actions, every execution is designed to run within a dedicated Hyperlight micro-VM, providing hardware-enforced isolation between customer workloads, the Azure Front Door data plane, and the underlying host environment.

Security design principles

Hypervisor-backed isolation ensures customer code executes within dedicated Hyperlight micro-VM boundaries rather than shared execution environments.
Data plane separation isolates edge actions execution from Azure Front Door's core traffic-processing path.
Minimal host surface area reduces the attack surface and limits privileged interactions.
Restricted execution context exposes only the request information required to process a request.
Reduced operational blast radius helps contain compromised or misbehaving workloads.

These architectural boundaries extend beyond workload isolation. Azure Front Door's data plane remains physically separated from the edge actions orchestration service, while each execution receives only the minimum context required to perform its task. This defense-in-depth approach reduces both security risk and operational blast radius without compromising performance.

Hyperlight: Security without sacrificing performance

A key differentiator of Azure Front Door edge actions is its use of Hyperlight micro-VMs to provide hardware-backed isolation without introducing the traditional performance penalties associated with virtual machines. Hyperlight was designed to make VM-level protection practical for high-throughput function execution, enabling strong tenant isolation while remaining suitable for latency-sensitive edge workloads.

Edge actions builds this foundation through the edge action orchestrator, which maintains a pool of warm Hyperlight sandboxes ready to serve requests. By reusing pre-initialized sandboxes instead of creating a new execution environment for every request, edge actions minimizes initialization overhead, reduces request latency, and sustains higher throughput under load. The result is a security model based on VM isolation that remains compatible with the performance expectations of a hyperscale edge platform.

Critically, performance optimizations do not weaken isolation guarantees. After each execution, sandbox state is cleaned before reuse, ensuring that subsequent invocations cannot access data from prior executions while preserving the efficiency benefits of warm sandboxing. In internal benchmarking, lightweight edge actions executed in less than 2 ms inside Hyperlight, with approximately 1.27 ms of total sandbox overhead, demonstrating that strong isolation and high-performance edge execution can coexist.

Security enables resiliency

Security and resiliency are closely related architectural goals. Isolation helps contain malformed inputs, unexpected behavior, and execution failures, preventing individual workloads from affecting the broader platform. In a multitenant edge service, isolation is not only a security requirement; it is also a key resiliency mechanism.

Resiliency built into the platform

Strong isolation is not only a security property, but also a foundational resiliency mechanism. By containing malformed inputs, unexpected behavior, and execution failures within dedicated execution boundaries, the platform prevents individual workloads from affecting neighboring tenants or the broader service. At hyperscale, robust isolation is essential for maintaining customer trust and predictable platform reliability.

Building on that foundation, Azure Front Door edge actions was designed around a simple operating principle: failures are inevitable, but their impact must be predictable, bounded, and recoverable. Because programmable compute introduces additional execution paths and runtime dependencies into the request path, resiliency must be built into the control points that determine when to execute, stop waiting, or fall back.

The platform incorporates lessons learned from operating Azure services at a global scale, with a focus on minimizing blast radius, maintaining service continuity, and enabling controlled recovery when dependencies fail, overload, or time out.

Resiliency principles

Bound failure impact through isolation and containment.
Recover predictably using health-aware routing and fallback paths.
Protect customer availability first through graceful degradation.
Fail fast rather than fail slowly to avoid latency amplification.
Continuously validate assumptions through Game Days and fault injections.

These principles translate into request-time behavior through deadlines, circuit breakers, fail-open behavior, and health-based fallback. Together, they ensure that optional programmable execution enhances application capabilities without compromising the stability of Azure Front Door's core request-processing pipeline.

Continuous validation of resiliency assumptions

Resilient architecture is credible only when validation becomes part of the operating model. For edge actions, Game Days and Fault Injections provide recurring opportunities to verify that architectural assumptions continue to hold under production-like stress.

Validation includes chaos and failure injections, timeout and dependency-loss exercises, overload and queue-growth scenarios, mixed-workload testing, and interface fuzzing. These exercises answer practical production questions: Does fail-open behavior protect the request path? Do circuit breakers engage early enough? Does fallback routing preserve service continuity? Do malformed inputs remain contained?

Repeated validation also strengthens operations. Detection improves, mitigation becomes more predictable, and recovery evolves from architectural intent into demonstrated operational capability.

Built for future intelligent & modern workloads

Edge actions is designed for lightweight programmable execution today, but the underlying architecture is intended to support increasingly intelligent decision-making over time. The engineering requirement remains unchanged: future intelligence workloads must operate within the same architectural constraints that govern today's request processing - bounded execution, strong isolation, predictable fallback, and protection of the common request path.

Architectural implications for intelligence workloads

Real-time AI inferencing for request classification and policy evaluation.
Intelligent bot, abuse, and fraud detection closer to users.
AI-assisted origin selection and traffic-routing decisions.
Application-specific SLM-powered decision making at the edge.

In that model, the objective is not simply to introduce more intelligence at the edge, but to ensure that intelligence inherits the same platform guarantees as every other component of the request path.

Closing thoughts

Programmable edge execution is becoming a foundational capability for modern distributed applications. The engineering challenge, however, extends far beyond running customer code closer to users. It is about preserving the system properties that customers already depend on while introducing a new execution surface into the critical request path.

Edge actions demonstrates that edge programmability, performance, security, tenant isolation, and resiliency are not independent design goals - they are a single architectural problem that must be solved together. By keeping the common path protected, failures bounded, tenants strongly isolated, and recovery predictable, Azure Front Door edge actions extends the platform's capabilities without compromising the engineering principles that underpin a global hyperscale edge service.

Learn more

Announcing public preview of Azure DDoS Protection custom policy

OfirSarfaty — Thu, 23 Jul 2026 17:16:28 GMT

We are excited to announce the public preview of Azure DDoS Protection custom policy, a new capability that gives customers more granular control over how Azure DDoS Protection detects and mitigates attacks against protected workloads.

Azure DDoS Protection has always focused on delivering automatic, adaptive protection at scale. With custom policy, customers can now fine-tune mitigation behaviour for supported resources and configure protocol-specific detection thresholds. This allows customers to better align protection settings with any planned or projected changes in their application traffic patterns upfront, while giving them additional control over supported protocol thresholds.

Azure DDoS Protection custom policy is currently in preview. See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet generally available.

Why customers asked for more control

Azure DDoS Protection automatically analyses traffic patterns and applies adaptive mitigation during attacks. While this approach works well for most workloads, some organizations require additional flexibility to support unique traffic characteristics, operational environments, or changes around big releases and events.

Customers running latency-sensitive applications, high-throughput services, gaming platforms, or workloads with predictable traffic spikes often want the ability to customize mitigation trigger behavior for specific protocols.

Example scenarios include:

Applications with known peak traffic periods

Workloads that experience sustained high packet-per-second rates

Services requiring protocol-specific tuning

Organizations that need separate mitigation policies across environments or applications

Custom policy allows organizations to align DDoS protection behaviour with their operational traffic baselines while still leveraging Azure’s global-scale mitigation infrastructure.

Key benefits:

Granular, protocol-level control: Configure custom detection thresholds for TCP, UDP, and TCP SYN traffic, so mitigation triggers reflect how your application behaves rather than generic baselines.
Predictable protection during planned events: Align mitigation behaviour with anticipated traffic changes product launches, seasonal peaks, gaming events, so legitimate traffic surges aren't mistaken for attacks.
Flexibility without sacrificing scale: Fine-tune triggers for specific workloads while still benefiting from Azure's global-scale mitigation infrastructure and adaptive protection everywhere else.
Per-resource policy management: Apply separate policies across environments or applications, giving teams the ability to tune protection independently for dev, test, and production workloads.
Full operational visibility: Existing Azure Monitor and DDoS Protection telemetry continue to work with custom policies, so you can validate threshold changes and monitor mitigation activity end to end.

Public preview walkthrough

Customers can deploy and manage DDoS custom policies directly from the Azure portal.

To create a new policy:

Open the Azure portal.
Search for DDoS custom policies.
Select Create.
Choose the subscription, resource group, and region.
Select a supported frontend IP configuration.
Configure protocol detection rules.
Review and deploy.

Once deployed, the custom policy can be associated with supported frontend IP resources to apply protocol-specific mitigation settings.

Current public preview scope

During public preview, Azure DDoS Protection custom policy supports:

Standard Load Balancer frontend IP configurations

TCP, UDP, and TCP SYN threshold customization

Azure portal management

ARM and REST API deployment

Current limitations include:

Support is currently limited to Standard Load Balancer frontend IPs and no Power Shell support

As with all preview features, functionality and supported scenarios may evolve before general availability.

Important considerations

When a customer configures a custom threshold for a protocol, Azure disables autotuning triggers for that protocol and uses the configured static value.

Customers should:

Use anticipated traffic baselines to guide threshold selection

Start with conservative tuning changes

Validate behaviour in lower environments before broad deployment

Monitor mitigation telemetry after configuration changes

Azure Monitor and existing Azure DDoS Protection telemetry continue to provide visibility into mitigation activity and operational behavior.

Looking ahead

Azure DDoS Protection continues to evolve to support modern application architectures, large-scale internet exposure, and advanced operational requirements.

Custom policy extends Azure DDoS Protection's automatic, adaptive baseline with optional per-resource control, without changing the turnkey default that protects every workload out of the box. Autotuning stays on everywhere a custom threshold is not explicitly configured.

We want customers to know that Azure DDoS continues to be a hands-off fully automated service, and that policy customization is not a new operational model, but rather an optional override-on-top automated/adaptive engine.

Get started

Customers can begin using Azure DDoS Protection custom policy today through the public preview experience.

To learn more:

Review the Azure REST API documentation for DDoS Custom Policies here

Deploy a test policy in a supported subscription

Explore the Azure portal experience for policy management

Evaluate protocol-specific threshold tuning for your applications

We look forward to hearing your feedback.

Introducing Azure Front Door edge actions - Bringing secure, programmable logic to the edge

akhilkarmalkar — Mon, 20 Jul 2026 15:32:26 GMT

Modern web applications are expected to feel instant, secure, and personalized, no matter where users connect from or what device they use. Delivering that experience requires more than moving static content closer to users. It increasingly depends on making smart decisions at the edge, from validating requests and selecting the right origin to personalizing responses and stopping suspicious traffic before it reaches the backend.

Because of this, over the last decade, compute resources for web applications have steadily moved closer to users. What began with content caching at the edge quickly evolved into dynamic routing, security enforcement, and intelligent application traffic management. Today, enterprises expect even more: programmable compute at the edge! Developers and platform teams want the flexibility to run lightweight logic at the edge without giving up the scale, security, and operational confidence they expect from Azure.

Azure Front Door through its rulesets offers a robust, declarative framework for applying common traffic management and security policies, such as redirects, header manipulation, and conditional routing. They are optimized for scenarios where behavior can be defined statically and evaluated efficiently at scale.

As customer workloads become more dynamic, and application logic increasingly moves closer to the user, additional capabilities are often required beyond declarative configuration.

Meet Azure Front Door edge actions, now in public preview

We are excited to announce Azure Front Door edge actions which represent Microsoft’s next step in this evolution. With edge actions, customers can execute custom logic directly at Microsoft’s global edge, enabling new classes of real-time personalization, security, and resiliency scenarios, without pushing complexity back to origins!

Edge actions allow customers to author lightweight JavaScript functions that execute as part of Azure Front Door request processing. In the current public preview, edge actions are invoked during the client request phase and are attached to Azure Front Door routes through rulesets.

This tight integration means edge actions work seamlessly with existing Azure Front Door capabilities, including Web Application Firewall (WAF), caching, and routing - while extending them with programmable logic. Customers can incrementally adopt edge actions without re-architecting their applications or delivery pipelines.

What can you build with edge actions today

Edge actions in public preview are optimized for lightweight, latency-sensitive scenarios that benefit from immediate decision-making. Common use cases include:

A/B experimentation and canary rollouts: Evaluate request context at the edge and route users to different application experiences or releases without adding origin-side decision logic.

Request and response header manipulation: Add, remove, or transform headers to support security controls, experimentation, routing, and application modernization patterns.

Request rejection: Stop unwanted, malformed, or unauthorized requests before they consume origin resources.

Dynamic origin selection: Choose the best origin based on request attributes, health signals, geography, device type, or business logic.

URL rewrite and redirect: Adapt paths or redirect users at the edge to simplify migrations, campaign launches, localization, and application routing.

Authentication and authorization scenarios: Validate tokens or request attributes close to the user, helping protect applications before traffic reaches backend services.

Please refer to Azure/EdgeActionsSamples to start building edge actions today.

Designed for industry leading security-first edge compute

Running customer-defined code at the edge introduces unique security challenges. Edge environments now process untrusted user code at massive scales, making strong isolation non-negotiable for Azure.

Enter Hyperlight: Microsoft’s foundation for secure execution. With Hyperlight, each edge action code runs in its own lightweight, hardware-backed micro-VM - like a secure apartment, isolated from neighbors. Unlike traditional virtual machines, Hyperlight micro‑VMs are extremely lightweight and do not have a general-purpose guest operating system. Because of their small footprint, they provide a much more reduced attack surface with a hardware-backed isolation boundary between every instance of customer code, the host infrastructure, and other tenants.

This model allows Azure Front Door to combine the safety properties of hardware virtualization with the performance characteristics required for edge compute. Customer code is isolated by design to reduce blast radius to a single instance, helping protect both the platform and neighboring workloads.

How edge actions fit into the request path 

When a client request reaches Azure Front Door, it follows Azure Front Door’s standard routing pipeline. The request is first evaluated against any configured WAF policies and routing rules. If a rule is configured to invoke an edge action, execution is handed off to the edge actions runtime (Hyperlight) at the edge POP.

At execution time, Azure Front Door provides the edge action with a constrained, immutable context that includes request metadata, server variables, origin health information, and geo or device signals. The edge action can then modify the request, generate a response, or influence routing decisions, all within strict execution and resource limits designed to preserve platform stability.

Ship safely with versions and execution filters

Edge actions are built for operational confidence. Each edge action supports multiple versions of code, and customers can control which version executes using execution filters. This enables header-based routing, canary deployments, and A/B testing scenarios without downtime.

Teams can gradually introduce new logic, validate behavior with real traffic, and roll back instantly if needed, bringing modern DevOps practices directly to the edge.

Observe and operate with confidence

Edge actions integrate with Azure’s existing observability stack. Customers can emit logs from their edge action code and correlate execution results with Azure Front Door access and routing logs. This unified view simplifies troubleshooting and provides visibility into edge execution behavior in production environments.

Pricing

Please refer to the pricing document for details regarding Edge actions pricing, including applicable billing meters and usage-based charges on invocations and execution time.

What’s next for edge actions

The public preview of edge actions represents the foundation of a broader roadmap. Over time, Microsoft plans to expand invocation points, capabilities, and integrations - while continuing to prioritize security, performance, and operational simplicity. Stay tuned for scenarios like response invocations, image/video optimizations, and edge inferencing during general availability.

By combining programmable edge logic with Hyperlight-based isolation, Azure Front Door edge actions mark a significant milestone in Microsoft’s edge strategy - enabling customers to build faster, safer, and more adaptive applications on a global scale.

Start building with Azure Front Door edge actions today! Explore the documentation and bring your complex edge scenarios to life.