AZ-500 Objective 2.1: Plan and Implement Security for Virtual Networks

 • 45 min read • Microsoft Azure Security Technologies

Share:

AZ-500 Exam Focus: This objective covers virtual network security including Network Security Groups (NSGs) with stateful filtering at Layer 4, Application Security Groups (ASGs) for workload-based rules, Azure Virtual Network Manager for centralized topology and security management, user-defined routes (UDRs) controlling traffic flow with next hop types, VNet peering vs VPN gateway for connectivity, Virtual WAN with secured virtual hub and Azure Firewall, VPN security for site-to-site and point-to-site connections, ExpressRoute encryption options (MACsec, IPsec, TLS), and Network Watcher tools including IP flow verify, NSG flow logs, packet capture, and Traffic Analytics for monitoring.

Understanding Azure Network Security

Network security forms the perimeter defense for cloud workloads, controlling traffic flow between resources, from internet to Azure, and between Azure and on-premises networks. Unlike traditional datacenters where physical network infrastructure defines security boundaries, Azure's software-defined networking requires deliberate security controls at every layer. Compromised network security enables lateral movement between resources, data exfiltration to external destinations, and unauthorized access to sensitive workloads. Azure provides comprehensive network security capabilities operating at different layers: Network Security Groups filtering traffic at transport layer based on IPs and ports, Azure Firewall providing stateful network and application-level filtering with threat intelligence, Azure DDoS Protection defending against volumetric attacks, and encryption protecting data in transit.

Effective network security follows defense-in-depth principles implementing multiple overlapping controls. If attacker bypasses one layer, additional controls prevent full compromise. Azure network security strategy includes microsegmentation using NSGs and ASGs to isolate workloads preventing lateral movement, traffic inspection routing through firewalls or network virtual appliances for deep packet inspection, encrypted connectivity using VPN or ExpressRoute with encryption for data confidentiality, secure connectivity through hub-spoke architecture centralizing security controls, and continuous monitoring with Network Watcher detecting anomalies and investigating incidents. This objective explores these capabilities enabling you to design and implement comprehensive network security protecting Azure workloads from network-based attacks while maintaining necessary connectivity for business operations.

Network Security Groups and Application Security Groups

NSG Fundamentals and Rule Processing

Network Security Groups (NSGs) provide distributed stateful packet filtering for Azure virtual networks. Each NSG contains security rules that allow or deny inbound and outbound network traffic based on five-tuple: source IP address, source port, destination IP address, destination port, and protocol (TCP, UDP, ICMP, or Any). NSGs are stateful—if you allow inbound traffic on port 443, the return traffic is automatically allowed without requiring explicit outbound rule. This simplifies configuration and prevents accidental blocking of response traffic. NSGs can be associated with subnets (affecting all resources in subnet) or network interfaces (affecting specific VM), and a single resource can have both subnet-level and NIC-level NSGs applied.

Rule processing follows priority order with rules evaluated from lowest to highest priority number (100-4096). First matching rule takes effect and remaining rules are not evaluated. This means rule order critically impacts effective security posture. Default rules automatically created with every NSG include: AllowVNetInBound (priority 65000) allowing traffic from any source in VNet to any destination in VNet, AllowAzureLoadBalancerInBound (65001) allowing Azure load balancer health probes, DenyAllInBound (65500) denying all other inbound traffic; and for outbound: AllowVNetOutBound, AllowInternetOutBound, DenyAllOutBound. These default rules have lowest priority and can be overridden by creating higher priority custom rules. Security rules support several source and destination types: IP addresses (specific IPv4 or IPv6), CIDR blocks (10.0.0.0/16), Service tags (predefined groups like Internet, VirtualNetwork, Storage, Sql), and Application Security Groups (logical groups of VMs).

Application Security Groups for Workload-Based Security

Application Security Groups (ASGs) enable defining network security based on application architecture rather than explicit IP addresses. Traditional NSG rules specifying IP addresses become maintenance burden as infrastructure scales—every time VM added or IP changes, rules must be updated. ASGs solve this by creating logical containers for VMs based on role or tier. Create ASG named "WebServers", assign web server VMs to that ASG, then create NSG rule allowing HTTP from Internet to WebServers ASG. When new web server deployed, simply add its NIC to WebServers ASG and all applicable rules automatically apply. No NSG rule changes needed. This approach provides several benefits: workload-centric thinking enabling security policies that reflect application architecture, reduced administrative overhead eliminating IP-based rule maintenance, improved documentation with rules describing intent ("allow app servers to database") rather than obscure IP addresses, support for complex scenarios where single VM may be in multiple ASGs, and consistency across environments by reusing ASG-based rule patterns.

Implementing ASG-based security: Create ASGs for each tier or function in your application (web-tier, app-tier, db-tier, management-tier). Assign VM NICs to appropriate ASGs (VM can be in multiple ASGs). Create NSG rules using ASGs as source or destination: "Allow port 443 from Internet to web-tier ASG", "Allow port 8080 from web-tier ASG to app-tier ASG", "Allow port 1433 from app-tier ASG to db-tier ASG", "Deny all other traffic". Rules now express application flow independent of specific IPs. Constraints: ASG and NSG must be in same region, ASGs used in NSG must be in same VNet, NICs assigned to ASG must be in same VNet. Best practices: Align ASG naming with application components, document which resources should be in which ASGs, automate ASG assignment during VM provisioning, combine ASGs with service tags for comprehensive rules, and regularly audit ASG membership ensuring accuracy.

Azure Virtual Network Manager

Centralized Network Management at Scale

Azure Virtual Network Manager addresses challenges of managing connectivity and security across many virtual networks. In traditional model, each VNet managed independently—creating peering relationships, configuring security rules, managing routing—becomes complex and error-prone at scale. Large organizations with hundreds of VNets across multiple subscriptions and regions need centralized approach ensuring consistency and compliance. Virtual Network Manager provides central management plane enabling definition of network topology (hub-spoke, mesh) and security policies once, then deploying to multiple VNets automatically. This eliminates manual configuration of individual VNet peerings, provides consistent security baseline across organization, enables rapid deployment of new VNets inheriting standard configuration, and simplifies troubleshooting through unified topology view.

Virtual Network Manager architecture consists of network manager resource containing configuration, network groups collecting VNets based on static membership or dynamic conditions, connectivity configurations defining how networks connect (hub-spoke or mesh topologies), and security admin rules providing enforced baseline security. Network groups use Azure Policy integration enabling dynamic membership—for example, automatically include all VNets tagged with "Environment:Production" in production network group. Connectivity configurations describe desired topology: hub-spoke with designated hub VNet and spoke VNets connecting to hub (optional spoke-to-spoke through hub), or mesh topology with full mesh peering between all VNets in group. Security admin rules create high-priority security rules that cannot be overridden by local NSG rules, ensuring baseline security regardless of individual resource configurations. This addresses common problem where resource owners inadvertently create NSG rules weakening security posture.

Connectivity and Security Administration

Implementing connectivity configurations: Define hub VNet serving as central connection point for shared services (firewall, VPN gateway, monitoring). Create spoke network group containing VNets that should connect through hub. Configure connectivity specifying direct connectivity between hub and spokes, optional spoke-to-spoke communication through hub, and whether to use existing peerings or create new. Deploy configuration to target regions and Virtual Network Manager automatically creates required peerings. As new VNets added to network group (manually or via dynamic policy), connectivity automatically applied. Security admin rules complement standard NSG rules providing enforced security layer. Create admin rule collection with priority and rules. Rules processed before regular NSG rules ensuring baseline protection. Example: Create admin rule denying RDP from internet with priority 100. Even if resource owner creates NSG rule allowing RDP, the admin rule denies traffic maintaining security baseline. Use cases: Prevent internet-facing RDP/SSH, enforce traffic through central firewall, require specific encryption protocols, block access to known malicious IPs. Security admin rules particularly valuable for compliance requirements needing technical controls preventing configuration drift.

User-Defined Routes

Custom Traffic Routing and Network Control

User-Defined Routes (UDRs) override Azure's default routing behavior enabling custom traffic paths through network. Azure automatically handles routing between subnets, VNets, and to internet, but scenarios requiring custom routing include forcing internet traffic through firewall for inspection, routing traffic through network virtual appliance (NVA) for packet filtering, preventing subnet from accessing internet, and implementing hub-spoke routing patterns. UDRs implemented through route tables containing custom routes associated with subnets. Each route specifies destination address prefix and next hop type: Virtual appliance (routes to specific IP—typically NVA), Virtual network gateway (routes through VPN or ExpressRoute gateway), Virtual network (uses Azure's default routing), Internet (routes through Azure edge), None (drops traffic creating blackhole route).

Common routing scenarios: Force all internet traffic through firewall—create route with destination 0.0.0.0/0 and next hop pointing to firewall internal IP. Associate with subnet containing VMs needing internet access. Now all internet-bound traffic routes to firewall first where security policies apply before allowing to internet. Hub-spoke traffic inspection—in hub-spoke architecture, route spoke-to-spoke traffic through hub firewall rather than direct peering. Create routes in spoke subnets with destination prefixes of other spokes and next hop to hub firewall. Traffic must traverse firewall enabling centralized security policy enforcement. Subnet isolation—prevent specific subnet from accessing internet by creating route with 0.0.0.0/0 destination and next hop None. Traffic dropped at routing layer before attempting internet connection. When implementing UDRs, ensure next hop device has IP forwarding enabled (Azure disables by default for security), configure device's OS to actually forward traffic (routing/firewall rules), plan for asymmetric routing in HA scenarios, and validate routing using Network Watcher's Next Hop tool.

VNet Peering and VPN Gateway

Virtual Network Peering

VNet peering connects Azure virtual networks using Microsoft's backbone network without gateways or public internet. Traffic between peered VNets remains on Azure's private network with extremely low latency (typically under 1ms within same region) and no bandwidth restrictions beyond VM and service limits. Regional peering connects VNets in same Azure region while global peering connects VNets across regions. Peering is non-transitive by default—if VNet A peers to VNet B, and B peers to C, A cannot reach C without direct peering to C. This provides security through explicit connectivity definition. Peering configuration is bidirectional requiring configuration in both VNets but can have asymmetric settings—one direction could allow gateway transit while other doesn't.

Peering features: Allow virtual network access (basic connectivity), allow forwarded traffic (permit traffic from sources outside directly connected VNet like on-premises through VPN), allow gateway transit (one VNet can use other's VPN or ExpressRoute gateway), use remote gateways (use peered VNet's gateway for on-premises connectivity). Gateway transit enables hub-spoke architecture where only hub VNet has expensive VPN/ExpressRoute gateway and spoke VNets use hub's gateway saving costs while maintaining connectivity. Peering considerations: VNets must not have overlapping address spaces, peering created between two VNets doesn't automatically peer other VNets, service chaining requires UDRs directing traffic, and peering charged based on data transfer (ingress/egress pricing varies by region). Benefits over VPN: Much higher performance (no encryption overhead), simple configuration (no gateway deployment), minimal latency, and supports large-scale connectivity. Use peering for Azure-to-Azure connectivity prioritizing performance and simplicity.

VPN Gateway Connectivity

VPN Gateway provides encrypted IPsec/IKE tunnels for site-to-site (on-premises to Azure), VNet-to-VNet (Azure VNet to Azure VNet), and point-to-site (client device to Azure) connectivity. Unlike peering which is unencrypted private connectivity, VPN gateway encrypts traffic but introduces latency overhead from encryption processing and gateway transit. VPN gateway deployed in dedicated GatewaySubnet (minimum /27, /26 or larger recommended) with public IP address for internet connectivity. Gateway SKUs determine throughput, connection count, and features: VpnGw1-5 providing 650 Mbps to 10 Gbps, supporting active-active and BGP. VPN types: Policy-based (static routing, limited to 1 tunnel, legacy devices only) and route-based (dynamic routing, multiple tunnels, modern deployments).

VNet-to-VNet VPN: Creates encrypted tunnel between Azure VNets, useful when encryption required, VNets in different Azure regions where peering not available, or transitive routing needed through gateway. Configuration: Create VPN gateways in both VNets, create connections defining pre-shared key and settings, verify tunnel establishment. S2S VPN for hybrid connectivity: Requires VPN device on-premises (physical firewall or software router) with public IP or FQDN, creates tunnel between on-premises network and Azure. Configuration includes defining local network gateway (represents on-premises network with prefixes and device IP), creating VPN gateway in Azure, establishing connection with shared key, and configuring on-premises device with matching settings. Supports active-active configuration with two public IPs for redundancy, can use BGP for dynamic routing, and integrates with ExpressRoute for backup path. Security: Use strong pre-shared keys, enable IKEv2 protocol, configure strong encryption ciphers, implement NSGs restricting GatewaySubnet access, and monitor gateway metrics and logs.

Virtual WAN and Secured Virtual Hub

Azure Virtual WAN Architecture

Azure Virtual WAN simplifies large-scale branch connectivity and network management through globally distributed Microsoft-managed hub-spoke architecture. Traditional hub-spoke requires manually configuring VPN gateways, peering relationships, routing tables, and firewall rules—complex and error-prone at scale. Virtual WAN automates this with virtual hubs (Microsoft-managed VNets) serving as regional connectivity points, automatically handling VPN gateway deployment, routing configuration, and inter-hub connectivity. Virtual WAN supports any-to-any connectivity: branch-to-Azure, branch-to-branch, Azure VNet-to-VNet, all through centrally managed hubs. Optimized routing uses Microsoft's global network achieving lower latency than internet-based connections between sites.

Virtual WAN components: Virtual WAN resource (top-level container), Virtual hubs (regional Microsoft-managed VNets with built-in gateways), VPN sites (branch office configurations), ExpressRoute circuits (private connectivity), VNet connections (spoke VNets connected to hub), and user VPN configurations (point-to-site). Hub capabilities include S2S VPN gateway (up to 20 Gbps aggregate), ExpressRoute gateway, P2S gateway (100K concurrent users), VNet connections (unlimited), and routing infrastructure handling complex scenarios automatically. Standard Virtual WAN includes all features while Basic supports only VPN. Virtual WAN automatically creates routing enabling traffic between branches, VNets, and on-premises without manual route table configuration. Supports custom routing scenarios through route tables and routing intent when specific traffic flows needed.

Secured Virtual Hub with Azure Firewall

Secured virtual hub integrates Azure Firewall into Virtual WAN hub enabling centralized security policy enforcement for all hub traffic. Traditional hub-spoke requires deploying and managing firewall separately, configuring routing to force traffic through firewall, and maintaining routing tables as topology changes. Secured hub automates this—deploying Azure Firewall in hub, automatically routing inter-hub, spoke-to-spoke, and internet-bound traffic through firewall based on routing intent configuration. Firewall Manager provides central policy management across multiple secured hubs ensuring consistent security posture. Create firewall policy defining network rules (allow/deny based on IP, port, protocol), application rules (FQDN filtering with TLS inspection), threat intelligence rules (block known malicious IPs/domains), and DNS proxy settings. Associate policy with secured hubs applying rules to all traffic traversing hubs.

Routing intent configures automatic routing through firewall: Private traffic intent routes traffic between VNets, branches, and ExpressRoute through firewall. Internet traffic intent routes all internet-bound traffic through firewall. Configure one or both based on requirements. Benefits include central security policy applied consistently, automatic routing eliminating manual UDRs, simplified management through Firewall Manager, integrated threat intelligence protecting all connected sites, and high availability built into platform. Use cases: Global organizations needing consistent security across regions, enterprises with many branches requiring VPN, multi-region Azure deployments needing secure connectivity, and migration from traditional hub-spoke to cloud-native architecture. Cost considerations: Secured hub includes Azure Firewall charges (deployment and data processing), Virtual WAN hub deployment charges, and scale unit charges based on throughput. Evaluate cost against operational benefits and compare to self-managed alternatives.

VPN Security (Site-to-Site and Point-to-Site)

Site-to-Site VPN Security

Site-to-site VPN creates encrypted IPsec/IKE tunnel between on-premises network and Azure, replacing expensive dedicated circuits with internet-based connectivity. Security criticality of S2S VPN—compromise enables attacker access to entire Azure environment or exfiltration of on-premises data. Security configuration starts with protocol selection: Use IKEv2 (more secure than legacy IKEv1), configure Phase 1 (IKE) with strong encryption like AES256 and integrity with SHA256, enable Perfect Forward Secrecy ensuring each session uses unique key, and configure Phase 2 (IPsec) with AES256 encryption and SHA256 integrity. Custom IPsec/IKE policy allows specifying exact algorithms avoiding automatic negotiation potentially selecting weaker ciphers. Authentication uses pre-shared key (minimum 20 random characters) or certificate-based authentication (more secure, recommended for production).

Gateway configuration for security: Deploy VPN gateway in dedicated GatewaySubnet, apply NSG to GatewaySubnet restricting management traffic sources, use VpnGw SKU (not Basic) supporting modern security features, enable active-active configuration for redundancy preventing single point of failure, configure zone-redundancy in supported regions for availability, enable BGP for dynamic routing preventing stale routes, and configure connection monitoring alerting on tunnel failures. On-premises device hardening: Use dedicated VPN appliance (not server with VPN software), keep device firmware updated, implement device admin access controls, configure device logging sending to SIEM, restrict device management to secure network, and maintain backup configuration for recovery. Network security around S2S VPN: Configure NSGs on Azure subnets accessible via VPN restricting which on-premises IPs can access which resources, use Azure Firewall inspecting all VPN traffic applying application and network rules, enable forced tunneling routing all on-premises internet traffic through Azure for monitoring, implement route filtering limiting which on-premises networks can access Azure, and monitor VPN gateway metrics and logs detecting anomalous patterns.

Point-to-Site VPN Security

Point-to-site VPN enables individual users connecting from anywhere to Azure VNet, requiring strong security preventing unauthorized access from compromised client devices. P2S authentication methods: Azure certificate authentication (client certificate validated against root certificate uploaded to gateway)—most secure, eliminates password-based attacks; Azure Active Directory (SAML-based SSO with conditional access)—enables MFA and device compliance requirements; RADIUS authentication—integrates with on-premises identity and MFA systems. Azure AD authentication recommended combining security with user experience—single sign-on eliminates separate VPN credentials, conditional access enforces MFA and device compliance, supports modern authentication protocols, enables certificate-based authentication through Azure AD, and integrates with identity protection detecting risky sign-ins.

P2S protocol selection affects security and compatibility: OpenVPN (SSL/TLS-based, most secure, works through firewalls, supports Windows/Mac/Linux/iOS/Android), IKEv2 (native to macOS/iOS, high performance), SSTP (Windows-only, uses SSL/TLS, works through firewalls requiring less client configuration). OpenVPN recommended for best security and compatibility. VPN configuration security: Enable split tunneling carefully—full tunnel (all client traffic through VPN) more secure but impacts internet performance; split tunnel (only Azure traffic through VPN) better performance but allows potentially compromised client direct internet access. Define address pool separate from on-premises and Azure ranges avoiding overlap. Configure DNS settings directing VPN clients to secure DNS servers. Enable revocation checking for certificate-based authentication immediately blocking compromised certificates. Client security: Use certificate authentication with certificates from trusted CA, enable MFA through Azure AD or RADIUS, configure conditional access requiring compliant devices, implement client firewall rules, keep VPN client software updated, revoke certificates for terminated employees immediately, and implement VPN usage logging. Monitor P2S connections through Azure Monitor viewing connection attempts, failures, and anomalies, configure alerts on failed authentication attempts, review client certificates before expiration, and conduct periodic access reviews of VPN users.

ExpressRoute Encryption

ExpressRoute Security and Encryption Options

ExpressRoute provides private connectivity between on-premises and Azure through dedicated circuit bypassing public internet. Common misconception: ExpressRoute traffic is encrypted by default—it's not. ExpressRoute provides private connectivity and isolation from internet but traffic travels unencrypted unless specifically configured. For regulated industries or sensitive data, encryption required even on private circuits. Three encryption approaches: MACsec (Media Access Control Security) provides Layer 2 encryption between customer edge routers and Microsoft edge routers on ExpressRoute Direct connections. Wire-level encryption with minimal performance impact. Configure through Azure portal or CLI specifying cipher (GcmAes128 or GcmAes256), connectivity association keys, and ensuring both ends have matching configuration. MACsec encrypts all traffic including management protocols. Limitations: Only ExpressRoute Direct (10/100 Gbps ports), not available for provider-based circuits, requires compatible hardware, and both ends must support same configuration.

IPsec VPN over ExpressRoute provides Layer 3 end-to-end encryption creating VPN tunnel over ExpressRoute private peering. ExpressRoute provides reliable private path while IPsec adds encryption. Implementation: Deploy VPN gateway in Azure VNet, configure on-premises VPN device peering with Azure VPN gateway using ExpressRoute private IP addresses (not public internet), establish IPsec tunnel, configure routing directing traffic through tunnel. Benefits: End-to-end encryption independent of circuit provider, works with any ExpressRoute circuit type (not just Direct), customer controls encryption policies and key management, and combines ExpressRoute reliability with VPN encryption. Drawbacks: Additional latency from encryption overhead (typically 2-5ms), throughput limited by VPN gateway SKU (up to 10 Gbps), additional complexity managing VPN configuration, and extra cost for VPN gateway resources. Recommended for scenarios requiring encryption on provider circuits or when end-to-end encryption policy mandated.

Application-Level Encryption and Defense in Depth

Application-level encryption (Layer 7) using TLS/SSL encrypts data within application independent of network transport. Always recommended as defense-in-depth even with network-level encryption. Implementation: Configure applications to use HTTPS for web traffic, enable TLS for database connections (Azure SQL supports TLS 1.2), use encrypted connections for storage (Azure Storage enforces HTTPS), enable encryption for messaging services, and use encrypted protocols for management (SSH not Telnet, HTTPS not HTTP). Benefits: Encryption regardless of network path (works over ExpressRoute, internet, VPN), defense in depth providing protection even if network encryption compromised, application controls encryption keys and policies, and protects data end-to-end from source application through network to destination application.

ExpressRoute security best practices: Implement encryption appropriate for data sensitivity—public data may not need network encryption, confidential data requires multiple layers. Use MACsec for ExpressRoute Direct providing wire-level encryption with minimal overhead. Implement IPsec VPN over ExpressRoute when using provider circuits and encryption required. Always use application-level TLS as baseline defense regardless of network encryption. Combine with network segmentation using NSGs restricting which resources accessible via ExpressRoute. Enable Azure Private Link forcing services traffic through private network. Use Azure Firewall inspecting ExpressRoute traffic applying application and network rules. Configure route filters controlling which prefixes advertised between networks. Enable connection monitoring detecting ExpressRoute failures. Implement redundant circuits (primary and backup) for high availability. Document encryption configuration and key management procedures. Verify compliance requirements—some industries require specific encryption standards. Plan for key rotation and certificate expiration. Monitor ExpressRoute metrics including availability, throughput, and packet counts detecting anomalies.

Configuring Firewall Settings on Azure Resources

Resource-Level Firewall Configuration

Many Azure resources include built-in firewall capabilities providing additional security layer beyond NSGs. Azure Storage accounts include firewall controlling network access to storage services. Configure through Firewalls and virtual networks settings: Allow access from All networks (default, least secure), Selected networks (recommended—specify allowed VNets and IP ranges), or Disabled (private endpoint access only). When using selected networks, add VNet subnets requiring access, specify public IP ranges for on-premises or external access, enable trusted Microsoft services (Azure Backup, Azure Site Recovery) bypassing firewall, and configure resource instances (specific Azure resources allowed access). Storage firewall applies to blob, file, queue, table, and Data Lake Storage. Best practice: Use selected networks with VNet service endpoints or private endpoints eliminating public internet access.

Azure SQL Database firewall rules control access to logical server and databases. Server-level rules apply to all databases on server while database-level rules apply to specific database. Configure server firewall through portal, PowerShell, CLI, or T-SQL specifying rule name and IP range (start and end IP). Allow Azure services toggle enables other Azure resources accessing database—use carefully as allows all Azure IPs not just your resources. Better approach: Use VNet service endpoints or private endpoints restricting access to specific VNets. Azure SQL supports IP-based rules (allow specific public IPs), VNet rules (allow specific subnets), and private endpoints (fully private access). For production, disable public access entirely using private endpoint ensuring all connectivity through private network. Azure Key Vault firewall controls access to secrets, keys, and certificates. Configure through Networking settings: Public endpoint (all networks), Public endpoint (selected networks—specify allowed VNets and IPs), or Private endpoint. Use selected networks or private endpoint for production vaults containing sensitive secrets. Enable trusted Microsoft services bypass for Azure DevOps, App Service, and other services needing vault access.

Network Watcher Monitoring

Network Watcher Diagnostic Tools

Network Watcher provides comprehensive monitoring and diagnostic capabilities essential for security monitoring and troubleshooting. IP flow verify tests whether packet allowed or denied between source and destination, showing which NSG rule made decision. Use for troubleshooting connectivity issues or validating NSG configuration. Specify VM, network interface, protocol (TCP/UDP), local port, remote IP and port, and direction (inbound/outbound). Network Watcher evaluates effective NSG rules returning Allow or Deny with rule name and NSG that caused decision. Next hop determines routing for traffic from VM showing whether traffic routes to Internet, Virtual Network, Virtual Appliance, None, or Virtual Network Gateway. Specify VM and destination IP, Network Watcher returns next hop type and IP address. Use for validating UDRs, troubleshooting routing issues, and ensuring traffic follows expected path.

Connection troubleshoot checks connectivity between VM and destination (another VM, FQDN, URI, or IP address). Performs TCP handshake, measures latency, shows hops in path, identifies where connection fails (NSG, routing, firewall, or application issue). Specify source VM, destination, protocol, and port. Network Watcher returns reachability status, average latency, and hop-by-hop analysis showing where packets dropped. NSG diagnostics evaluates traffic flow through NSG rules without needing actual VM. Specify source/destination IPs, ports, protocol, direction and Network Watcher shows which rules matched and final action (allow/deny). Useful for validating rule changes before implementation or troubleshooting complex NSG configurations. Packet capture records network packets to/from VM for deep analysis. Configure capture duration, packet size, filters (protocol, local/remote IP/port), and storage location (Storage account or VM disk). Capture runs in Azure Monitoring Agent collecting packets matching filters. Download capture file and analyze with Wireshark or other tools identifying specific traffic patterns, protocol issues, or security events.

NSG Flow Logs and Traffic Analytics

NSG flow logs capture information about IP traffic flowing through Network Security Groups, essential for security monitoring, compliance, and forensics. Flow logs record: Source and destination IP addresses, Source and destination ports, Protocol, Traffic direction (inbound/outbound), Action (allowed or denied), Timestamp, and Bytes/packets sent. Flow logs stored in Azure Storage accounts in JSON format. Enable flow logs per NSG (not global setting) specifying NSG, Storage account, retention period, and log version (version 2 recommended including flow state and throughput information). Flow logs capture both allowed and denied traffic providing complete visibility. Analyze denied flows identifying port scans, attack attempts, or misconfigured applications.

Traffic Analytics provides visualization and analysis of NSG flow logs. Enable Traffic Analytics when configuring flow logs selecting Log Analytics workspace. Traffic Analytics processes flow logs providing insights including top talkers (highest traffic sources/destinations), most active hosts, application protocols distribution, geographic traffic patterns, VNet communication patterns, blocked flows analysis, security threat detection (port scans, malware communication), and capacity planning (bandwidth utilization trends). Traffic Analytics dashboard shows: Activity section with traffic volume trends, Environment health (blocked flows, failed connections), Network health (top VMs by traffic), and Security insights (detected threats). Drill into specific traffic flows viewing details like which VMs communicating, which ports, traffic volume over time, geographic locations involved. Use for security monitoring identifying anomalous traffic patterns indicating compromise, compliance demonstrating traffic logging, capacity planning forecasting bandwidth needs, and troubleshooting investigating connectivity or performance issues. Best practices: Enable flow logs on all critical NSGs, use version 2 for additional metrics, configure appropriate retention based on compliance requirements, enable Traffic Analytics for visualization, integrate with Azure Sentinel for security correlation, review traffic patterns regularly establishing baseline, configure alerts on specific traffic patterns, and maintain Log Analytics workspace retention for historical analysis.

Real-World Network Security Scenarios

Scenario 1: Enterprise Hub-Spoke Architecture

Business Requirement: Global enterprise with operations in multiple Azure regions needs centralized network security management, secure connectivity to on-premises datacenters, internet access through central firewall, and microsegmentation between workloads while maintaining high availability and performance.

Azure Solution: Virtual WAN with Secured Hub and Comprehensive Security

  • Virtual WAN Architecture: Create Virtual WAN resource with Standard SKU. Deploy virtual hubs in each region (East US, West Europe, Southeast Asia) serving as connectivity focal points. Enable secured virtual hub in each hub deploying Azure Firewall with Premium SKU for TLS inspection. Configure Firewall Manager policy defining global security rules (allow HTTP/HTTPS to specific FQDNs, deny RDP from internet, block known malicious IPs). Associate policy with all secured hubs ensuring consistent security globally.
  • On-Premises Connectivity: Configure ExpressRoute circuits in each region connecting datacenters to Azure. Create ExpressRoute connections to virtual hub gateways. Implement IPsec VPN over ExpressRoute private peering for end-to-end encryption meeting compliance requirements. Configure backup S2S VPN over internet for redundancy. Enable BGP advertising Azure prefixes to on-premises and on-premises prefixes to Azure automatically.
  • Spoke VNet Configuration: Create spoke VNets for each application (production, development, shared services). Connect spokes to regional hub using VNet connections (automatically creates peering with gateway transit enabled). Spokes inherit hub's connectivity automatically reaching on-premises, internet, and other spokes through hub. Configure routing intent for Private traffic (routing spoke-to-spoke through firewall) and Internet traffic (routing internet-bound through firewall).
  • Microsegmentation with NSGs and ASGs: Create Application Security Groups for workload tiers in each spoke: web-tier, app-tier, db-tier, management-tier. Assign VM NICs to appropriate ASGs during deployment. Create NSG rules using ASGs: Allow HTTPS from Internet to web-tier, Allow port 8080 from web-tier to app-tier, Allow port 1433 from app-tier to db-tier, Allow RDP/SSH from management-tier (jump host) to all tiers, Deny all other traffic. Associate NSGs with spoke subnets (subnet-level for simplified management).
  • Firewall Rules and Policies: Network rules: Allow on-premises ranges to Azure ranges on specific ports, Allow hub-to-hub traffic, Allow required Azure service communication. Application rules: Allow outbound HTTPS to approved SaaS services (Microsoft 365, Salesforce), Block unauthorized cloud services, Inspect outbound HTTPS with TLS inspection detecting malware in encrypted traffic. Threat intelligence: Enable alert and deny mode blocking known malicious actors automatically. IDPS: Enable signature-based detection alerting on attack patterns.
  • User-Defined Routes: Override default routing in specific scenarios: Force all spoke internet traffic through hub firewall (automatic with routing intent but verify), Route management subnet traffic directly to internet bypassing firewall for troubleshooting, Blackhole routes for isolated subnets preventing internet access entirely. Configure route tables and associate with subnets requiring custom routing.
  • Monitoring and Alerting: Enable NSG flow logs on all spoke NSGs streaming to Log Analytics. Enable Traffic Analytics providing visualization and threat detection. Configure Azure Firewall diagnostics sending logs to Log Analytics. Create Network Watcher in each region. Configure alerts: High number of denied flows (potential attack), Traffic from unexpected geographic locations, Connections to known malicious IPs, VPN/ExpressRoute disconnections, Firewall rule processing errors. Integrate with Azure Sentinel for correlation with identity and application security events.
  • Disaster Recovery and High Availability: Active-active configuration with traffic distributed across regions. Automatic failover if regional hub becomes unavailable—Virtual WAN handles routing changes automatically. ExpressRoute redundancy with two circuits per region. Backup VPN connections providing internet-based connectivity if ExpressRoute fails. Zone-redundant firewall deployment within regions protecting against datacenter failures. Test failover quarterly verifying automatic recovery.

Outcome: Globally consistent network security with centrally managed policies, secure connectivity to on-premises with encryption and redundancy, microsegmentation preventing lateral movement within Azure, comprehensive monitoring detecting threats across all regions, and high availability architecture with automatic failover. Security incidents reduced 75% due to centralized firewall and automated threat blocking. Network operations simplified with Virtual WAN automation reducing manual configuration by 80%. Compliance audits streamlined through central policy definition and flow log retention.

Scenario 2: Multi-Tier Application with Defense in Depth

Business Requirement: Healthcare application processing protected health information (PHI) requires maximum security with defense-in-depth, network segmentation, encryption, monitoring, and compliance with HIPAA requiring audit trails and access controls.

Azure Solution: Layered Network Security with Multiple Controls

  • Network Topology: Deploy three-tier architecture with dedicated subnets: Web tier (public subnet with Azure Application Gateway WAF), Application tier (private subnet no internet access), Database tier (private subnet with Azure SQL Private Endpoint), Management tier (bastion host subnet for admin access). Configure Azure Bastion eliminating need for VMs with public IPs—all admin access through Bastion with session recording and MFA.
  • Application Security Groups: Create ASGs: web-servers, app-servers, db-servers, bastion-hosts, healthcare-admins. Assign VM NICs to ASGs based on role. Create granular NSG rules: Allow HTTPS (443) from Internet to web-servers ASG, Allow port 8080 from web-servers ASG to app-servers ASG (application API), Allow port 1433 from app-servers ASG to Azure SQL private endpoint IP, Allow RDP/SSH from bastion-hosts ASG to healthcare-admins ASG (jump host pattern), Deny all other inbound and outbound traffic (whitelist approach).
  • Web Application Firewall: Deploy Application Gateway with WAF v2 in front of web tier. Enable OWASP 3.1 rule set detecting SQL injection, cross-site scripting, remote file inclusion. Configure custom rules blocking requests from specific countries (geofencing) and rate limiting preventing brute force. Enable bot protection identifying and blocking automated attacks. Configure WAF in Prevention mode (not just Detection) actively blocking malicious requests. Send WAF logs to Log Analytics correlating with NSG flow logs and Azure Sentinel.
  • Database Security: Use Azure SQL Database with private endpoint (no public internet access). Configure Azure SQL firewall denying all public access. Enable Advanced Threat Protection detecting anomalous access patterns (unusual locations, principals, applications), SQL injection attempts, and data exfiltration attempts. Enable SQL Audit logging all database operations (DDL, DML, DCL) for HIPAA compliance. Configure transparent data encryption (TDE) protecting data at rest. Enable Always Encrypted for sensitive columns (patient identifiers, diagnosis codes) with keys in Azure Key Vault.
  • VPN for Remote Healthcare Providers: Deploy Point-to-site VPN with Azure AD authentication requiring MFA. Configure conditional access policy: Require MFA, Require compliant device (Intune-enrolled), Block access from non-US IP addresses, Require password change if user risk high. Use OpenVPN protocol for best security and compatibility. Configure full tunnel (all traffic through VPN) preventing remote users accessing public internet while connected. Define VPN address pool separate from Azure and on-premises ranges. Configure NSG rules allowing VPN pool to specific resources only (not blanket access).
  • Encryption in Transit: Enforce HTTPS on Application Gateway terminating TLS 1.2 at gateway. Use TLS 1.2 between Application Gateway and web tier VMs (end-to-end encryption). Configure application servers using TLS for database connections (encrypted even with private endpoint). Use VPN for remote access encrypting all management traffic. Document encryption in transit for compliance proving PHI protected during transmission.
  • User-Defined Routes: Configure route table for application tier forcing all outbound traffic through Azure Firewall deployed in hub VNet. Associate route table with app-tier subnet. Firewall inspects all outbound connections to internet (updates, APIs) with application rules allowing only approved destinations. Deny rule at end blocking all other outbound traffic preventing data exfiltration. Blackhole route for database subnet preventing any outbound traffic to internet (databases should only accept connections, never initiate).
  • Monitoring and Compliance: Enable NSG flow logs with Traffic Analytics on all subnets. Configure log retention 7 years meeting HIPAA requirements. Create alerts: Access to PHI databases outside business hours, Failed login attempts exceeding threshold (brute force), WAF blocking requests (potential attack), VPN access from new location, Firewall denying outbound traffic (potential exfiltration attempt). Generate monthly compliance reports showing: All network access to PHI systems, Denied access attempts and investigation results, Changes to network security configuration, Review of NSG and firewall rules. Integrate logs with Azure Sentinel creating HIPAA workbook showing compliance posture.

Outcome: Defense-in-depth network security with multiple layers protecting PHI: WAF protecting web tier from application attacks, NSGs with ASGs providing microsegmentation, VPN with MFA and conditional access for remote users, encryption in transit at all layers, database private endpoint eliminating internet exposure, comprehensive audit trails for compliance. Zero network security breaches in 18 months. Successful HIPAA audit with no findings related to network security. Reduced attack surface by 90% through private endpoints and NSG controls.

Scenario 3: Secure Branch Connectivity with Virtual WAN

Business Requirement: Retail company with 200 branch stores needs secure VPN connectivity to Azure for point-of-sale systems, inventory management, and reporting. Requires centralized security, simplified management, any-to-any connectivity, and high availability with minimal IT staff at branches.

Azure Solution: Virtual WAN with Automated Branch Connectivity

  • Virtual WAN Setup: Create Virtual WAN resource with Standard SKU. Deploy virtual hubs in two regions (East US primary, West US secondary) for redundancy. Configure S2S VPN gateway in each hub with scale units based on throughput requirements (10 scale units = 2 Gbps aggregate). Enable branch-to-branch connectivity allowing stores to communicate directly through Virtual WAN.
  • Branch VPN Configuration: Each store has SD-WAN device (Cisco Meraki, VMware VeloCloud, or similar) connecting to Virtual WAN. Create VPN sites in Virtual WAN representing each branch with site name, public IP, BGP configuration (if supported), and address prefixes. Download VPN configuration for each site from portal (contains pre-shared keys and connection settings). Deploy configuration to SD-WAN devices through central management console (automated mass deployment to 200 sites). Devices establish tunnels to both hubs providing redundancy.
  • Spoke VNet Architecture: Create spoke VNets for different services: POS-VNet (point-of-sale backend services), Inventory-VNet (inventory management), Reporting-VNet (data warehouse and BI), Management-VNet (jump hosts, monitoring, patch management). Connect all spokes to Virtual WAN hubs. Automatic routing enables stores reaching all spoke VNets through hub and spokes can reach all stores.
  • Secured Hub with Firewall: Convert virtual hubs to secured hubs deploying Azure Firewall Premium. Configure Firewall Manager policy with centralized rules: Network rules allowing branch prefixes to specific services in spoke VNets (port restrictions by service), Application rules allowing POS systems to external payment processors (PCI DSS compliance—only authorized destinations), Threat intelligence blocking known malicious actors, IDPS detecting attack patterns. Configure routing intent forcing all branch traffic through firewall before reaching applications.
  • Microsegmentation for Spoke Resources: Within spoke VNets, implement NSGs with ASGs: POS-backend ASG (database servers for transaction processing), Inventory-api ASG (API servers for inventory updates), Report-services ASG (BI and reporting services), Management-tier ASG (admin jump hosts). Create NSG rules: Allow branches to POS-backend on port 1433, Allow branches to Inventory-api on port 443, Allow branches to Report-services on port 443, Deny direct database access from branches (must go through APIs), Allow Management-tier to all resources on RDP/SSH.
  • Zero Trust Access: Deploy Azure AD Application Proxy for store managers accessing management portal without VPN. Configure conditional access requiring MFA and compliant device. Deploy Azure Bastion in Management-VNet for IT admin access to Azure VMs without VPN. No VMs have public IPs—all management through Bastion with session recording. Configure just-in-time VM access through Microsoft Defender for Cloud opening management ports only when needed for specific time period.
  • Monitoring and Operations: Enable NSG flow logs on all spoke subnets. Configure Network Watcher connection monitors from hubs to branch sites measuring latency, packet loss, and availability—alerts when connectivity degrades. Azure Firewall diagnostics sending logs to Log Analytics. Create monitoring workbook showing: Active VPN tunnels per branch, Bandwidth utilization, Firewall-blocked traffic by branch, Top talkers and destinations, Failed connection attempts. Configure alerts: VPN tunnel down exceeding 5 minutes, Firewall blocking excessive traffic from branch (potential compromise), Unusual traffic patterns (off-hours activity, excessive data transfer), Connection latency exceeding threshold.
  • Disaster Recovery: Each branch maintains tunnels to both regional hubs (East US and West US). If East US hub fails, traffic automatically routes through West US hub without manual intervention. Spoke VNets connected to both hubs. If spoke VNet fails, deploy replacement from ARM template automatically connecting to hubs. Test regional failover quarterly verifying branches maintain connectivity during hub outage. Document failover procedures and recovery time objectives.

Outcome: Simplified branch connectivity with automated VPN deployment eliminating manual configuration for 200 sites. Centralized security through secured virtual hub ensuring consistent policy across all branches. High availability with dual-hub architecture providing automatic failover. Comprehensive monitoring detecting connectivity issues and security threats. Operational overhead reduced 85% compared to previous hub-spoke architecture with manual VPN management. Network incidents reduced 60% through automated monitoring and proactive alerting. PCI DSS compliance maintained through firewall inspection and audit trails.

Exam Preparation Tips

Key Concepts to Master

  • NSGs: Stateful filtering, 5-tuple rules (source IP/port, dest IP/port, protocol), priority processing (100-4096), subnet and NIC association
  • ASGs: Logical VM grouping, rules based on workload not IPs, dynamic membership, same VNet requirement
  • Virtual Network Manager: Centralized management, connectivity configurations (hub-spoke, mesh), security admin rules (enforced baseline)
  • UDRs: Next hop types (Virtual appliance, VNet gateway, VirtualNetwork, Internet, None), longest prefix match, override system routes
  • VNet peering vs VPN: Peering = private, low latency, no encryption; VPN = encrypted, higher latency, gateway required
  • Virtual WAN: Hub-spoke automation, any-to-any connectivity, secured hub with firewall, routing intent
  • VPN types: S2S (on-premises to Azure), P2S (client to Azure), VNet-to-VNet; IKEv2 protocol, certificate or PSK auth
  • ExpressRoute encryption: MACsec (Layer 2, Direct only), IPsec VPN (Layer 3, all circuits), TLS (Layer 7, always use)
  • Network Watcher: IP flow verify, Next hop, NSG flow logs, Traffic Analytics, Packet capture, Connection troubleshoot

Practice Questions

Sample AZ-500 Exam Questions:

  1. Question: What is the primary benefit of using Application Security Groups (ASGs) in NSG rules?
    • A) Faster packet processing
    • B) Rules based on workload instead of explicit IP addresses
    • C) Cross-region rule replication
    • D) Automatic DDoS protection

    Answer: B) Rules based on workload instead of explicit IP addresses - ASGs enable creating security rules based on application architecture rather than managing individual VM IPs.

  2. Question: Which next hop type in user-defined routes (UDRs) drops traffic completely?
    • A) Virtual network
    • B) Internet
    • C) None
    • D) Virtual appliance

    Answer: C) None - Next hop type "None" creates a blackhole route that drops matching traffic.

  3. Question: What is the main difference between VNet peering and VPN gateway?
    • A) Peering provides private connectivity with low latency; VPN provides encrypted connectivity with higher latency
    • B) Peering is free; VPN gateway has costs
    • C) Peering requires gateway; VPN gateway does not
    • D) Peering only works within same region

    Answer: A) Peering provides private connectivity with low latency; VPN provides encrypted connectivity with higher latency - Peering uses Microsoft backbone without encryption; VPN encrypts traffic with gateway overhead.

  4. Question: What feature does secured virtual hub provide in Azure Virtual WAN?
    • A) Automatic VPN tunnel creation
    • B) BGP route advertisement
    • C) Azure Firewall integration with automatic traffic routing
    • D) DDoS protection

    Answer: C) Azure Firewall integration with automatic traffic routing - Secured hub deploys Azure Firewall in Virtual WAN hub with automatic routing through firewall based on routing intent.

  5. Question: Which authentication method is recommended for point-to-site VPN for best security and user experience?
    • A) Pre-shared key
    • B) Azure Active Directory
    • C) RADIUS
    • D) Certificate without MFA

    Answer: B) Azure Active Directory - Azure AD provides SSO, MFA, conditional access, and device compliance checks for best security.

  6. Question: Which encryption option works with all ExpressRoute circuit types (not just Direct)?
    • A) MACsec
    • B) IPsec VPN over ExpressRoute
    • C) BGP encryption
    • D) ExpressRoute encryption

    Answer: B) IPsec VPN over ExpressRoute - IPsec VPN can be configured over any ExpressRoute circuit; MACsec only works with ExpressRoute Direct.

  7. Question: Which Network Watcher tool shows which NSG rule allowed or denied specific traffic?
    • A) Next hop
    • B) Connection troubleshoot
    • C) IP flow verify
    • D) Packet capture

    Answer: C) IP flow verify - IP flow verify tests specific traffic flow and shows which NSG rule caused the allow or deny decision.

  8. Question: What does Traffic Analytics require to provide visualization of NSG flow logs?
    • A) Azure Firewall
    • B) Log Analytics workspace
    • C) Application Insights
    • D) Azure Monitor Workbook

    Answer: B) Log Analytics workspace - Traffic Analytics processes NSG flow logs stored in Log Analytics workspace providing insights and visualization.

AZ-500 Success Tip: Remember NSGs provide stateful filtering with priority-based rule processing—first match wins. ASGs enable workload-based rules simplifying management at scale. Virtual Network Manager provides centralized connectivity (hub-spoke, mesh) and security admin rules (enforced baseline). UDRs control routing with next hop types: Virtual appliance (NVA), VNet gateway (VPN/ExpressRoute), VirtualNetwork (Azure default), Internet (edge), None (drop). VNet peering = fast, private, no encryption; VPN gateway = encrypted, slower, requires gateway. Virtual WAN automates hub-spoke with secured hub integrating Azure Firewall. ExpressRoute encryption: MACsec (Direct only), IPsec VPN (all circuits), TLS (always use). Network Watcher tools: IP flow verify (NSG rule), Next hop (routing), NSG flow logs with Traffic Analytics (monitoring).

Hands-On Practice Lab

Lab Objective

Implement comprehensive virtual network security including NSGs with ASGs, UDRs for traffic control, VNet peering and VPN gateway, resource firewalls, and Network Watcher monitoring tools.

Lab Activities

Activity 1: Create NSG with ASG-based Rules

  • Create resource group: Portal → Resource groups → Create → Name "RG-Network-Security-Lab"
  • Create VNet: Virtual networks → Create → Name "VNet-Lab", Address space 10.0.0.0/16, Subnets: web-subnet (10.0.1.0/24), app-subnet (10.0.2.0/24), db-subnet (10.0.3.0/24)
  • Create ASGs: Application security groups → Create → Names: ASG-Web, ASG-App, ASG-DB in same region as VNet
  • Create test VMs: Deploy one VM in each subnet, assign NICs to respective ASGs during creation (Advanced networking)
  • Create NSG: Network security groups → Create → Add rules using ASGs: Priority 100: Allow port 443 from Internet to ASG-Web; Priority 200: Allow port 8080 from ASG-Web to ASG-App; Priority 300: Allow port 1433 from ASG-App to ASG-DB; Priority 400: Deny all other traffic
  • Associate NSG: Attach NSG to app-subnet and db-subnet (web-subnet can receive internet traffic)
  • Test connectivity: Use IP flow verify validating rules work as expected

Activity 2: Configure User-Defined Routes

  • Create NVA VM: Deploy VM in separate subnet (10.0.10.0/24) to simulate firewall/NVA
  • Enable IP forwarding: VM → Networking → NIC → IP configurations → Enable IP forwarding
  • Create route table: Route tables → Create → Name "RT-App-Subnet"
  • Add routes: Routes → Add → Name "Route-To-Internet", Address prefix 0.0.0.0/0, Next hop type Virtual appliance, Next hop address [NVA internal IP]
  • Associate route table: Subnets → Associate → Select VNet-Lab and app-subnet
  • Verify routing: Network Watcher → Next hop → Select VM in app-subnet, Destination 8.8.8.8 → Should show next hop as Virtual appliance

Activity 3: Implement VNet Peering

  • Create second VNet: Name "VNet-Lab2", Address space 10.1.0.0/16 (non-overlapping)
  • Create peering: VNet-Lab → Peerings → Add → Name "Peer-To-VNet2", Virtual network VNet-Lab2, Allow virtual network access
  • Verify bidirectional: VNet-Lab2 → Peerings → Should show peering from VNet-Lab (automatically created)
  • Test connectivity: Deploy VM in VNet-Lab2, try pinging VM in VNet-Lab (should work after allowing ICMP in NSG)
  • View effective routes: VM NIC → Effective routes → Shows routes for peered VNet

Activity 4: Configure Resource Firewalls

  • Create Storage account: Storage accounts → Create → Standard tier
  • Configure firewall: Networking → Firewalls and virtual networks → Selected networks → Add existing virtual network → Select VNet-Lab, web-subnet
  • Add IP range: Firewall → Add your client IP address (for portal access)
  • Test access: From allowed VNet VM, access storage (should work); From other location, access storage (should be blocked)
  • Create Key Vault: Key Vaults → Create → Standard tier
  • Configure vault networking: Networking → Private endpoint → Create private endpoint in VNet-Lab connecting to Key Vault
  • Disable public access: Networking → Disable public access ensuring only private endpoint access allowed

Activity 5: Enable Network Watcher Monitoring

  • Enable Network Watcher: Automatically enabled per region when first network resource created
  • IP flow verify: Network Watcher → IP flow verify → Select web VM, Protocol TCP, Local port 80, Remote IP 0.0.0.0, Remote port 12345, Direction Outbound → Shows Allow/Deny and rule name
  • Next hop: Network Watcher → Next hop → Select app VM, Destination IP 8.8.8.8 → Shows next hop type (should be Virtual appliance if UDR configured)
  • Connection troubleshoot: Network Watcher → Connection troubleshoot → Source web VM, Destination app VM port 8080 → Shows connectivity status and path
  • Enable NSG flow logs: Network Watcher → NSG flow logs → Select NSG → Configure → Storage account, Version 2, Enable Traffic Analytics, Select Log Analytics workspace → Enable
  • View Traffic Analytics: After ~30 minutes, Traffic Analytics → Overview → Shows top talkers, flows, geography (note: needs time to process logs)

Activity 6: Test and Validate Security Configuration

  • Test ASG rules: From web VM, attempt connection to app VM on port 8080 (should succeed), attempt connection to db VM on port 1433 (should fail—only app tier allowed)
  • Validate UDR: Check VM effective routes confirming 0.0.0.0/0 points to NVA, trace route to internet destination showing NVA as first hop
  • Verify peering: From VNet-Lab VM ping VNet-Lab2 VM confirming cross-VNet connectivity
  • Check flow logs: Storage account → Containers → insights-logs-networksecuritygroupflowevent → View JSON logs showing allowed/denied flows
  • Review documentation: Document lab configuration including NSG rules with ASG associations, UDR next hops, VNet peering configuration, and monitoring setup for future reference

Lab Outcomes

After completing this lab, you'll have hands-on experience with Azure network security controls. You'll understand how to implement NSGs with Application Security Groups for workload-based filtering, configure user-defined routes for custom traffic paths, set up VNet peering for low-latency connectivity, configure resource-level firewalls on Storage and Key Vault, and use Network Watcher tools for troubleshooting and monitoring. These practical skills demonstrate network security capabilities tested in AZ-500 exam and provide foundation for implementing defense-in-depth network security in production Azure environments.

Frequently Asked Questions

What are Network Security Groups (NSGs) and how do they work?

Network Security Groups (NSGs) are fundamental Azure network security capability providing distributed network layer filtering for virtual networks. NSG contains security rules controlling inbound and outbound traffic to Azure resources based on source/destination IP address, port, and protocol. NSGs operate at Layer 4 (TCP/UDP) implementing stateful filtering—if you allow inbound traffic on specific port, return traffic automatically allowed without explicit outbound rule. Each NSG can contain up to 1000 security rules (default limit 200, can be increased). Rules processed in priority order (100-4096, lower number = higher priority) with first matching rule applied, remaining rules skipped. NSG association: Associate with subnet (applies to all resources in subnet), or network interface (applies to specific VM). Resource can have both subnet-level and NIC-level NSGs; inbound traffic processed through subnet NSG then NIC NSG, outbound traffic processed through NIC NSG then subnet NSG. Security rules specify Name, Priority (100-4096), Source (IP address, CIDR, service tag, application security group), Source port ranges, Destination (similar to source), Destination port ranges, Protocol (TCP, UDP, ICMP, Any), Action (Allow or Deny). Default rules created automatically include AllowVNetInBound (allow traffic within VNet), AllowAzureLoadBalancerInBound (allow health probes), DenyAllInBound (deny all other inbound); and AllowVNetOutBound, AllowInternetOutBound, DenyAllOutBound for outbound. Default rules have lowest priority (65000+) and cannot be deleted but can be overridden with higher priority rules. Service tags simplify rule creation—instead of specifying IP ranges, use tags like Internet, VirtualNetwork, AzureLoadBalancer, Storage, Sql, AzureActiveDirectory representing Microsoft services. When using service tags, rules automatically updated when Microsoft changes IP ranges. NSG flow logs capture information about traffic flowing through NSG including allowed and denied traffic, useful for security analysis, compliance, monitoring, and troubleshooting. Best practices: Create NSGs at subnet level for simplified management, use application security groups for workload-based rules, implement deny rules carefully considering existing allow rules, document rule purpose in descriptions, regularly review rules removing unnecessary access, use service tags instead of IP addresses when possible, and enable NSG flow logs for security monitoring.

How do Application Security Groups (ASGs) simplify network security?

Application Security Groups (ASGs) enable organizing virtual machines into logical groups and defining network security policies based on workload patterns rather than explicit IP addresses. Instead of creating NSG rules specifying individual VM IP addresses requiring updates whenever VM added or removed, create ASG representing application tier (web, app, database) and assign VMs to ASG, then create NSG rules using ASGs as source or destination. This approach provides workload-centric security, simplified management, and dynamic scaling. Example: Create ASGs for 'WebServers', 'AppServers', 'DatabaseServers'. Assign VMs to appropriate ASGs based on role. Create NSG rules: 'Allow HTTP from Internet to WebServers', 'Allow port 8080 from WebServers to AppServers', 'Allow port 1433 from AppServers to DatabaseServers'. When adding new web server VM, simply assign it to WebServers ASG and it automatically inherits all NSG rules referencing that ASG. Benefits include logical grouping enabling thinking about application architecture rather than infrastructure, reduced management overhead eliminating need to update rules when VMs added/removed, improved readability with rules describing intent rather than IP addresses, support for complex architectures enabling multiple ASGs per NIC, and consistency across environments reusing ASG-based rules. Implementation: Create ASG in resource group (no additional configuration needed); Assign VM network interfaces to ASG (VM can be in multiple ASGs); Create NSG rules using ASG as source or destination instead of IP addresses; Rules automatically apply to all VMs in ASG. Considerations: ASGs and NSG must be in same region, ASGs referenced in NSG rules must be in same virtual network, VM network interface and ASG must be in same VNet, and each NIC can be associated with up to 3000 ASGs (default 200 can be increased). Best practices: Name ASGs descriptively based on workload (db-tier, web-tier), align ASG strategy with application architecture, document which VMs should be in which ASGs, automate ASG assignment during VM deployment, use ASGs consistently across all NSG rules, combine ASGs with service tags for comprehensive rules, and review ASG membership regularly ensuring accuracy.

What is Azure Virtual Network Manager and what are its benefits?

Azure Virtual Network Manager is centralized network management service enabling consistent policy application and connectivity configuration across virtual networks at scale, particularly valuable in large enterprise environments with hundreds of VNets. Traditional VNet management requires configuring each VNet individually—peering relationships, security rules, routing—becoming complex and error-prone at scale. Virtual Network Manager addresses this through management groups defining scope of networks to manage, network groups collecting VNets based on static membership or dynamic policies, connectivity configurations defining hub-spoke or mesh topologies, and security admin rules applying security policies across network groups. Key capabilities: Centralized management configuring multiple VNets from single location, connectivity management creating hub-spoke or mesh topologies automatically, security administration enforcing security rules that cannot be removed by local admins, policy-based configuration using Azure Policy for automatic compliance, and topology visualization showing network relationships. Connectivity configurations: Hub-and-spoke topology—designated hub VNet with spoke VNets peered to hub, optional spoke-to-spoke connectivity through hub, typical for centralized security and shared services. Mesh topology—all VNets in group directly connected with full mesh peering, suitable for distributed applications needing direct communication. Connected groups—collection of VNets with specific connectivity requirements. Security admin rules supplement NSGs providing enforced security rules at higher priority than regular NSG rules, cannot be overridden by subscription or resource owners, ensure baseline security regardless of individual configurations. Use cases: Global organizations managing networks across regions, enterprises enforcing consistent security posture, multi-subscription environments needing centralized control, and complex hub-spoke architectures requiring automated management. Implementation: Create network manager in subscription, define management scope (subscriptions or management groups), create network groups (static or dynamic membership), define connectivity configurations (hub-spoke or mesh), create security admin rules, deploy configurations to regions. Benefits include reduced operational overhead eliminating manual peering, consistent security through enforced rules, improved governance with centralized policy, faster deployment creating connectivity automatically, and better compliance through auditable centralized management.

Share:

Written by Joe De Coppi - Last Updated November 14, 2025

Previous: Objective 1.2 Manage Microsoft Entra Application Access

Next: Objective 2.2 Plan Implement Security Private Access Azure Resources