Design a secure hub-spoke network for regional web applications in Azure

When you host a web application in Azure, the network design you choose determines how much of your infrastructure is exposed to attack. Without an intentional design, teams commonly leave default configurations in place, expose management ports to the internet, or skip application-layer inspection—all of which increase the attack surface.

This article explains a repeatable architecture pattern that uses a minimal hub-spoke topology to build a secure-by-default foundation for single-region web applications. A hub virtual network hosts shared services like Azure Bastion, while a spoke virtual network contains your workload—whether running on Azure App Service (PaaS) or virtual machines (IaaS). The pattern scales from a single web app to multiple workloads by adding spokes.

The pattern follows a layered approach. The hub and spoke virtual networks form the base, virtual network (VNet) peering connects them, and NSGs add default-deny access control at every subnet boundary. Higher-level services—Application Gateway with Web Application Firewall (WAF) in the spoke, Azure Bastion in the hub, and DDoS Protection across both—layer on top. Each layer depends on the one below it. The Deployment steps section later in this article walks through the recommended order.

This pattern is for network engineers and architects at small or midsize organizations who need to:

• Separate shared services from workloads using a hub-spoke topology that's ready to grow.
• Put an application-layer gateway with WAF in front of every web workload.
• Enforce default-deny traffic rules at the subnet level.
• Eliminate direct RDP/SSH exposure to backend VMs.
• Protect public IPs from volumetric DDoS attacks when the threat profile warrants it.
• Keep the design simple enough to deploy without specialized networking expertise.

Architecture

The backend compute model—IaaS or PaaS—determines which shared services are needed in the hub. Both variants use the same hub-spoke foundation with VNet peering, NSGs on every subnet, and conditional DDoS Protection.

IaaS backend (Virtual Machines)

When the backend includes VMs, internet traffic flows through Application Gateway with WAF in the spoke to backend VMs in a private workload subnet. The hub hosts Azure Bastion for secure RDP/SSH management across peered spokes, and NAT Gateway provides explicit outbound connectivity for private workload subnets. Azure Firewall in the hub is optional and provides centralized egress control when FQDN-based filtering is needed.

PaaS backend (App Service)

When the backend is PaaS, internet traffic flows through Application Gateway with WAF in the spoke to App Service in the workload subnet. You don't need Bastion because there's no OS-level access to manage. The hub exists for optional shared services (Azure Firewall) and future growth. VNet peering is always provisioned; it carries active traffic only when Azure Firewall handles centralized egress.

The architecture uses two virtual networks connected by VNet peering:

Hub virtual network — Hosts shared services that workloads use. In this minimal pattern, the hub contains Azure Bastion for secure VM management. As the organization grows, the hub can also host Azure Firewall for centralized egress control, a VPN or ExpressRoute gateway for on-premises connectivity, or centralized DNS.

Spoke virtual network — Contains workload-specific resources. Internet traffic arrives at a public IP address associated with Azure Application Gateway, which operates as a Layer 7 reverse proxy in a dedicated spoke subnet. A WAF policy inspects every HTTP/HTTPS request against OWASP Core Rule Set rules before forwarding traffic to the backend pool. The backend pool contains either PaaS endpoints (such as App Service) or IaaS resources (VMs or Virtual Machine Scale Sets) in a dedicated workload subnet.

VNet peering connects the hub and spoke with low-latency, high-bandwidth connectivity over the Azure backbone. Peering is nontransitive—each spoke connects only to the hub, not to other spokes—which enforces workload isolation by default.

Network security groups (NSGs) enforce default-deny rules on every subnet in both virtual networks. The Application Gateway subnet allows inbound HTTPS and the required GatewayManager health probe ports. The workload subnet accepts traffic only from the Application Gateway subnet. When the backend includes VMs, Azure Bastion in the hub provides secure RDP/SSH access across the peering connection. When there are internet-facing public IPs, Azure DDoS Protection defends against volumetric and protocol attacks at Layers 3 and 4.

Each component in this pattern has a clear role:

Why use hub-spoke instead of a single virtual network?

A single virtual network with all resources is simpler to set up initially, but it creates problems as the organization grows:

• CIDR collisions block peering. If you start with a single virtual network and later need to peer it with a hub, the address spaces can't overlap. Retrofitting CIDR ranges on a live workload often requires redeployment.
• Can't reuse shared services. You must duplicate bastion, DNS, and monitoring resources for each new workload when you deploy them in a workload virtual network.
• No isolation boundary. All workloads share the same network boundary, so a compromise in one workload has a larger impact.

The minimal hub-spoke pattern in this article adds only one extra virtual network and one peering connection. The incremental complexity is small - roughly equivalent to creating one more NSG - but the architecture is ready to scale without rework.

Deployment steps

This foundation is built in layers. Each layer depends on the one before it, so deploy in this order:

Network foundation: VNet and subnet planning

Before deploying any security service, create both virtual networks and size all subnets. Every component in this pattern requires a specific subnet, and some have strict naming and sizing requirements.

Hub virtual network

The hub is intentionally small. It hosts shared services that spokes consume.

Spoke virtual network

The spoke contains workload-specific resources. Each new workload gets its own spoke.

CIDR planning for hub-spoke

Plan CIDR ranges for both VNets before the first deployment. Address spaces must not overlap. VNet peering fails if any CIDR ranges collide. Use the following approach for a minimal hub-spoke architecture:

VNet peering

Virtual network peering connects the hub and spoke with low-latency connectivity over the Azure backbone. Configure peering as bidirectional so that traffic flows in both directions:

• Hub → Spoke: Enables Bastion to reach VMs and (when present) Azure Firewall to inspect spoke traffic.
• Spoke → Hub: Enables workloads to use shared hub services.

Key peering settings:

Network segmentation with NSGs

Both the hub and spoke virtual networks use NSGs to enforce default-deny rules at every subnet boundary. By using separate subnets for each role—Application Gateway, workload, Bastion, and optional Firewall—you can use NSGs to control traffic precisely.

Essentials when deploying

• Associate an NSG with every subnet in both VNets. Start with a deny-all inbound rule. Add explicit allow rules only for traffic the design requires.
• Application Gateway subnet rules (spoke): Allow inbound HTTPS (443) from the internet. Allow inbound on ports 65200-65535 from the GatewayManager service tag (required for v2 health probes). Allow the AzureLoadBalancer service tag.
• Workload subnet rules (spoke): Allow inbound only from the Application Gateway subnet on the application port. Deny all other inbound traffic.
• Bastion subnet rules (hub): Follow the Bastion NSG requirements exactly. Bastion has specific inbound and outbound rules that you must apply for connectivity to work across peered VNets.
• Restrict egress. Use NSG outbound rules to deny unwanted outbound traffic. For most regional web apps, limiting egress to known Azure service destinations is sufficient. If you need FQDN-based filtering, add Azure Firewall in the hub virtual network (see Centralized egress with Azure Firewall).
• Enable flow logs. Virtual network flow logs capture traffic patterns for security analysis and troubleshooting. If you still use NSG flow logs, migrate to VNet flow logs before the NSG flow logs retirement on September 30, 2027.

DDoS Protection: Do you need it?

Azure DDoS infrastructure protection and Azure DDoS Protection are separate services. All Azure services with public IPv4 and IPv6 addresses receive Azure DDoS infrastructure protection at no extra cost. However, infrastructure protection defends the Azure platform as a whole—it operates at a higher threshold than most individual applications can handle and doesn't protect customer resources at the resource level. It provides no adaptive tuning to your specific traffic patterns, no diagnostics or alerting, and no response support. For workloads that accept traffic from the public internet, enable a DDoS Protection plan (Network Protection or IP Protection) to get resource-level adaptive tuning, attack diagnostics, rapid response support, and cost protection guarantees. Don't rely on infrastructure protection alone to protect your services.

The decision is straightforward:

• Public IP facing the internet → Enable DDoS Protection. Choose the tier based on how many public IPs you protect. Don't rely on infrastructure protection alone for customer-facing workloads.
• Private only (no public IP), or behind Azure Front Door → A DDoS Protection plan is optional. Front Door includes its own integrated DDoS protection. Private-only resources have no public endpoint to attack, but infrastructure protection alone doesn't provide resource-level guarantees.

In a hub-spoke topology, link the DDoS Protection plan to both the hub and spoke VNets so that public IPs in either network are covered.

For more information, see Azure DDoS Protection tier comparison.

Application Gateway with WAF

Application Gateway is a regional Layer 7 load balancer purpose-built for web traffic. The WAF_v2 SKU provides OWASP CRS-based protection against SQL injection, cross-site scripting, and other common web exploits. It supports autoscaling, zone redundancy, and a static VIP.

You deploy Application Gateway into its dedicated subnet in the spoke virtual network—close to the workload it protects. This placement keeps ingress traffic in the spoke and avoids routing internet traffic through the hub unnecessarily.

When to choose something else: If you need global load balancing across multiple Azure regions, use Azure Front Door with WAF instead. If traffic isn't HTTP/HTTPS (for example, raw TCP or UDP), use Azure Load Balancer at Layer 4.

Essentials when deploying

• Use WAF policies, not legacy WAF configuration. You can't create new WAF configuration deployments on WAF v2 starting March 15, 2025. Migrate existing configurations to WAF policies before March 15, 2027. WAF policies provide per-site and per-URI rule granularity, bot protection, and the next-generation WAF engine.
• Start in Detection mode, switch to Prevention before production. Detection mode logs threats without blocking them, giving you time to tune rules and identify false positives. Use Prevention mode for all production workloads.
• Size the subnet to /24. Application Gateway v2 supports up to 125 instances and requires a dedicated subnet. A /24 provides 251 usable addresses for autoscaling and maintenance upgrades.
• Store TLS certificates in Azure Key Vault. Use Key Vault integration with managed identities for automated certificate rotation. This approach eliminates manual certificate management and prevents outages from expired certificates.
• Enable diagnostic logging from day one. Send access logs, firewall logs, and performance metrics to a Log Analytics workspace. Without logs, you can't investigate security incidents or tune WAF rules.

For security hardening guidance, see Secure your Azure Application Gateway. For sizing and performance recommendations, see Architecture best practices for Application Gateway v2.

Azure Bastion in the hub: PaaS versus IaaS decision

Whether you need Azure Bastion depends entirely on your backend compute model:

Why Bastion lives in the hub

When you place Bastion in the hub virtual network, you can deploy it once and use it to manage VMs across all peered spokes. If you put Bastion in each spoke, every new workload needs its own Bastion instance, which adds cost and management overhead.

The Basic SKU and higher support virtual network peering, so Bastion in the hub can connect to VMs in any peered spoke. For a full feature comparison across Developer, Basic, Standard, and Premium SKUs, see Bastion SKU comparison.

Essentials when deploying

• Deploy Bastion in a dedicated AzureBastionSubnet of /26 or larger. Azure requires this exact subnet name and you can't share it with other resources.
• Use Premium SKU for production workloads. Premium supports private-only deployment (no public IP required), session recording for compliance, and host scaling (2-50 instances). The cost difference over Standard is marginal. For smaller deployments, Basic is an acceptable minimum - it provides dedicated instances and supports VNet peering. The Developer SKU uses shared infrastructure, doesn't support peering, and isn't suitable for production.
• Follow the Bastion NSG requirements. The Bastion subnet has specific inbound and outbound rules that you must apply exactly. Missing rules cause connection failures. When Bastion is in the hub, ensure the spoke workload subnet NSG allows inbound RDP (3389) or SSH (22) from the hub VNet's address space.
• Enable Microsoft Entra ID authentication for SSH/RDP. Entra ID authentication eliminates distributing SSH keys or local passwords and enables MFA and conditional access policies. SSH via Entra ID in the portal is generally available; RDP via Entra ID in the portal is in public preview. The Basic SKU supports Entra ID auth in the portal; the Standard SKU or higher is required for native client connections. For setup instructions, see Entra ID authentication for Azure Bastion.

Centralized egress with Azure Firewall (optional)

For organizations that need FQDN-based outbound filtering, TLS inspection, or centralized logging of all egress traffic, add Azure Firewall to the hub virtual network. Azure Firewall is optional in this pattern - NSGs provide basic egress control, and many startups operate successfully without it.

When to add Azure Firewall

If you choose to add it

• Use the Basic SKU for SMBs. Azure Firewall Basic supports up to 250 Mbps throughput and costs less than Standard or Premium SKUs. It's designed for small and midsize environments. For help choosing a SKU, see Choose the right Azure Firewall SKU.
• Deploy in AzureFirewallSubnet (/26) in the hub. Azure Firewall Basic also requires a dedicated AzureFirewallManagementSubnet (/26) to separate management traffic from customer traffic. Create both subnets before deploying the firewall.
• Create UDRs on spoke subnets with a default route (0.0.0.0/0) pointing to the firewall's private IP. This route forces all outbound traffic through the hub for inspection.
• Start simple. Begin with a small set of application and network rules. Add rules as you understand your workload's traffic patterns.

Outbound access and private subnets

Starting after March 31, 2026, new virtual networks in Azure default to private subnets (defaultOutboundAccess set to false). VMs in a private subnet receive no implicit outbound public IP from Azure - an explicit outbound method is required to reach public endpoints. This change aligns with Zero Trust principles: the previous default assigned a Microsoft-owned IP address that could change without notice, making outbound traffic unpredictable. For full details, see Default outbound access for VMs in Azure.

What this means for the architecture

Workload subnets in this pattern need an explicit egress path. Choose the method that fits your requirements:

NAT Gateway for explicit outbound

When you don't need FQDN-based filtering, attach a NAT Gateway to the workload subnet for explicit, predictable outbound connectivity. NAT Gateway provides a static outbound IP, supports up to 50 Gbps throughput (Standard SKU), and requires no UDRs.

NAT Gateway V2 (StandardV2 SKU) offers zone-redundant operation across all availability zones, IPv6 support, and 100 Gbps throughput at the same price as the Standard SKU. When deploying a new NAT Gateway, prefer StandardV2 where available. Note current limitations: StandardV2 requires StandardV2-SKU public IPs (Standard public IPs aren't compatible), doesn't yet support Terraform, and isn't available in all regions. For a full comparison, see NAT Gateway SKU comparison.

Identity and access control

Use Microsoft Entra ID for role-based access control (RBAC) across all networking resources:

• Assign built-in roles like Network Contributor instead of custom roles where possible.
• Require at least Microsoft.Network/virtualNetworks/subnets/join/action and subnets/read for users and service principals operating Application Gateway.
• Use managed identities for Application Gateway to access Key Vault—don't store credentials.

Mistakes to avoid

When things go wrong

502 Bad Gateway from Application Gateway

Check first: Verify the Application Gateway subnet NSG allows ports 65200-65535 from GatewayManager. Confirm backend health probe settings match the application's listening port and path, and that the backend returns HTTP 200-399 on the probe endpoint.

Common causes: Blocked GatewayManager health probes, misconfigured custom health probes, backend app crashes, or TLS certificate mismatch when end-to-end TLS is enabled.

WAF blocks legitimate traffic (false positives)

Check first: Enable WAF diagnostic logs and filter by blocked actions. Identify the rule ID (for example, 942130 for SQL injection detection) and determine whether the match is on safe content like authentication tokens.

Fix: Use WAF exclusion lists to omit specific request attributes, or use per-rule exclusions available in WAF policies.

Can't connect to VMs through Bastion

Check first: Verify the AzureBastionSubnet is /26 or larger. Check that the NSG on the Bastion subnet in the hub has the required rules. Confirm the target VM's NSG in the spoke allows inbound RDP (3389) or SSH (22) from the hub VNet's address space.

Common causes: Missing or incorrect NSG rules on the Bastion subnet, Bastion SKU doesn't support peering (Developer SKU), subnet too small, or the target VM's OS-level firewall blocking connections.

Peering shows "Disconnected" status

Check first: Verify that both sides of the peering exist (hub-to-spoke and spoke-to-hub). You must create peering in both directions. If you delete one side, the other side shows "Disconnected."

Fix: Delete the remaining peering and recreate both sides. Ensure CIDR address spaces don't overlap.

Next steps

• Apply Zero Trust principles to a hub virtual network in Azure
• Apply Zero Trust principles to a spoke virtual network with Azure PaaS Services