Secure Native Access to Azure Kubernetes Service (AKS) Private Clusters with Azure Bastion
Written in Collaboration with AvirupChat ShabazShaik Mohit_Kumar YuriDiogenes Introduction: As organizations move toward containerized workloads such as Azure Kubernetes Service (AKS), secure access to cluster resources becomes critical. Making the Kubernetes API server private, therefore, significantly reduces the attack surface. However, it also changes how engineers perform routine management tasks. Operations as simple as running kubectl logs, describing resources, or troubleshooting workloads require connectivity to the virtual network hosting the cluster. This challenge becomes even more apparent during day-to-day operations. An engineer may have the necessary Kubernetes credentials and Azure RBAC permissions yet still be unable to access the cluster because the API server is reachable only from within the private network. Establishing VPN connectivity, using jump hosts, or deploying dedicated management workstations often becomes part of the operational workflow, adding complexity to what should be straightforward administrative tasks. This balance between maintaining strong network isolation and enabling efficient cluster management is exactly what Azure Bastion's native client tunneling support for private AKS clusters is designed to address. Many Azure customers already use Azure Bastion to securely access virtual machines without exposing them to the public internet. Native client tunneling now brings that same secure access model to AKS private clusters. This capability is in public preview currently. Before discussing how it works, it is worth understanding the operational challenges it is designed to solve and how it's done. Bastion for Azure Kubernetes Service (AKS) private clusters: At its core, Azure Bastion is designed to simplify secure access to private Azure resources. Since its launch, it has provided browser-based and native client RDP and SSH connectivity to Azure VMs without exposing management ports to the internet. No public IPs on your VMs. No inbound NSG rules for port 22 or 3389. Just TLS over port 443, routed through a fully managed service that Microsoft patches, scales, and secures on your behalf. When you establish a Bastion tunnel to your private AKS cluster, you are not signing in to an intermediary machine and running kubectl from there. You are opening an encrypted tunnel from your local machine, through Bastion, directly to the private API server endpoint. Your kubeconfig points to localhost on a dynamically assigned port, so local kubectl, helm, and scripts continue to work as they would against a public cluster. You get the developer experience of a public cluster with the security posture of a private one as shown in Figure 1. The high-level flow has three parts: The engineer authenticates to Azure, retrieves cluster credentials, and uses Azure Bastion to establish a managed tunnel into the private network. Local Kubernetes tools then use that tunnel to reach the private API server. This keeps the workflow familiar while removing the need for jump hosts or VPN-based access paths. However, this raises an important question - Does making access easier also make it easier for an attacker to connect? The short answer is no. In fact, Bastion tunneling strengthens the security posture in ways that are worth unpacking. First, the API server itself remains private. There is no public endpoint. There is no public IP address discoverable by scanners. The only network path to the API server runs through Azure's managed infrastructure. Authentication and authorization then depend on the AKS cluster configuration. Second, Bastion eliminates an entire class of infrastructure that itself becomes a security target. Jump box VMs, when not meticulously maintained, accumulate credentials, kubeconfig files, and browser sessions. They are machines that admins log into, which means they are machines that can be compromised. Bastion is not a machine you log into. It is an agentless, managed tunnel you pass through. And for public clusters, there is a related but distinct benefit. Many teams use API server authorized IP ranges to restrict which source IPs can reach their public API endpoint. This is a good practice, but it breaks down quickly when your team works remotely, uses dynamic IPs, or includes contractors. Adding Bastion's stable public IP to the authorized range gives you a consistent, managed access path without the operational toil of constantly updating IP allow lists. With the network path established through Bastion, the next question is how users are authenticated and authorized once they reach the AKS API server. That distinction matters: Bastion provides secure connectivity, while AKS access is governed by the authentication and authorization model configured on the cluster. Authentication and authorization options: When creating an AKS cluster, you can choose from three authentication and authorization modes, as shown in Figure below. That choice shapes everything about how access is granted, audited, and governed over the lifetime of the cluster. ⚠️Local accounts with Kubernetes RBAC is the default if you change nothing. It uses a static certificate that never expires, is shared across all administrators, and has no connection to your corporate identity provider. There is no MFA. No Conditional Access. Note: For most production environments, Microsoft recommends using Microsoft Entra ID integrated authentication rather than local accounts to enable centralized identity, MFA, and auditing. ☑️ Microsoft Entra ID with Kubernetes RBAC moves authentication to Entra ID, which means users sign in with their corporate identity, MFA is enforced, and Conditional Access policies apply. Authorization is handled through native Kubernetes Role and ClusterRole bindings, which reference Entra ID users and groups as subjects. This works well for teams that manage cluster configuration through GitOps, because RBAC manifests live alongside other cluster YAML. The limitation is that these permissions are invisible in Azure IAM — they live only inside the cluster. ✅ Microsoft Entra ID with Azure RBAC is the model we recommend for most production environments. Authentication still flows through Entra ID with full MFA and Conditional Access support. But authorization is handled by Azure RBAC role assignments on the AKS resource itself. Permissions are visible in Azure IAM, participate in access reviews, and integrate with Privileged Identity Management for just-in-time elevation. You can assign the built-in Azure Kubernetes Service RBAC Cluster Admin, Admin, Writer, or Reader roles at either cluster scope or namespace scope. A single subscription-level role assignment can grant access to every cluster in the subscription. The real value is the combination. Bastion provides the encrypted network tunnel. Entra ID provides the identity, MFA, and Conditional Access. Azure RBAC provides centralized, auditable authorization that your security team can review alongside every other Azure resource. For the exact steps to configure Entra ID authentication and Azure RBAC on your AKS cluster, see the AKS identity documentation. End-to-end flow for connectivity to AKS via Bastion: az account set --subscription <subscription ID> Retrieve credentials to your AKS private cluster using the commands below: az aks get-credentials --name <AKSClusterName> --resource-group <ResourceGroupName> Open the tunnel to your target AKS Cluster with the following command: az aks bastion --name <aksClusterName> --resource-group <aksClusterResourceGroup> --bastion <bastionResourceId> Now the default authentication method is Device code authentication i.e., this authentication method prompts the device code for the user to sign in from a browser session. If you want CLI only authentication, you can run the following command next. kubelogin convert-kubeconfig -l azurecli Then go on with your AKS connectivity: kubectl get nodes How to Try It: If you are already running private AKS clusters, getting started is straightforward. You need a Standard or Premium Azure Bastion host deployed in the same VNet as your cluster (or in a peered VNet), with native client support enabled. The aks-preview and bastion CLI extensions handle the rest. The detailed connection steps are documented on Microsoft Learn. We Want Your Feedback Write a comment in this blog or open an issue on the AKS GitHub repository or leave feedback directly on the Microsoft Learn documentation page. We read everything, and it genuinely influences what we prioritize.
Designing Cloud Landing Zones by Traffic Flow: A Defence‑in‑Depth, DMZ‑First Architecture
As enterprises adopt Microsoft Azure for large‑scale and regulated workloads, security architecture must be driven by traffic trust boundaries and inspection intent, not connectivity alone. Regulatory frameworks consistently require a clear separation between Internet‑untrusted and private enterprise traffic, enforced through defence‑in‑depth controls aligned to the OSI model. This drives the adoption of a DMZ‑first landing zone architecture, where volumetric protection, application‑layer inspection, and perimeter controls are enforced at well‑defined trust boundaries. Security enforcement is prioritised before access, rather than being an afterthought of connectivity. A distributed hub architecture enables this model at scale, delivering consistent controls while improving resiliency, fault isolation, and operational clarity. Traffic Classification in an Enterprise Landing Zone Enterprise traffic flows are classified based on origin, destination, and trust level, which directly dictates inspection requirements: Internet Inbound (North–South): Traffic from the public Internet to Azure‑hosted applications Internet Outbound (South–North): Egress traffic from private workloads to the Internet East–West: Traffic between virtual networks within or across regions Hybrid Connectivity: Traffic between Azure, on‑premises, and multi‑cloud environments Each flow presents a distinct risk profile, making a uniform connectivity and inspection model unsuitable for enterprise and regulated environments. Hub‑and‑Spoke as the Foundation for Centralised Security Enterprises commonly adopt a Hub‑and‑Spoke topology using VNET peering or Azure Virtual WAN, extending hybrid connectivity via Site‑to‑Site VPN or ExpressRoute. The hub provides a centralised, datapath‑centric layer for shared networking and security services, while spoke VNETs host application workloads and remain private, typically without public IPs. Ingress and egress are handled through shared, centrally managed endpoints. This model consolidates critical controls—Azure Firewall, Azure WAF, and DDoS protection—at controlled entry and exit points, significantly reducing the attack surface. Integration with Microsoft Sentinel enables cross‑layer visibility, threat hunting, and detection of risks such as unauthorised access and data exfiltration. Why a Single Hub Is Not Sufficient Using a single hub to process all traffic types introduces operational and security challenges at scale by forcing Internet‑untrusted and private traffic through the same inspection tier. Key limitations include: Coupled Internet and private security policies Rapid firewall rule sprawl and management overhead A single blast radius across all traffic types Throughput and SNAT scalability constraints Increased difficulty meeting regulatory separation requirements These issues become more pronounced as environments scale across regions and workloads. Multi‑Hub as an Enterprise‑Grade Evolution A multi‑hub architecture resolves these challenges by separating inspection responsibilities across dedicated hubs: DMZ Hub VNET: Internet‑facing traffic and perimeter security enforcement Core Hub VNET: Outbound Internet access, East‑West, and hybrid traffic inspection This separation aligns security controls with traffic intent, reduces policy complexity, limits blast radius, and simplifies operations. In the next section, we explore multi‑hub architecture patterns and examine how each traffic flow is inspected and governed in practice. Scenario 1 – Third‑Party Firewall–Centric Multi‑Hub Design In this scenario, third‑party firewalls provide inspection for all traffic flows—Internet inbound, Internet outbound, East‑West, and hybrid connectivity—while Azure WAF and Azure DDoS Protection are used to defend against volumetric attacks, application‑layer threats, and malicious bot traffic. Architecture Overview The design uses two dedicated hub virtual networks, with spoke VNets peered to both hubs to maintain traffic separation based on trust and inspection requirements: DMZ Hub VNET (Internet Ingress Hub) Core Hub VNET (Egress, East‑West, and Hybrid Hub) DMZ Hub VNET – Internet Inbound (North–South) Traffic The DMZ hub establishes a dedicated perimeter for Internet‑facing applications. Internet traffic lands on a public Application Gateway with Azure WAF, protected by an Azure DDoS Protection Plan applied to the public frontend IP. Third‑party firewalls are deployed behind the Application Gateway to perform deep packet inspection. Firewalls operate in active‑active mode as standalone appliances, using three dedicated network interfaces (Untrust, Trust, and Management), each placed in separate subnets. Application Gateway provides load balancing and health probing, ensuring firewall availability and resiliency. Core Hub VNET – Egress, East‑West, and Hybrid Traffic The core hub handles all non‑Internet‑inbound traffic flows, including private inter‑VNET communication and hybrid connectivity. Third‑party firewalls are deployed behind an internal Azure Load Balancer, which maintains high availability using health probes. Firewalls follow the same active‑active, three‑NIC design for consistent policy enforcement and operational symmetry. Azure NAT Gateway is associated with the firewall Untrust subnet to scale outbound SNAT and simplify Internet egress with deterministic public IP. Site‑to‑site VPN or ExpressRoute terminate in this hub for on‑premises and multi‑cloud connectivity, ensuring private and regulated traffic bypasses Internet‑facing controls. Architecture Patterns - Traffic Flow 1.1 North–South (Internet Inbound) Traffic Flow This flow applies when applications hosted on Azure (VMs, VM Scale Sets, or services behind Internal Load Balancer / Internal Application Gateway) are published to the Internet. As shown in the diagram, Internet-bound client requests enter Azure through a dedicated DMZ Hub, where perimeter security controls are enforced before traffic reaches private application spokes. Inbound Request Flow (Blue Path) Client → Application Gateway (WAF) A client request (for example, app1.example.com) is resolved via DNS and lands on the public endpoint of Azure Application Gateway. Azure WAF performs Layer‑7 inspection, bot protection, and rule evaluation. Application Gateway → Firewall (DMZ Hub) Based on hostname and routing rules, Application Gateway forwards traffic to the firewalls while preserving the client’s real IP using the X‑Forwarded‑For (XFF) header. Firewall → Application (Spoke VNET) The firewall performs DNAT to the internal destination (Internal Application Gateway or Internal Load Balancer) and SNAT to its trust‑interface IP to ensure symmetric return traffic. Traffic is then routed over VNET peering to the private application workload. Response Flow (Green Path) Application → Firewall The application responds using its private IP, with the firewall trust interface as the destination. Firewall → Application Gateway The firewall forwards the response based on its session state. Application Gateway → Client Application Gateway returns the response to the Internet client. DDoS Protection Azure DDoS Protection continuously monitors the Application Gateway public IP and mitigates volumetric attacks before they reach the application stack. Key Design Considerations Application Gateway routing - Use a multi‑site listener with hostname‑based rules to steer traffic to the appropriate firewall backend. Firewall backend mapping - Register firewall VMs in a single backend pool and differentiate applications using distinct backend settings (same protocol, different ports). Application steering at firewall - Firewalls perform port‑based DNAT (or private FQDN‑based DNAT where supported) to forward traffic to the correct application private IP in spoke VNets. Traffic symmetry - Source NAT is applied on the firewall trust interface to maintain symmetric return paths. Protocol support - The same pattern applies to TCP/UDP workloads, using an External Azure Load Balancer instead of Application Gateway where WAF is not required. Client IP visibility Application Gateway enables WAF inspection using the real client IP, preserved downstream via X‑Forwarded‑For. With Azure Load Balancer, client IP is retained up to the firewall for IP‑based enforcement, with Azure DDoS Protection safeguarding the public frontend. 1.2 Hybrid Connectivity Traffic Flow Hybrid connectivity represents communication between Azure workloads and on‑premises environments using Site‑to‑Site VPN or ExpressRoute. Traffic Flow Request (Blue: 1–4): Traffic originates from applications in spoke VNETs and is forwarded via UDRs to the Internal Load Balancer, through active‑active firewalls, and then to on‑premises via VPN or ExpressRoute. Response (Green: 5–8): Return traffic follows the same path in reverse. Key Design Considerations Source and destination IP addresses remain unchanged end‑to‑end, despite firewalls operating behind an Internal Load Balancer. UDRs steer both outbound and inbound hybrid traffic to the Internal Load Balancer as the next hop. Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. Azure Virtual Network Manager can be used to manage and scale UDR deployment centrally across Hub and spoke networks. 1.3 East-West Traffic flow This traffic flow represents the connectivity between resources across VNETs through Firewall. Considerations remain same as “Hybrid Connectivity Traffic flow” mentioned above. 1.4 Egress/Outbound Connectivity Traffic flow This traffic flow represents the connectivity from the resources hosted inside VNETs to Internet through Firewalls deployed behind Internal Load Balancer in Core Hub VNET. Egress/Outbound Connectivity Traffic flow Key Considerations: A default route (0.0.0.0/0) UDR directs Internet-bound traffic to the Internal Load Balancer for firewall inspection. Firewall performs SNAT to its untrusted interface, after which Azure NAT Gateway translates traffic to a fixed public IP. Alternatively, a public IP can be assigned to the firewall untrusted interface to perform SNAT directly, removing the need for NAT Gateway and reducing cost. Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. However, with horizontal firewall scaling, outbound public IPs become non-deterministic. Scenario 2: Third‑Party Firewalls for Ingress, Azure Firewall for Private Flows In this scenario, third‑party firewalls secure Internet‑facing traffic, while Azure Firewall handles Egress, East–West, and Hybrid flows. This separation enables organisations to retain existing perimeter security investments while adopting a fully managed, cloud‑native control and data plane for internal traffic flows. As private traffic patterns scale, particularly for chatty East–West communication, Azure Firewall helps simplify operations and improves scalability by offloading traffic inspection to a managed service. This approach reduces operational overhead and provides consistent policy enforcement across internal and hybrid flows. Setup DMZ Hub design remains unchanged from Scenario 1. Core Hub VNET use Azure Firewall for better scalability, built‑in resilience, and simplified operations. Azure Firewall eliminates the need for load balancers and reduces complexity for chatty east‑west traffic. It requires a single subnet (unless force tunnelling is enabled), optimising IP consumption. Outbound traffic is SNATed by Azure Firewall and further translated via Azure NAT Gateway. Firewall‑based SNAT to public IP can be used to avoid NAT Gateway costs when deterministic egress IPs or higher SNAT scale are not required. Traffic Flow North–South (Internet Inbound) Traffic Flow represented with Numbers. Request flow represented with Blue: 1–3 Response flow represented with Brown: 4–6 Egress/Outbound Connectivity Traffic flow represented with alphabets. Request flow represented with Green: A–C Response flow represented with Blue: D–F Hybrid flow represented with purple Architecture Diagram: Third‑Party Firewalls for Ingress, Azure Firewall for Private Flows Further if you want to use Azure Firewall for the Internet Ingress flow, you can use it as well. Below is the architecture diagram explaining the same pattern. Azure Firewalls for Ingress and Private Flows Key Considerations: Application Gateway behaviour remains the same as Scenario 1; however, backend pools use IP‑based targets. Internal applications should be exposed via internal Application Gateway or internal load balancer to provide stable backend IPs. To optimise traffic flow and avoid unnecessary network address translation, the private IP address of the Application Gateway or internal Load Balancer should be configured in the backend pool of External Load Balancer in DMZ Hub VNET. This design does not need Azure Firewall to perform both source NAT (SNAT) and destination NAT (DNAT) operations. Further, implementing User Defined Routes (UDRs) in the Application Gateway subnet—specifically for spoke VNet CIDR ranges steers traffic routing through the Firewall. For non-web (TCP/UDP) workloads, applications can be directly exposed through the firewall public IP, with Azure DDoS Protection applied to mitigate volumetric attacks. Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. Scenario 3 - Overcoming Peering Complexity at Scale with Azure Virtual WAN In environments where each application is hosted in its own dedicated VNET for isolation and stronger security, a traditional hub‑and‑spoke model quickly becomes complex. With a single hub, "N" spoke VNETs require "N" peering's; introducing multiple hubs increases this to "2N", significantly amplifying operational overhead—especially across multiple regions. Azure Virtual WAN addresses this challenge by eliminating the need for extensive VNET peering. As a global, managed service, it simplifies large‑scale and multi‑region architectures while providing built‑in scalability and operational consistency. Setup DMZ Hub design and components remain unchanged from Scenario 1 keeping defense in depth principles intact for Internet Inbound or North-South traffic. Core Hub VNET is replaced with Azure Virtual WAN Secure Hub which has Azure Firewall inside the managed Secure Hub VNETs. This further eliminates the need for creating Azure Firewall Subnet, Azure NAT Gateway resources for East-West, Egress and Hybrid connectivity and provides same level of security protection as mentioned in Scenario 2. Secure Hub design using Virtual WAN removes the routing and inspection complexity which was unless required in Scenario 2 by removing UDR configurations in Spoke VNETs, Gateway Subnet and Azure Firewall Subnet. This provides simplified design and operations with built-in resiliency by leveraging the managed platform. Azure Firewall eliminates the need for load balancers and reduces complexity for chatty east‑west traffic. East-West, Egress, and Hybrid connectivity happens via VPN Gateway and Express Route Gateway present in Virtual Hub. All private and Internet Egress traffic is inspected by Azure Firewall present in secure Hub. Outbound traffic is SNATed to Public IP by Azure Firewall thus avoiding the need of Azure NAT Gateway. Firewall‑based SNAT to public IP can be used to avoid NAT Gateway costs when deterministic egress IPs or higher SNAT scale are not required. Traffic Flow North–South (Internet Inbound) Traffic Flow represented with Numbers. Request flow represented with Blue: 1–5 Response flow represented with Green: 6–10 Egress/Outbound Connectivity Traffic flow represented with Red Hybrid flow represented with Green East-West connectivity flow represented with black Architecture Diagram: Key Considerations Virtual WAN has additional cost Refer to architecture diagram above for different traffic flows. The DMZ VNET components consideration remains same as per scenario 1 You can use your own managed public IP on Azure Firewall for applying standard IP/Network DDoS protection plan. Benefits of multi-Hub approach over single Hub You can use this table as decision matrix to choose the best option for your application requirements. Dimensions Multi-Hub Design Resiliency · Independent scaling of DMZ and Core firewalls · Failure in Internet inspection does not impact East‑West traffic · Easier multi‑region active‑active designs Security & Compliance Clear trust boundaries Auditable inspection points Easier alignment with Zero Trust & regulatory frameworks Operational Simplicity Smaller, purpose‑built firewall policies Clear ownership (Perimeter vs Core team) Faster troubleshooting due to deterministic flows Cost Optimisation Avoids over‑inspection of East‑West traffic by DMZ firewalls Smaller firewall SKUs per hub Better scale‑unit consumption Performance Efficiency Reduced latency for private traffic No unnecessary hair‑pinning Optimised SNAT and connection tracking Key Takeaways Security‑first landing zones should not be designed as one‑size‑fits‑all networks. By designing hubs based on traffic trust level and inspection intent, rather than convenience, organisations gain: o Stronger security boundaries and better fault isolation o Predictable operations at scale o Lower long‑term cost and complexity o Design for traffic flows, not just connectivity o Use DMZ hubs exclusively for Internet‑untrusted traffic o Use Core hubs for East‑West, outbound, and hybrid connectivity o Map security controls to OSI layers o Avoid single‑hub designs for large, regulated, or multi‑region environments This distributed hub‑and‑DMZ landing zone provides a clean, scalable, and secure foundation for enterprise workloads in any Hyperscaler. For regulated, internet‑exposed, or multi‑region environments, a distributed hub with a dedicated DMZ is no longer optional — it is a foundational architecture decision.How Azure network security can help you meet NIS2 compliance
With the adoption of the NIS2 Directive EU 2022 2555, cybersecurity obligations for both public and private sector organizations have become more strict and far reaching. NIS2 aims to establish a higher common level of cybersecurity across the European Union by enforcing stronger requirements on risk management, incident reporting, supply chain protection, and governance. If your organization runs on Microsoft Azure, you already have powerful services to support your NIS2 journey. In particular Azure network security products such as Azure Firewall, Azure Web Application Firewall WAF, and Azure DDoS Protection provide foundational controls. The key is to configure and operate them in a way that aligns with the directive’s expectations. Important note This article is a technical guide based on the NIS2 Directive EU 2022 2555 and Microsoft product documentation. It is not legal advice. For formal interpretations, consult your legal or regulatory experts. What is NIS2? NIS2 replaces the original NIS Directive 2016 and entered into force on 16 January 2023. Member states must transpose it into national law by 17 October 2024. Its goals are to: Expand the scope of covered entities essential and important entities Harmonize cybersecurity standards across member states Introduce stricter supervisory and enforcement measures Strengthen supply chain security and reporting obligations Key provisions include: Article 20 management responsibility and governance Article 21 cybersecurity risk management measures Article 23 incident notification obligations These articles require organizations to implement technical, operational, and organizational measures to manage risks, respond to incidents, and ensure leadership accountability. Where Azure network security fits The table below maps common NIS2 focus areas to Azure network security capabilities and how they support compliance outcomes. NIS2 focus area Azure services and capabilities How this supports compliance Incident handling and detection Azure Firewall Premium IDPS and TLS inspection, Threat Intelligence mode, Azure WAF managed rule sets and custom rules, Azure DDoS Protection, Azure Bastion diagnostic logs Detect, block, and log threats across layers three to seven. Provide telemetry for triage and enable response workflows that are auditable. Business continuity and resilience Azure Firewall availability zones and autoscale, Azure Front Door or Application Gateway WAF with zone redundant deployments, Azure Monitor with Log Analytics, Traffic Manager or Front Door for failover Improve service availability and provide data for resilience reviews and disaster recovery scenarios. Access control and segmentation Azure Firewall policy with DNAT, network, and application rules, NSGs and ASGs, Azure Bastion for browser based RDP SSH without public IPs, Private Link Enforce segmentation and isolation of critical assets. Support Zero Trust and least privilege for inbound and egress. Vulnerability and misconfiguration defense Azure WAF Microsoft managed rule set based on OWASP CRS. Azure Firewall Premium IDPS signatures Reduce exposure to common web exploits and misconfigurations for public facing apps and APIs. Encryption and secure communications TLS policy: Application Gateway SSL policy; Front Door TLS policy; App Service/PaaS minimum TLS. Inspection: Azure Firewall Premium TLS inspection Inspect and enforce encrypted communication policies and block traffic that violates TLS requirements. Inspect decrypted traffic for threats. Incident reporting and evidence Azure Network Security diagnostics, Log Analytics, Microsoft Sentinel incidents, workbooks, and playbooks Capture and retain telemetry. Correlate events, create incident timelines, and export reports to meet regulator timelines. NIS2 articles in practice Article 21 cybersecurity risk management measures Azure network controls contribute to several required measures: Prevention and detection. Azure Firewall blocks unauthorized access and inspects traffic with IDPS. Azure DDoS Protection mitigates volumetric and protocol attacks. Azure WAF prevents common web exploits based on OWASP guidance. Logging and monitoring. Azure Firewall, WAF, DDoS, and Bastion resources produce detailed resource logs and metrics in Azure Monitor. Ingest these into Microsoft Sentinel for correlation, analytics rules, and automation. Control of encrypted communications. Azure Firewall Premium provides TLS inspection to reveal malicious payloads inside encrypted sessions. Supply chain and service provider management. Use Azure Policy and Defender for Cloud to continuously assess configuration and require approved network security baselines across subscriptions and landing zones. Article 23 incident notification Build an evidence friendly workflow with Sentinel: Early warning within twenty four hours. Use Sentinel analytics rules on Firewall, WAF, DDoS, and Bastion logs to generate incidents and trigger playbooks that assemble an initial advisory. Incident notification within seventy two hours. Enrich the incident with additional context such as mitigation actions from DDoS, Firewall and WAF. Final report within one month. Produce a summary that includes root cause, impact, and corrective actions. Use Workbooks to export charts and tables that back up your narrative. Article 20 governance and accountability Management accountability. Track policy compliance with Azure Policy initiatives for Firewall, DDoS and WAF. Use exemptions rarely and record justification. Centralized visibility. Defender for Cloud’s network security posture views and recommendations give executives and owners a quick view of exposure and misconfigurations. Change control and drift prevention. Manage Firewall, WAF, and DDoS through Network Security Hub and Infrastructure as Code with Bicep or Terraform. Require pull requests and approvals to enforce four eyes on changes. Network security baseline Use this blueprint as a starting point. Adapt to your landing zone architecture and regulator guidance. Topology and control plane Hub and spoke architecture with a centralized Azure Firewall Premium in the hub. Enable availability zones. Deploy Azure Bastion Premium in the hub or a dedicated management VNet; peer to spokes. Remove public IPs from management NICs and disable public RDP SSH on VMs. Use Network Security Hub for at-scale management. Require Infrastructure as Code for all network security resources. Web application protection Protect public apps with Azure Front Door Premium WAF where edge inspection is required. Use Application Gateway WAF v2 for regional scenarios. Enable the Microsoft managed rule set and the latest version. Add custom rules for geo based allow or deny and bot management. enable rate limiting when appropriate. DDoS strategy Enable DDoS Network Protection on virtual networks that contain internet facing resources. Use IP Protection for single public IP scenarios. Configure DDoS diagnostics and alerts. Stream to Sentinel. Define runbooks for escalation and service team engagement. Firewall policy Enable IDPS in alert and then in alert and deny for high confidence signatures. Enable TLS inspection for outbound and inbound where supported. Enforce FQDN and URL filtering for egress. Require explicit allow lists for critical segments. Deny inbound RDP SSH from the internet. Allow management traffic only from Bastion subnets or approved management jump segments. Logging, retention, and access Turn on diagnostic settings for Firewall, WAF, DDoS, and Application Gateway or Front Door. Send to Log Analytics and an archive storage account for long term retention. Set retention per national law and internal policy. Azure Monitor Log Analytics supports table-level retention and archive for up to 12 years, many teams keep a shorter interactive window and multi-year archive for audits. Restrict access with Azure RBAC and Customer Managed Keys where applicable. Automation and playbooks Build Sentinel playbooks for regulator notifications, ticket creation, and evidence collection. Maintain dry run versions for exercises. Add analytics for Bastion session starts to sensitive VMs, excessive failed connection attempts, and out of hours access. Conclusion Azure network security services provide the technical controls most organizations need in order to align with NIS2. When combined with policy enforcement, centralized logging, and automated detection and response, they create a defensible and auditable posture. Focus on layered protection, secure connectivity, and real time response so that you can reduce exposure to evolving threats, accelerate incident response, and meet NIS2 obligations with confidence. References NIS2 primary source Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng Azure Firewall Premium features (TLS inspection, IDPS, URL filtering). https://learn.microsoft.com/en-us/azure/firewall/premium-features Deploy & configure Azure Firewall Premium. https://learn.microsoft.com/en-us/azure/firewall/premium-deploy IDPS signature categories reference. https://learn.microsoft.com/en-us/azure/firewall/idps-signature-categories Monitoring & diagnostic logs reference. https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall-reference Web Application Firewall WAF on Azure Front Door overview & features. https://learn.microsoft.com/en-us/azure/frontdoor/web-application-firewall WAF on Application Gateway overview. https://learn.microsoft.com/en-us/azure/web-application-firewall/overview Examine WAF logs with Log Analytics. https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics Rate limiting with Front Door WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit Azure DDoS Protection Service overview & SKUs (Network Protection, IP Protection). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview Quickstart: Enable DDoS IP Protection. https://learn.microsoft.com/en-us/azure/ddos-protection/manage-ddos-ip-protection-portal View DDoS diagnostic logs (Notifications, Mitigation Reports/Flows). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-view-diagnostic-logs Azure Bastion Azure Bastion overview and SKUs. https://learn.microsoft.com/en-us/azure/bastion/bastion-overview Deploy and configure Azure Bastion. https://learn.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal Disable public RDP and SSH on Azure VMs. https://learn.microsoft.com/en-us/azure/virtual-machines/security-baseline Azure Bastion diagnostic logs and metrics. https://learn.microsoft.com/en-us/azure/bastion/bastion-diagnostic-logs Microsoft Sentinel Sentinel documentation (onboard, analytics, automation). https://learn.microsoft.com/en-us/azure/sentinel/ Azure Firewall solution for Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/firewall/firewall-sentinel-overview Use Microsoft Sentinel with Azure WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Architecture & routing Hub‑spoke network topology (reference). https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke Azure Firewall Manager & secured virtual hub. https://learn.microsoft.com/en-us/azure/firewall-manager/secured-virtual-hubPublic Preview: Managed Identity support for graphical session recording
Overview Azure Bastion provides secure RDP and SSH access to Azure virtual machines directly via the Azure portal or via the native SSH/RDP client already installed on your local computer. Today, we are introducing public preview for managed identity support for session recording, giving administrators a seamless, identity-based way to authenticate Bastion when writing recordings to a designated storage account. Why Managed Identities? With managed identity support, Bastion authenticates directly to your storage account using an Azure identity, no additional credentials to configure or manage. You can use either a system-assigned or user-assigned managed identity depending on your needs. Authentication is handled automatically through Microsoft Entra ID, which means setup is straightforward: enable the identity, assign a role, and point Bastion at your storage container. For organizations operating at scale across many Bastion deployments and regions, this identity-based approach removes the need to manage credentials, aligns with Zero Trust principles, and lets you control access centrally through Azure RBAC. Getting Started in Azure Portal Prerequisites Ensure that Azure Bastion is deployed with the Premium SKU Ensure that a storage account with a dedicated container for session recordings is created Ensure that the storage account has the required CORS policy configured. Click here to set up the storage account for session recordings Ensure that users who need to view recordings have the Storage Blob Data Reader role on the storage account Steps Navigate to your Bastion resource in the Azure portal. Select Identity (Preview) in the left pane and turn the Status to On to enable a system-assigned managed identity. Wait for the configuration to complete. Select Azure role assignments, then select Add role assignment (Preview). Assign the Storage Blob Data Contributor role scoped to your storage account. Select Save, then navigate to the Configuration blade. Under Session Recording Configuration, select System Assigned Managed Identity and enter the Blob Container URI for your storage container. Navigate to the Session recordings blade to view and play back recorded sessions. Next Steps Learn more about configuring session recording with managed identities here and keep up to date with all things Azure Bastion in our What's New page.
Designing Outbound Connectivity for "Private Subnets" in Azure
Why Private Subnets Change Everything Historically, Azure virtual machines relied on default outbound internet access, where the platform automatically assigned a dynamic SNAT IP from a shared pool. This was convenient but problematic: ❌ No deterministic outbound IP addresses ❌ No traffic inspection or filtering ❌ No FQDN or URL governance ❌ Difficult to audit for compliance ❌ Susceptible to noisy neighbor SNAT exhaustion With private subnets, outbound access is disabled by default. This shifts the responsibility to the architect — deliberately. The result is an environment where: ✅ Every outbound flow is intentional ✅ Every outbound IP is known and documented ✅ Every egress path can be governed and logged ✅ Compliance evidence is straightforward to produce The question is no longer "does my VM have internet access?" but rather "how exactly does my VM reach the internet, and is that path appropriate for this workload?" The Three Outbound Patterns at a Glance Option Primary Role Inspection Scale Cost Best For NAT Gateway Managed outbound SNAT ❌ None ⭐⭐⭐ High 💲 Low Simple, scalable egress Azure Firewall Secure governed egress ✅ Full L3–L7 ⭐⭐⭐ High 💲💲💲 Higher Security boundaries Load Balancer Legacy SNAT ❌ None ⭐⭐ Limited 💲 Low Legacy / transitional Scenario 1: NAT Gateway What is NAT Gateway? Azure NAT Gateway is a fully managed, zone‑resilient, outbound‑only SNAT service. It attaches at the subnet level and automatically handles all outbound flows from that subnet using one or more static public IP addresses or prefixes. It is purpose‑built for one thing: providing predictable, scalable outbound internet access — without routing complexity or inline devices. Key flow are depicted below: VM → NAT Gateway: Automatic SNAT (no UDR required) NAT Gateway → Internet: Static, deterministic public IP Inbound: NOT supported (outbound only) How it works (step by step) VM initiates an outbound connection (e.g., HTTPS to an API) NAT Gateway intercepts the flow at the subnet boundary Source IP is translated to the NAT Gateway's static public IP The packet is forwarded to the internet Return traffic is automatically tracked and delivered back to the VM No UDRs. No routing tables. No inline devices. It just works. Strengths Massive SNAT scale — no port exhaustion concerns at typical enterprise scale Deterministic outbound IPs — easy to allowlist with external services Zone resilient — survives availability zone failures Subnet scoped — applies to all VMs in the subnet automatically No routing configuration required Limitations ❌ No traffic inspection or filtering ❌ No FQDN or URL policy enforcement ❌ No threat intelligence integration ❌ Cannot restrict which internet destinations are allowed Best Fit Use Cases ✅ Application tiers calling external SaaS APIs ✅ VMs requiring OS updates and patch downloads ✅ CI/CD build agents and pipeline runners ✅ Spoke VNets in hub‑and‑spoke where east‑west goes through firewall, but simple internet egress is acceptable ✅ Dev/test environments Scenario 2: Azure Firewall What is Azure Firewall? Azure Firewall is a cloud‑native, stateful, L3–L7 network security service. When used for outbound egress, it transforms the egress path from a connectivity function into a security enforcement boundary. Unlike NAT Gateway, Azure Firewall inspects every packet, evaluates it against policy, and either allows or denies it based on network rules, application rules, and threat intelligence feeds. KEY Flow are depicted below: VM → UDR: Forces ALL outbound traffic to Firewall Firewall: Evaluates against policy before allowing Firewall → Internet: Only explicitly permitted flows pass All denied flows: Logged and alertable How it works (step by step) VM initiates an outbound connection UDR intercepts the flow and redirects to Azure Firewall's private IP Azure Firewall evaluates the traffic: Network rules (IP/port match) Application rules (FQDN/URL match) Threat intelligence (known malicious IPs/domains) If allowed: traffic is forwarded via Firewall's public IP If denied: traffic is dropped and logged All flows (allowed and denied) are logged to Log Analytics / Sentinel Strengths ✅ Full L3–L7 inspection ✅ FQDN and URL‑based filtering (application rules) ✅ Threat intelligence integration (Microsoft TI feed) ✅ TLS inspection (Premium SKU) ✅ Centralized governance across multiple VNets via Firewall Manager ✅ Rich logging — every allowed and denied flow is recorded ✅ IDPS (Intrusion Detection and Prevention) available in Premium Limitations ❌ Higher cost (hourly + data processing charges) ❌ Requires UDR configuration on each spoke subnet ❌ Adds latency (small but non‑zero) ❌ Requires careful SNAT configuration at scale Best Fit Use Cases ✅ Regulated industries (financial services, healthcare, government) ✅ Any workload where outbound internet is a security boundary ✅ Environments requiring egress allowlisting for compliance ✅ Hub‑and‑spoke architectures with centralized control plane ✅ SOC environments needing outbound flow telemetry Scenario 3: Load Balancer Outbound What is Load Balancer Outbound? Azure Load Balancer outbound rules were historically the primary mechanism for providing SNAT to VMs behind a Standard Load Balancer. While newer patterns (NAT Gateway, Azure Firewall) have largely replaced this approach for new designs, outbound rules remain valid in specific scenarios. Key flows are depicted below: VMs → Load Balancer: Backend pool members get SNAT LB Outbound Rules: Define port allocation per VM ⚠️ Port exhaustion risk at scale ⚠️ No inspection or policy enforcement How it works (step by step) VM in the backend pool initiates an outbound connection Load Balancer applies SNAT using the frontend public IP Ephemeral ports are allocated per VM from a fixed pool Return traffic is tracked and delivered back to the correct VM If port pool is exhausted: connections fail (SNAT exhaustion) Strengths Lower cost than NAT Gateway or Firewall Tightly integrated with existing load‑balanced workloads Familiar operational model for legacy teams Limitations ❌ SNAT port pool is fixed and must be manually managed ❌ Risk of SNAT exhaustion at scale ❌ No traffic inspection ❌ Less flexible than NAT Gateway ❌ Not recommended for new designs Best Fit Use Cases ✅ Existing architectures already built around Azure Load Balancer ✅ Low outbound connection volume workloads ✅ Transitional architectures during modernization to NAT Gateway Decision Framework: Choosing the Right Outbound Pattern Common Pitfalls to Avoid ⚠️ Pitfall 1: Forgetting SNAT scale limits Load Balancer outbound rules allocate a fixed number of ephemeral ports per VM. At scale this exhausts quickly. Use NAT Gateway instead. ⚠️ Pitfall 2: Over‑securing low‑risk workloads Not every workload needs Azure Firewall for outbound. Dev/test and patch traffic are better served by NAT Gateway — simpler, cheaper, faster. ⚠️ Pitfall 3: Mixing outbound models in the same subnet NAT Gateway and Load Balancer outbound rules cannot coexist on the same subnet. NAT Gateway always takes precedence. Plan your subnet boundaries carefully. ⚠️ Pitfall 4: Blocking Azure platform dependencies Many Azure services still use public endpoints (even when Private Link is available). Ensure your outbound policy allows required Azure service tags before enforcing egress controls. ⚠️ Pitfall 5: Relying on platform defaults Default outbound access is retired for new VNets. Do not assume VMs can reach the internet without explicit configuration. Summary and Key Takeaways Scenario Best Choice Why Simple internet egress at scale NAT Gateway Scalable, predictable, no complexity Security boundary for egress Azure Firewall Inspection, FQDN rules, threat intel Legacy load‑balanced workloads Load Balancer Outbound Transitional only Regulated / compliance environments Azure Firewall Audit logs, policy enforcement Dev / test / patch traffic NAT Gateway Low cost, low friction The core principle Private subnets make outbound access intentional. Choose the outbound pattern that matches the risk level of the workload — not the most complex option available. References https://learn.microsoft.com/azure/nat-gateway/nat-overview https://learn.microsoft.com/azure/firewall/overview https://learn.microsoft.com/azure/load-balancer/outbound-rules https://azure.microsoft.com/blog/default-outbound-access-for-vms-in-azure-will-be-retiredOrchestrating Intrusion Detection and Prevention Signature overrides in Azure Firewall Premium
Introduction: Azure Firewall Premium provides strong protection with a built-in Intrusion Detection and Prevention System (IDPS). It inspects inbound, outbound, and east-west traffic against Microsoft’s continuously updated signature set and can block threats before they reach your workloads. IDPS works out of the box without manual intervention. However, in many environments administrators need the flexibility to override specific signatures to better align with operational or security requirements. Common reasons include: Compliance enforcement – enforcing policies that require certain threats (such as High severity signatures) to always be blocked, directional tuning or protocol/category-based tuning. Incident response – reacting quickly to emerging vulnerabilities by enabling blocking for newly relevant signatures. Noise reduction – keeping informational signatures in alert mode to avoid false positives while still maintaining visibility. In many environments, signature overrides are typically managed in one of two ways: Using the global IDPS mode Using the Azure portal to apply per-signature overrides individually While these approaches work, managing overrides manually becomes difficult when thousands of signatures are involved. The Azure portal also limits the number of changes that can be applied at once, which makes large tuning operations time-consuming. To simplify this process, this blog introduces an automation approach that allows you to export, filter, and apply IDPS signature overrides in bulk using PowerShell scripts. A Common Operational Scenario: Consider the following scenario frequently encountered by security teams: Scenario A security team wants to move their firewall from Alert → Alert + Deny globally to strengthen threat prevention. However, they do not want Low severity signatures to Deny traffic, because these signatures are primarily informational and may create unnecessary noise or false positives. Example: Signature ID: 2014906 Severity: Low Description: INFO – .exe File requested over FTP This signature is classified as informational because requesting an .exe file over FTP indicates contextual risk, not necessarily confirmed malicious activity. If the global mode is switched to Alert + Deny, this signature may start blocking traffic unnecessarily. The goal therefore becomes: Enable Alert + Deny globally Keep Low severity signatures in Alert mode The workflow described in this blog demonstrates how to achieve this outcome using the IDPS Override script. Automation Workflow: The automation process uses two scripts to export and update signatures. Workflow overview Azure Firewall Policy │ ▼ Export Signatures (ipssigs.ps1) │ ▼ CSV Review / Edit │ ▼ Bulk Update (ipssigupdate.ps1) │ ▼ Updated Firewall Policy Before implementing the workflow, it’s helpful to review the available IDPS modes and severity as seen below, very briefly. IDPS Modes: Severity: Prerequisites: Now that we understand Azure Firewall IDPS concepts and have the context for this script, let's get started with the workings of the script itself. First of all, let us ensure that you are connected to your Azure account and have selected the correct subscription. You can do so by running the following command: Connect-AzAccount -Subscription "<your-subscription-id>" Ensure the following modules are installed which are required for this operation: Az.Accounts Az.Network 💡 Tip: You can check if the above modules are installed by running the following command: Get-Module -ListAvailable Az* or check specific modules using this following commands: Get-module Az.Network | select Name, Version, Path Get-module Az.Accounts | select Name, Version, Path If you need to install/import them, run the following command which downloads all generally available Azure service modules from the PowerShell Gallery, overwriting existing versions without prompting: Import-Module Az.Network Import-Module Az.Accounts Restart PowerShell after installation. Configure ipsconfig.json Now, let's configure the ipsconfig.json file and ensure the configuration file contains your target environment details i.e., target subscription, target firewall policy resource group name, firewall name, firewall policy name, location and rule collection group name. Example: { "subs": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "rg": "TEST-RG", "fw": "fw", "fwp": "fw-policy", "location": "CentralUS", "rcg": "DefaultNetworkRuleCollectionGroup" } Note: Your account must have permissions to read and update firewall policy and IDPS settings. Running the Script: 1. Export Signatures Now that we have all the prerequisites ready, it's time to run the script. Run the following command in PS in the directory where the script exists: .\ipssigs.ps1 Now, the script should prompt for filtering criteria as shown below and you can input the values as per your requirements: For the example scenario that we considered, we will give the following inputs as shown above in the snapshot: Mode: Alert Severity: Low 💡 Tip: When specifying multiple values, ensure there is space between the 2 values but no comma, otherwise the script may return no results. The script now exports the results to ipssignatures_results.csv file by default (or a custom filename if specified). The exported CSV includes metadata such as severity, direction, group, and protocol, which can help inform tuning decisions. 2. Prepare the CSV Now, we do not need all of these columns when inputting the CSV file to update the Firewall Policy. We only need the following columns. Signature Id Mode Therefore, we will need to remove all other columns while keeping the SignatureId and mode columns along with their headers as seen below: 3. Update the Firewall Policy Now, it's time to update the Firewall Policy with the signature/mode overrides that we need using the above CSV file. However, please note that the script supports two operations: Changing the global IDPS mode Applying bulk signature overrides using the CSV file You can use either option independently or both together. Let's understand this further by looking at these 2 examples. Example 1: Change Global Mode and Override Low Severity Signatures Goal: Set global mode to Alert + Deny Keep Low severity signatures in Alert Command: .\ipssigupdate.ps1 -GlobalMode Deny -InputFile Lowseveritysignatures.csv Result: High and Medium signatures → Alert + Deny Low signatures → Alert Example 2: Override Signatures Only If the global mode should remain unchanged, then run the following command only. .\ipssigupdate.ps1 The script will then prompt for the input CSV file in the next step as seen below: As seen the changed were made to the Azure Firewall in just a few seconds. After the script completes, updated signature actions should appear in the firewall policy. 4. Monitoring Script Execution Please use the following commands to track and monitor the background processes, to verify the status, check for any error and remove completed jobs as seen below: You can check background job status using: Get-Job -Id <#> View results: Receive-Job -Id <#> -Keep Remove completed jobs: Remove-Job -Id <#> Note: Up to 10,000 IDPS rules can be customized at a time 5. Validate the Changes: Now that we finished running the script, it's time to verify the update by confirming: Global IDPS mode in the firewall policy Signature override state Alert or block events in your logging destination (Log Analytics or Microsoft Sentinel) Note: Please note that, while most signatures support Off, Alert, or Deny actions, there are some context-setting signatures, that have fixed actions and cannot be overridden. Conclusion: Azure Firewall Premium makes it straightforward to apply broad IDPS configuration changes through the Azure portal. However, as environments scale, administrators often require more precise and repeatable ways to manage signature tuning. The automation approach described in this blog allows administrators to query, review, and update thousands of signatures in minutes. This enables repeatable tuning workflows, improves operational efficiency, and simplifies large-scale security configuration changes. References: Github Repository for the IDPS scripts Azure Firewall IDPS Azure Firewall IDPS signature rule categoriesAssess Azure DDoS Protection Status Across Your Environment
Introduction Distributed Denial of Service (DDoS) attacks continue to be one of the most prevalent threats facing organizations with internet-facing workloads. Azure DDoS Protection provides cloud-scale protection against L3/4 volumetric attacks, helping ensure your applications remain available during an attack. However, as Azure environments grow, maintaining visibility into which resources are protected and whether diagnostic logging is properly configured becomes increasingly challenging. Security teams often struggle to answer basic questions: Which Public IP addresses are protected by Azure DDoS Protection? Are we using IP Protection or Network Protection (DDoS Protection Plan)? Is diagnostic logging enabled for protected resources? To address these questions at scale, we’ve developed a PowerShell script that assesses your Azure DDoS Protection posture across all subscriptions. Understanding Azure DDoS Protection SKUs Azure offers three DDoS Protection tiers: Protection Type Description Scope Network Protection Enterprise-grade protection via a DDoS Protection Plan attached to VNETs All Public IPs in protected VNETs IP Protection Per-IP protection for individual Public IP addresses Individual Public IP For more details, see Azure DDoS Protection overview. The Assessment Script The Check-DDoSProtection.ps1 script provides a full view of DDoS Protection status across your Azure environment. This section covers the script’s key capabilities and the resource types it supports. Key Features Multi-subscription support: Scan a single subscription or all subscriptions you have access to DDoS Protection status: Identifies which Public IPs are protected and which SKU is being used VNET correlation: Automatically determines the VNET associated with each Public IP to assess Network Protection inheritance Diagnostic logging check: Verifies if DDoS diagnostic logs are configured for protected resources CSV export: Export results for further analysis or reporting Prerequisites Before running the script, ensure you have: Azure PowerShell modules installed: Run the following commands in PowerShell (version 5.1+) or PowerShell Core to install the required Azure modules. No special permissions are needed, these will install in your user profile. Install-Module -Name Az.Accounts -Scope CurrentUser -Force Install-Module -Name Az.Network -Scope CurrentUser -Force Install-Module -Name Az.Monitor -Scope CurrentUser -Force Appropriate Azure permissions: o Reader role on subscriptions you want to scan o Microsoft.Network/publicIPAddresses/read o Microsoft.Network/virtualNetworks/read o Microsoft.Insights/diagnosticSettings/read Azure login: Authenticate to Azure before running the script. This opens a browser window for interactive sign-in. Connect-AzAccount How to Use the Script Run the script from a PowerShell session where you’ve already authenticated with Connect-AzAccount. The account must have Reader role on the subscriptions you want to scan. Download the Script You can download the script from: - GitHub: Check-DDoSProtection.ps1 Basic Usage: Scan Current Subscription Scans only the subscription currently selected in your Azure context. .\Check-DDoSProtection.ps1 Scan a Specific Subscription Scans a single subscription by its ID. .\Check-DDoSProtection.ps1 -SubscriptionId "12345678-1234-1234-1234-123456789012" Scan All Subscriptions Scans every subscription your account has Reader access to. .\Check-DDoSProtection.ps1 -AllSubscriptions Export Results to CSV Exports the assessment results to a CSV file for reporting or further analysis. .\Check-DDoSProtection.ps1 -AllSubscriptions -ExportPath "C:\Reports\DDoS-Report.csv" Large Environment Options For organizations with many subscriptions or thousands of Public IPs, use the following parameters to handle errors gracefully and avoid API throttling. .\Check-DDoSProtection.ps1 -AllSubscriptions ` -ContinueOnError ` -SavePerSubscription ` -ExportPath "C:\Reports\DDoS-Report.csv" ` -ThrottleDelayMs 200 Parameters for large environments: Parameter Description -ContinueOnError Continue scanning even if a subscription fails (e.g., access denied) -SavePerSubscription Save a separate CSV file for each subscription -ThrottleDelayMs Delay between API calls to avoid throttling (default: 100ms) Understanding the Output The script provides both console output and optional CSV export. This section covers what each output type contains. Console Output The script displays a summary table for each subscription: Summary Statistics At the end of each subscription scan: CSV Export Columns Column Description Subscription Name of the Azure subscription Public IP Name Name of the Public IP resource Resource Group Resource group containing the Public IP Location Azure region IP Address Actual IP address (or “Dynamic” if not allocated) IP SKU Basic or Standard DDoS Protected Yes/No Risk Level High (unprotected) / Low (protected) DDoS SKU Network Protection, IP Protection, or None DDoS Plan Name Name of the DDoS Protection Plan (if applicable) VNET Name Associated Virtual Network name Associated Resource Resource the Public IP is attached to Resource Type Type of associated resource (VM, AppGw, LB, etc.) Diagnostic Logging Configured/Not Configured/N/A Log Destination Log Analytics, Storage, Event Hub, or None Recommendation Suggested action for unprotected resources Sample Scenarios Scenario 1: Protected Application Gateway Public IP Name: appgw-frontend-pip DDoS Protected: Yes DDoS SKU: Network Protection DDoS Plan Name: contoso-ddos-plan VNET Name: production-vnet Diagnostic Logging: Configured (Log Analytics) Risk Level: Low Explanation: The Application Gateway’s Public IP inherits protection from the VNET which has a DDoS Protection Plan attached. Diagnostic logging is properly configured. Scenario 2: Unprotected External Load Balancer Public IP Name: external-lb-pip DDoS Protected: No DDoS SKU: VNET not protected VNET Name: (External LB) Diagnostic Logging: N/A Risk Level: High Recommendation: Enable DDoS Protection on associated VNET or enable IP Protection Explanation: This external Load Balancer’s Public IP is not in a protected VNET. The script flags this as high risk. Scenario 3: IP Protection Without Logging Public IP Name: standalone-api-pip DDoS Protected: Yes DDoS SKU: IP Protection VNET Name: - Diagnostic Logging: Not Configured Risk Level: Low Recommendation: Configure diagnostic logging for DDoS-protected resources Explanation: The IP has IP Protection enabled, but diagnostic logging is not configured. While protected, you won’t have visibility into attack telemetry. Troubleshooting Script Doesn’t Find All Subscriptions Use the following command to list your Azure role assignments and verify you have Reader access to the target subscriptions. Run this from Azure Cloud Shell or a local PowerShell session after authenticating with Connect-AzAccount. # Check your role assignments Get-AzRoleAssignment -SignInName (Get-AzContext).Account.Id | Select-Object Scope, RoleDefinitionName API Throttling The script includes built-in retry logic for API throttling. If you still experience rate limit errors, increase the delay between API calls. Run this from the directory containing the script. .\Check-DDoSProtection.ps1 -AllSubscriptions -ThrottleDelayMs 500 Access Denied for Specific Resources The script displays “(Access Denied)” for VNETs or resources you don’t have permission to read. This doesn’t affect the overall assessment but may result in incomplete VNET information. Summary This guide covered how to use the Check-DDoSProtection.ps1 script to identify unprotected Public IP addresses, determine which DDoS SKU (Network Protection vs. IP Protection) is in use, verify diagnostic logging configuration, and assess risk levels across all subscriptions. Running this script periodically helps security teams track protection coverage as their Azure environment evolves. Related Resources Azure DDoS Protection Overview Azure DDoS Protection SKU Comparison Configure DDoS Protection Diagnostic Logging Best Practices for Azure DDoS Protection Zero Trust with Azure DDoS Protection
Detect, correlate, contain: New Azure Firewall IDPS detections in Microsoft Sentinel and XDR
As threat actors continue to blend reconnaissance, exploitation, and post-compromise activity, network-level signals remain critical for early detection and correlated response. To strengthen this layer, we're introducing five new Azure Firewall IDPS detections, now available out of the box in the Azure Firewall solution for Microsoft Sentinel and Microsoft Defender XDR. See It in Action This short demo walks through Azure Firewall's IDPS capabilities, the new Sentinel detections, and the automated response playbook — from malicious traffic hitting the firewall to the threat being contained without manual intervention. Watch the demo → Azure Firewall integration with Microsoft Sentinel and Defender XDR Read on for the full details on each detection, customization options, and a step-by-step walkthrough of the automated response workflow. What’s new The Azure Firewall solution now includes five new analytic detections built on Azure Firewall. Detection name What it detects (network signal) MITRE ATT&CK tactic(s) Example ATT&CK techniques (representative) SOC impact High severity malicious activity Repeated high confidence IDPS hits such as exploit kits, malware C2, credential theft, trojans, shellcode delivery Initial access (TA0001) execution (TA0002) Command and Control (TA0011) Exploit public facing application (T1190) command and control over web protocols (T1071.001) Ingress Tool Transfer (T1105) Highlights active exploitation or post compromise behavior at the network layer; strong pivot point into XDR investigations Elevation of privilege attempt Repeated attempts or success gaining user or administrator privileges Privilege escalation (TA0004) Exploitation for privilege escalation (T1068) Flags critical inflection points where attackers move from foothold to higher impact control Web application attack Probing or exploitation attempts against web applications Initial access (TA0001) Exploit public facing application (T1190) Surfaces external attack pressure against internet facing apps protected by Azure Firewall Medium severity malicious activity Potentially unwanted programs, crypto mining, social engineering indicators, suspicious filenames/system calls Initial access (TA0001) execution (TA0002) impact (TA0040) User Execution (T1204) Resource Hijacking (T1496) Early stage or lower confidence signals that help teams hunt, monitor, and tune response before escalation Denial of Service (DoS) attack Attempted or sustained denial of service traffic patterns Impact (TA0040) Network Denial of Service (T1498) Enables faster DoS identification and escalation, reducing time to mitigation Where these detections apply These detections are available through the Azure Firewall solution in: Microsoft Sentinel, enabling SOC centric investigation, hunting, and automation Microsoft Defender XDR, allowing network level signals to participate in end-to-end attack correlation across identity, endpoint, cloud, and email They are powered by the AZFWIdpsSignature log table and require Azure Firewall with IDPS enabled (preferably with TLS inspection). Customizing the detections to fit your environment The Azure Firewall IDPS detections included in the Microsoft Sentinel solution are designed to be fully adaptable to customer environments, allowing SOC teams to tune sensitivity, scope, and signal fidelity based on their risk tolerance and operational maturity. Each detection is built on the AZFWIdpsSignature log table and exposes several clearly defined parameters that customers can modify without rewriting the analytic logic. 1. Tune alert sensitivity and time horizon Customers can adjust the lookback period (TimeWindow) and minimum hit count (HitThreshold) to control how aggressively the detection triggers. Shorter windows and lower thresholds surface faster alerts for high-risk environments, while longer windows and higher thresholds help reduce noise in high volume networks. 2. Align severity with internal risk models Each analytic rule includes a configurable minimum severity (MinSeverity) aligned to Azure Firewall IDPS severity scoring. Organizations can raise or lower this value to match internal incident classification standards and escalation policies. 3. Focus on relevant threat categories and behaviors Optional filters allow detections to be scoped to specific threat categories, descriptions, or enforcement actions. Customers can enable or disable: Category filtering to focus on specific attack classes (for example, command and control, exploit kits, denial of service, or privilege escalation). Description filtering to target specific behavioral patterns. Action filtering to alert only on denied or alerted traffic versus purely observed activity. This flexibility makes it easy to tailor detections for different deployment scenarios such as internet facing workloads, internal east-west traffic monitoring, or regulated environments with stricter alerting requirements. 4. Preserve structure while customizing output Even with customization, the detections retain consistent enrichment fields including source IP, threat category, hit count, severity, actions taken, and signature IDs ensuring alerts remain actionable and easy to correlate across Microsoft Sentinel and Microsoft Defender XDR workflows. By allowing customers to tune thresholds, scope, and focus areas while preserving analytic intent, these Azure Firewall IDPS detections provide a strong out of the box baseline that can evolve alongside an organization’s threat landscape and SOC maturity. Automated detection and response for Azure Firewall using Microsoft Sentinel In this walkthrough, we’ll follow a real-world attack simulation and see how Azure Firewall, Microsoft Sentinel, and an automated playbook work together to detect, respond to, and contain malicious activity, without manual intervention. Step 1: Malicious traffic originates from a compromised source A source IP address 10.0.100.20, hosted within a virtual network, attempts to reach a web application protected by Azure Firewall. To validate the scenario, we intentionally generate malicious outbound traffic from this source, such as payloads that match known attack patterns. This is an outbound flow, meaning the traffic is leaving the internal network and attempting to reach an external destination through Azure Firewall. At this stage: Azure Firewall is acting as the central enforcement point Traffic is still allowed, but deep packet inspection is in effect Step 2: Azure Firewall IDPS detects malicious behavior Azure Firewall's intrusion detection and prevention system (IDPS) is enabled and inspects traffic as it passes through the firewall. When IDPS detects patterns that match known malicious signatures, the action taken depends on the signature's configured mode: Alert mode: IDPS generates a detailed security log for the matched signature but allows the traffic to continue. This is useful for monitoring and tuning before enforcing blocks. Alert and Deny mode: IDPS blocks the matching traffic and generates a detailed security log. The threat is stopped at the network layer while full telemetry is preserved for investigation. In both cases, IDPS records rich metadata including source IP, destination, protocol, signature name, severity, and threat category. These logs are what power the downstream detections in Microsoft Sentinel. In this walkthrough, the signature is configured in Alert and Deny mode, meaning the malicious traffic from 10.0.100.20 is blocked immediately at the firewall while the corresponding log is forwarded for analysis. Step 3: Firewall logs are sent to Log Analytics All Azure Firewall logs, including IDPS logs, are sent to a Log Analytics workspace named law-cxeinstance. At this point: Firewall logs are centralized Logs are normalized and can be queried No alerting has happened yet, only data collection This workspace becomes the single source of truth for downstream analytics and detections. Step 4: Microsoft Sentinel ingests and analyzes the Firewall logs The Log Analytics workspace is connected to Microsoft Sentinel, which continuously analyzes incoming data. Using the Azure Firewall solution from the Sentinel Content Hub, we previously deployed a set of built-in analytic rule templates designed specifically for Firewall telemetry. One of these rules is: “High severity malicious activity detected”. This rule evaluates IDPS logs and looks for: High-confidence signatures, known exploit techniques and malicious categories identified by Firewall IDPS. Step 5: Sentinel creates an incident When the analytic rules are met, Microsoft Sentinel automatically: Raises an alert Groups related alerts into an incident Extracts entities such as IP addresses, severity, and evidence In this case, the source IP 10.0.100.20 is clearly identified as the malicious actor and attached as an IP entity to the incident. This marks the transition from detection to response. Step 6: An automation rule triggers the playbook To avoid manual response, we configured a Sentinel automation rule that triggers whenever: An incident is created The analytic rule name matches any of the analytic rules we configured The automation rule immediately triggers a Logic App playbook named AzureFirewallBlockIPaddToIPGroup. This playbook is available as part of the Azure Firewall solution and can be deployed directly from the solution package. In addition, a simplified version of the playbook is published in our GitHub repository, allowing you to deploy it directly to your resource group using the provided ARM template. This is where automated containment begins. Step 7: The playbook aggregates and updates the IP Group The playbook performs several critical actions in sequence: Extracts IP entities from the Sentinel incident Retrieves the existing Azure Firewall IP Group named MaliciousIPs Checks for duplicates to avoid unnecessary updates Aggregates new IPs into a single array/list Updates the IP Group in a single operation. It is important to note that the playbook managed identity should have contributor access on the IP Group or its resource group to perform this action. In our scenario, the IP 10.0.100.20 is added to the MaliciousIPs IP Group. Step 8: Firewall policy enforces the block immediately Azure Firewall already has a network rule named BlockMaliciousTraffic configured with: Source: MaliciousIPs IP Group Destination: Any Protocol: Any Action: Deny Because the rule references the IP Group dynamically, the moment the playbook updates MaliciousIPs, the firewall enforcement takes effect instantly — without modifying the rule itself. Traffic originating from 10.0.100.20 is now fully blocked, preventing any further probing or communication with the destination. The threat has been effectively contained. When a SOC analyst opens the Sentinel incident, they see that containment has already occurred: the malicious IP was identified, the IP Group was updated, and the firewall block is in effect — all with a full audit trail of every automated action taken, from detection through response. No manual intervention was required. Conclusion With these five new IDPS detections, Azure Firewall closes the gap between network-level signal and SOC-level action. Raw signature telemetry is automatically transformed into severity-aware, MITRE ATT&CK-mapped alerts inside Microsoft Sentinel and Microsoft Defender XDR — giving security teams correlated, investigation-ready incidents instead of isolated log entries. Combined with automation playbooks, the result is a fully integrated detect-and-respond workflow: Azure Firewall identifies malicious behavior, Sentinel raises and enriches the incident, and a Logic App playbook contains the threat by updating firewall policy in real time — all without manual intervention. These detections are included at no additional cost. Simply install the Azure Firewall solution from the Microsoft Sentinel Content Hub, and the analytic rules automatically appear in your Sentinel workspace — ready to enable, customize, and operationalize. Get started today: Azure Firewall with Microsoft Sentinel overview Automate Threat Response with Playbooks in Microsoft Sentinel Azure Firewall Premium features implementation guide Recent real‑world breaches underscore why these detections matter. Over the past year, attackers have repeatedly gained initial access by exploiting public‑facing applications, followed by command‑and‑control activity, web shell deployment, cryptomining, and denial‑of‑service attacks. Incidents such as the GoAnywhere MFT exploitation, widespread web‑application intrusions observed by Cisco Talos, and large‑scale cryptomining campaigns against exposed cloud services demonstrate the value of correlating repeated network‑level malicious signals. The new Azure Firewall IDPS detections are designed to surface these patterns early, reduce alert noise, and feed high‑confidence network signals directly into Microsoft Sentinel and Microsoft Defender XDR for faster investigation and response. Your network telemetry is a first-class security signal - let it work for you! Visit us at RSA 2026 to see the full detection-to-containment workflow live.
Navigating the 2025 holiday season: Insights into Azure’s DDoS defense
The holiday season continues to be one of the most demanding periods for online businesses. Traffic surges, higher transaction volumes, and user expectations for seamless digital experiences all converge, making reliability a non-negotiable requirement. For attackers, this same period presents an opportunity: even brief instability can translate into lost revenue, operational disruption, and reputational impact. This year, the most notable shift wasn’t simply the size of attacks, but how they were executed. We observed a rise in burst‑style DDoS events, fast-ramping, high-intensity surges distributed across multiple resources, designed to overwhelm packet processing and connection-handling layers before traditional bandwidth metrics show signs of strain. From November 15, 2025 through January 5, 2026, Azure DDoS Protection helped customers maintain continuity through sustained Layer 3 and Layer 4 attack traffic, underscoring two persistent realities: Most attacks remain short, automated, and frequently create constant background attack traffic. The upper limit of attacker capability continues to grow, with botnets across the industry regularly demonstrating multi‑Tbps scale. The holiday season once again reinforced that DDoS resilience must be treated as a continuous operational discipline. Rising volume and intensity Between November 15 and January 5, Azure mitigated approximately 174,054 inbound DDoS attacks. While many were small and frequent, the distribution revealed the real shift: 16% exceeded 1M packets per second (pps). ~3% surpassed 10M pps, up significantly from 0.2% last year. Even when individual events are modest, the cumulative impact of sustained attack traffic can be operationally draining—consuming on-call cycles, increasing autoscale and egress costs, and creating intermittent instability that can provide cover for more targeted activity. Operational takeaway: Treat DDoS mitigation as an always-on requirement. Ensure protection is enabled across all internet-facing entry points, align alerting to packet rate trends, and maintain clear triage workflows. What the TCP/UDP mix is telling us this season TCP did what it usually does during peak season: it carried the fight. TCP floods made up ~72% of activity, and ACK floods dominated (58.7%) a reliable way to grind down packet processing and connection handling. UDP was ~24%, showing up as sharp, high-intensity bursts; amplification (like NTP) appeared, but it wasn’t the main play. Put together, it’s a familiar one-two punch: sustain TCP/ACK pressure to exhaust the edge, then spike UDP to jolt stability and steal attention. The goal isn’t just to saturate bandwidth, it’s to push services into intermittent instability, where things technically stay online but feel broken to users. TCP-heavy pressure: Make sure your edge and backends can absorb a surge in connections without falling over—check load balancer limits, connection/state capacity, and confirm health checks won’t start flapping during traffic spikes. UDP burst patterns: Rely on automated detection and mitigation—these bursts are often over before a human can respond. Reduce exposure: Inventory any internet-facing UDP services and shut down, restrict, or isolate anything you don’t truly need. Attack duration: Attackers continued to favor short-lived bursts designed to outrun manual response, but we also saw a notable shift in “who” felt the impact most. High-sensitivity workloads, especially gaming, experienced some of the highest packet-per-second and bandwidth-driven spikes, often concentrated into bursts lasting from a few minutes to several minutes. Even when these events were brief, the combination of high PPS + high bandwidth can be enough to trigger jitter, session drops, match instability, or rapid scaling churn. Overall, 34% of attacks lasted 5 minutes or less, and 83% ended within 40 minutes, reinforcing the same lesson: modern DDoS patterns are optimized for speed and disruption, not longevity. For latency- and session-sensitive services, “only a few minutes” can still be a full outage experience. Attack duration is an attacker advantage when defenses rely on humans to notice, diagnose, and react. Design for minute-long spikes: assume attacks will be short, sharp, and high PPS such that your protections should engage automatically. Watch the right signals: alert on PPS spikes and service health (disconnect rates, latency/jitter), not bandwidth alone. Botnet-driven surges: Azure observed rapid rotation of botnet traffic associated with Aisuru and KimWolf targeting public-facing endpoints. The traffic was highly distributed across regions and networks. In several instances, when activity was mitigated in one region, similar traffic shifted to alternate regions or segments shortly afterward. “Relocation” behavior is the operational signature of automated botnet playbooks: probe → hit → shift → retry. If defenses vary by region or endpoint, attackers will find the weakest link quickly. Customers should standardize protection posture, ensure consistent DDoS policies and thresholds across regions. Monitor by setting the right alerts and notifications. The snapshot below captures the Source-side distribution at that moment, showing which industry verticals were used to generate the botnet traffic during the observation window The geography indicators below reflect where the traffic was observed egressing onto the internet, and do not imply attribution or intent by any provider or country. Preparing for 2026 As organizations transition into 2026, the lessons from the 2025 holiday season marked by persistent and evolving DDoS threats, including the rise of DDoS-for-hire services, massive botnets underscore the critical need for proactive, resilient cybersecurity. Azure's proven ability to automatically detect, mitigate, and withstand advanced attacks (such as record-breaking volumetric incidents) highlights the value of always-on protections to maintain business continuity and safeguard digital services during peak demand periods. Adopting a Zero Trust approach is essential in this landscape, as it operates on the principle of "never trust, always verify," assuming breaches are inevitable and requiring continuous validation of access and traffic principles that complement DDoS defenses by limiting lateral movement and exposure even under attack. To achieve comprehensive protection, implement layered security: deploy Azure DDoS Protection for network-layer (Layers 3 and 4) volumetric mitigation with always-on monitoring, adaptive tuning, telemetry, and alerting; combine it with Azure Web Application Firewall (WAF) to defend the application layer (Layer 7) against sophisticated techniques like HTTP floods; and integrate Azure Firewall for additional network perimeter controls. Key preparatory steps include identifying public-facing exposure points, establishing normal traffic baselines, conducting regular DDoS simulations, configuring alerts for active mitigations, forming a dedicated response team, and enabling expert support like the DDoS Rapid Response (DRR) team when needed. By prioritizing these multi-layered defenses and a well-practiced response plan, organizations can significantly enhance resilience against the evolving DDoS landscape in 2026.
