Recommend a Solution to Optimize Network Security — Lesson

A large regulated bank's annual penetration test report lands on the architect's desk. The findings are extensive: VMs in production with NSGs allowing the internet ($0.0.0.0/0$) inbound on common admin ports such as RDP 3389 and SSH 22; no central egress filtering or auditing of outbound traffic; storage accounts and SQL databases with public endpoints reachable from anywhere on the internet with only allow-list firewall rules; a flat VNet topology with no internal segmentation, so any compromised VM can reach every other VM laterally. The architect's six-month remediation programme systematically rewrites the security posture from end to end: every Azure PaaS backend is moved onto a Private Endpoint with public network access disabled; a hub-based Azure Firewall Premium with TLS inspection and IDPS enabled becomes the single egress chokepoint; NSGs and Application Security Groups segment workloads at the subnet and NIC level by role rather than by CIDR; DDoS Network Protection is enabled on the VNets hosting tier-1 public IPs; Azure WAF policies are enabled on every public Application Gateway and at the Front Door edge. The next year's pen test report is one page long with no critical findings. This lesson is about deliberately designing network-layer security — layered, defence-in-depth, identity-aware, Zero-Trust-aligned — instead of relying on perimeter firewall alone or a single magic security product.

We will work through Azure's network-security story in the order the AZ-305 exam expects you to think about it: NSGs and ASGs at the segmentation layer, Azure Firewall Standard / Premium / Basic at the egress layer, DDoS Protection at the network edge, Azure WAF on Application Gateway and Front Door at the L7 layer, and Private Link / Private Endpoints / service endpoints at the PaaS perimeter. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill $4.4 on network security and the Microsoft Zero Trust architecture documentation.

Why This Matters

Network security is the foundation of any defensible Azure architecture and the most visible part of a customer's posture during audit reviews. Misconfigured, network security is the failure mode that lands a customer in a public breach disclosure or a regulator's escalation queue. The AZ-305 exam tests this LO heavily because architects make most network-security choices at design time — choices that set the security ceiling for the workload's lifetime and are operationally difficult to add after the fact.

The career payoff is concrete: every pen-test remediation programme, every "we just got SOC2 audit findings" project, every Zero-Trust transformation programme, every regulated workload's design review, every "why did we fail this audit?" retrospective, and every cyber-incident response touches this LO at some point in the workload's life. If you can match a security requirement to the right Azure service and layer the controls correctly across edge, regional, segmentation, PaaS, egress, and admin tiers, you will pass this slice of the exam and design network security like a senior architect — turning audit findings from inevitable to rare.

Prerequisites

• NSG basics. Can you describe rule precedence (lower priority = higher priority)? — Self-check: what's the default outbound rule?
• TCP / UDP. Are you familiar with stateful vs stateless connections? — Self-check: which is firewalled most easily?
• TLS basics. Do you understand TLS termination vs passthrough? — Self-check: when does TLS inspection require certificate trust?
• Private endpoint concept. Have you used Private Endpoints? — Self-check: which DNS zone does Private Link populate?
• Defence-in-depth. Are you familiar with the concept? — Self-check: name three layers in a layered network defence.

If any of these feels shaky, pause and review LO-8 (secrets/keys), LO-45 (internet connectivity), and LO-11 (identity governance) before continuing this lesson on network security.

Learning Objectives

1. Analyse a workload's security requirements (perimeter, micro-segmentation, egress filtering, DDoS, application-layer threats) and translate them to the right Azure services.
2. Recommend NSG vs ASG vs Azure Firewall placement for a given segmentation need, including hub-spoke routing patterns.
3. Design a Private Endpoint topology that removes public access from PaaS resources and pair it with the right private DNS plumbing.
4. Configure Azure Firewall (Standard / Premium / Basic) for centralised egress filtering, with TLS inspection and IDPS where appropriate.
5. Deploy WAF policies on Application Gateway and Front Door for OWASP protection, bot management, and geo / IP restrictions.
6. Recognise anti-patterns — flat VNet, public PaaS endpoints, no DDoS Network Protection, NSG rules with $0.0.0.0/0$ on admin ports, missing WAF in front of public apps — and rewrite each one.

Building Blocks

NSG (Network Security Group) — Stateful 5-tuple ACL at the NIC or subnet level. Formally, Microsoft.Network/networkSecurityGroups with inbound + outbound rules ordered by priority (100 – 4096, lower = higher priority). It matters because NSGs are the first line of segmentation inside a VNet.

ASG (Application Security Group) — A logical grouping of NICs by application role. Formally, Microsoft.Network/applicationSecurityGroups referenced from NSG rules. Lets rules use ASG names instead of CIDRs. It matters because ASGs make NSG rules readable and decouple them from IP changes.

Azure Firewall — Managed stateful L3/L4/L7 firewall. Tiers Basic / Standard / Premium. Premium adds TLS inspection, IDPS, URL filtering. Sits in a hub VNet; UDRs force spoke egress through it. It matters because Azure Firewall is the canonical egress / inter-spoke filtering point.

Azure DDoS Protection — Network Protection (paid) and Basic (free, always-on). Network Protection adds adaptive tuning, attack analytics, and cost protection. Per-VNet pricing. It matters because basic protects against most volumetric attacks; Network Protection is required for tier-1 workloads.

Azure WAF — Web Application Firewall on Application Gateway or Front Door. Formally, OWASP CRS-based rule sets + custom rules + bot management. Detects SQL injection, XSS, command injection, etc. It matters as the L7 defence layer for HTTP workloads.

Private Link / Private Endpoint — Bring PaaS services onto a private IP in your VNet. Formally, Microsoft.Network/privateEndpoints linking to a resource (storageAccount, sql server, cosmos account, etc.) and a privateDnsZoneGroup for DNS resolution. It matters because Private Endpoint removes the PaaS service from the public internet entirely.

Service endpoint — Older mechanism that adds a VNet attribute to a PaaS service's firewall, restricting access by VNet identity. Subnet-level. Largely superseded by Private Endpoint for new designs but still in use.

Zero Trust — A security philosophy: never trust based on network position; always verify identity. Formally, "assume breach", verify every access request, enforce least privilege. It matters because Zero Trust drives the move from perimeter security to identity-based controls.

Microsoft Defender for Cloud — Continuous security posture management across Azure. Detects misconfigured NSGs, public endpoints, missing DDoS protection, etc. It matters because Defender produces the prioritised remediation backlog that drives ongoing security work.

Deep Dive

1. The defence-in-depth stack

Network security is layered, not single-line. Each layer covers what the others miss.

[!IMPORTANT] Removing any single layer creates a gap. Production architectures should have all six layers in place even if some are minimal (e.g., Defender free tier rather than Defender for Servers), so that no single misconfiguration creates a complete bypass.

2. NSGs and ASGs — segmentation done right

[!TIP] Use ASGs everywhere. Reference roles, not IPs. When a VM moves between subnets, the ASG follows; when an IP changes, the rule still applies.

3. Azure Firewall — egress + inter-spoke control

The hub-spoke pattern places Azure Firewall in the hub VNet; spoke subnets have UDRs that point egress traffic to the firewall's private IP.

[!WARNING] TLS inspection on Premium tier requires distributing a trusted CA to clients. Some workloads (mobile clients with cert pinning) cannot have inspected TLS — exempt them via Firewall rules.

4. WAF on App Gateway and Front Door

Front Door's WAF filters at the edge, before traffic enters the region. App Gateway's WAF filters at the regional boundary. Use both for layered protection on public services.

5. Private Endpoints — removing PaaS from the public internet

The pattern: deploy a Private Endpoint to each PaaS resource; disable public access on the PaaS resource; configure private DNS zone so <account>.privatelink.<service> resolves to the private IP.

[!IMPORTANT] Pair Private Endpoint with publicNetworkAccess: Disabled on the PaaS resource. Otherwise the public endpoint remains an attack surface.

6. DDoS Network Protection — when it's worth the price

Network Protection is per-VNet, so consolidating public IPs in a small number of VNets reduces cost. Cost-protection credits are an underrated benefit — they reimburse scaling charges incurred during DDoS attacks.

7. Zero Trust translation to network controls

8. Hybrid security considerations

Hybrid connectivity introduces shared-trust models. Best practices:

Worked Examples

Easy — segment a web tier from a DB tier

Problem. A web VM scale set must talk to a DB on port 1433; no other ports. Recommend.

Solution. Create asg-web and asg-db ASGs; attach NICs accordingly. NSG rules: allow asg-web $\to$ asg-db on TCP 1433; deny all other inbound to asg-db. Apply NSG at the DB subnet.

Medium — egress filtering for compliance

Problem. A regulated workload must inspect TLS traffic to the internet and block known malicious URLs. Recommend.

Solution. Deploy Azure Firewall Premium in the hub VNet with TLS inspection enabled and IDPS turned on. UDR on every spoke subnet routes $0.0.0.0/0$ to the firewall's private IP. Add URL filtering rules for malicious categories. Spokes use Private Endpoints for PaaS to avoid round-trips through the firewall for trusted Microsoft services.

Hard — public global API with full defence-in-depth

Problem. Tier-1 public API. Requirements: WAF at edge, regional WAF, DDoS protection, private backends, egress filtering, no admin RDP.

Solution. Stack: Front Door Premium (WAF, bot management, DDoS Premium-included) $\to$ regional Application Gateway v$2$ WAF $\to$ private backends with Private Endpoints to PaaS. Egress through Azure Firewall Premium (TLS inspection, IDPS). Admin via Azure Bastion. DDoS Network Protection on the VNet hosting public IPs. Defender for Cloud at Standard tier for posture management.

9. Service endpoints vs Private Endpoints

Both reduce PaaS exposure but differ in their isolation model:

Service endpoints are legacy. Microsoft's recommendation for new workloads is Private Endpoint with publicNetworkAccess: Disabled. Service endpoints remain useful for low-cost, in-VNet-only constraints where private DNS adds operational overhead.

10. virtual network flow logs and Traffic Analytics

A network without observability is a black box. virtual network flow logs capture every allow/deny decision per NIC; Traffic Analytics aggregates them for visualisation.

[!TIP] Enable flow logs everywhere, even if Traffic Analytics is too expensive across the whole estate. Raw flow logs are cheap and become invaluable during incident response.

11. Identity-based perimeter — the modern frontier

Network controls protect against network-layer attacks, but most modern attacks combine network and identity vectors. The modern Zero Trust perimeter sits at identity — Entra ID, managed identities, Conditional Access. Combine network and identity layers:

For tier-1 workloads, both must be tight. Some control planes (Microsoft Defender for Identity, Entra ID Protection) cross between network signals and identity signals to detect compromise patterns invisible from either side alone.

Visual Explanations

Figure 1 — Security architecture decision flow

Figure 2 — Hub-spoke with central firewall

Figure 3 — Quick chooser

Figure 4 — WAF policy rule structure

A typical Front Door WAF policy combines managed rule sets, bot management, and custom rules:

Set the WAF policy mode to Detection initially to log without blocking; review false positives over a one- to two-week observation window; flip to Prevention once the false-positive rate is acceptable. The exam tests the Detection $\to$ Prevention progression.

Figure 5 — Private Endpoint DNS plumbing

Private Endpoints work end-to-end only when DNS resolves the public hostname to the private IP. The plumbing:

1. Create the Private Endpoint $\to$ a private IP appears in the VNet.
2. Create / link a private DNS zone (e.g., privatelink.database.windows.net) to the VNet.
3. Add an A record in the zone mapping <account> to the private IP.
4. On-prem clients: configure conditional forwarders to Azure DNS Private Resolver inbound endpoint.

Without the DNS plumbing in place, clients still resolve the public hostname through public DNS, even though they then send packets to a private IP address. The result varies: TLS errors at best, complete connection failure at worst.

12. Microsoft Defender for Cloud — posture, not just detection

Defender for Cloud has two layers:

For network-security posture, the Secure Score captures NSG misconfigurations, public endpoints, missing WAF, missing DDoS — and drives the prioritised remediation backlog. Run it across all production subscriptions on a regular cadence and feed its recommendations back into the architecture roadmap.

13. JIT VM access — a complementary control

For VMs that must accept admin connections (despite Bastion being preferred), Just-In-Time VM Access (a Defender for Cloud feature) opens NSG rules on demand for a time-bound window. Operators request access; Azure opens RDP / SSH for, say, 3 hours; closes automatically. Combine with Bastion for the strongest pattern: most operators use Bastion for routine work; emergency-access via JIT for the rare cases that need direct NSG opens for diagnostics or vendor support.

Common Mistakes

❌ Myth: "Public endpoints with firewall rules are secure enough." ✅ Reality: Public endpoints are reachable from any internet host. Firewall rules at the PaaS resource limit what reaches it, but the resource is still discoverable. Private Endpoint removes it from the public network entirely.

❌ Myth: "NSGs at subnet are enough — no need for ASGs." ✅ Reality: NSGs by IP are brittle; IPs change. ASGs by role are stable and self-documenting. Use both.

❌ Myth: "DDoS Basic is enough." ✅ Reality: Basic absorbs common volumetric attacks. Network Protection adds adaptive tuning, alerts, cost protection — essentials for tier-1 public workloads.

❌ Myth: "TLS inspection breaks everything." ✅ Reality: TLS inspection breaks workloads with certificate pinning. For everything else, distribute the firewall's CA and inspect. Exempt the cert-pinning workloads via rules.

Practice Exercises

🟢 Exercise 1. Recommend a way to remove a SQL DB from the public internet.

▶✅ Solution

Deploy a Private Endpoint; set publicNetworkAccess: Disabled; configure private DNS zone for privatelink.database.windows.net.

🟡 Exercise 2. A workload needs OWASP rule enforcement at the global edge. Recommend.

▶✅ Solution

Front Door Premium with WAF policy in Prevention mode; enable OWASP $3.x$ rule set and bot management.

🟡 Exercise 3. A regulated workload needs egress IDPS and URL filtering. Recommend.

▶✅ Solution

Azure Firewall Premium with IDPS enabled and URL category-filtering rules. Hub-spoke with UDR force-through.

🔴 Exercise 4. A VM in subnet $A$ should never reach VMs in subnet $B$, but the NSG isn't blocking traffic. Diagnose.

▶✅ Solution

Check NSG rule precedence — a higher-priority allow rule may override the deny. Also check NIC-level NSGs that may override subnet-level. Verify with virtual network flow logs.

🔴 Exercise 5. A team wants Private Endpoint but the PaaS resource still receives public traffic. Diagnose.

▶✅ Solution

publicNetworkAccess is still Enabled. Set to Disabled to fully isolate.

🟢 Exercise 6. True or false: Azure DDoS Basic protects every Azure public IP at no charge.

▶✅ Solution

True. Basic is always-on, no charge. Network Protection adds paid features.

🟡 Exercise 7. Sketch Bicep for an NSG rule referencing two ASGs.

▶✅ Solution

bicepCopy

resource nsg 'Microsoft.Network/networkSecurityGroups@2024-03-01' = { name: 'nsg-app' location: location properties: { securityRules: [ { name: 'AllowWebToApi' properties: { priority: 100 direction: 'Inbound' access: 'Allow' protocol: 'Tcp' sourceApplicationSecurityGroups: [{ id: asgWeb.id }] destinationApplicationSecurityGroups: [{ id: asgApi.id }] destinationPortRange: '443' sourceAddressPrefix: '*' destinationAddressPrefix: '*' } } ] } }

Figure 6 — When Azure Firewall Basic is enough

Azure Firewall Basic is cheaper but limited. It supports L3/L4 filtering, threat intelligence-based filtering, and FQDN filtering only via the threat-intelligence path. It does not support TLS inspection or IDPS.

Basic's 250 Mbps throughput cap makes it unsuitable for any meaningful production workload. Use Basic only for dev/test scenarios where the cost matters more than the security feature set and the throughput cap is acceptable.

Figure 7 — TLS inspection deployment considerations

TLS inspection on Azure Firewall Premium requires several pieces to work together correctly:

The operational overhead of TLS inspection is significant — CA distribution, exemption lists, performance impact — but the security benefit is full visibility into outbound encrypted traffic for content inspection and IDPS pattern matching. Reserve for regulated workloads where the audit requirement justifies the complexity.

Summary & Concept Map

• Defence in depth: six layers — Edge (Front Door WAF + DDoS), Regional WAF (AppGW), Egress (Azure Firewall), Segmentation (NSG/ASG), PaaS (Private Endpoint), Admin (Bastion + PIM).
• NSGs use ASGs for readable, IP-decoupled rules.
• Azure Firewall Premium adds TLS inspection and IDPS for regulated workloads.
• Private Endpoint removes PaaS from the public internet — pair with publicNetworkAccess: Disabled.
• WAF on both Front Door and App Gateway for layered application-layer defence.
• DDoS Network Protection for tier-1 public workloads.
• Zero Trust translates to: verify identity, deny-by-default, assume breach, micro-segment.