13.3 Network Security Optimization Design
Key Takeaways
- NSGs are stateful, free, Layer 3/4 allow/deny filters at the subnet or NIC level with priorities 100-4096 (lower number = higher priority) and five default rules that cannot be deleted, only overridden.
- Azure Firewall is a centralized, stateful Layer 3-7 service supporting FQDN filtering, threat intelligence, and DNAT; Premium SKU adds IDPS, TLS inspection, and URL filtering that Standard SKU lacks.
- Azure DDoS Protection has two paid tiers: IP Protection (per-IP billing, no cost protection or rapid response) and Network Protection (per-100-IPs billing, adds cost protection, rapid response, and WAF discount) — infrastructure-level protection is always free and automatic.
- Private Endpoints bring a PaaS resource's private IP directly into your VNet and eliminate the public endpoint entirely; Service Endpoints keep the resource's public IP but restrict access to it from selected VNet subnets.
- Layered design — NSG for basic segmentation, Azure Firewall for centralized egress/FQDN control, Private Endpoints for PaaS isolation, DDoS Network Protection for volumetric attacks — is the standard AZ-305 answer for a zero-trust or regulated workload.
Why This Topic Matters
"Recommend a solution to optimize network security" is official Domain 4 bullet #47. Because Domain 4 (Infrastructure) is worth 30-35% — the single largest slice of the exam — and network security spans nearly every workload scenario, this topic recurs across the exam in disguise: identity questions reference Private Endpoints, data-storage questions reference Service Endpoints, and business-continuity questions reference Azure Firewall's role in DR failover traffic. Mastering the layered security stack pays off across multiple domains, not just this one section.
Network Security Groups (NSGs)
A Network Security Group is a free, stateful Layer 3/4 packet filter applied to a subnet or a network interface (NIC). Key exam facts:
- Rules are evaluated in priority order, lowest number first (range 100-4096); the first matching rule wins and evaluation stops.
- Every NSG ships with default rules (e.g., allow VNet-to-VNet, allow Azure Load Balancer probes, deny all other inbound) that cannot be deleted — only overridden by adding a custom rule with a lower (higher-priority) number.
- Rules can target service tags (e.g.,
Internet,VirtualNetwork,Storage,AzureCloud) instead of literal IP ranges, and application security groups (ASGs) to group VMs logically (e.g., "WebTier") rather than by IP address, so rules survive VM scale-out without editing. - NSGs are stateless about protocol semantics — they filter on IP/port/protocol only, with no awareness of HTTP headers, FQDNs, or application payloads.
Azure Firewall
Azure Firewall is a fully managed, centralized, stateful Layer 3-7 network security service, typically deployed once in a hub VNet or Virtual WAN Secure Hub to protect all spoke traffic.
| Capability | Standard SKU | Premium SKU |
|---|---|---|
| Stateful L3-L4 filtering, DNAT, SNAT | Yes | Yes |
| FQDN filtering (application rules) | Yes | Yes |
| Threat intelligence-based filtering | Yes | Yes |
| TLS inspection | No | Yes |
| IDPS (Intrusion Detection and Prevention System) | No | Yes |
| URL filtering (vs. FQDN-only) | No | Yes |
Choose Premium whenever the scenario calls out regulated industries, deep-packet inspection, or protection against known-vulnerability exploitation (IDPS) — Standard is sufficient for basic FQDN/network filtering and DNAT scenarios.
NSG vs. Azure Firewall
| Dimension | NSG | Azure Firewall |
|---|---|---|
| Layer | 3/4 | 3-7 (Premium adds deep inspection) |
| Scope | Per subnet/NIC | Centralized, typically one per hub |
| Cost | Free | Paid, hourly + data processed |
| FQDN filtering | No | Yes |
| Threat intelligence | No | Yes |
| Typical use | Micro-segmentation between tiers | Centralized egress control, DNAT, hybrid perimeter |
Most production designs use both: NSGs for east-west micro-segmentation between subnets/tiers, and Azure Firewall for centralized north-south (internet/on-premises) egress control — not one instead of the other.
Azure DDoS Protection
Azure's infrastructure-level DDoS protection is free and automatic for every public IP in Azure — no configuration needed. Beyond that baseline, two paid tiers add adaptive, application-aware protection:
| Feature | DDoS IP Protection | DDoS Network Protection |
|---|---|---|
| Active traffic monitoring, L3/L4 automatic mitigation | Yes | Yes |
| Mitigation policies tuned to your application | Yes | Yes |
| Protects Public IP Basic-tier resources | No | Yes |
| DDoS Rapid Response support | No | Yes |
| Cost protection (credits for attack-driven scale-out) | No | Yes |
| WAF discount | No | Yes |
| Billing model | Per protected IP | Per 100 protected IPs |
Guidance: fewer than ~15 public IPs to protect → IP Protection is more cost-effective; more than ~15 → Network Protection wins on cost and adds cost protection plus a 15-minute-SLA rapid response team. Network Protection also carries the overall 99.99% availability SLA.
Private Endpoints vs. Service Endpoints
- A Private Endpoint provisions a private IP address from your VNet that maps directly to a specific PaaS resource instance (a specific storage account, SQL server, Key Vault) using Azure Private Link. Traffic never leaves the Microsoft backbone, and — critically — the public endpoint can be disabled entirely, fully removing the resource from internet reachability.
- A Service Endpoint extends your VNet's identity to the Azure backbone for a service (e.g.,
Microsoft.Storage), letting you restrict the PaaS resource's firewall to allow only traffic from specific VNet/subnets — but the resource keeps its public IP address and DNS name; traffic is optimized and restricted by source, not made private.
The deciding question: must the public endpoint disappear entirely? If yes (zero-trust, regulatory mandate, or the earlier Front Door Premium Private Link scenario), use Private Endpoint. If a simpler, no-cost VNet-scoped restriction is sufficient and the resource can retain a public DNS name, Service Endpoint is the lighter-weight, cheaper choice.
Exam Scenario
A healthcare company stores PHI in Azure SQL Database and Blob Storage and must satisfy an auditor's requirement that these resources have no public network path whatsoever, that all traffic between application tiers is segmented, and that the environment is protected against both volumetric DDoS attacks and known CVE-based exploitation attempts from a compromised on-premises partner network. The design: Private Endpoints for SQL Database and Blob Storage (eliminating public endpoints), NSGs on each subnet enforcing tier-to-tier segmentation (web → app → data only), a hub-deployed Azure Firewall Premium (IDPS enabled) inspecting all traffic between the on-premises partner connection and the workload, and DDoS Network Protection enabled on the VNet (justified because the environment has well over 15 public-facing IPs across its App Service and Front Door tier, and the auditor requires the cost-protection guarantee).
An organization has 8 public IP addresses to protect against DDoS attacks and has no requirement for a rapid-response team or cost protection guarantees. Which DDoS Protection tier is the most cost-effective choice?
A design requires that an Azure SQL Database's public endpoint be completely removed from internet reachability while still allowing access from an on-premises network over ExpressRoute. Which solution meets this requirement?