Network Security Architecture

Network Security in the Zero Trust Era

Traditional network security relied on perimeter defence — a corporate firewall separating the trusted internal network from the untrusted internet. In cloud and hybrid environments, this model breaks for three reasons:

1. There’s no perimeter. Resources are in Azure, AWS, on-premises, SaaS apps, and employee homes.
2. East-west traffic is the real risk. Once an attacker is inside the network, lateral movement is how they reach valuable targets. Perimeter firewalls don’t inspect traffic between internal resources.
3. PaaS services are internet-accessible by default. An Azure SQL Database has a public endpoint. A Storage Account is reachable from the internet. The perimeter never protected these.

The security architect’s job is to design a network architecture where:

• Every traffic flow is explicitly authorised
• North-south traffic (internet ↔ internal) is inspected
• East-west traffic (internal ↔ internal) is segmented and controlled
• PaaS services are accessible only through private networks
• All traffic is logged and analysed

Segmentation: NSGs, ASGs, and Subnets

Network Security Groups (NSGs)

NSGs are stateful packet filters that control traffic to and from Azure resources. They contain inbound and outbound rules that allow or deny traffic based on:

• Source/destination IP addresses or ranges
• Source/destination ports
• Protocol (TCP, UDP, ICMP)

NSGs can be applied at two levels:

• Subnet level — Rules apply to all resources in the subnet
• NIC level — Rules apply to a specific network interface

Architect’s principle: Apply NSGs at the subnet level for baseline security (deny by default), and at the NIC level only for exceptions.

Application Security Groups (ASGs)

ASGs solve the management problem with NSGs. Instead of writing rules with IP addresses (which change as you scale), you create logical groups:

• Web servers → “WebServers” ASG
• Application servers → “AppServers” ASG
• Database servers → “DBServers” ASG

Then rules become:

• Allow TCP 443 from Internet to WebServers
• Allow TCP 8080 from WebServers to AppServers
• Allow TCP 1433 from AppServers to DBServers
• Deny everything else

When a new VM is created and added to the “AppServers” ASG, it automatically inherits the correct network rules. No IP-based rule updates needed.

Subnet Design

Subnets define trust boundaries within a VNet. The architect designs subnets to align with workload tiers and security zones:

• Web tier subnet — Internet-facing resources, NSG allows inbound 443
• Application tier subnet — Only reachable from web tier
• Data tier subnet — Only reachable from application tier
• Management subnet — Jump boxes, Bastion hosts, restricted access

Traffic Inspection: Azure Firewall vs NSGs

This is a critical architectural decision: when to use NSGs and when to use Azure Firewall.

NSGs vs Azure Firewall: When to Use Each

Characteristic	Network Security Groups (NSGs)	Azure Firewall
Traffic direction	East-west (between subnets/VNets)	North-south (internet) + east-west (centralised)
Inspection level	L3/L4 (IP, port, protocol)	L3/L4 + L7 (FQDN, URL, application rules)
Threat intelligence	❌	✅ Microsoft threat intel feed
TLS inspection	❌	✅ (Premium SKU)
IDPS	❌	✅ (Premium SKU — intrusion detection/prevention)
FQDN filtering	❌	✅ Allow/deny by domain name
Logging	Virtual network flow logs (IP/port level)	Structured diagnostic logs with full context
Cost	Free (included with VNet)	Per-hour + per-GB processed
Scale	Platform-managed, unlimited	Scales within SKU limits
Typical use	Microsegmentation within subnets	Centralised inspection for all traffic
Design guidance	Apply to every subnet as baseline	Deploy in hub VNet for centralised policy

The Hub-Spoke Architecture for Security

The hub-spoke topology is the standard network architecture for security-conscious Azure deployments:

Hub VNet — Contains shared security services:

• Azure Firewall — inspects all traffic between spokes and to/from the internet
• Azure Bastion — secure management access without exposing RDP/SSH
• VPN Gateway or ExpressRoute Gateway — hybrid connectivity
• DNS servers

Spoke VNets — Contain workloads:

• Each workload or environment (production, staging, dev) gets its own spoke VNet
• Spokes are peered to the hub
• User-defined routes (UDRs) force all traffic through the hub’s Azure Firewall

Why this matters for security: All traffic between spokes must transit the hub Firewall. There’s no direct spoke-to-spoke communication without inspection. This gives the security team a single point to enforce policy, log traffic, and detect threats.

Virtual WAN is Microsoft’s managed alternative to hub-spoke. It provides the same security architecture with less manual configuration — routing, peering, and Firewall integration are built in. The trade-off is less customisation.

Private Endpoints: Eliminating Public Exposure

This is one of the most important network security concepts for SC-100. By default, Azure PaaS services (Storage, SQL Database, Key Vault, Cosmos DB) have public endpoints accessible from the internet. Private endpoints change this.

A private endpoint creates a private IP address in your VNet for the PaaS service. Traffic from your VNet to the PaaS service stays on the Microsoft backbone network — it never traverses the public internet.

Why this matters architecturally:

• The Storage Account no longer has a public IP. There’s nothing to attack from the internet.
• Data exfiltration through PaaS services is prevented — you can configure Private Link to restrict which Storage Account a resource can connect to.
• Traffic is encrypted and stays within the Microsoft network.

Architect’s design pattern:

1. Create private endpoints for all PaaS services in production
2. Disable public access on those PaaS services
3. Configure Private DNS Zones for name resolution (so mystorageaccount.blob.core.windows.net resolves to the private IP, not the public one)
4. Use Azure Policy to deny creation of PaaS services without private endpoints in production subscriptions

Network Monitoring and Analytics

Network Watcher

Network Watcher provides network diagnostic and monitoring tools:

• Connection troubleshoot — test connectivity between resources
• IP flow verify — check if NSG rules allow or deny specific traffic
• Next hop — determine where traffic will be routed
• Packet capture — capture network traffic on VMs for analysis

Virtual Network Flow Logs

Virtual network flow logs (the successor to NSG flow logs, which are being retired) record all network flows at the virtual network level. They’re essential for:

• Security auditing — who connected to what, when
• Forensic investigation — what traffic occurred before/during an incident
• Compliance — prove network access is properly controlled

Virtual network flow logs should be enabled and sent to a Storage Account for retention and to Log Analytics for analysis.

Traffic Analytics

Traffic Analytics processes virtual network flow logs to provide:

• Visual map of traffic flows between VNets and subnets
• Identification of top talkers (highest bandwidth consumers)
• Detection of allowed traffic to open ports that shouldn’t be open
• Geographic analysis of internet traffic sources

DDoS Protection

Azure provides two tiers of DDoS protection:

DDoS Network Protection — Applied to VNets. Provides:

• Always-on traffic monitoring
• Automatic attack mitigation tuned to your application’s traffic patterns
• Attack analytics and telemetry
• Cost protection (credit for scale-out costs during an attack)
• Rapid response support from Microsoft’s DDoS team

DDoS IP Protection — Applied to individual public IPs. Simpler pricing model, same platform protection but without the analytics, cost protection, or rapid response support.

Architect’s decision: DDoS Network Protection for production VNets with internet-facing workloads. DDoS IP Protection for smaller deployments or individual resources where the full plan isn’t cost-justified.

☁️ Scenario: Rajan’s Hub-Spoke Network Design

Rajan is designing the Azure network architecture for a healthcare company with strict HIPAA requirements. The company runs three workloads: a patient portal (internet-facing), an electronic health records (EHR) system (internal), and a data analytics platform.

“Every packet between workloads must be inspected,” Rajan tells Priya Anand. “HIPAA requires we can demonstrate that access to patient data is controlled and logged.”

Hub VNet (10.0.0.0/16):

• Azure Firewall Premium (TLS inspection and IDPS enabled) in AzureFirewallSubnet
• Azure Bastion for secure management access
• ExpressRoute Gateway connecting to the company’s on-premises data centre

Spoke 1 — Patient Portal (10.1.0.0/16):

• Web subnet (10.1.1.0/24) — Application Gateway with WAF
• App subnet (10.1.2.0/24) — Application servers
• NSG on web subnet: allow HTTPS from Application Gateway only
• NSG on app subnet: allow 8080 from web subnet only
• UDR: all traffic → hub Firewall

Spoke 2 — EHR System (10.2.0.0/16):

• Application subnet (10.2.1.0/24)
• Database subnet (10.2.2.0/24)
• Private endpoints for Azure SQL Database in the database subnet
• NSG on database subnet: allow SQL from application subnet only
• UDR: all traffic → hub Firewall

Spoke 3 — Analytics (10.3.0.0/16):

• Compute subnet (10.3.1.0/24)
• Private endpoints for Storage Account and Synapse Analytics
• NSG: allow access from EHR spoke only (read-only access to anonymised data)

“Notice what’s happening,” Rajan explains to Deepak Malhotra. “The patient portal can’t talk directly to the EHR system. The analytics platform can’t access the patient portal. Every cross-spoke flow goes through the hub Firewall where we log, inspect, and enforce policy. If the patient portal is compromised, the attacker hits a wall between spokes.”

💰 Scenario: Ingrid’s Private Endpoint Strategy

Ingrid Svensson at Nordic Capital Partners has a different challenge. The company’s Azure SQL databases contain financial transaction data regulated by the Financial Conduct Authority. The regulator requires that no financial data traverses the public internet — even encrypted.

“Private endpoints aren’t optional for us,” Ingrid tells Harald Eriksen, the compliance officer. “They’re a regulatory requirement.”

Ingrid’s design:

1. Private endpoints for every PaaS service: Azure SQL, Storage Accounts, Key Vault, Azure Data Factory — all get private endpoints in their respective VNets.
2. Public access disabled: After private endpoints are created, public access is explicitly disabled on each service. Even if someone misconfigures a firewall rule, there’s no public endpoint to reach.
3. Private DNS Zones: Ingrid deploys Azure Private DNS Zones linked to all VNets. When an application resolves nordiccapital-sql.database.windows.net, it gets the private IP (10.2.2.4), not the public one.
4. Azure Policy enforcement: A policy definition denies creation of Storage Accounts, SQL databases, and Key Vaults without private endpoints. This is prevention, not detection — non-compliant resources can’t be created in the first place.
5. Virtual network flow logs + Traffic Analytics: Yuki Tanaka, the IAM lead, requested evidence that database traffic stays within the private network. Traffic Analytics provides visualisation showing all SQL traffic flows between private endpoints — zero internet-bound database traffic.

“When the FCA auditor asks ‘Can this data leave your private network?’, I can show them the architecture and the traffic analytics data,” Ingrid tells Harald. “The answer is a verifiable no.”

Exam Strategy: Network Security Questions

Network security is a dense topic for SC-100. Focus on architectural decisions, not configuration details:

• “Inspect traffic between workloads” → Azure Firewall in a hub VNet with UDRs forcing traffic through it. Not NSGs — they filter but don’t inspect at L7.
• “Eliminate public exposure of PaaS services” → Private endpoints with public access disabled. Look for this pattern in any question mentioning sensitive data in PaaS.
• “Microsegmentation” → NSGs with ASGs at the subnet level. This is east-west (lateral movement) control.
• “DDoS protection for internet-facing app” → DDoS Network Protection on the VNet. If cost is a concern, DDoS IP Protection on specific IPs.
• “Centralised security policy for multiple workloads” → Hub-spoke with Azure Firewall in the hub. Or Virtual WAN with Secured Hub.
• “Compliance requires traffic logging” → Virtual network flow logs + Traffic Analytics. These provide the evidence trail.
• “TLS inspection” → Azure Firewall Premium. Standard SKU doesn’t support TLS inspection.
• Watch for questions about DNS with private endpoints — if private DNS isn’t configured correctly, applications resolve to the public IP and bypass the private endpoint. The architecture must include Private DNS Zones.

Question

In a hub-spoke topology, why must user-defined routes (UDRs) force spoke traffic through the hub Firewall?

Click or press Enter to reveal answer

Answer

Without UDRs, spoke VNets can communicate directly through VNet peering — bypassing the Firewall entirely. UDRs override the default routing by setting the hub Firewall's private IP as the next hop for all traffic. This ensures every packet between spokes (east-west) and to/from the internet (north-south) is inspected, logged, and subject to Firewall policy.

Click to flip back

Question

What's the difference between NSGs and Azure Firewall, and when do you use each?

Click or press Enter to reveal answer

Answer

NSGs are L3/L4 filters (IP, port, protocol) — use them on every subnet for microsegmentation baseline. They're free and platform-managed. Azure Firewall is L3-L7 with FQDN filtering, threat intelligence, TLS inspection, and IDPS — use it in the hub VNet for centralised traffic inspection. NSGs are distributed per-subnet controls; Azure Firewall is centralised policy enforcement. Use both together.

Click to flip back

Question

Why are private endpoints architecturally significant for PaaS security?

Click or press Enter to reveal answer

Answer

PaaS services (SQL, Storage, Key Vault) have public endpoints by default. Private endpoints create a private IP in your VNet, so traffic stays on the Microsoft backbone. Combined with disabling public access, the PaaS service is unreachable from the internet — there's no attack surface. This is the single most impactful network security control for Azure PaaS workloads.

Click to flip back

Question

What does Azure Firewall Premium add over Standard that matters for security architecture?

Click or press Enter to reveal answer

Answer

Two critical capabilities: 1) TLS inspection — decrypts, inspects, and re-encrypts HTTPS traffic so threats hidden in encrypted connections are detected. 2) IDPS (Intrusion Detection and Prevention System) — signature-based detection of known exploits and malicious traffic patterns. Premium is required when compliance mandates inspection of encrypted traffic or when advanced threat detection at the network layer is needed.

Click to flip back

Knowledge Check

A company runs a web application in Azure with an Application Gateway (WAF), application VMs in a subnet, and an Azure SQL Database. The security team wants to prevent the SQL Database from being accessible from the internet while ensuring the application VMs can still connect. What architecture should the security architect design?

AA. Configure the SQL Database firewall to allow only the application subnet's IP range and deny all other trafficBB. Create a private endpoint for the SQL Database in the application subnet, disable public access on the database, and configure a Private DNS Zone for name resolutionCC. Deploy Azure Firewall between the application VMs and the SQL Database to filter trafficDD. Use an NSG on the application subnet to block outbound traffic to the SQL Database's public IP from all sources except the application VMs

Check Answer

Knowledge Check

An organisation is deploying three separate workloads across Azure: a customer-facing web app, an internal API, and a data warehouse. The security team requires that all traffic between workloads is inspected and logged, and no workload can directly communicate with another without passing through a security inspection point. What network topology should the security architect recommend?

AA. Deploy all three workloads in a single VNet with NSGs between subnetsBB. Deploy each workload in a separate spoke VNet peered to a hub VNet containing Azure Firewall, with UDRs routing all inter-spoke traffic through the FirewallCC. Deploy each workload in a separate VNet with direct peering between all three VNets and NSGs on each subnetDD. Deploy all three workloads in separate subscriptions with no VNet peering, using public endpoints for inter-workload communication

Check Answer

Knowledge Check

A security architect needs to implement network monitoring that provides evidence for compliance audits showing which resources communicated with which, when, and on what ports. The solution must also identify unusual traffic patterns. What combination of tools should be deployed?

AA. Azure Firewall logs only — they capture all traffic flowing through the FirewallBB. Virtual network flow logs sent to Log Analytics, with Traffic Analytics enabled for visualisation and anomaly detectionCC. Network Watcher packet capture running continuously on all VMsDD. Azure Monitor metrics for network throughput on each VNet

Check Answer

🎬 Video coming soon

---

Next up: Security Service Edge: Internet and Private Access — move beyond network perimeter security to identity-based, cloud-delivered network controls with Microsoft Entra Internet Access and Private Access.