Hey Checkyourlogs Fans,

Azure Virtual WAN is a managed networking service in Azure that unifies and simplifies connectivity for distributed environments. It combines branch connectivity, VPN (site-to-site and point-to-site) access, ExpressRoute private circuits, and built-in routing and security in a single pane of glass. Azure Virtual WAN uses a hub-and-spoke cloud architecture: Azure “Virtual Hubs” (managed by Microsoft) act as central transit hubs in each region, connecting to on-premises sites (via VPN or SD-WAN devices, or ExpressRoute), Azure virtual networks (VNets), and remote users. All Virtual WAN hubs in the Standard tier are automatically interconnected in a full mesh, enabling any-to-any connectivity across your global network over Microsoft’s backbone. In short, Azure Virtual WAN provides a global transit network architecture where distributed endpoints can communicate through Azure’s hubs with centralized policy control.

Cartoon beavers working with tools AI-generated content may be incorrect.

Azure Virtual WAN connects on-premises sites, virtual networks, and remote users via centralized cloud hubs (one per region) interconnected through Microsoft’s global backbone. This hub-and-spoke architecture supports site-to-site VPN, ExpressRoute, and point-to-site user VPN connectivity in a unified solution (illustrated above). All hubs in a Standard Virtual WAN are fully meshed for any-to-any connectivity between spokes.

Key Use Cases: Azure Virtual WAN is versatile and can start small (even a single use case) and grow as needed. Common scenarios include:

  • Any-to-any branch and cloud connectivity: The Virtual WAN hubs enable seamless branch-to-branch, branch-to-Azure VNet, and VNet-to-VNet communication, leveraging Azure’s high-performance global network. This is ideal for organizations replacing or augmenting traditional MPLS networks with cloud-based transit, improving performance and latency by using Microsoft’s backbone.
  • Unified remote access for users: Virtual WAN provides secure Point-to-Site (P2S) VPN access for remote employees. Users can connect to their nearest Azure hub (Azure VPN Client, Openvpn, or IKEv2) and reach company resources globally. This consolidates remote user VPN management and can integrate with Azure AD for authentication.
  • Hybrid cloud connectivity: Integrate on-premises data centers and branch offices with Azure using Site-to-Site VPN and ExpressRoute connections into Virtual WAN hubs. Virtual WAN supports simultaneous VPN and ExpressRoute connections and even interconnects them (e.g., allowing VPN-connected branches to reach ExpressRoute-connected sites). This is useful for hybrid cloud setups and gradual application migrations to Azure.
  • SD-WAN integration: Simplify branch connectivity using Azure’s partnership with major SD-WAN and VPN appliance vendors. Virtual WAN directly allows automated IPsec tunnel setup from supported branch devices (e.g. Cisco, Fortinet, Palo Alto, etc.) to Azure hubs. Many SD-WAN vendors provide one-click integration with Azure Virtual WAN, or even let you deploy their virtual appliances inside the Virtual WAN hub for optimized routing. This use case is typical for mid-market companies that already use SD-WAN in their branches and want to extend it into Azure with minimal fuss.
  • Centralized security and routing control: Virtual WAN hubs can incorporate Azure Firewall or third-party network virtual appliances, allowing organizations to inspect and filter traffic centrally. For example, internet-bound traffic from branches or VNets can be forced through a firewall in the hub (using routing policies) for compliance. This architecture supports a “secure hub” model, where a centralized security layer protects all branch/VNet connections.

Typical Deployment Timeline and Phased Rollout

Mid-market Azure Virtual WAN projects are typically executed in phases to reduce risk and complexity. While the exact timeline varies by number of sites and regions, a phased rollout approach allows incremental testing and adoption. Below is an example timeline with phases:

  1. Planning & Design (1–3 weeks): Gather requirements (network inventory, bandwidth needs, security/compliance goals) and design the Virtual WAN architecture. This includes choosing Azure region hubs, deciding on connectivity methods (VPN/ExpressRoute), and integration points with existing network infrastructure. Early design workshops ensure the solution fits the customer’s current and future needs.
  2. Pilot Deployment (2–4 weeks): Deploy a pilot Azure Virtual WAN hub and connect a small subset of the environment. For example, one Azure hub in a primary region can be set up, a couple of test branch sites can be connected via VPN, and perhaps a sample of remote users can be onboarded. The goal is to validate connectivity, routing, and security policies on a small scale. In this phase, the team can resolve configuration issues and familiarize itself with Azure’s interface. (Starting with a pilot allows testing and adjustments before full-scale implementation​.)
  3. Core Implementation (4–8 weeks): Roll out Virtual WAN to production for core connectivity. This often involves deploying production hubs in all needed Azure regions (e.g. one per major geography), then migrating critical connections to use these hubs. For instance, establish the primary site-to-site VPN tunnels or ExpressRoute circuits from data centers and headquarters into the new Virtual WAN hubs. At this stage, key Azure VNets are attached to the hubs (as VNet connections), and primary workloads start routing through Virtual WAN. This phase may be done region by region or site by site, with the careful management of routing cutovers to avoid downtime.
  4. Phased Branch Onboarding (4–12+ weeks): Gradually connect remaining branch offices and remote sites to the Azure WAN. Rather than migrating all offices simultaneously, branches can be onboarded in waves – for example, region by region or office size priority. Branch devices can be configured in batches through the SD-WAN orchestrator to establish IPsec tunnels to the Azure hubs if SD-WAN integration is leveraged. Each wave is tested for connectivity and performance before proceeding. Over several iterations, all targeted sites and users are moved onto the Virtual WAN. The timeline for this phase depends on the number of sites (a mid-market client with, say, 20–50 branches might complete in a couple of months, whereas more sites or complex locations could extend the timeline).
  5. Optimization & Handover (1–2 weeks): Once all sites are connected, fine-tune routing policies, security rules, and throughput settings. For example, custom route tables or routing intent can be implemented if specific traffic needs to be directed through a firewall or to specific hubs. Ensure monitoring (Azure Monitor) is set up for the Virtual WAN (latency, throughput, connectivity health). The IT team is trained on the Azure Portal/CLI for day-2 operations. Finally, legacy network routes (like old VPN hubs or redundant MPLS links) can be decommissioned after confirming the Virtual WAN is fully operational.

Typical duration: In practice, a mid-market deployment of Azure Virtual WAN often spans around 2–4 months from planning to completion. Simpler projects (few sites in one region) may be faster, while more distributed environments could take 6+ months with a cautious rollout. The phased approach ensures minimal disruption – critical connections go first, and success is proven before wide rollout. It’s essential to adjust the pace based on customer readiness, with potential pauses between phases to address any issues or to align with business schedules (for example, avoiding peak business periods for cutovers). This staged method ensures a smoother transition and stakeholder buy-in at each step.

Common Azure Virtual WAN Configuration Examples

When designing an Azure Virtual WAN solution, several common architecture patterns and configurations must be considered. Below are examples of typical configurations and how they apply to mid-market scenarios:

  • Hub-and-Spoke Network Architecture: Azure Virtual WAN adopts a hub-and-spoke topology, where an Azure Virtual Hub (managed by Microsoft) in a region serves as the central point of connectivity for that region. All your spoke resources – such as VNet networks, on-premises site VPNS, and ExpressRoute circuits – connect into the hub rather than meshing directly. The hub’s built-in router enables transitive routing between spokes, so a branch office connected via VPN can reach an Azure VNet or another branch through the hub. In a Standard Virtual WAN, multiple hubs (in different Azure regions) automatically connect, creating a global mesh of hubs. This means a branch in Region A can seamlessly communicate with a branch in Region B or a VNet in Region B through the inter-hub connection – all using Microsoft’s private backbone. For mid-market customers, a standard design is to deploy one hub per central region (for resiliency and local performance), and use Azure’s backbone to handle inter-region traffic rather than managing complex on-prem WAN links. (In smaller scenarios, a single hub might suffice if most offices are in one geography.) The hub-and-spoke model simplifies management because you don’t need full mesh VPNS between every site – the Azure hub handles routing centrally.
  • Integration with SD-WAN and VPN Devices: If the customer uses an SD-WAN solution or specific VPN appliances at branch sites, Azure Virtual WAN can integrate with those to automate connectivity. Microsoft has a broad ecosystem of Virtual WAN partners (Cisco Meraki, Fortinet, Palo Alto, CloudGenix, VMware VeloCloud, Silver Peak/Aruba, Check Point, and many others).
  • There are two integration approaches: (1) Automated IPsec VPN connectivity from branch devices: Many SD-WAN vendors allow you to enter your Azure credentials or import Azure Virtual WAN info into their management console. The device automatically connects IPsec tunnels to the Virtual WAN hub’s endpoints and manages routing. This saves time compared to manual configuration. (For example, a Cisco Meraki appliance can one-click connect to an Azure Virtual WAN hub using Meraki’s dashboard configuration​) (2) Deploying a virtual SD-WAN appliance in the Azure hub: Azure allows certain vendor network virtual appliances (NVAs) to be deployed directly inside a Virtual WAN hub (as a managed service). These could function as an SD-WAN gateway or firewall. For instance, a Fortinet or VMware SD-WAN virtual edge can be spun up in the hub to terminate proprietary SD-WAN tunnels, and then it hands off to the Virtual WAN router. This approach can be helpful if the branch devices speak a protocol optimized for that SD-WAN — the hub NVA effectively becomes a translation point into the Azure Virtual WAN. Mid-market customers with existing SD-WAN investments benefit by preserving their current hardware and operational processes while extending connectivity to Azure. The key point is that Azure Virtual WAN is vendor-agnostic and works in tandem with popular branch networking solutions, rather than replacing them outright.
  • VPN and ExpressRoute Connections (Hybrid Connectivity): Azure Virtual WAN hubs support both Site-to-Site VPN connections and ExpressRoute private peering connections, even concurrently. This flexibility allows a hybrid network setup: for example, a mid-market company might connect smaller branch offices via site-to-site VPN over the internet, but use an ExpressRoute circuit for the main data center to Azure (for higher bandwidth and reliability). In Virtual WAN, both connection types terminate in the hub and are treated as spokes – and importantly, Virtual WAN supports transitive routing between them. That means a branch office using VPN can communicate with a datacenter linked via ExpressRoute through the hub (Azure handles the route exchange between the VPN gateway and the ExpressRoute gateway in the hub). This “VPN <-> ExpressRoute interconnectivity”​ is valuable for scenarios like backhauling branch traffic to a datacenter or enabling branches to use a centralized internet breakout at HQ.
  • Additionally, Virtual WAN offers ExpressRoute encryption – you can configure IPsec encryption over your ExpressRoute circuits for added security (this addresses cases where sensitive data needs encryption even on private links). Typical configuration: The Azure hub is enabled with an ExpressRoute gateway (to link to your ExpressRoute circuit) and/or a VPN gateway (for IPsec tunnels), but unlike traditional Azure networking, you don’t need to deploy separate gateways per VNet – the one hub can service all spokes. This simplifies management and can reduce costs (fewer separate gateway VMs needed). For remote user connectivity, you enable a User VPN (P2S) gateway on the hub, allowing users to dial in and be treated as another spoke. Virtual WAN hubs become the one-stop termination point for all connectivity types (VPN, ER, P2S), centralizing your hybrid network.
  • Security and NVA Integration (Azure Firewall & Third-Party Firewalls): A significant advantage of Azure Virtual WAN is the ability to embed security services in the hub. Microsoft offers Azure Firewall integration via the “Secured Virtual Hub” concept. This means you can deploy an Azure Firewall instance directly in the Virtual WAN hub and manage it with Azure Firewall Manager. All traffic passing through the hub (branch-to-VNet, VNet-to-internet, branch-to-internet, etc.) can be inspected by this firewall, based on your policies. For example, you might force all branch internet traffic to go through the Azure Firewall in the hub for filtering (instead of letting branches go directly to the internet), and similarly, inspect traffic between Azure and on-premises. Azure Firewall Manager allows you to create and apply centralized policies across multiple hubs. This setup provides a fully cloud-managed security solution with high availability.
  • On the other hand, if you have preferred security vendors, Azure Virtual WAN also supports certain third-party firewall NVAs in the hub. Currently, a few vendors (e.g. Check Point CloudGuard and Fortinet FortiGate as NVAs, and Palo Alto Networks Cloud NGFW as a service) can be deployed and deeply integrated into the Virtual WAN hub. When you deploy a supported NVA in the hub, Azure essentially inserts it into the routing path: traffic can automatically route from the Virtual WAN router to the NVA and back, for inspection (this uses a feature known as routing intent or custom route tables). The integration is a joint effort between Azure and the partner, making it operationally more straightforward. For instance, a Check Point firewall NVA can be added to the hub; once in place, branch and VNet connections will automatically forward traffic to Check Point for security scanning, and you manage the firewall rules in the Check Point management server as usual. This allows companies to leverage familiar security tools in their Azure network. Mid-market customers who already own licenses for third-party firewalls or have skillsets in those platforms might choose this route. In either case (Azure Firewall or third-party), Azure Virtual WAN’s design means you don’t need to haul traffic back to on-prem for security – you can enforce security in the cloud hub, closer to the apps and users. This can improve performance and simplify the network design (no backhaul to a central datacenter just for a firewall).

Note: Azure Virtual WAN is available in two tiers – Basic and Standard. Basic supports only site-to-site VPN connectivity (no inter-hub mesh, user VPN, ExpressRoute, or integrated firewall). Standard is needed for most use cases discussed above (multi-region hubs, user VPN, ExpressRoute, Azure Firewall, etc.) and is the tier that almost all mid-market and enterprise deployments will use. You can start with Basic for a simple scenario and later upgrade to Standard if needed, but you cannot downgrade from Standard to Basic. In practice, if a customer plans to utilize any advanced features or multiple connection types, they will deploy a Standard Virtual WAN from the get-go.

Discovery Questions for Customer Calls

During a pre-sales discovery call, asking the right questions is key to understanding the customer’s current environment, requirements, and goals. Below is a detailed list of discovery questions grouped by topic. These questions will help identify how Azure Virtual WAN can fit the mid-market customer’s needs and what design/configuration will suit them best:

Current Network Architecture and Infrastructure

  • Topology: Can you describe your current network architecture? (For example, do you use a hub-and-spoke WAN with central data centers, a full mesh between sites, or MPLS connectivity between branches?) Understanding whether they have a central hub today or multiple independent sites helps map to a Virtual WAN design.
  • Existing VPN/Networking Equipment: What hardware or solutions do you use for site-to-site connectivity? (e.g., Cisco routers, Meraki appliances, SonicWall/WatchGuard, etc.) Are these devices IPsec VPN capable, and do they support BGP? This will tell us how easily they can connect to Azure Virtual WAN and whether their gear can integrate smoothly or needs replacement.
  • Network Scale: How many branch offices, retail locations, or remote sites do you have that would need to connect? Are they all similar in size/importance, or do you have tiers (e.g., a couple of main offices and many small branches)? This gives a sense of scale—Azure Virtual WAN supports up to 1,000 branch connections per hub, so we want to ensure their sites can be accommodated in an appropriate number of hubs.
  • Data Center Connectivity: Do you have central data centers or headquarters that aggregate traffic from these branches? If so, how are those connected to your network currently (VPN hubs, MPLS, etc.)? This will highlight if there’s an existing “hub” we will be replacing or integrating with (for instance, if they have a physical hub in a colocation, we might connect it via ExpressRoute to Azure).
  • Pain Points: Are there any challenges with your current network setup? (Examples: difficulty managing many VPN tunnels, limited bandwidth at certain sites, high latency between far-offices, or costly MPLS links.) This helps identify the problems Azure Virtual WAN should solve—whether it’s simplifying management with a single interface, improving performance with Microsoft’s backbone, or reducing reliance on expensive private circuits.

Connectivity and Bandwidth Requirements

  • Connectivity Goals: What kind of connectivity do your sites need with each other and Azure? For instance, is branch-to-branch communication essential (e.g., for voice, replication, or peer-to-peer applications between offices), or do branches primarily communicate with a central location/cloud? Azure Virtual WAN can support both patterns (any-to-any connectivity), but knowing this will influence routing policies (e.g., allowing direct branch-to-branch via the cloud).
  • Number of Users / Remote Workforce: Do you have remote or mobile users that need VPN access to the network? How many concurrent remote users do you expect, and from which global locations? If they have a significant remote workforce, we’d plan to use the Virtual WAN User VPN to give them local POPs (points of presence). Also, if they use an existing remote access solution (like a VPN concentrator or Azure AD Application Proxy), we’d consider how to integrate or replace it.
  • Bandwidth and Performance Needs: Can you estimate each site’s bandwidth for cloud connectivity? (e.g., “Headquarters needs 1 Gbps to Azure”, “Small branches need only 20–50 Mbps”). And are there latency-sensitive applications (VoIP, video conferencing, trading systems, etc.) that we should account for? Azure Virtual WAN can scale to high bandwidth (up to 20 Gbps aggregate VPN per hub with scale units ), but the cost and design depend on the required throughput. If some sites need very high throughput or guaranteed performance, that might lean towards using ExpressRoute or multiple VPN tunnels.
  • Existing Private Circuits: Do you have existing ExpressRoute circuits or MPLS lines? If yes, would you want to continue using them with Azure Virtual WAN or eventually phase them out? For example, if they already have an ExpressRoute to Azure, we’d connect it to the Virtual WAN hub. If they have an MPLS network, we might integrate it into a hub (perhaps via an NVA or an ExpressRoute if MPLS cloud exchange is available).
  • Internet Breakout Strategy: Do branch sites currently go to the internet directly, or do they backhaul internet traffic to a central location? This influences whether we use Azure Virtual WAN to provide a secured internet breakout via an Azure Firewall or if branches use local internet for non-Azure traffic. For instance, if they backhaul today due to security, Virtual WAN could give them a local breakout with security in the cloud hub.

Security and Compliance Requirements

  • Traffic Inspection: What are your security requirements for traffic flowing between sites and to the cloud? For example, do you need to inspect inter-site traffic or traffic between on-prem and Azure for threats or data compliance? If yes, we should consider Azure Firewall or a third-party firewall in the Virtual WAN hub to perform that inspection. If all branch traffic is currently forced through a firewall at HQ, we can replicate that model in Azure (secured virtual hub).
  • Preferred Firewall Solutions: What firewall or network security products are you using today (vendor and model)? Would you prefer to continue using that vendor’s solution in Azure, or are you open to using Azure’s native Firewall? Azure Virtual WAN allows sure third-party firewalls to be deployed in the hub (e.g., Check Point, Fortinet, Palo Alto)​. So if, for example, the customer is a big Fortinet shop, we could integrate FortiGate VM in the Virtual WAN. If they don’t have a preference, an Azure Firewall might be simpler.
  • Segmentation and Access Control: Do you require network segmentation between business units or application types? (For instance, isolating traffic from retail POS systems vs. corporate IT.) If so, we’d ask how they segment today (VLANs, VRFs, separate VPNs?), design Virtual WAN with multiple hubs, or use Azure Firewall policies/routing intent to segregate traffic. Virtual WAN’s routing allows for custom route tables, which can help enforce segmentation if needed.
  • Compliance and Encryption: Are there specific regulatory or compliance requirements for your network traffic? (Examples: All data must be encrypted in transit, certain traffic must stay in-country, etc.) Virtual WAN encrypts all VPN traffic by default (IPsec). ExpressRoute traffic is not encrypted by default, but Azure Virtual WAN can encrypt ExpressRoute traffic if required. If data residency is a concern, we’d ensure that hubs are placed in required regions and possibly restrict routing so that European traffic stays within EU hubs (this can be controlled by not connecting specific hubs). Gather any such requirements now.
  • Internet Access and Zero Trust: How do users and sites access the internet currently, and is there a desire to move toward a “direct internet with zero-trust” model? This question is forward-looking: some customers might want to leverage Azure as a central point for internet egress with a firewall and perhaps integrate with Azure security services (like Azure Firewall, DNS filtering, etc.). Suppose they mention interest in SASE (Secure Access Service Edge) or something similar. In that case, Azure Virtual WAN can be a component (with Azure Firewall and perhaps integration to Azure AD for user authorization).

Cloud Adoption and Application Landscape

  • Current Cloud Footprint: What is your current Azure usage regarding virtual networks and applications? (e.g., number of VNets, regions in use, types of workloads deployed). This helps determine how we will connect those VNets to Virtual WAN hubs. We should discuss migrating to Virtual WAN hubs if they already have a hub-and-spoke in Azure with a Network Virtual Appliance. If they have multiple Azure regions, it confirms the need for multiple hubs.
  • Multi-Cloud or Azure-Only: Are you using other clouds (AWS, GCP) that need connectivity to Azure or on-prem? While Azure Virtual WAN is an Azure-specific service, we might need to plan connectivity between Azure and other clouds (possibly via on-prem data centers as intermediaries or Azure routing). If they have AWS, for example, do they expect Azure Virtual WAN to route to AWS (we could do this if AWS is connected via an on-prem router or an NVA in Azure)? It’s good to identify this to avoid overlooking any segment of their network.
  • Application Criticality: Which applications are the most critical to run over this network? (e.g., Office 365, SAP, databases, etc.) This can influence design – for instance, critical apps might warrant ExpressRoute or dedicated QoS. Also, if they heavily use SaaS like Office 365 from branches, we might highlight that Azure Virtual WAN can provide local egress to Microsoft’s network (as Microsoft peering) for optimal O365 performance.
  • Azure Services Integration: Do you plan to use Azure services like Azure VMware Solution, Azure Backup/DR, etc., that involve on-prem connectivity? Virtual WAN can simplify connecting to these services (for example, AVS can hook into a Virtual WAN hub). Any specific planned Azure projects that involve networking should be noted to ensure compatibility with Virtual WAN.

Geographic Footprint and Azure Regions

  • Locations of Offices: What is the geographic distribution of your offices and users? (List of countries/regions or general locations would help – e.g., “Mostly in US East, a few in Europe, and an APAC office in Singapore”). We need this to decide where to put Azure Virtual WAN hubs. Ideally, you have a hub close to each primary concentration of users for performance. If they’re primarily in one country, maybe one hub; if spread globally, likely a hub per continent.
  • Azure Region Preferences: Do you have specific Azure regions you use or prefer to use for networking? Often, you’d choose regions that correspond (Azure East US for East Coast offices, Azure West Europe for Europe offices, etc.). Customers who have data residency requirements might insist on specific regions. Also, check if any region they need is unavailable for Virtual WAN (though Virtual WAN is available in most Azure regions – we could verify if needed).
  • Geographic Redundancy: Do you require redundancy across regions for disaster recovery? For example, can another hub pick up critical connectivity if one Azure region hub goes down? Virtual WAN supports connecting to multiple hubs for resiliency. If the customer has East and West coast presence, we might deploy two hubs and have some branches connect to both for backup. Ask if that level of DR is needed or if a single hub per region is sufficient.
  • International Bandwidth/Latency Considerations: If the company has intercontinental traffic, how is it handled today? (For example, is there a private global WAN, or do they use the internet?) This is to highlight Azure Virtual WAN’s benefit: using Microsoft’s global network for inter-region traffic. Suppose they complain about latency between far-offices. In that case, we can potentially place hubs to reduce that (e.g., a hub in Asia for Asian offices instead of everyone connecting to the US). Make a note of any particularly problematic routes today.

Preferred Partners or Vendors (SD-WAN, Networking Gear)

  • SD-WAN Usage: Are you using an SD-WAN solution or a specific network vendor for your branch offices? (Cisco SD-WAN (Viptela or Meraki), Fortinet Secure SD-WAN, Palo Alto CloudGenix, VMware/Velocloud, etc.). This is crucial because Azure Virtual WAN can integrate with many of these. If they are using one, dive deeper: Which vendor and model are they using, the vendor’s cloud gateway or just site-to-site? If they have Meraki SD-WAN, we know we can likely automate tunnels from the Meraki devices to Azure Virtual WAN.
  • Integration Expectations: If an SD-WAN is in place, do they expect Azure to be an extension of that SD-WAN fabric (i.e., using the SD-WAN’s capabilities end-to-end), or are they okay treating Azure as just another site via IPsec? Some SD-WAN vendors have cloud hubs, so the customer might wonder if Azure Virtual WAN replaces or complements that. For instance, “Would our SD-WAN orchestrator be able to manage the connections to Azure?” – the answer is often yes, via the Virtual WAN integration. It’s good to ask if they have spoken with their vendor about Azure connectivity.
  • Existing Firewall Appliances in Azure: Do you currently deploy any network virtual appliances (NVAs) in Azure for connectivity or security? (e.g., running a Palo Alto or Cisco CSR in an Azure VNet as a manual hub). If yes, this implies they tried manually implementing something like Virtual WAN. We’d want to know the reason (perhaps specific features) to ensure Virtual WAN can meet those needs. Also, if they have existing NVAs, we might plan a migration where Virtual WAN takes over routing, and those NVAs could potentially be retired or moved into the Virtual WAN hub if supported.
  • Microsoft Partner Involvement: Are any existing Microsoft or vendor partners involved in your network management? (This might not be directly asked to the customer in these terms, but as a pre-sales engineer, you’d want to know if an outside integrator is managing their SD-WAN or network – if yes, they might have insights or preferences on integration.)

Desired Outcomes and Success Criteria

  • Primary Drivers: What main outcomes do you want to achieve with this project? It’s good to let the customer articulate this in their own words. Often, it will be one or more of the following: simplify network management, improve connectivity performance, enhance security, reduce costs, support cloud migration, etc. Listen for keywords. For example, if they say “we need to cut down on the time it takes to manage connectivity” or “we have too many outages with our current setup,” those indicate priorities. Map these to Azure Virtual WAN’s strengths: it can simplify routing configuration (automated route learning), improve performance by leveraging Microsoft’s backbone, boost security via integrated firewalls, and potentially lower OPEX using a cloud-managed service.
  • Cost Expectations: With this move to Azure networking, are you looking to reduce network costs? If so, where do you expect the savings (MPLS replacement, hardware retirement, less management overhead)? While Azure Virtual WAN introduces Azure service costs, it often lowers total costs compared to maintaining extensive on-prem infrastructure. Understanding the customer’s view on cost will help us tailor a solution that meets ROI expectations. If they have budget constraints, we might design a phased approach (as above) or consider keeping some cheaper connectivity options (like VPN vs ExpressRoute) to manage costs.
  • Success Criteria: How will you measure the success of an Azure Virtual WAN deployment? It’s helpful to define this upfront. It could be technical metrics (e.g., “50% reduction in network latency for cloud apps” or “ability to add a new site in hours instead of days”) or process metrics (“IT spends less time managing network configuration”). For example, if the customer can specify, “We want to be able to bring a new branch online in less than a day, whereas currently it takes a month to get an MPLS circuit,” that becomes a success benchmark.
  • Timeline and Urgency: Are any deadlines or compelling events driving this initiative? (For instance, contract renewal dates for current network providers, office relocations, data center exits, or upcoming compliance audits.) This will affect how we plan the rollout. If they say, “Our MPLS contract is up in 6 months and we want to be off it by then,” we know the project needs to move quickly and cover all sites by then. If it’s more open-ended, they might be exploring and not committed yet, in which case a smaller pilot might be a good next step.
  • Concerns or Open Questions: Finally, ask if the customer has specific concerns about moving to Azure Virtual WAN. They might worry about reliability (“What if Azure goes down?” – we can discuss SLA and multi-hub resilience), about skill gaps (“Will my team be able to manage this?” – highlight the unified portal and available training), or about compatibility (“Can we still use our favorite firewall?” – we’ve covered that with third-party NVA support). Addressing these concerns is crucial in pre-sales to build confidence in the solution.

By covering these questions, a pre-sales engineer can clearly understand the customer’s environment and goals, which will guide the Azure Virtual WAN solution design and highlight the relevant benefits.

Licensing and Cost Considerations for Mid-Market Customers

When discussing Azure Virtual WAN with mid-market customers, it’s essential to clarify the pricing model and licensing aspects, since they differ from traditional network hardware purchases. Below are key points to cover:

  • Azure Service, Not a Box: Azure Virtual WAN is a service with no upfront license cost or appliance hardware to buy for the WAN itself. Instead, it’s usage-based (pay-as-you-go in Azure). This is good for mid-market clients as it shifts costs to operational expense and scales with actual use. (However, any third-party software integrated might carry its own license – more on that shortly.) The Azure Virtual WAN pricing page details the cost components. In summary, you pay for:
    • Virtual Hub infrastructure – a fixed rate per hour for each hub deployed. (Think of this like the base cost for having a “router in the cloud”. For a Standard hub, this is a few tens of cents USD per hour in many regions. If you enable advanced features like custom routing tables or third-party NVA integration, there can be a slightly higher rate​ – e.g. a Standard hub with Routing Intent might be a bit more per hour.)
    • VPN and ExpressRoute gateways – Azure allocates gateway capacity in scale units if you use VPN or ExpressRoute in the hub. For example, a VPN gateway scale unit might be 500 Mbps throughput. Each scale unit and each connection (tunnel) has an hourly charge. For a mid-market deployment, you might only need 1–2 scale units for VPN unless you have high traffic. These charges replace what would traditionally be the cost of physical VPN appliances – here, you essentially rent them by the hour.
    • Data transfer (Egress) – data going out of the Virtual WAN (to the internet or between regions) has a per GB charge, similar to standard Azure bandwidth charges. For example, egress to the internet or another region might be billed per GB (rates vary by zone, e.g. ~$0.09/GB for US/EU regions as of this writing. Data transfer between spokes and hubs within the same region might not incur extra cost beyond the above (except for minimal costs like VNet peering charges if applicable). It’s important to note that ingress data is generally free; Azure charges primarily for outbound. Mid-market customers should size their expected monthly bandwidth to estimate this cost.
    • Azure Firewall or Security Services—If you deploy an Azure Firewall in the hub (Secured Virtual Hub), that firewall has its own pricing (hourly rate for the firewall VM and per GB processed). This is equivalent to how Azure Firewall is priced outside Virtual WAN. So, essentially, adding security services will add additional Azure costs.
    • Route Management—Azure now has features like routing intent, and at very large scales (thousands of routes), there can be a small additional charge (the routing infrastructure unit). Most mid-market deployments won’t exceed the free route limit (the first 2,000 VMs or so), so this may not come into play, but it’s worth knowing if the customer plans to connect a huge number of spokes or VMs.
  • No “User CALs” or Hidden Licensing: Unlike traditional VPN solutions that license per user or tunnel, Azure Virtual WAN’s costs are purely based on the resources used (tunnels, throughput, data). There isn’t a concept of licensing per user or device in Azure networking. This can be a relief to customers who are used to VPN appliances that require purchasing connection licenses. In Azure, if you need to support more user VPN connections, you scale up the P2S gateway (and pay the hourly rate for that capacity while it’s running). You’re not paying for idle licenses – just the base infrastructure when not in use.
  • Third-Party NVA Licensing: If the design includes third-party network virtual appliances (such as a firewall from Check Point, Fortinet, etc., deployed in the Virtual WAN hub), be clear that those vendors may have their licensing costs. Azure will charge for the VM/container infrastructure to run that NVA (and maybe a small premium for integration), but the software license (e.g., firewall subscription) might need to be procured by the customer via the Azure Marketplace or a BYOL (bring your license) arrangement. For instance, Palo Alto’s Cloud NGFW is offered as a SaaS with its rate on top of Azure. Always outline which parts of the solution are Azure-native (Azure billing) vs. third-party (vendor billing) so the customer isn’t surprised. For mid-market clients, the appeal might be to stick with Azure’s built-in security if they want to avoid separate licenses, unless they already own or require a specific vendor.
  • Total Cost Considerations: Mid-market companies often have fixed budgets, so they will be concerned about the ongoing Azure costs. It’s helpful to compare the Azure Virtual WAN approach with its current costs. For example: hardware refresh savings (no need to buy new routers/firewalls for each site – you can use Azure VPN for many sites, and perhaps smaller devices on-prem), circuit cost trade-off (internet-based VPN vs. expensive MPLS – many find cost savings in moving to internet VPN with Azure handling the transit), and IT management savings (one centralized system vs. many individual device configs). An Azure Virtual WAN can often be more cost-effective than a DIY hub-and-spoke WAN when you factor in management and uptime. Emphasize that you pay only for what you use: if a branch is closed or not using much bandwidth, costs stay low; if the business grows, costs scale linearly with usage (no massive upfront investment). Additionally, there are no termination fees – if they decide to stop using a hub, they delete it and stop paying.
  • Cost Optimization for Mid-Market: There are ways to ensure the solution remains cost-friendly:
    • Choose the correct number of hubs: Each hub has a fixed cost, so a mid-market customer with a moderate number of sites might use just 1 or 2 hubs (maybe one per region of operation) rather than deploying many hubs. For example, if they operate in North America and Europe, two hubs can suffice – one in an East US Azure region and one in West Europe, instead of multiple hubs per country. This balances performance vs. cost.
    • Utilize Basic tier if applicable: While most will need Standard, if a customer truly only needs site-to-site connectivity and nothing else, the Basic Virtual WAN tier has no charge for the hub itself (Basic hubs are free but limited in function) – you only pay for VPN gateways. This could be a niche case (perhaps a smaller mid-market that just wants to connect a few sites via Azure without using point-to-site or ER). It’s good to mention that it exists, but it also needs to be clarified that basic hubs do not mesh globally and lack features. Given our scenario is more advanced (with multiple features), Standard is likely required.
    • Turn off unused components: Azure charges are granular. If the customer sets up a User VPN gateway but later doesn’t need it (say they moved to a different remote access solution), they can disable it to stop those charges. Or if a branch is decommissioned, remove the connection to avoid any per-connection charges. Azure’s flexibility here can help trim costs over time.
    • Plan for data egress strategically: If a lot of data is being transferred out of Azure (say backups or large datasets), consider options to minimize costs, like Azure’s peering or seeing if compressing data via an NVA helps. Also, intraregional traffic (within the same region) is cheaper, so architecture that keeps traffic local where possible will save money. For instance, if two Azure VNets need to talk a lot, putting them behind the same hub avoids inter-region egress costs.
  • Licensing for Azure Firewall: Azure Firewall in a Secured Hub doesn’t require any separate license purchase – it’s billed like a service (per hour + per GB). This is simpler than some third-party firewalls that require a license file. Mid-market customers who don’t want to manage licenses might prefer Azure Firewall. The Basic SKU of Azure Firewall was introduced for smaller workloads with lower cost; if the customer’s throughput needs are modest and they want to save, a Basic Azure Firewall might suffice (though as of 2025, Basic Firewall is only in some regions and supports fewer features). It’s something to evaluate in pricing discussions.
  • Compared to Traditional WAN Costs: If the customer is replacing an MPLS, you might want to do a quick comparison: e.g., “You’re paying $X per month per site for MPLS of Y Mbps. An Azure VPN over the internet might cost you (internet ISP $A) + (Azure data transfer $B) per site, which could be significantly less for more bandwidth.” Often, internet bandwidth is cheaper per Mbps than MPLS, and Azure’s cost per GB can be reasonable if sized right. This helps justify the move in financial terms. Also, the soft cost savings include less time managing routers (which is a staff cost) and potentially avoiding expensive support contracts on network appliances because Azure manages the infrastructure in the cloud.
  • Azure Pricing Calculator: For transparency, use the Azure Pricing Calculator to model their scenario. This can be done after gathering all requirements: plug in the number of hubs, estimated hours (which is just always-on, so 730 hours a month), number of VPN connections, and data egress. Show the customer the monthly estimate. The calculator factors in regional pricing (some regions differ slightly). Mid-market customers appreciate seeing an actual number for which to budget. Remember that Azure enterprise agreements or CSPs might offer discounts – if the customer has those, their effective price could be lower than pay-as-you-go rates.
  • Avoiding Surprises: Lastly, we reiterate that monitoring costs are essential for cloud services. Azure Cost Management can alert if usage spikes. For example, if someone misconfigures something and a lot of data egress starts flowing, it can generate unexpected costs. We will ensure to set budgets or alerts as part of best practices. This proactive stance will assure the customer that moving network services to Azure won’t incur unchecked costs. Azure Virtual WAN also provides metrics (like data in/out) that can be monitored.

In summary, the mid-market customer should understand that Azure Virtual WAN’s pricing is flexible and consumption-based. There is no separate “license fee” for the technology itself – it’s all about what resources you use. When used efficiently, it can save money compared to traditional networks​ (especially considering the removal of physical appliances and leased lines). However, planning is key: a poorly optimized deployment could run up costs (for instance, sending all traffic through an unnecessary region). We, as the solution provider, will design with cost in mind – right-sizing hubs, leveraging the appropriate features, and using Azure’s included capabilities to ensure the solution is cost-effective.

Dave Kawula -Microsoft MVP