Azure Networking Blog articles

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 introduces Traffic Manager linked records (Public Preview)

samimodak — Tue, 18 Aug 2026 16:14:39 GMT

We're excited to announce the public preview of 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 features 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 available today in public preview.

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.

Azure Front Door: Resiliency Series – Part 3: Tenant isolation

AbhishekTiwari — Fri, 10 Jul 2026 22:08:29 GMT

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

Azure Front Door serves hundreds of thousands of tenants from hundreds of edge locations, densely sharing the globally distributed edge fleet. That density is exactly what allows us to deliver global scale, performance, and cost efficiency. It also means that, without strong isolation, a single tenant’s incompatible configuration or anomalous traffic can, in the worst case, affect many other tenants. The October 2025 incidents reinforced how important it is to contain this class of risk. Our goal for this tenant isolation is simple to state and hard to achieve: no single tenant’s configuration or traffic should be able to impact any other tenant.

In Part 1 of our three part mini blog series, we outlined our four‑pillar strategy for improving the resiliency of Azure Front Door: configuration resiliency, data plane resiliency, tenant isolation, and accelerated Recovery Time Objective (RTO). Part 1 detailed how we would make configuration propagation safer and how the data plane keeps serving from a ‘last‑known‑good’ (LKG) configuration, even if an incompatible configuration change is propagated to the data plane. Part 2 turned to recovery, showing how we bring the system back to full operation in an accelerated, predictable, and in a bounded timeframe. In this final part, we turn to the tenant isolation pillar that ensures that any single tenant configuration or traffic issues are limited in scope to that tenant alone and do not impact other tenants. We will also show how Azure Front Door achieves single-tenant containment through configuration isolation, lazy loading, and a micro-cellular layered ingress-sharding architecture.

Repair status: all outstanding items now complete

Before we dive into tenant isolation, here is a final update on the overall repair items from the two October 2025 incidents (you can review the details in our Azure Incident Retrospective sessions for the October 9th and October 29th incidents). We are pleased to report that all outstanding work across every pillar is now complete and fully deployed in production – including the tenant isolation work described in this post. With these safeguards in place, we have also returned configuration propagation latency to pre‑incident levels while keeping platform stability our top priority. In the table below, “Completed” means broadly deployed in production.

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

Why isolation at edge scale is deceptively hard

Traditional isolation techniques such as dedicating separate hardware to each tenant or running every tenant inside its own virtual machine are impractical at the edge. Edge sites are constrained on space, power, and capacity. The entire premise of a modern, multi-tenant application delivery platform is that any tenant can be served from any site closest to the user. We cannot simply partition hundreds of thousands of tenants onto dedicated machines without giving up either proximity, scale, or the efficiency that make the edge fast and cost efficient. Isolation therefore, must be achieved in software, inside a multi-tenant fleet.

What we already do today

Azure Front Door already includes several layers of tenant isolation and partitioning. However, the incidents in October clearly highlighted that these techniques were not enough. Prior to the incidents, our protection mechanisms included:

Infrastructure partitioning. Edge sites were organized into physically isolated primary and fallback traffic rings.
Noisy‑neighbor protection. Fair‑share resource allocation, rate limiting, and anomaly-based load protection kept any single tenant from monopolizing shared resources such as CPU, memory, or network bandwidth on an Azure Front Door server.
Circuit breakers. Circuit breakers shed costly work first and can disable a risky per‑tenant feature before it exhausts shared resources on a server.
Real‑time crash protection. A crash‑analysis system correlates crash signatures across machines and can pinpoint and block crash patterns caused by tenant IPs or traffic patterns.

While these protections are valuable, many of them are reactive and proved insufficient during the October incidents. The next generation of isolation makes single‑tenant containment a fundamental part of the platform which governs how configurations are loaded, and how traffic is served.

Configuration isolation: loading only what is needed

Part 2 introduced ‘lazy loading’ as a recovery optimization technique. It is also an important configuration‑isolation mechanism. Historically, every worker on every edge server had to be ready to serve any tenant, which meant each worker loaded a large set of tenant configurations. A single incompatible configuration could therefore ripple across many workers.

With lazy loading, a worker loads a tenant’s configuration and its TLS certificates only when it actually receives traffic for that tenant. The practical consequence for isolation is powerful: a faulty configuration can only affect the workers that have loaded that specific tenant, never the entire server or fleet. Combined with per‑tenant validation on load, and the Food Taster safeguard from Part 1 (a sacrificial process that pretests every configuration change in isolation), configuration problems are caught early and contained to the smallest possible footprint.

Figure 1: With lazy loading, an incompatible configuration is contained to the workers serving that tenant, instead of poisoning the whole server.

Tenant isolation: a micro-cellular, layered ingress sharding architecture

Configuration isolation limits the blast radius of an incompatible configuration. Traffic isolation addresses the other half of the problem: a tenant whose anomalous traffic incident, like a sudden surge, a pathological request pattern, or malicious activity, could degrade a shared worker. Our approach is a micro‑cellular architecture that combines multiple concepts working together.

Worker‑process isolation. Each edge server already runs many independent worker processes. Instead of letting every worker serve every tenant, we assign tenants to specific groups of workers. Those worker group (shards) become the unit of isolation: if a tenant destabilizes its shard, the impact is contained to that shard’s workers while the rest of the server keeps serving normally.
Ingress sharding. Rather than a handful of fixed shards, we compose shards from overlapping subsets of a server’s workers. Even a modest number of workers can be combined into an enormous number of distinct, overlapping shards – giving us a very large number of fine‑grained fault domains without dedicating hardware to every tenant.

Figure 2: Tenants are randomly assigned to different shards on each server (layer). Even when a good tenant shares the noisy tenant’s shard on one layer, routing steers its traffic to healthy shards on the others.

Multi‑layer ingress sharding. This is where ‘layered’ comes in. Each edge server is treated as an independent layer, and each tenant is assigned to a different, randomly chosen shard on every server. Because assignments are independent from one server to the next, two tenants that happen to share a shard on one server are extremely unlikely to share a shard again on another server. The chance of any good tenant repeatedly colliding with a noisy tenant across many servers becomes vanishingly small.
Intelligent ingress routing. Tying it together is a routing layer that terminates each incoming connection, identifies the tenant, and steers the request to that tenant’s assigned, healthy shard. If a shard is unhealthy or saturated, traffic is directed to the tenant’s healthy shards on other layers.

Figure 3: Intelligent Ingress Routing

The combined effect is that when a noisy tenant overwhelms or crashes its shard on one server, only that shard is affected. Because every other tenant is spread across a different, randomized set of shards, they continue to find healthy paths, and the routing layer moves their traffic accordingly. A worst-case availability problem is downgraded to, at most, a small and redistributable capacity problem, that the routing layer smooths over.

An in-depth technical analysis of layered ingress sharding is available here for reference.

Shrinking the blast radius

Taken together, these mechanisms fundamentally change the shape of failure. In a uniform, fully shared fleet, an incompatible tenant can, in the worst case, affect a large share of the tenants on a machine, in an edge location, or beyond. With configuration isolation and layered ingress sharding, the same failure is confined to a subset of workers serving the offending tenant. Our target for this tenant isolation pillar is effectively single‑tenant containment: a configuration or traffic anomaly caused by one tenant should never cause issues to any other tenants.

Figure 4: From a shared fleet where a single tenant can affect many, to micro‑cellular shards that confine impact to the offending tenant.

Validating isolation in practice

As with our recovery work, we don’t simply design these boundaries and assume they hold, we test them. Through deliberate fault‑injections, we have pushed noisy and faulty tenants into the system and confirmed that impact stayed contained to the offending shard, that healthy tenants kept serving, and that the routing layer steered around unhealthy shards as intended. This turns isolation from a design claim into a well-drilled, and repeatable outcome.

Closing

This post concludes our three-part mini blog series on Azure Front Door resiliency. We have shared how we are making configuration propagation safer (Part 1), recovering faster when failures do occur (Part 2), and containing the blast radius stemming from any single tenant through configuration isolation and a micro‑cellular, layered‑sharding architecture (Part 3).

Resiliency, however, is not a project with an end date. It is an ongoing commitment. While this series concludes the blog series of our response to the October 2025 incidents, our investments in Azure Front Door’s resiliency, isolation, and recovery will continue. As we make further improvements, we will keep sharing them with you.

We deeply value our customers’ trust in Azure Front Door. We remain committed to exceeding expectations for security, reliability, and transparency.

Azure Firewall explicit proxy Migration Guide

devanshirastogi — Fri, 19 Jun 2026 18:21:40 GMT

Purpose of the blog

This blog outlines the key upcoming changes to Azure Firewall explicit proxy and provides detailed migration guidance for customers using PAC file–based configurations. It also covers the supported deployment options for enabling explicit proxy after the changes are released, including the Azure portal, PowerShell, and Azure CLI.

Who is this article for?

This article is intended for customers currently using Azure Firewall explicit proxy in preview. If you use PAC file–based proxy configuration, follow the steps below to configure the new PAC file SAS URL retrieval method, which will become the standard approach going forward.

Azure Firewall explicit proxy

Azure Firewall operates in a transparent proxy mode by default. In this mode, you use a user-defined route (UDR) configuration to send traffic to the firewall. The firewall intercepts that traffic inline and passes it to the destination.

When you set up explicit proxy on the outbound path, you can configure a proxy setting on the sending application (such as a web browser) with Azure Firewall configured as the proxy. As a result, traffic from the sending application goes to the firewall's private IP address and therefore egresses directly from the firewall without using a UDR.

The Azure Firewall explicit proxy feature is in Preview at the time this article was published.

Upcoming changes to the explicit proxy feature in Azure Firewall

PAC (Proxy Auto-Configuration) file size is now limited to 256 KB.
Support HTTP and HTTPS traffic over a single HTTP proxy port.
Removal of the previous dual-port configuration requirement (explicit proxy v1).
Ability to enable explicit proxy directly using Firewall Policy creation in the Azure portal.
Following general availability (GA), explicit proxy will require both a PAC file SAS URL and Managed Identity (MSI), along with the appropriate role assignments to meet Microsoft security standards.

Follow the steps below to migrate to the new PAC file retrieval model that uses customer-managed Azure Storage and Managed Identity authentication.

Step 1: Create a PAC File SAS URL

Create an Azure Storage container by following the steps in Manage blob containers using the Azure portal - Azure Storage | Microsoft Learn. Note: Use a subscription in which required permissions to add roles exist.
Upload the PAC file to the storage container.

Select the uploaded file and copy the file URL. Example URL: "https://eproxypstestresources.blob.core.windows.net/explicitproxycontainer/proxy.pac"

Step 2: Create a Managed Identity and assign required roles

Navigate to Managed Identity blade and create a Managed Identity. See Manage user-assigned managed identities using the Azure portal - Managed identities for Azure resources | Microsoft Learn for more details.
Go to the storage account resource created in the previous step and navigate to Access Control (IAM). Select Add to add the role assignment.
Go to the Add role assignment page and search for Storage Blob Data Contributor and Storage Blob Data Reader, then select both.

Go to Members → Managed Identity and select the identity created earlier. Review the changes and click Assign in Review + Assign blade.

Verify that your changes are reflected under Role Assignments by searching for the managed identity. Note: Make sure that the Managed Identity created has prefix "PacFileMSI-".

Configuration using portal, PowerShell and Azure CLI

Portal configuration

After obtaining the PAC file SAS URL and Managed Identity, enable the PAC file in the explicit proxy configuration by:

providing the PAC file SAS URL, and
selecting the Managed Identity created in the previous steps.

PowerShell configuration

To securely use explicit proxy, customers must provide:

the PAC file SAS URL, and
a Managed Identity with the required permissions to access the PAC file from the customer-managed Blob Storage account.

Create Firewall Policy with explicit proxy settings:$exProxy = New-AzFirewallPolicyExplicitProxy ` -EnableExplicitProxy ` -HttpPort 100 ` -EnablePacFile ` -PacFilePort 130 ` -PacFile "https://sampleurlfortesting.blob.core.windows.net/container/proxy.pac"
```
Update Firewall Policy with explicit proxy configuration:
```
New-AzFirewallPolicy ` -Name "fp1" ` -ResourceGroupName "TestRg" ` -ExplicitProxy $exProxy ` -UserAssignedIdentityId "/subscriptions/e7eb2257-46e4-4826-94df-153853fea38f/resourcegroups/testrg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/PacFileMSI-eproxyidentity"

Azure CLI configuration

Create Firewall Policy with explicit proxy settings:az network firewall policy create -g "testrg" -n "testfwpolicy" --sku Premium --explicit-proxy enable-explicit-proxy=true http-port=9001 enable-pac-file=true pac-file-port=122 pac-file="https://eproxypstestresources.blob.core.windows.net/explicitproxycontainer/proxy.pac" --identity "Identity_ID"
Update Firewall Policy with Explicit Proxy Configuration:az network firewall policy update -g "testrg" -n "testfwpolicy" --explicit-proxy enable-explicit-proxy=true http-port=9001 enable-pac-file=true pac-file-port=124 pac-file="https://eproxypstestresources.blob.core.windows.net/explicitproxycontainer/proxy.pac" --identity "Identity_ID"

Migrating from MSEE Hairpin Routing to AVNM Mesh for Large-Scale VNet-to-VNet Connectivity

Jay-Li — Fri, 19 Jun 2026 07:55:59 GMT

Introduction

A common pattern in large Azure deployments is to route VNet-to-VNet traffic through Microsoft Enterprise Edge (MSEE) routers. This happens when spoke VNets in a hub-and-spoke topology communicate with each other by hairpinning through the ExpressRoute circuit: traffic exits the Azure data center, traverses MSEE, and re-enters the data center to reach the destination VNet.

This pattern works, but it was not designed as the long-term connectivity model for east-west traffic. With Azure Virtual Network Manager (AVNM) mesh connectivity and recent scale improvements — including high-scale mesh up to 5,000 VNets and High-Scale Private Endpoints (HSPE) up to 20,000 Private Endpoints across connected VNets — enterprises can migrate to a direct, in-datacenter routing model that removes MSEE dependency for VNet-to-VNet traffic.

This article explains why the migration is useful, what the new scale limits are, how to enable the required features, and how to execute the migration with minimal disruption.

Who This Is For

This migration is most relevant if you have 50 or more spoke VNets communicating east-west through ExpressRoute hairpin routing, are approaching VNet peering limits, want to reduce ExpressRoute utilization from internal traffic, or need a simpler centrally managed connectivity model. Even if most east-west flows must continue through a hub firewall for inspection, you can still simplify connectivity management for the flows allowed to go direct.

Why MSEE Hairpin Routing for VNet-to-VNet Is Not Recommended

When spoke VNets communicate through MSEE, traffic follows a suboptimal path:

Spoke A → Hub VNet → ExpressRoute Gateway → MSEE → ExpressRoute Gateway → Hub VNet → Spoke B

Single point of failure. MSEE becomes a shared dependency for east-west traffic. An MSEE outage or capacity constraint can affect every VNet pair in the topology.
Lower-latency path. Traffic no longer needs to leave the data center and return for spoke-to-spoke communication. Direct mesh keeps east-west traffic on an in-datacenter path, which is generally lower latency than hairpinning through MSEE.
Bandwidth constraints. MSEE circuits have finite bandwidth. Routing east-west traffic through them competes with north-south on-premises traffic and can saturate the circuit.
Operational risk at scale. Large deployments place significant load on MSEE infrastructure, creating scalability, reliability, and operational concerns for environments with thousands of VNets.

Why Manual Peering Was Not a Practical Alternative

The obvious alternative — creating direct VNet peerings between every spoke pair — solves the MSEE dependency but introduces its own operational complexity:

Combinatorial growth. Connecting N spokes requires N × (N - 1) / 2 peering relationships. For 100 spokes, that is 4,950 peerings. For 1,000 spokes, it is nearly 500,000.
Management overhead. Each peering must be individually provisioned, monitored, and maintained. This increases drift, audit, and operational overhead.

How AVNM Mesh Solves This

AVNM mesh provides group-based connectivity. You define a set of VNets as a network group, apply a mesh connectivity configuration, and AVNM establishes bi-directional connectivity across all members.

Traffic between meshed VNets stays within the Azure data center: no MSEE traversal, no hub hop, and no manual peering management.

Define once, connect all. A single mesh configuration connects every VNet in the group to every other VNet.
Centralized management. Add or remove VNets from the group; AVNM reconciles connectivity automatically.
Direct spoke-to-spoke paths. Traffic flows directly between VNets, bypassing both the hub and MSEE.
Dynamic membership. Use Azure Policy to auto-enroll new VNets based on tags or resource group conditions.

How to Migrate Large Scale Topology

High-scale mesh lets user migrate larger topology — up to 5,000 VNets and 20,000 Private Endpoints in a mesh.

Scale — Standard Mesh vs. High-Scale Mesh

Dimension	Standard Mesh	High-Scale Mesh
VNets per mesh	Up to 250 (soft limit, can request increase)	Up to 5,000
Private Endpoints per mesh	Up to 2,000	Up to 20,000 (with HSPE enabled)
Private Endpoints per VNet	Up to 1,000	Up to 5,000 (with HSPE enabled)

Enabling High-Scale Private Endpoints (HSPE)

As a mesh footprint grows, so does the number of Private Endpoints deployed across the connected VNets. The default platform limits — 1,000 Private Endpoints per VNet and 2,000 across connected VNets and mesh — can be reached quickly in large environments. Enabling HSPE raises these limits to 5,000 and 20,000, respectively.

For large-scale mesh migrations, enable HSPE proactively if the environment is expected to grow toward standard Private Endpoint limits by following the steps below.

Step 1 — Prepare Each VNet

Ensure Private Endpoint Network Policies are set to Enabled or RouteTableEnabled on all subnets containing Private Endpoints. This is a prerequisite.
Set the VNet-level property PrivateEndpointVNetPolicies to Basic. This activates HSPE on the VNet.

Step 2 — Enable HSPE on the Mesh Configuration

In the AVNM mesh connectivity configuration, enable the option for high-scale private endpoints. AVNM validates that all VNets in the mesh are HSPE-enabled. If any VNet is missing the configuration, the deployment is blocked with a clear error.

Step 3 — Deploy

Deploy the connectivity configuration. AVNM applies HSPE across the mesh.

Behavior Changes When Enabling HSPE

Brief connection reset. Enabling or disabling HSPE triggers a one-time, approximately 1-second connection reset for existing Private Endpoint connections in the VNet. Plan this during a maintenance window.
Per-PE Bytes In / Out monitoring is no longer available. HSPE treats each Private Endpoint IP like any other IP in the VNet, which removes per-PE traffic counters. If you depend on per-PE metrics, evaluate alternatives before enabling.
On-premises PE traffic billing changes. PE traffic originating from on-premises appears as an aggregate bill on the gateway VNet, not on the individual Private Endpoint resource. The total bill does not change.

How to Avoid Downtime

Mesh coexists with existing peerings. AVNM does not delete manually created peerings unless explicitly configured to do so.
Traffic shifts automatically. Once mesh is deployed, spoke-to-spoke traffic routes directly. The MSEE hairpin path remains available if mesh is removed.
No reconfiguration of hub components. Firewalls, gateways, and NVAs in the hub continue to function. North-south on-premises traffic still flows through the hub gateway.
Rollback is simple while the legacy path remains. Keep the MSEE hairpin path in place during validation so affected VNets can fall back by removing them from the network group or undeploying the mesh configuration.

Security and East-West Traffic Inspection

A common concern is whether direct mesh connectivity bypasses hub firewalls or network virtual appliances. The answer depends on how inspection is enforced today.

Mesh provides connectivity, not routing policy. If spoke subnets have UDRs that direct traffic through a hub NVA or firewall, those UDRs continue to apply and can keep inspected flows on the firewall path.
Security Admin Rules provide centralized segmentation. For flows that do not require firewall inspection, AVNM Security Admin Rules can enforce network-level allow or deny policies across network groups.
Use both where appropriate. Mesh can provide direct connectivity for approved flows while Security Admin Rules enforce segmentation boundaries where required.

Recommendation: Before migrating, inventory which spoke-to-spoke flows currently traverses the firewall. Decide per flow whether to maintain inspection by keeping UDRs in place or allowing a direct mesh path by removing the UDR for that flow pair.

Migration Order and Process

The migration from MSEE hairpin routing to AVNM mesh is non-disruptive by design. Mesh connectivity overlays on top of existing peerings and takes routing precedence for east-west traffic. You do not need to tear down the existing hub-and-spoke topology first.

Recommended Steps

Design the mesh topology. Group VNets by region into mesh groups. If you expect more than 250 VNets per mesh, register the AllowHighScaleConnectedGroup feature in advance.
Create a Network Manager and define Network Groups. Ensure that the AVNM scope covers all relevant subscriptions. Use static membership for initial migration or dynamic membership through Azure Policy for ongoing enrollment.
Enable HSPE on every VNet in the mesh. Follow the HSPE enablement steps if you need to have more than 2,000 Pes in a mesh. Schedule the change during a maintenance window to account for the brief connection reset.
Create the mesh connectivity configuration in AVNM. Select the network groups, enable mesh topology, enable high-scale private endpoints, and enable global mesh if cross-region connectivity is required.
Deploy incrementally. Start with a pilot region or non-critical environment. Validate effective routes, spoke-to-spoke connectivity, spoke-to-hub-to-on-premises connectivity, Private Endpoint reachability, and expected VNet flow log patterns before expanding to production regions.

Route Behavior During and After Migration

During migration, mesh and MSEE can coexist. Mesh-connected VNets receive direct routes for mesh-connected destinations, while existing ExpressRoute gateway routes continue to serve on-premises destinations. UDRs still override system routes, so forced-tunneling and firewall inspection patterns remain in effect when UDRs are present.

Mesh destinations. Traffic between mesh-connected VNets goes directly instead of hairpinning through MSEE when no UDR overrides the route.
On-premises destinations. ExpressRoute continues to provide north-south connectivity to on-premises networks.
Gateway transit. Spokes can continue to reach on-premises through the hub gateway when the design uses gateway transit.

Infrastructure-as-Code Considerations

If VNet peerings are managed through Terraform, Bicep, or ARM templates, treat AVNM mesh as the new source of truth only after validation.

Deploy mesh first. AVNM mesh can coexist with existing peerings, so do not remove peering resources from IaC before validating the mesh path.
Validate the traffic path. Use effective routes, Connection Monitor, and flow logs to confirm traffic is using mesh where expected.
Guard against drift. Review pipeline state and lifecycle settings before decommissioning old peerings, especially in environments where multiple teams manage network resources.
Codify AVNM. Manage the Network Manager, network groups, configuration, and deployment through IaC so mesh becomes the governed connectivity model.

DNS Resolution Across Mesh

Mesh connectivity does not change DNS resolution behavior by itself. If spoke VNets are already linked to Private DNS Zones hosted or managed through the hub, those links continue to determine name resolution. If spokes use custom DNS servers in the hub, verify that any UDR changes made during migration do not unintentionally alter the DNS traffic path.

Migration Example — Two Hub-and-Spoke Topologies into a Single Mesh

This example shows how an enterprise can migrate two regional hub-and-spoke environments into one centrally managed AVNM mesh while preserving the existing MSEE path during validation.

Current State — Two Hub-and-Spoke Topologies with MSEE Hairpin

Contoso Corp operates a large Azure environment in the East US region with two hub-and-spoke topologies:

	Topology A	Topology B
Hub VNet	Hub-A	Hub-B
Spoke VNets	500	500
ExpressRoute Gateway	ER-GW-A in Hub-A	ER-GW-B in Hub-B
ExpressRoute Circuit	Shared circuit, connected to both gateways	Same shared circuit
Avg. Private Endpoints per spoke	~8 (4,000 total)	~12 (6,000 total)
Total Private Endpoints	10,000 across both topologies

How traffic flows today:

Spoke-to-spoke within Topology A: Spoke-A-01 → Hub-A → ER-GW-A → MSEE → ER-GW-A → Hub-A → Spoke-A-02
Spoke-to-spoke across topologies: Spoke-A-01 → Hub-A → ER-GW-A → MSEE → ER-GW-B → Hub-B → Spoke-B-01

Every spoke-to-spoke packet — whether within the same topology or across topologies — exits the data center, traverses MSEE, and re-enters. With 1,000 spokes generating east-west traffic, MSEE becomes a shared single point of failure and adds latency to every flow.

Target State — A Single AVNM Mesh with 1,000 VNets

Contoso's goal is to consolidate all 1,000 spoke VNets into a single AVNM mesh, removing MSEE from the east-west traffic path.

Spoke-to-spoke traffic, any pair: Spoke-A-01 → directly→ Spoke-B-01. Traffic stays in the data center and uses the direct mesh path.
MSEE role: MSEE carries north-south on-premises traffic. East-west load is removed from the ExpressRoute hairpin path.

Migration Execution

Phase 0 — Pre-Work

Register the feature. Since the mesh contains 1,000 VNets, above the 250 standard limit, Contoso registers the AllowHighScaleConnectedGroup feature flag on the subscription. This enables high-scale mesh support for up to 5,000 VNets.
Inventory Private Endpoints. With 10,000 Private Endpoints across 1,000 VNets, Contoso exceeds the standard mesh Private Endpoint limit of 2,000. HSPE must be enabled.

Phase 1 — Enable HSPE on All 1,000 Spoke VNets

Batch 1: Enable HSPE on all 500 spoke VNets in Topology A during the maintenance window by following the instructions.
Batch 2: Apply the same configuration to all 500 spokes in Topology B.
Expected impact: Each VNet may experience a brief connection reset for existing Private Endpoint connections when HSPE is enabled. Schedule the change during a maintenance window.

Phase 2 — Create the AVNM Mesh

Create a Network Manager scoped to the management group containing all 1,000 spoke VNets.
Define a single network group called eastus-mesh-all-spokes with dynamic membership using an Azure Policy and the tags.
Create a mesh connectivity configuration. Set topology to Mesh, network group to eastus-mesh-all-spokes, high-scale private endpoints to Enabled, and global mesh to Not needed because all VNets are in the same region.
Save the configuration as a draft and do not deploy yet.

Phase 3 — Incremental Deployment

Wave 1 — Pilot: Contoso deploys the mesh configuration to 50 dev/test spokes, either by using a temporary network group or by tagging only those VNets initially. Validation includes effective routes showing ConnectedGroup as the next-hop type for meshed spoke prefixes, spoke-to-spoke connectivity through the direct mesh path, Private Endpoint reachability across meshed spokes, unchanged on-premises connectivity through the hub and MSEE, and VNet flow logs that confirm expected direct spoke-to-spoke flows.

Wave 2 — Light production traffic VNets: After a successful pilot, Contoso tags light production traffic VNets. The dynamic network group picks them up automatically. Contoso redeploys the connectivity configuration, runs the same validation checklist, and monitors traffic to confirm that east-west traffic from these VNets is moving away from the ExpressRoute hairpin path.

Wave 3 — All remaining production VNets: Contoso tags all remaining spokes and redeploys the configuration. At this point, all 1,000 spokes are in the mesh.

No downtime migration: During Waves 2 and 3, existing MSEE hairpin routing remains functional. VNets not yet in the mesh continue to communicate through MSEE. VNets already in the mesh communicate directly through the mesh. This avoids a planned connectivity gap during migration.

Phase 4 — Post-Migration Validation

After deployment, confirm that mesh is active and traffic is taking the expected path before decommissioning the legacy route.

Effective routes. Verify spoke subnets show direct routes to peer VNet prefixes instead of routing through the gateway or MSEE.
Connection Monitor. Track representative spoke-to-spoke flows and compare latency and reachability before and after migration.
VNet flow logs. Confirm east-west traffic matches the expected mesh path and is not still traversing the ExpressRoute gateway path.
Network Watcher topology. Visualize the resulting connectivity model and identify any VNets not enrolled in the target network group.

If traffic is still hairpinning after mesh deployment, check for UDRs overriding system routes, spokes missing from the network group, deployment not committed to the target region, or IaC pipelines recreating legacy peerings.

Rollback

Quick rollback while MSEE remains in place. Remove affected VNets from the network group or undeploy the mesh connectivity configuration. AVNM removes only the connectivity it created, and traffic can fall back to the existing MSEE hairpin path.
Rollback after decommissioning legacy paths. If old peerings or route dependencies have already been removed, rollback may require reprovisioning those resources and should be treated as a longer change window.
Recommendation. Keep the MSEE hairpin path available for at least two weeks after mesh deployment, monitor traffic patterns, and only then remove the legacy path.

Before and After Summary

Metric	Before (MSEE Hairpin)	After (AVNM HSPE Mesh)
Spoke-to-spoke latency in the same region	Higher due to the MSEE hairpin path	Lower-latency direct in-datacenter path; actual latency depends on workload, region, and network conditions
Traffic path for east-west	Spoke → Hub → MSEE → Hub → Spoke	Spoke → Spoke directly through the Mesh
MSEE dependency for east-west	Yes, shared dependency	No MSEE dependency for east-west traffic
Manual peerings required	0 when using hairpin routing, but 499,500 if built manually for 1,000 spokes	0 manual spoke-to-spoke peerings; AVNM manages connectivity
Private Endpoints supported	2,000 per mesh under standard limits	20,000 per mesh with HSPE
Rollback complexity	Not applicable to the current hairpin model	Remove VNets from the network group or undeploy the connectivity configuration
Migration downtime	Not applicable	Designed for no planned downtime when deployed incrementally and validated carefully

Closing Notes

Migrating to AVNM mesh does not require tearing down your existing network. The hub gateway, firewalls, and NVAs continue to function as they do today. What changes is that east-west spoke-to-spoke traffic stops leaving the data center unnecessarily.

MSEE is not the right tool for the east-west fabric. Removing internal traffic from the ExpressRoute circuit is a reliability and capacity improvement.
AVNM mesh replaces combinatorial complexity with group-based intent. The operational model scales with the number of groups, not the number of VNets.
High-scale mesh and HSPE remove the ceiling — up to 5,000 VNets and 20,000 Private Endpoints per mesh.
The migration is incremental and reversible. Mesh coexists with existing paths, and you can validate wave by wave before decommissioning the legacy route.

Start with a pilot mesh in a non-critical environment, validate the traffic shift, and expand from there.

Resources

ICMP Support for Azure StandardV2 NAT Gateway

malaikanazim — Wed, 17 Jun 2026 17:44:22 GMT

Our customers, across all industries, depend on consistent outbound connectivity and observability to operate and troubleshoot their cloud workloads at scale. As Azure environments grow in size and complexity, teams increasingly rely on standard network diagnostic tools such as ping to quickly validate reachability and identify connectivity issues.

When customers route outbound traffic through Azure NAT Gateway, they benefit from centralized and scalable outbound connectivity designed to prevent SNAT port exhaustion, while simplifying management by removing the need for per‑resource public IPs. Historically, outbound connectivity through Azure NAT Gateway supported TCP and UDP traffic only for Azure workloads.

We are pleased to announce that Azure StandardV2 NAT Gateway now supports outbound ping through ICMP Echo Request and Echo Reply traffic. Workloads that rely on NAT Gateway for internet egress can now use ping to validate reachability, improving operational visibility and simplifying network troubleshooting while preserving the scalability and resiliency characteristics of NAT Gateway.

What’s now supported?

Azure StandardV2 NAT Gateway supports outbound ICMP Echo Request and Echo Reply traffic (ping) for IPv4 and IPv6. Other ICMP message types are not currently supported.

With this update, ICMP traffic sent from workloads behind a NAT Gateway can be translated to a public IP address and reliably receive responses from external endpoints. This brings ICMP behavior in line with existing TCP and UDP outbound flows, enabling consistent network diagnostics across all common transport types.

This capability is available automatically when workloads egress through a StandardV2 NAT Gateway - no additional configuration or rule changes are required.

Scenarios enabled by ICMP support

Support for ICMP through StandardV2 NAT Gateway unlocks several common operational scenarios:

Basic reachability testing – Operators can use ping from virtual machines, VM scale sets, or AKS nodes behind NAT Gateway to verify outbound connectivity to internet endpoints.
Health validation and troubleshooting – Teams can perform quick checks during incident triage without deploying jump hosts, public IPs per VM, or temporary firewall exceptions.

These scenarios are especially valuable in large‑scale environments where workloads rely on centralized outbound connectivity via NAT Gateway.

How ICMP works through StandardV2 NAT Gateway

Unlike TCP or UDP, ICMP does not use ports to differentiate flows. Instead, ICMP messages include an identifier field, which is used by diagnostic tools to correlate requests and responses.

A common troubleshooting scenario is when workloads deployed behind an Azure StandardV2 NAT Gateway are unable to reach external endpoints. Since these workloads typically do not have public IP addresses, it can be difficult to quickly determine whether the issue is related to basic network reachability or higher-layer configuration. In such cases, ICMP‑based diagnostics such as ping can be used to validate outbound connectivity and help isolate the source of the issue.

When a workload sends an outbound ICMP packet through a NAT Gateway:

NAT Gateway translates the source private IP to one of its associated public IP addresses.
The platform tracks the ICMP flow using the ICMP identifier and other packet attributes.
Return ICMP responses from the external destination are matched to the originating flow.
The response is translated back to the original private IP and delivered to the workload.

Flow chart showing handling of outbound ICMP Echo Request and Echo Reply traffic through Azure NAT Gateway

This stateful handling allows replies to be routed correctly even when multiple workloads are sending ICMP traffic concurrently through the same NAT Gateway.

Using ICMP for end-to-end outbound troubleshooting

To validate outbound connectivity using ICMP from workloads deployed behind StandardV2 NAT Gateway:

Go to your virtual network in the Azure portal and select the subnet hosting your workload.
Verify that a StandardV2 NAT Gateway is associated with the subnet.
The workload does not require a public IP address.
Connect to the workload (for example, a virtual machine) running in the subnet.
Run an ICMP ping to an external destination to validate outbound reachability.

Successful ping from a workload behind an Azure StandardV2 NAT Gateway demonstrating outbound connectivity and ICMP Echo reply.
Review the results.
Successful ICMP echo replies confirm that outbound connectivity through StandardV2 NAT Gateway is functioning and that ICMP traffic is translated and returned correctly

Summary

With ICMP Echo support, Azure StandardV2 NAT Gateway provides a more complete outbound networking experience by enabling essential diagnostic tools to function reliably through NAT. Customers can validate reachability, perform basic troubleshooting, and diagnose connectivity issues while continuing to benefit from the simplicity and scale of centralized outbound connectivity.

Learn More

Network security perimeter for Azure Service Bus & also now available in Azure Gov. Regions

shashankamalladi — Tue, 16 Jun 2026 10:56:27 GMT

TL; DR

Network security perimeter support for Azure Service Bus is now Generally Available. With this, you can now place your Service Bus namespace inside a central security boundary and apply perimeter-based governance for inbound/outbound network access—while keeping key PaaS-to-PaaS scenarios secure and auditable.

Introduction

We’re excited to announce that network security perimeter support for Azure Service Bus is now Generally Available (GA).

This milestone brings one of Azure’s most widely used messaging services into the network security perimeter ecosystem, enabling customers to define a centralized security boundary across messaging and data services.

Alongside this, we are also expanding network security perimeter’s reach — network security perimeter is now available in Azure Government regions, including:

Texas
Arizona
Virginia
DoD East
DoD Central

This ensures that customers operating in regulated, sovereign, and mission-critical environments can adopt network security perimeter while meeting their compliance and regional requirements.

Why this matters?

Modern applications rely heavily on messaging layers like Service Bus. These systems often connect microservices, data platforms, key management systems and external integrations. As architectures scale, managing network access individually becomes complex and error prone.

Network security perimeter changes this by introducing a perimeter-based access model, where:

Communication is restricted by default
Access must be explicitly allowed
Governance is applied consistently across services

With Service Bus now onboarded and network security perimeter extending into Azure Gov regions, customers can apply this model across both commercial and sovereign environments.

What you can do with Service Bus + network security perimeter

Confine communication within a security boundary

Service Bus namespaces communicate only with resources inside the perimeter by default—blocking unintended access.

Secure PaaS-to-PaaS communication

Enable secure interactions between Service Bus, Azure Key Vault (for CMK scenarios) and other network security perimeter-enabled services (What is a network security perimeter? - Azure Private Link | Microsoft Learn)

Define explicit access controls

Inbound rules → IP ranges and subscriptions
Outbound rules → FQDN-based filtering

Enable audit and compliance visibility

Diagnostic logs capture all access attempts, supporting compliance and investigation workflows.

Use Private Link seamlessly

Private endpoint traffic continues to work without additional configuration inside the perimeter.

Azure Government Availability

With this update, network security perimeter is now available in key Azure Government regions (Texas Arizona Virginia DoD East DoD Central), enabling:

Consistent security across clouds

Apply the same network security perimeter model across public Azure regions and Azure Government environments.

Support for regulated workloads

Customers in federal, defence, and highly regulated industries can now:

Enforce perimeter-based governance
Reduce exposure risks
Meet compliance requirements

Enable secure cross-service patterns in Gov clouds

Azure Government boundaries now support scenarios like:

CMK with Key Vault
Service-to-service messaging
Controlled external access

More details of onboarded PaaS services are detailed in What is a network security perimeter? - Azure Private Link | Microsoft Learn

What’s next

Service Bus GA further strengthens network security perimeter’s growing coverage across Azure PaaS services. We will continue to:

Expand PaaS service onboarding
Improve access rule capabilities (e.g. Service tag-based access, identity-based access)

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

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

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

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

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

What does Pod CIDR Expansion enable?

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

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

Choosing a Pod CIDR

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

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