AZ-305 Network Design: Hybrid Connectivity, Private Endpoints, Firewalls and Load Balancing

For outbound internet access from private VMs, recommend Azure NAT Gateway on the subnet; give a VM its own public IP only when it must accept inbound connections itself. A NAT gateway translates every outbound flow from the subnets it is attached to into one or more static public IP addresses or a public IP prefix that you own, and it accepts no unsolicited inbound connections. Because the addresses are yours and static, partners can allowlist them in advance.

Default outbound access is going away for new networks. Microsoft is retiring the implicit outbound IP: new virtual networks created in the portal or with current API versions (released after 31 March 2026) default to private subnets, which have no outbound internet access until you add an explicit method such as a NAT gateway. Existing virtual networks are unchanged, for their existing and newly created VMs alike, and older API versions and templates still allow default outbound access, so this isn't a blanket shutdown. New designs should still always name the outbound method.

SNAT port exhaustion is a classic outbound problem. With load balancer outbound SNAT, each back-end instance gets a fixed share of ports per frontend IP, so many instances making many calls to the same destination run out of ports and new connections fail. Associating a NAT gateway with the subnet takes over the subnet's outbound flows and allocates ports on demand, with no per-instance tuning, while inbound traffic keeps arriving through the load balancer. Adding more frontend IPs to the outbound rule also adds ports, but you still manage the allocation.

Inbound from the internet comes through a public endpoint you deliberately expose: a public load balancer, Application Gateway, Azure Front Door, Azure Firewall DNAT, or a VM's own public IP. Standard public IPs are secure by default: inbound traffic is blocked until a network security group (NSG) allows it. The Basic SKUs of public IP and Load Balancer were retired on 30 September 2025, so designs use Standard.

Azure Bastion gives administrators RDP and SSH to VMs that have no public IP addresses, over TLS from the Azure portal or a native client, without exposing ports 3389 or 22 to the internet. The dedicated tiers (Basic, Standard and Premium) deploy a managed host in a subnet named AzureBastionSubnet, while the Developer tier runs on a shared pool and needs no subnet or public IP of its own; either way, the target VMs only need private IPs. The tier decides which features you get.

Two design facts shape a Bastion deployment. First, every dedicated tier, from Basic up, reaches VMs across virtual network peering, so one Bastion host in the hub serves all peered spokes; deploying one per network multiplies cost. Second, choose the lowest tier that delivers every stated feature: native clients need Standard, graphical session recording needs Premium, and plain browser access across peered networks needs only Basic. Only session recording captures what happens inside a session; logs describe connections.

Microsoft Defender for Cloud just-in-time (JIT) VM access is a different control: it opens management ports on a VM's NSG for an approved source and a limited time. It reduces exposure for VMs that already have a reachable address; it doesn't give a workstation a path to a VM with only a private IP.

Use a site-to-site VPN for encrypted connectivity over the internet at low cost and short lead time; use ExpressRoute when traffic must not cross the public internet or needs predictable latency and high bandwidth. Point-to-site VPN connects individual devices, not sites.

ExpressRoute peerings. Private peering carries traffic to private IP addresses in your Azure virtual networks, through an ExpressRoute gateway. Microsoft peering reaches Microsoft's public endpoints (Microsoft 365 and Azure PaaS public IPs, selected with route filters). A common design trap: to reach a PaaS service such as Azure Storage with public network access disabled, Microsoft peering doesn't help, because it targets the public endpoint. Put a private endpoint for the service in a connected virtual network instead; on-premises clients then reach it on a private IP over the existing private peering. Service endpoints don't help either, because they only apply to traffic that starts in an Azure subnet.

The ExpressRoute Premium add-on extends a circuit's reach to virtual networks in any region worldwide (across geopolitical boundaries) and raises the route and VNet-link limits. It changes what the circuit can reach; it adds neither encryption nor resilience.

A single ExpressRoute circuit already has two links, but both land in one peering location, so surviving the loss of a whole location needs a second circuit at a different peering location or a coexisting site-to-site VPN as a backup path. Microsoft's maximum-resiliency guidance is two circuits at two peering locations; a coexisting VPN over the internet is the cheaper fallback. A zone-redundant ExpressRoute gateway (an AZ SKU) protects the Azure side against an availability-zone failure; it doesn't help when the peering location fails.

ExpressRoute and VPN coexistence

• Both gateways go into the same GatewaySubnet, which must be /27 or larger. A virtual network has only one GatewaySubnet.
• The VPN gateway must be route-based and not the Basic SKU; policy-based gateways can't coexist. Active-active is optional.
• If the existing GatewaySubnet is too small (for example /28), Microsoft's procedure is to delete the ExpressRoute gateway, enlarge the subnet and recreate the gateway, which causes downtime, so plan the subnet size up front.
• When both paths advertise the same prefixes, Azure prefers ExpressRoute, so the VPN carries traffic only when ExpressRoute fails.

Global Reach: site-to-site over the Microsoft backbone

Connecting two circuits to the same ExpressRoute gateway does not let the two on-premises sites talk to each other: the gateway doesn't transit routes between circuits. ExpressRoute Global Reach links the circuits so traffic between your datacenters crosses the Microsoft backbone, which can replace a private WAN or MPLS link between them.

Encrypting ExpressRoute

MACsec is available only on ExpressRoute Direct ports, never on a provider circuit. FastPath, Global Reach and the Premium add-on encrypt nothing.

Point-to-site VPN connects individual devices to an Azure virtual network gateway; the design choices are the tunnel type and how clients authenticate.

Tunnel types: OpenVPN (TLS-based, works on Windows, macOS, Linux, iOS and Android, required for Entra ID authentication), IKEv2 (IPsec, native on Windows and macOS) and SSTP (TLS-based, Windows only). A gateway can enable more than one.

Routing for P2S clients: when a spoke is peered with the hub using gateway transit and use remote gateways, P2S clients can reach it through the hub gateway. The gateway side updates on its own, but clients install routes from the VPN client profile they downloaded. After a topology change such as a new peering, Microsoft's guidance is to download and install the client profile again; until then the Windows client has no route to the new address space.

In a hub-and-spoke network, shared services (gateways, firewall, Bastion, DNS) live in a hub virtual network and workloads in spokes peered to it; because peering is not transitive, you add gateway transit for hybrid traffic and user-defined routes through a hub firewall or NVA for spoke-to-spoke traffic.

• Peering is non-transitive. Spoke A learns the hub's address space, not spoke B's, so spoke-to-spoke traffic has no route by default. A direct spoke-to-spoke peering would connect them but bypass central inspection.
• Gateway transit. On the hub's side of each peering set allow gateway transit; on the spoke's side set use remote gateways. Spokes then use the hub's VPN or ExpressRoute gateway and learn on-premises routes without a gateway of their own. The pair is directional: the side that owns the gateway allows transit, and the side that borrows it uses remote gateways.
• Allow forwarded traffic lets a peering accept packets that an appliance relayed from somewhere else; it's needed on the spoke side when traffic arrives via the hub firewall, but it creates no routes.
• Spoke-to-spoke through the firewall: associate route tables with the spoke subnets that send the other spokes' prefixes (or a summary, or 0.0.0.0/0) to the firewall's private IP as a virtual appliance next hop.

How Azure picks a route

Azure chooses the route with the longest prefix match; only when prefixes are equal does it prefer a user-defined route over a BGP route over a system route. That catches designs that send 0.0.0.0/0 to the firewall: the spokes also learn on-premises prefixes (say a /16) from the gateway through BGP, and the more specific /16 wins, so hybrid traffic skips the firewall. The fix is to disable gateway route propagation on the spoke route tables, so the default route catches everything; the firewall's own subnet still learns the on-premises routes. For symmetric return traffic, add a route table on the GatewaySubnet that sends spoke prefixes to the firewall.

Azure Virtual WAN

Virtual WAN provides Microsoft-managed hubs with automatic transit between branches, users and virtual networks, which suits large estates (hundreds of branches, many VNets, several regions) when the team wants least routing effort.

Self-managed hubs remain valid when you need full control, but you own every route table, and a single VPN gateway has a fixed tunnel limit well below several hundred sites. Azure Virtual Network Manager connectivity configurations can create hub-and-spoke or mesh peerings at scale; they build connectivity, not traffic filters.

A private endpoint puts one specific PaaS resource on a private IP address in your virtual network through Azure Private Link; a service endpoint keeps the service's public endpoint but lets it recognise traffic from a chosen subnet.

Name resolution for private endpoints

Clients keep using the normal name (for example account.blob.core.windows.net). Public DNS returns a CNAME to the privatelink name, and a private DNS zone such as privatelink.blob.core.windows.net, holding the endpoint's A record, answers with the private IP. Three rules follow:

• Azure-provided DNS answers from the zones linked to the querying VNet. A VNet whose zone isn't linked resolves the public address. Add a virtual network link from the existing zone rather than creating a duplicate zone.
• Custom DNS servers in Azure (for example domain controllers in the hub) must forward the service's zone to the Azure DNS virtual IP 168.63.129.16, using a conditional forwarder for the public zone (such as blob.core.windows.net), and the privatelink zone must be linked to the VNet where those DNS servers run. If they forward everything to on-premises DNS, the answer stays public. Domain-joined VMs keep the domain controllers as their DNS servers; the forwarder is what brings Azure's private zones into their answers.
• On-premises clients can't reach 168.63.129.16; it only answers inside Azure virtual networks. Give on-premises DNS a private IP in Azure to forward to: an Azure DNS Private Resolver inbound endpoint is the managed option (forwarder VMs also work but must be run and patched). On-premises DNS gets conditional forwarders for the service zones pointing at the inbound endpoint. The resolver's outbound endpoint with a forwarding ruleset handles the opposite direction: Azure VMs resolving on-premises names.

Private endpoint name resolution is a DNS design task: only zone links and forwarding paths change which address a client receives.

Optimising network security means filtering at the right layer: Azure Firewall for central inspection of traffic between networks and to the internet, NSGs and application security groups for micro-segmentation, Virtual Network Manager for guardrails teams can't override, DDoS Protection for network-layer floods and a WAF for layer-7 attacks.

Azure Firewall tiers

Standard filters web traffic by FQDN (host name) only; anything that needs the decrypted payload or the URL path needs Premium. Traffic reaches the firewall only if routes send it there (see hub-and-spoke routing), so routing comes first and rules second.

NSGs and application security groups

An application security group (ASG) is a label attached to VM network interfaces. NSG rules can use ASGs as source or destination, so tiers sharing one subnet can still be segmented (web to API on one port, API to database on another), and scaling adds or removes NICs from the groups without anyone editing IP addresses. Use one ASG per tier: one shared group can't tell tiers apart, and ASGs attach to NICs, not subnets. By default, traffic inside a subnet goes VM to VM and never passes a hub firewall; forcing it through one needs a UDR for the subnet's own prefix and adds latency and cost, so NSGs with ASGs are the native way to segment co-located tiers.

Central guardrails with Azure Virtual Network Manager

Security admin rules in Azure Virtual Network Manager apply to network groups across subscriptions and are evaluated before NSG rules. A Deny rule drops the traffic whatever an NSG allows, Always Allow skips NSG evaluation, and Allow lets the NSG decide. Network groups can use Azure Policy for dynamic membership, so new virtual networks are covered automatically. This is how a central team blocks, for example, inbound RDP and SSH from the internet everywhere while application teams still own their NSGs. An Azure Policy deny effect only blocks future configurations; it doesn't filter traffic. For visibility, VNet flow logs (the successor to NSG flow logs) record traffic flows.

DDoS Protection tiers

A few public IPs with no need for rapid response or cost protection fit IP Protection; many IPs across networks, or a need for those extras, fit Network Protection.

Web Application Firewall

DDoS Protection works at layers 3 and 4, so a flood of well-formed HTTPS requests looks like normal traffic to it. Layer-7 protection is a WAF policy on Azure Front Door (global edge) or Application Gateway WAF v2 (regional): managed rule sets block common web attacks such as SQL injection and cross-site scripting, and rate-limit custom rules throttle clients that exceed a request threshold per window. Throttling abusive clients is a layer-7 decision, so it belongs in the WAF policy rather than in capacity or layer-4 rules.

Network performance in Azure is improved at four points: inside the VM (accelerated networking), between VMs (proximity placement groups), on the hybrid path (ExpressRoute FastPath) and for distant users (edge caching with Azure Front Door).

Read the bottleneck before choosing. If circuit utilisation is low but the gateway limits throughput, more circuit bandwidth or a second circuit on the same gateway leaves the gateway in the path; FastPath removes it. Accelerated networking helps only once a packet reaches the host. DNS-based routing helps only when there are several origins to choose between, and physical placement, not virtual network layout, sets VM-to-VM latency.

Choose a load balancer with two questions: is the traffic HTTP(S) or any TCP/UDP protocol, and is it global (across regions) or regional?

Traffic Manager routing methods: priority (failover), weighted, performance (lowest latency, which may cross borders), geographic (maps the DNS query's source location to a specific endpoint, which enforces data residency), multivalue and subnet. Only geographic routing guarantees that users from a country go to a named region; performance routing and the cross-region Load Balancer pick the closest or fastest region instead.

Front Door tiers and Application Gateway

With Premium, Front Door connects to the origin through a private endpoint that the origin owner approves, so the app's public network access can be turned off. Restricting an app to the AzureFrontDoor.Backend service tag is weaker: the public endpoint stays open. When the entry point itself must sit inside your virtual network and reach back ends on private IPs, the answer is Application Gateway, because Front Door is a global edge service outside your network. Retired or retiring options aren't design choices: Application Gateway v1 has been retired, Basic Load Balancer was retired in September 2025, and Front Door (classic) is being retired in favour of the Standard and Premium tiers.

Load balancing network virtual appliances

• Internal Standard Load Balancer with an HA ports rule: balances every TCP and UDP flow on every port across NVAs, keeps each flow on the same appliance in both directions and fails over using health probes. Spoke and gateway UDRs point at its frontend IP. HA ports is available only on internal load balancers. This suits east-west and hybrid inspection.
• Gateway Load Balancer: chained to a Standard public load balancer frontend or a VM's public IP configuration, it transparently sends inbound and outbound packets through an appliance pool and back, with no UDRs and no change to the public IP. This suits inserting third-party appliances in front of an internet-facing service.