Azure Networking: VNets, NSGs, Private Endpoints, and Routing

Plan VNets and Subnets

An Azure Virtual Network provides private IP space for subnets, network interfaces, private endpoints, gateways, and connected services.

Network Security Groups filter traffic, route tables influence packet paths, and private endpoints give supported platform services a private IP inside a VNet.

Internet entry, application routing, outbound connectivity, and hybrid networking are separate decisions and should not be collapsed into one broad subnet or firewall rule.

Choose non-overlapping address spaces that leave room for future subnets and hybrid connectivity. Segment workloads when routing, security, delegation, or lifecycle differs.

Reserve ranges before peering or connecting on-premises networks.
Account for addresses Azure reserves in every subnet.
Use subnet delegation only for services that require it.

Control Traffic With NSGs and Routes

NSGs contain prioritized stateful rules and can apply to subnets or network interfaces. User-defined routes can send traffic through appliances or override selected system routes.

Use service tags and application security groups where they clarify intent.
Check effective security rules and effective routes during troubleshooting.
Avoid rules that expose management ports to the internet.

Choose Public and Private Entry Points

Azure Load Balancer handles layer-four traffic, Application Gateway provides regional layer-seven routing and WAF options, and Front Door provides global HTTP entry. Private endpoints bring supported services into private address space.

Select the entry service from protocol, scope, and inspection needs.
Configure private DNS zones for private-link names.
Disable public service access when the design requires private-only connectivity.

Outbound and Hybrid Connectivity

Use NAT Gateway for predictable internet egress, VPN Gateway for encrypted network connections, and ExpressRoute for private connectivity through a provider. Monitor SNAT use and route symmetry.

Do not rely on implicit outbound access for durable designs.
Inspect Network Watcher flow and connectivity data.
Test DNS, forward routing, return routing, and application listeners separately.

Address and Subnet Plan

Choose non-overlapping IPv4 and IPv6 address spaces with room for application tiers, private endpoints, platform delegation, zone growth, and temporary migration. Azure reserves addresses in every subnet, and some services require dedicated delegated subnets or minimum sizes. Record allocations centrally before peering or hybrid connectivity makes overlap expensive.

A subnet is a routing and policy boundary, not merely a naming folder. Separate ingress, application, data, private endpoints, gateways, and platform integrations when their route, NSG, delegation, or lifecycle differs. Do not create a subnet per resource without a control reason, and do not place unrelated workloads into one oversized shared subnet by default.

Plan DNS with addressing. Azure-provided DNS, custom DNS servers, Azure DNS Private Resolver, and private DNS zones solve different needs. Every private endpoint and hybrid name must resolve consistently from the clients that use it, including after regional recovery.

Reserve space for endpoints and delegated services.
Prevent overlap before peering or hybrid connection.
Separate subnets by policy and lifecycle need.
Design private DNS with the address plan.

Routes and VNet Connections

Azure creates system routes for virtual networks and connected services. User-defined routes can send traffic to a virtual appliance, virtual network gateway, or other supported next hop. Effective routing depends on route source, prefix specificity, BGP propagation, and platform rules. Inspect effective routes before modifying an NSG.

VNet peering provides private connectivity with nontransitive behavior unless an architecture explicitly routes through a hub or appliance. Plan forwarded traffic, gateway transit, DNS, network security, and address space. A hub-and-spoke design centralizes shared connectivity but can create a shared failure, throughput, and cost boundary.

Virtual WAN, VPN Gateway, ExpressRoute, and peering provide different scale, transport, resilience, and operating models. Define route ownership, redundant connections, on-premises return paths, BGP behavior, encryption, and failure tests. Connectivity does not grant Entra or application authorization.

Inspect effective routes at the real network interface.
Do not assume peering is transitive.
Design symmetric return paths through appliances.
Test redundant hybrid links and route withdrawal.

NSG and Firewall Layers

Network security groups contain prioritized allow or deny rules evaluated for inbound and outbound traffic at subnet and network-interface scope. Effective rules combine both scopes with default rules. Use application security groups and service tags where they express stable relationships, and keep explicit broad internet rules exceptional and reviewed.

NSGs filter at network layer but do not provide application-aware inspection, centralized outbound policy, or a complete denial-of-service strategy. Azure Firewall, network virtual appliances, Web Application Firewall, and DDoS Protection address different layers. Choose controls from the threat and traffic path instead of stacking products without ownership.

Changing a rule does not prove a route, DNS answer, listener, certificate, or guest firewall works. Record priority and intent, remove expired diagnostic rules, test IPv4 and IPv6, and use Policy to find dangerous exposure. Keep management ports behind Bastion, VPN, or another controlled path.

Review subnet and NIC rules together.
Use application groups for stable tier relationships.
Select firewall controls by protocol layer.
Expire temporary broad rules.

Private Link and Service Endpoints

A private endpoint places a network interface with a private IP in a VNet and connects it to one supported service subresource through Private Link. The service keeps its normal hostname, which private DNS resolves to that address. Plan approval, subresource, subnet, NSG behavior, DNS zone links, and public endpoint policy together.

A service endpoint extends VNet identity to a supported public service endpoint and lets a resource firewall allow selected subnets. Traffic remains addressed to the service public endpoint, unlike Private Link. Choose from privacy, cross-network access, cost, DNS, service support, and data-exfiltration controls rather than treating one as the universal replacement.

Private Link service can expose a customer service privately to consumers without peering whole networks. Review provider load balancer, approval, NAT behavior, tenant boundaries, and consumer DNS. Test approved and rejected connections and ensure failover does not leave a stale private DNS record.

Create endpoints for each required service subresource.
Verify normal hostnames resolve privately for clients.
Configure public endpoint access separately.
Choose endpoints from the real connectivity contract.

Ingress and Outbound Design

Azure Load Balancer operates at transport layer, Application Gateway provides regional HTTP routing and optional WAF, and Azure Front Door provides global edge HTTP delivery and routing. Choose the entry point from protocol, scope, TLS, inspection, origin, health, and failover requirements. Keep application backends private where the architecture permits.

Use NAT Gateway or a controlled firewall path for explicit scalable outbound internet connectivity from private subnets. Do not depend on implicit default outbound behavior. Inventory destination needs, source addresses, SNAT capacity, route precedence, DNS, logging, and the cost of processed and transferred traffic.

Health probes should represent service readiness without creating correlated failure. Preserve client identity through supported headers or proxy protocols only after securing trust boundaries. Test direct-backend bypass, certificate rotation, zone failure, and origin unavailability.

Choose the load-balancing layer from protocol and scope.
Make outbound connectivity explicit.
Protect backends from unintended direct access.
Test health and failover at the complete request path.

Network Evidence and Diagnosis

Capture source address, destination name and address, protocol, port, timestamp, subscription, and expected path. Check DNS, effective routes, peering or gateway, NSGs, firewall policy, private endpoint state, target health, and return route in order. One hypothesis and one change at a time preserves useful evidence.

Network Watcher provides topology, connection monitoring, IP flow verification, NSG diagnostics, next hop, effective rules, packet capture, and gateway troubleshooting for supported IaaS paths. Use virtual network flow logs for new flow-logging designs and migrate from retiring NSG flow logs according to current Microsoft guidance.

An allowed network flow can still fail because the process is not listening, TLS validation fails, authentication is denied, or a PaaS service firewall blocks the data plane. Correlate network evidence with Activity Log, service diagnostics, load balancer health, and application traces. Turn resolved incidents into continuous connection tests.

Record the failing five-tuple and timestamp.
Inspect forward and return paths in sequence.
Use current virtual network flow-log guidance.
Separate packet reachability from application success.

Network Change Control

Preview and peer-review address, route, NSG, firewall, private DNS, and endpoint changes as infrastructure code. Record the expected flow and rollback before deployment. A control-plane rollback may not immediately restore cached DNS, active connections, learned routes, or third-party appliance state.

Use staged policy and route changes when a broad scope is involved, preserve out-of-band administration, and run connection monitors through the critical paths after deployment. Decommission old routes, public addresses, peerings, DNS links, and temporary rules only after traffic evidence confirms they are unused.

Document expected flows before a network change.
Keep a tested administration path during rollout.
Verify and then remove obsolete network state.

Network Path Examples

Allow HTTPS Inbound in an NSG

az network nsg rule create \
  --resource-group rg-network-dev \
  --nsg-name nsg-web \
  --name Allow-Https \
  --priority 100 \
  --access Allow \
  --protocol Tcp \
  --direction Inbound \
  --destination-port-ranges 443

Trace Private Endpoint DNS

An application resolves a database hostname to its public address after a private endpoint is added.

Trace Private Endpoint DNS

Constraints: The private DNS zone must be linked to the application VNet and hybrid clients use a forwarding resolver.
Decision: Trace the queried name, CNAME chain, private zone link, resolver path, subnet route, and NSG rules.
Verification: The application resolves the private address and a connection test reaches the endpoint without public egress.
Failure test: Unlink the private zone in a test VNet and confirm the diagnostic detects the public resolution.

Output

Expected evidence: The application resolves the private address and a connection test reaches the endpoint without public egress.

This is a worked engineering decision, so the result is operational evidence rather than terminal output.

Before you move on