Secure Networking & Edge Protection

Secure Networking & Edge Protection — Full Guide

Unit 2 of 7. The comprehensive full-coverage note for Secure Networking & Edge Protection (NSG/ASG, Firewall, Private Link, VPN, WAF, SSE). This is AZ-500’s largest single engineering domain (Secure networking, ~20-25%). Companion notes: quick recall in the cheat-sheet (see fold note below) · the highest-yield concepts in the High-ROI entry · date-sensitive facts, glossary, and the deprecation timeline in 99-Appendix. Prerequisite: Identity, Access & Privileged Access — every network control authorizes against identity. See the sequencing rationale in 00-Strategy-and-Map.

Network segmentation and private connectivity are the next Zero Trust layer after identity. They govern how every downstream workload — compute, storage/databases & Key Vault, and apps — is exposed or isolated. This unit owns the network/edge layer end to end. The unifying principle is default-deny, then authorize each flow explicitly: micro-segment, assume breach, and ensure a compromised tier cannot pivot laterally.

1. Network Security Groups (NSGs) and Application Security Groups (ASGs)

NSG — the stateful L3-L4 filter

An NSG is a stateful Layer 3-4 packet filter: a prioritized list of allow/deny rules, each matching the 5-tuple {source, source port, destination, destination port, protocol}. You attach it to a subnet, a NIC, or both.

• Custom rule priorities run 100-4096 — the lowest number is evaluated first, and the first match wins (no rule below a match is considered).
• Default rules occupy 65000-65500 and cannot be deleted: they allow inbound from VirtualNetwork and AzureLoadBalancer, allow outbound to VirtualNetwork and Internet, and DenyAllInbound from the Internet (with the matching DenyAllOutBound at 65500).
• Because NSGs are stateful, an allowed inbound flow’s return traffic is permitted automatically — you do not write a mirror outbound rule. (This is a frequent exam distractor.)

Effective rules when both levels apply. When a subnet NSG and a NIC NSG both bind to a flow, the result is the intersection — for inbound, the subnet NSG is evaluated, then the NIC NSG, and both must allow; for outbound, the NIC NSG then the subnet NSG. Use Network Watcher “effective security rules” (§10) to compute the real, merged rule set on a NIC.

ASG — policy by role, not by IP

An Application Security Group lets you reference a group of NICs as the source or destination of an NSG rule, decoupling policy from addressing. Membership is by NIC.

• All NICs in an ASG must reside in the same VNet as the first NIC assigned; when an ASG is used as both source and destination of a rule, all referenced NICs must share that VNet. Cross-VNet ASG membership is invalid.
• This is the idiomatic way to do role-based micro-segmentation (asg-web / asg-app / asg-db) that survives autoscale — a new VM’s NIC joins the ASG and inherits the policy instantly, with no IP edits.

Service tags — Microsoft-managed IP ranges

Service tags are symbolic, Microsoft-maintained IP-range groupings — VirtualNetwork, Internet, AzureLoadBalancer, Storage, AzureKeyVault, Sql, AzureCloud, and regional variants like Storage.EastUS. Use them in NSG and Azure Firewall rules so you never hardcode Microsoft ranges (which change constantly).

2. User-defined routes (UDRs)

Azure injects system routes automatically (intra-VNet, to peered VNets, to gateways, and a default route to the Internet). A route table carrying user-defined routes overrides them on a per-subnet basis.

Next-hop types:

Route-selection precedence: UDR > BGP-learned > system route, with longest-prefix match as the tiebreaker among same-source candidate routes.

The canonical pattern is 0.0.0.0/0 → VirtualAppliance (Azure Firewall private IP) to force all egress through the firewall for inspection.

3. Azure Virtual Network Manager (AVNM)

AVNM centrally manages connectivity and security across many VNets and subscriptions from a single management-group/subscription scope. Three concepts:

1. Network groups — collections of VNets with static (manual) membership or dynamic membership driven by Azure Policy conditions (e.g., all VNets tagged env=prod). New VNets that match are auto-enrolled into the group’s configurations.
2. Connectivity configurations — hub-and-spoke or mesh topology applied at scale (AVNM auto-creates the underlying peerings), including direct spoke-to-spoke connectivity (connected groups).
3. Security admin rules — global allow/deny rules enforced before NSGs, which NSG owners cannot override. This lets a central security team mandate “deny SSH/RDP from Internet everywhere” while still delegating the rest of the NSG to app teams.

4. Peering, VPN Gateway, ExpressRoute encryption, and Virtual WAN

VNet peering (non-transitive)

VNet peering privately connects two VNets (same-region or global) over the Microsoft backbone. It is non-transitive — spokes peered to a hub cannot reach each other through the hub by default. Spoke-to-spoke requires one of: a hub NVA/Azure Firewall + UDRs, gateway transit, or an AVNM mesh/connectivity configuration.

VPN Gateway

• Site-to-Site (S2S): an IPsec/IKE tunnel to an on-prem VPN device; active-active and zone-redundant SKUs provide HA.
• Point-to-Site (P2S): individual client tunnels. Protocols: OpenVPN, IKEv2, SSTP. Authentication: certificate, Microsoft Entra ID, or RADIUS/Active Directory. Entra ID auth lets you apply Conditional Access to the VPN (link back to identity). (Note: not every auth method pairs with every protocol — e.g., Entra ID authentication is used with OpenVPN.)

ExpressRoute encryption (a classic gotcha)

ExpressRoute is a private circuit but is NOT encrypted by default. When a compliance regime mandates encryption-in-transit, add it explicitly:

• MACsec — Layer-2 encryption on ExpressRoute Direct ports.
• IPsec over ExpressRoute private peering — Layer-3 (e.g., a VPN gateway tunnel riding the ER circuit).

Virtual WAN and the secured virtual hub

Virtual WAN (vWAN) is a Microsoft-managed networking hub providing automated any-to-any (branch, VNet, user) connectivity — replacing hand-built hub-spoke. A secured virtual hub is a vWAN hub with Azure Firewall (or a supported third-party SECaaS provider) integrated and managed through Azure Firewall Manager; routing intent directs Internet and private (spoke-to-spoke) traffic through the firewall without manual UDRs on every spoke — the scalable replacement for hand-built hub-spoke + UDR.

5. Private connectivity to PaaS — Service Endpoints, Private Endpoints, Private Link service

This pair is the single most confused topic in the unit and almost always carries an item on both exams.

Service Endpoint

Extends the VNet’s identity to a PaaS service so the service firewall can allow “this subnet.” The PaaS resource keeps its public IP; traffic stays on the Azure backbone, but the endpoint is still public-facing and not reachable from on-premises. Lightweight, free, scoped to service + region.

Private Endpoint (Azure Private Link)

Injects a private-IP NIC into your subnet that maps to one specific PaaS resource instance (often a specific sub-resource, e.g., blob, sqlServer, vault). You can then disable public network access on the resource entirely. Reachable from on-premises over VPN/ExpressRoute. It also provides data-exfiltration protection (the endpoint maps to one named resource, not the whole service).

Private Link service

The provider side: expose your own service (fronted by a Standard Load Balancer) to consumers in other VNets, subscriptions, or Microsoft Entra tenants via their private endpoints — no VNet peering, no public exposure. This is how SaaS/ISVs offer private connectivity to customers.

6. Network integration for App Service / Functions, ASE, SQL MI, and TLS

App Service & Functions — three distinct features (don’t conflate)

• Regional VNet integration — gives the app outbound access into a delegated subnet (to reach private endpoints, on-prem). It does not secure inbound.
• Private Endpoint — gives the app private inbound access and lets you disable its public endpoint.
• Access restrictions — IP / service-tag / Service-Endpoint allow-lists on the public inbound endpoint.

App Service Environment (ASE v3)

A single-tenant App Service deployment injected into a customer subnet (delegated to Microsoft.Web/hostingEnvironments), available as internal (ILB) or external (with an internal or external VIP). Because it lives in your subnet, NSGs and UDRs apply directly — full network control, unlike multi-tenant App Service.

Azure SQL Managed Instance

Deployed into a dedicated, delegated subnet (Microsoft.Sql/managedInstances) that requires an associated NSG and a route table. Connection types:

• Redirect — the client connects directly to the node: lower latency / higher throughput, but requires extra NSG ports open. (Redirect is the default connection type as of October 2025.)
• Proxy — all traffic flows via the MI gateway: simpler firewalling, higher latency.

TLS to applications

• App Service: bind custom domains with App Service managed certs or Key Vault certs; enforce minimum TLS version (1.2+) and HTTPS-only.
• API Management (APIM): control TLS/cipher policy, enforce mutual TLS (client-certificate) validation; can be VNet-injected (internal/external) to combine with the controls above. (APIM security configuration itself is covered in the Apps/Capstone unit; TLS-to-applications is the explicit AZ-500 networking objective.)

7. Azure Firewall, Firewall Manager, and firewall policies

Azure Firewall is a cloud-native, stateful, highly available, auto-scaling firewall-as-a-service.

SKUs

Premium deep dive

• TLS inspection decrypts → inspects → re-encrypts outbound/east-west TLS using a customer-provided CA certificate stored in Azure Key Vault — that is what lets IDPS and URL filtering see inside HTTPS. (Key Vault: Data, Storage & Key Management.)
• IDPS is signature-based (continuously updated), with per-signature modes Disabled / Alert / Alert and Deny, applied across L3-L7. Configurable private IP ranges classify traffic as inbound, outbound, or internal/east-west.
• URL filtering matches the full path (vs Standard’s web-category FQDN matching).

Firewall Policy

Rules live in a Firewall Policy (tiers Basic / Standard / Premium, matching the firewall SKU) rather than legacy Classic rules:

• Hierarchical parent/child inheritance — a child policy inherits a parent’s rule collection groups; parent rules win and are evaluated first, and Threat Intel mode can only be made stricter in a child.
• Rule processing order is always DNAT → Network → Application, regardless of priority or inheritance.
• IP Groups consolidate addresses for reuse.
• Azure Firewall Manager centrally manages policies across hub VNets and secured virtual hubs (§4), and can associate a DDoS plan + WAF policy in the same pane.

Governance hook: Azure Policy definitions exist to require Threat Intelligence, multi-AZ deployment, IDPS, TLS inspection, DNS proxy, and Premium upgrade — feeding Posture & Governance.

8. Application Gateway, Front Door / CDN, and Web Application Firewall (WAF)

Application Gateway — regional L7

A regional, Layer-7 reverse proxy / load balancer (URL routing, SSL offload / end-to-end TLS, mutual TLS, autoscaling, redirection). WAF is delivered by the WAF_v2 tier (OWASP CRS managed rules, custom rules, end-to-end + mutual TLS). Use it for a single-region app, internal L7, or mTLS-to-backends.

Azure Front Door — global L7 + CDN

A global, Layer-7 application-delivery network: anycast edge, path-based + latency routing, CDN caching, SSL offload, and an edge WAF. The Premium tier adds Private Link to origins (so backends need no public IP), managed rule sets, and bot protection. Use it for multi-region, global users, and edge caching.

Web Application Firewall (WAF)

Protects against the OWASP Top 10 (SQLi, XSS, etc.).

• Modes: Detection (log only) → Prevention (block).
• Managed rules: OWASP CRS on Application Gateway; Default Rule Set (DRS) + Bot Manager rules on Front Door.
• Custom rules: match conditions, rate limiting, geo-filtering, IP allow/deny.

Choosing — the discriminator is scope: global / multi-region / edge-cache + WAF → Front Door (Premium for Private Link origins). Single-region or internal L7 with mTLS → App Gateway WAF_v2. They also compose — Front Door at the edge → App Gateway regionally.

9. Azure DDoS Protection — when to recommend

Free infrastructure DDoS protection already covers every Azure public IPv4/IPv6 (volumetric/protocol, no configuration). The paid service adds adaptive tuning, telemetry, alerting, mitigation reports/flow logs, a Sentinel connector, and an SLA — in two tiers:

Microsoft’s “recommend-when” rule (memorize the number):

• < 15 public IP resources → IP Protection is cheaper.
• > 15 public IP resources → Network Protection is cheaper and unlocks Rapid Response, cost protection, and the WAF discount.

10. Monitoring with Network Watcher

A regional, data-plane diagnostics service:

• Connection Monitor — continuous reachability/latency between endpoints (Azure, on-prem, external).
• IP flow verify — “is this 5-tuple allowed or denied, and by which NSG rule?”
• NSG diagnostics / effective security rules — the computed, merged rule set on a NIC/subnet.
• Next hop — shows where a packet to a destination is routed (validates UDRs).
• Packet capture, Connection troubleshoot, VPN troubleshoot.
• Flow logs → Traffic Analytics (top talkers, malicious-flow detection), feeding Security Operations.

11. Security Service Edge — Microsoft Entra Internet Access & Private Access (the SC-100 delta)

This is the SC-100-only layer — not in scope for AZ-500. It is the same Zero Trust segmentation goal delivered through identity instead of (or alongside) VNet appliances.

Global Secure Access (GSA) is the unifying term and the unified location in the Microsoft Entra admin center for Microsoft’s Security Service Edge (SSE), built on Zero Trust (least privilege, verify explicitly, assume breach) and delivered from Microsoft’s global WAN. GSA comprises two products:

Microsoft Entra Internet Access — identity-aware SWG

A cloud-delivered, identity-aware secure web gateway (SWG), configured at the tenant level. It enforces Conditional Access, web content filtering, and TLS-based inspection on Internet and Microsoft 365 traffic. It supports cross-tenant configurations for Microsoft Services — e.g., tenant restrictions that block users from signing into unsanctioned M365 tenants from managed devices.

Microsoft Entra Private Access — ZTNA, no VPN

Zero Trust Network Access (ZTNA) that replaces legacy VPN. Built on Microsoft Entra application proxy, it provides per-app, Conditional-Access-gated access to private resources on any port/protocol (TCP/UDP), across hybrid/multi-cloud, with no inbound firewall rules (the Private Network Connector dials outbound). Quick Access publishes ranges of IPs/FQDNs (a transition state); per-app access scopes individual apps. It is more granular than a VPN because access is identity + device + risk evaluated continuously.

Shared mechanics

The Global Secure Access client on endpoints acquires traffic per traffic forwarding profiles — Internet access, Microsoft 365 access, and Private access — administered with the Global Secure Access Administrator role. GSA coexists side-by-side with third-party SSE (Cisco Secure Access, Palo Alto Prisma, Netskope), handling a subset of traffic.

12. AZ-500 (operate) ↔ SC-100 (architect): the throughline

The whole unit is one idea applied at every layer — default-deny, then authorize each flow explicitly (Zero Trust “assume breach” at the network). AZ-500 makes you build the controls; SC-100 makes you choose between them for a stated requirement.

Everything here authorizes against identity and gates exposure for compute, storage/databases, and apps — making this unit the connective tissue of the Zero Trust architecture.

Cross-references

• Prerequisite: Identity, Access & Privileged Access — every network control authorizes against RBAC / Conditional Access; P2S Entra-ID auth, SSE Conditional Access, and Firewall managed identity all consume it.
• Adjacent / downstream units:
  • Data, Storage & Key Management — Private Endpoints / Private Link for Key Vault & Storage; the Key Vault CA cert behind Firewall Premium TLS inspection.
  • Secure Compute, Containers & Endpoints — private AKS clusters, egress via Firewall/UDR, NSGs around VM/Bastion/JIT workloads sitting inside this perimeter.
  • Posture, Governance & Compliance — Azure Policy enforcement of firewall/IDPS/TLS/multi-AZ; AVNM as the landing-zone segmentation lever.
  • Security Operations (Sentinel, XDR, SOAR) — Network Watcher flow logs → Traffic Analytics → Sentinel detection.
  • Apps, API, M365 & Strategy Capstone — APIM security config, WAF/Front Door/App Gateway app-security design, DDoS in BCDR/resiliency.
• Recall & index: 01-Cheat-Sheet (networking folded into other unit sections — see top-of-note callout) · High-ROI · Unit 2 · 99-Appendix

Authoritative references

• Network security groups overview
• Application security groups
• Service tags overview
• User-defined routes overview
• Azure Virtual Network Manager — security admin rules
• VNet peering overview
• Point-to-Site VPN — about
• ExpressRoute encryption (MACsec / IPsec)
• Secured virtual hub
• Private Endpoint overview
• Private Endpoint DNS configuration
• Private Link service overview
• Compare Private Endpoints and Service Endpoints
• App Service VNet integration
• App Service Environment overview
• SQL Managed Instance connectivity architecture
• Choose the right Azure Firewall SKU
• Azure Firewall Premium features (TLS / IDPS / URL filtering)
• Azure Firewall Policy overview
• Azure Firewall rule processing logic
• Application Gateway WAF overview
• Azure Front Door overview
• Web Application Firewall overview
• DDoS Protection SKU comparison
• DDoS Protection FAQ (tier choice / pricing)
• Network Watcher overview
• What is Global Secure Access
• Microsoft Entra Internet Access concept
• Microsoft Entra Private Access concept
• GSA traffic forwarding profiles
• AZ-500 study guide
• SC-100 study guide