Network Security Groups (NSGs) act as a stateful firewall for Azure resources, filtering traffic at either the subnet or NIC (network interface) level. Each NSG contains a set of inbound and outbound security rules. Every rule must include a priority number between 100 and 4096; rules are evaluated from lowest to highest priority, and once a match occurs, no further rules are processed. Because of this evaluation order, you should place explicit Deny rules at a lower priority than broad Allow rules to block specific traffic while permitting the general flow. Service tags simplify rule creation by representing a group of Azure service IP address prefixes, such as VirtualNetwork, Internet, or AzureLoadBalancer, so you do not need to manage changing IP ranges yourself. Using a "deny by default, permit by exception" model ensures that only explicitly allowed traffic passes through the NSG, reducing the risk of unintended access.
Application Security Groups (ASGs) let you group virtual machines by their application role (for example, "web-tier," "app-tier," or "database-tier") without relying on fixed IP addresses. When you reference an ASG as the source or destination in an NSG rule, the rule automatically applies to all VMs that are members of that ASG, even as VMs are added or removed. This logical grouping eliminates the need to update NSG rules whenever the infrastructure scales. ASGs work best when you assign them based on dynamic attributes, such as the workload's function or environment tag, rather than static network location. To enforce least-privilege traffic controls, each application tier should only be able to communicate with the tiers it depends on; for example, the web tier can send traffic to the app tier, and the app tier can send traffic to the database tier, but the database tier should not initiate connections to the web tier.
NSG flow logs capture information about IP traffic flowing through an NSG, including source and destination IPs, ports, protocols, and whether the traffic was allowed or denied. These logs should be sent to Azure Monitor Log Analytics for long-term storage and analysis. Traffic Analytics processes flow log data to visualize traffic patterns, identify top talkers, and detect threat patterns such as port scans or unusual outbound traffic. For quick inventory and validation, use Azure Resource Graph to query NSG and ASG associations, rule priority settings, and rule configurations across your subscription. These monitoring tools help you identify misconfigurations, verify that segmentation policies are working, and troubleshoot connectivity issues before they become security incidents.
Azure Virtual Network Manager uses Azure Policy to automate the application of security and routing rules across many virtual networks at once. You define the rules you want, such as which ports to block or how traffic should be routed, and then assign those rules to logical collections of networks called network groups. This allows you to manage configurations for hundreds of networks spread across different subscriptions and regions from a single place, ensuring consistent security and routing everywhere. After a policy is assigned, it also evaluates all existing virtual networks within its scope, and you must validate that the policy has correctly propagated to all the intended networks.
A key feature is the ability to use conditional statements to define network group membership dynamically. Instead of manually adding each virtual network to a group, you can set a rule, like "all virtual networks with a tag of Environment=Production". Any network that matches this condition is automatically added to the group, and the security and routing policies assigned to that group are instantly applied to it. To automate adding networks to groups, you use a specific Azure Policy effect called addToNetworkGroup. You write a custom policy definition that uses this effect, which automatically adds any virtual network that meets the policy's conditions into a specified network group. For advanced scenarios, you can create Custom policy definitions written in JSON to enforce very precise rules tailored to your organization's needs, going beyond the built-in policy definitions.
Default system routes in Azure let virtual machines communicate with each other within the same virtual network and send internet-bound traffic without any extra setup. When an organization needs to enforce deep security inspection—such as sending all traffic through a firewall or malware scanner—it creates user-defined routes (UDRs) to override the defaults. A user-defined route specifies which traffic destinations the rule applies to through an address prefix, and where that traffic should go through a next-hop type. This override ensures every packet follows the security path the organization requires.
To create a custom route table, you define the traffic you want to control and where it should go. The address prefix tells Azure which destination IP ranges the route affects, such as 10.0.0.0/16 for an entire subnet or 0.0.0.0/0 for all internet traffic. The next-hop type determines the destination for matching traffic. Common next-hop types are VirtualAppliance for sending traffic to a network virtual appliance for inspection, VirtualNetworkGateway for routing traffic to a VPN or ExpressRoute connection, and Internet for forcing egress traffic directly to the public internet. After defining routes in a route table, you assign the route table to one or more subnets to put it into effect. This association overrides Azure's default system routes for that subnet.
To confirm that custom routes are working correctly, use Azure CLI or PowerShell to inspect the effective route table for a virtual machine's network interface. This shows all routes currently affecting that network interface, helping you verify that traffic follows your intended path. When routing traffic through a network virtual appliance (NVA), you must enable IP forwarding on the appliance's network interface card. IP forwarding allows the NVA to accept packets addressed to other destinations and forward them onward. Without this setting enabled, Azure drops any packets sent to the appliance that are not destined for the appliance itself, breaking your user-defined routes.
VNet Peering connects separate virtual networks directly, allowing resources in one network to communicate with resources in another. Traffic flows entirely over the private Azure backbone network, which means it never travels across the public internet. This connection type provides high bandwidth and extremely low latency because it behaves like a single, unified network. You can set up peering across different subscriptions and regions, though you must ensure that the IP address spaces of the connected networks do not overlap.
An Azure VPN Gateway connects virtual networks to other virtual networks or to on-premises environments by using encrypted traffic tunnels. To secure data transit, the gateway establishes connections over the public internet or private lines using standard IPsec/IKE protocols. You can configure a site-to-site VPN to link an entire office building to Azure, or a point-to-site VPN to connect individual employee devices. For high-availability scenarios, a VPN gateway can act as a backup path alongside an ExpressRoute circuit, ensuring that traffic still flows if the primary private line fails.
Choosing between these two connectivity methods depends on your network design, latency limits, and security rules. Choose VNet Peering when you require the highest possible speed and lowest latency for communication within the cloud. Choose a VPN Gateway when you must connect a physical on-premises datacenter or need to encrypt data in transit over a public network path. You can also use a combination of both when building a hub-and-spoke topology, where a central hub contains the gateway and spokes connect to the hub via peering. Both connectivity methods require strong access controls; you can apply Network Security Groups (NSGs) to subnets or individual network interfaces to filter the inbound and outbound traffic passing through the connection.
Azure Virtual WAN is a global transit network service that uses a hub-and-spoke architecture. A secured virtual hub adds a firewall instance, such as Azure Firewall or a partner network virtual appliance (NVA), directly inside the hub to inspect and filter all inter-spoke, branch, and Internet traffic. This approach centralizes security controls and enforces a Zero Trust stance by denying by default and only allowing traffic that matches explicit rules. Virtual hubs connect in a full mesh, providing any-to-any connectivity across branches, VNets, and users.
To protect traffic flows, you deploy Azure Firewall and define a Firewall Policy in Azure Firewall Manager. The policy can be created from scratch, derived from a base, or imported from an existing firewall. Firewall Manager lets you centrally link this policy to multiple secured virtual hubs, ensuring consistent rule sets across regions. Policy-based routing uses hub route tables and routing settings to steer traffic to the firewalls or NVAs. You define custom route tables with routes that specify an address prefix and a next hop (for example, the private IP of Azure Firewall or NVA). Routes are applied to the virtual hub, and connections (spoke VNets or sites) can opt in or out of forced tunneling.
Implementation can be performed via the Azure portal or Azure PowerShell. Secured virtual hubs with policy-based routing and firewall integration offer key benefits: centralized security with uniform policies across all regions, scalability through automated spoke setup, optimized routing by leveraging Azure’s backbone for full mesh connectivity, and compliance via granular traffic inspection and logging.
Azure VPN Gateway enables secure connections from individual client devices to an Azure virtual network, known as a point-to-site (P2S) VPN. You configure this by first creating a route-based VPN gateway and then defining an authentication method, choosing between certificate-based authentication or Azure Active Directory authentication. To strengthen P2S VPN security, using Azure AD authentication allows you to integrate with multifactor authentication and Conditional Access policies. You can also customize the cryptographic protocols used in the VPN tunnel by defining a custom IPsec policy to select specific, strong algorithms for encryption and data integrity.
A site-to-site (S2S) VPN creates an encrypted tunnel between an on-premises network and an Azure virtual network. Implementation requires configuring both the Azure side and the on-premises side. In Azure, you create a Virtual Network Gateway and a Local Network Gateway object, which holds the public IP address and address ranges of your on-premises network. You must ensure your on-premises VPN device is a validated model and is configured with a matching shared key and the same address space definitions. For high availability and better performance, you select a redundant gateway SKU and can enable BGP peering, which allows the two networks to dynamically exchange routing information.
To guarantee a reliable S2S connection, careful configuration and troubleshooting are essential. Traffic selectors must be correctly defined so the VPN gateway knows which subnets' traffic should be sent through the tunnel. If connectivity fails, a structured approach is needed: reset both gateways, verify the shared key matches exactly, and check that no User-Defined Routes (UDR) or Network Security Groups (NSG) are incorrectly blocking traffic on the gateway subnet. You can also monitor VPN tunnel health by checking a specific health probe endpoint on the gateway to detect issues proactively.
MACsec stands for Media Access Control Security, and it protects data as it travels between your on-premises network and Microsoft’s network over ExpressRoute Direct. MACsec works at the data-link layer (Layer 2), which means it encrypts the entire frame before it leaves your router and decrypts it only when it reaches Microsoft’s edge, creating a secure tunnel over the physical connection. To use MACsec, you need two secret values: the Connectivity Association Key (CAK) and the Connectivity Association Key Name (CKN). You store both secrets in Azure Key Vault, which keeps them safe and controls access. You then create a user-assigned managed identity, give it permission to read the secrets from the vault, and link this identity to your ExpressRoute port, allowing Azure to retrieve the keys automatically.
A cipher determines how the encryption math works, and ExpressRoute Direct supports different options depending on your port speed. For 10 Gbps ports, you can choose either GcmAes128 or GcmAes256. For 40 Gbps or faster ports, you have additional options called XPN variants: GcmAesXpn128 and GcmAesXpn256. The XPN ciphers prevent session drops during heavy traffic, so choose these when running at higher speeds. You configure MACsec using PowerShell, Azure CLI, or an ARM template by updating the MacSecConfig properties on each ExpressRoute port, providing the secret identifiers from Key Vault and specifying which cipher to use. After setting these values, you apply the changes and ensure the port's administrative state is enabled.
Once MACsec is running, you verify it works by checking your BGP sessions and ARP resolution. Both require the encryption to be working correctly for neighbors to be reachable and for IP addresses to be resolved. If the CAK, CKN, or cipher settings mismatch between your router and Microsoft, ARP and BGP will fail to establish, and no traffic will flow. For deeper verification, you can capture packets on your own edge devices to confirm data is encrypted, and you can monitor Azure Monitor metrics to track encryption health and spot any failures before they affect users.
An Azure Firewall Policy acts as a top-level resource that defines how traffic is inspected and controlled across your virtual networks. Inside each policy, you organize traffic rules into rule collection groups, which process traffic in a specific order based on their assigned priority. Each group holds rule collections that contain the individual rules used to allow or block traffic. Setting a clear priority and action, such as allow or deny, for every collection establishes a predictable hierarchy for network security.
When building firewall rules, you must choose the right type of rule collection to match your traffic needs. Use DNAT rules for inbound translation to map a public IP address to a private IP address within your network. Use Network rules for layer 3 and layer 4 filtering based on source and destination IP addresses, ports, and protocols. To manage layer 7 traffic, use Application rules to filter connections by fully qualified domain names (FQDNs) and URLs. Enabling diagnostic logging allows you to record firewall events for later analysis. To actively stop malicious actors, turn on threat intelligence in either alert or alert-and-deny mode to detect and block traffic from known malicious IP addresses and domains.
Optimizing your firewall settings ensures that traffic flows quickly and rules remain easy to manage. To minimize processing latency, place your most frequently triggered rules early in their collections so the firewall evaluates them first. You can use policy analytics to identify unused or conflicting rules and receive automated recommendations for cleaning up your policies. Grouping similar IP ranges into IP Groups helps you avoid reaching rule limits, while adding multiple public IPs prevents SNAT port exhaustion. Finally, implement web categories for bulk URL filtering to control access to large classes of websites with minimal effort.
Network Security Group (NSG) flow logs record information about IP traffic that passes through an NSG. The logs are written in JSON format and include the source and destination IP addresses, ports, protocol, the network interface (NIC) involved, and whether the traffic was allowed or denied. Azure Network Watcher enables these logs by associating an NSG with a diagnostic setting and directing the output to a storage account or a Log Analytics workspace. This data gives a high-level view of traffic volumes and which rules are being hit, helping you identify which connections are succeeding and which are being blocked.
Packet capture sessions let you collect raw network traffic for deeper, packet-by-packet inspection. To configure a packet capture, you need an Azure subscription with Network Watcher enabled, a virtual machine that has the Network Watcher agent extension installed, and a storage account accessible from the VM’s subnet to store the capture files. You can start a capture in the Azure portal, Azure CLI, or PowerShell, specifying the target VM, filters such as IP address or port, and a storage location. After collecting NSG flow logs and packet captures, you analyze them together to detect unauthorized connections and anomalous traffic patterns. NSG flow logs provide a broad overview, while packet captures offer granular details about individual packets. Integrate these insights with Azure Monitor or Traffic Analytics for continuous threat detection and faster incident response.
Are you a guardian of your domain? Lean how to leverage your aptitude in security to protect Microsoft Azure technologies, with a goal of earning the Microsoft Certified: Azure Security Engineer Associate certification!
Prepare and test your skills
Prepare and test your skills
Each NSG rule must include a priority number between 100 and 4096. Rules are evaluated from lowest to highest priority, and once a match occurs, no further rules are processed.
Application Security Groups (ASGs) let you group virtual machines by their application role without relying on fixed IP addresses. When you reference an ASG as the source or destination in an NSG rule, the rule automatically applies to all VMs that are members of that ASG, even as VMs are added or removed.
VNet Peering connects separate virtual networks directly over the private Azure backbone network, providing high bandwidth and extremely low latency. A VPN Gateway connects virtual networks to other virtual networks or on-premises environments using encrypted traffic tunnels over the public internet or private lines with IPsec/IKE protocols.
MACsec stands for Media Access Control Security, and it protects data as it travels between your on-premises network and Microsoft's network over ExpressRoute Direct. MACsec works at the data-link layer (Layer 2), encrypting the entire frame before it leaves your router and decrypting it only when it reaches Microsoft's edge.
StudyCerts
StudyCerts