Azure Application Gateway’s Web Application Firewall (WAF) has a new tool in its toolbox, exceptions are now in public preview. We already have other tools for allowing traffic: custom rules, exclusions, and disabling rules. Exceptions allow you to bypass WAF inspection for specific requests.

The four-tool comparison

Start by checking the WAF logs to confirm the false positive, then apply the right control.

Why exceptions are interesting

Unlike exclusions, which exclude specific request attributes from inspection, exceptions control which security rules are evaluated for matching requests.

In practice, that means you can keep a rule fully active for all traffic and skip it only for the narrow, identifiable requests that trip it falsely. For example, a specific API path like /api/search that legitimately sends payloads the SQLi rules flag — you scope the exception to that path, and the rule keeps protecting everything else.

Caveats

Choosing the right tool takes some evaluation. With exceptions specifically, expect to iterate: because they’re so narrow, you often end up discovering request by request what you need to open up — the rule stays fully active and keeps blocking everything else (assuming you’re running WAF in prevention mode).

The exceptions feature has some limitations that are important to know about.The current documentation provides details on theese.

• Each WAF policy supports up to 60 exceptions.

• An Application Gateway can have a total of 60 exceptions, regardless of how many WAF policies are associated with the gateway.

• Within a single exception, there are limits of 600 IP addresses, or 10 URIs, or 10 request headers.

Referances

• Microsoft Learn - Azure Application Gateway WAF exceptions list

ExpressRoute traffic visibility is a gap most Azure observability doesn't fill - As a platform engineer i'll be sharing my findings and observations setting up ExpressRoute Traffic Collector using infrastructure as code with the AzApi provider. Hopefully by the end of this, you will be familiar with what it does, if it makes sense to set it up in your platform and see a practical IaC example

What challenges does it solve?

Traffic Collector makes sense to evaluate when your operational question is specifically about the hybrid boundary.

1. What traffic is actually crossing my ExpressRoute?

2. Who are the top talkers?

3. Which source/destination pairs are consuming the circuit?

It solves the visibility gap between on-premises and Azure. Traffic Collector observes sampled flows at the Microsoft Enterprise Edge (MSEE) with a rate of 1:4096 and aggregates flows - so it is not packet capture and shouldn't be treated as a complete record of every connection. It handles the observation independently of how traffic is routed inside Azure. For comparison, in my previous writing I covered VNet flow logs - those primarily solve the challenge of What communicates inside our Azure VNets.

I would highly recommend having a look at Jose Morenos article on ExpressRoute traffic visibility to gain a deeper understanding about the differences between VNet Flow Logs and ExpressRoute Traffic Collector.

Overview of Traffic Collector

The Collector sits at the MSEE routers and provides flow-level visibility for traffic traversing an ExpressRoute circuit. It samples flow metadata such as source and destination, ports, protocol and traffic volumes for traffic crossing the ExpressRoute private or Microsoft peering. The collected records are aggregated, and can be exported to Log Analytics, Storage, or Event Hubs.

Infrastructure as code setup - AzApi

The setup has three parts to ensure the creation of the Traffic Collector instance, collector policy and a diagnostic setting to send the logs to the desired destination - in my example, Log Analytics Workspace.

// Creating the ExpressRoute Traffic Collector resource on the circuit
resource "azapi_resource" "er_traffic_collector" {
  type      = "Microsoft.NetworkFunction/azureTrafficCollectors@2022-11-01"
  name      = var.er_traffic_collector_name
  parent_id = var.parent_id
  location  = var.location
  tags      = var.tags
}

// Creating the collector policy for the ExpressRoute Traffic Collector and defining its ingestion and emission policies
resource "azapi_resource" "er_traffic_collector_policy" {
  type      = "Microsoft.NetworkFunction/azureTrafficCollectors/collectorPolicies@2022-11-01"
  name      = var.er_traffic_collector_policy_name
  parent_id = azapi_resource.er_traffic_collector.id
  location  = var.location

  depends_on = [azapi_resource.er_traffic_collector]

  body = {
    properties = {
      ingestionPolicy = {
        ingestionType = "IPFIX"
        ingestionSources = [
          {
            resourceId = var.er_circuit_id
            sourceType = "Resource"
          }
        ]
      }
      emissionPolicies = [
        {
          emissionType = "IPFIX"
          emissionDestinations = [
            {
              destinationType = "AzureMonitor"
            }
          ]
        }
      ]
    }
  }
}


// Sending the IPFIX data to Log Analytics Workspace
resource "azapi_resource" "er_traffic_collector_to_law" {
  type      = "Microsoft.Insights/diagnosticSettings@2021-05-01-preview"
  name      = "er-traffic-collector-to-law"
  parent_id = azapi_resource.er_traffic_collector.id

  depends_on = [azapi_resource.er_traffic_collector_policy]

  body = {
    properties = {
      workspaceId = var.log_analytics_workspace_id
      logs = [
        {
          category = "ExpressRouteCircuitIpfix"
          enabled  = true
        }
      ]
    }
  }
}

A few things worth noticing:

• depends_on is needed to ensure the policy is created after the Traffic Collector instance.

• Traffic Collector — parent_id = var.parent_id (the RG ID for the ExpressRoute Circuit)

• ``destinationType` in the collector policy accepts AzureMonitor. If you need Event Hubs or Storage, that's handled through a separate diagnostic setting rather than through this body.

• Verify that you aren't already sending the log category with diagnostic settings, If you are, the diagnostic settings code block isn't needed

Gotchas

• Traffic Collector is currently supported for ExpressRoute Circuits with 1 gbps or greater - with private of Microsoft peering. No SKU restrictions.

• The ExpressRoute circuit, the Traffic Collector, and the Log Analytics workspace must all sit in the same geo-political region.

• The Traffic Collector resource itself is accessed from the ExpressRoute circuits blade. Diagnostic settings created by IaC land on the circuit.

• Data starts flowing into Log Analytics within minutes, though how quickly depends on traffic volume — the 1:4096 sampling means low-volume periods may take longer to surface first records.

This is part 2 on Azure network observability. That closes the planned series — more network observability posts will come as I run into things worth writing about.

Referances

References

• ExpressRoute traffic visibility: Flow Logs or Traffic Collector? — Jose Moreno (Cloudtrooper)

• Microsoft.NetworkFunction/azureTrafficCollectors — Terraform reference

• azapi provider — NetworkFunction 2022-11-01 type definitions (GitHub)

• Microsoft Learn Configure Traffic Collector for ExpressRoute

Network monitoring beyond what flows through your firewall or NVA gives you a more holistic view of your traffic — patterns, trends, and what never touches the firewall in the first place. That's where VNet flow logs and traffic analytics come in.

Why VNet flow logs and Traffic Analytics

VNet flow logs is a Network Watcher feature that captures network traffic for a Virtual Network and writes the raw output to a blob container in a designated storage account. This feature can be enabled at a VNet, subnet, or NIC level. The logs on their own aren't very useful, but paired with Traffic Analytics, the picture is clearer.

Traffic Analytics is what turns them into something you can work with, it ingests the raw logs, enriches them, and lands them in a Log Analytics workspace where you can query and visualise the data. A built-in dashboard covers the common views out of the box. Information such as allowed vs blocked, top talkers, and threat hits.

why bother enabling them

Each platform team should weigh the monitoring value setting this solution up against the cost — storage and Log Analytics ingestion aren't free, so decide before enabling broadly. A few questions that can help out:

1. Do we need visibility into Azure traffic that does not traverse our firewall?

2. Do we need to troubleshoot workload connections — for example, from an Azure workload to a private endpoint?

3. Do we need visibility into inter-VNet traffic?

Automating deployment with Azure Policy

In an enterprise environment with several spoke networks that each need a Network Watcher, you'll want to automate the deployment. Azure Policy has a built-in policy definition that does exactly that: Configure virtual network to enable Flow Log and Traffic Analytics.

Configuring this with Enterprise Policy as Code (EPAC) requires a policy assignment at your target scope that references the built-in policy.

A few things worth knowing about the assignment:

1. policyId hooks up the assignment with the correct policy definition

2. Flow logs are enabled per region, so each region needs its own assignment.

3. networkWatcherRG and networkWatcherName values are hardcoded (explained below)

4. Retention can be 30 or 60 days.

5. You can centralise both: raw logs to a shared storage account, Traffic Analytics to a shared Log Analytics workspace.

{
  "$schema": "https://raw.githubusercontent.com/Azure/enterprise-azure-policy-as-code/main/Schemas/policy-assignment-schema.json",
  "nodeName": "/root",
  "definitionEntry": {
    "policyId": "/providers/Microsoft.Authorization/policyDefinitions/3e9965dc-cc13-47ca-8259-a4252fd0cf7b",
    "displayName": "Configure virtual network to enable Flow Log and Traffic Analytics"
  },
  "assignment": {
    "name": "Configure VNet Flow Logs and Traffic Analytics - Norway East",
    "displayName": "Configure VNet Flow Logs and Traffic Analytics - <REGION>",
    "description": "Deploys and enables VNet flow logs with Traffic Analytics for virtual networks in the specified region. Flow logs are written to a central storage account and Traffic Analytics data is sent to a Log Analytics workspace. Each subscription hosts its own Network Watcher flow log resource."
  },
  "metadata": {
    "assignedBy": "epac/<ID>/prod"
  },
  "parameters": {
    "effect": "DeployIfNotExists",
    "vnetRegion": "norwayeast",
    "storageId": "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT>",
    "timeInterval": "60",
    "workspaceResourceId": "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.OperationalInsights/workspaces/<LOG_ANALYTICS_WORKSPACE>",
    "workspaceRegion": "<REGION>",
    "networkWatcherRG": "NetworkWatcherRG",
    "networkWatcherName": "NetworkWatcher_norwayeast",
    "retentionDays": "30"
  },
  "scope": {
    "prod": [
      "/providers/Microsoft.Management/managementGroups/<MANAGEMENT_GROUP>"
    ]
  }
}

The naming-consistency dependency

At one VNet, most of these are quirks. Across dozens of subscriptions and Virtual Networks, they're the difference between a working rollout and a broken one.

For this to scale, the values networkWatcherRGand networkWatcherName must match across subscriptions where there is a VNet you want to set up flow logs and Traffic Analytics. The assignment explicitly checks for Network Watchers in a Resource Group following this naming standard and if conditions are met the DeployIfNotExists effect will trigger. The compliance page will help you narrow down whether a subscription is missing the Resource Group entirely, or has the Resource Group but is missing the Network Watcher.

A couple of smaller things worth knowing

Storage accounts can be private

You might expect flow logs to require public network access on the storage account. They don't — you can lock the storage account down and put the blob service behind a private endpoint. Flow logs will still write.

Data Collection Rule (DCR) and Data Collection Endpoint (DCE)

Traffic Analytics deploys a Data Collection Rule and Data Collection Endpoint into the resource group containing the Log Analytics workspace. If you tightly control which resource types are allowed at that scope, make sure both are permitted. I had some issues debugging this part, because it does not show up in Activity Logs.

References

• VNet flow logs overview

• Built-in policy definition

• Aidan Finn MVP - VNet Flow Logs

Introduction

This article will go over how to enable a PIM role assignment permanently without any expiration date for Azure resources with Terraform. You might encounter a 365-day limitation on PIM eligible role assignments. This article will show how to work around that.

What I was trying to achieve

While improving our security posture, we were switching from permanent normal role assignments to PIM eligible role assignments for our Entra ID groups. While enabling PIM on these, we ran into a constraint on the maximum eligible assignment duration: The management policy did not allow more than 365 days, so we couldn't set the assignment to have no expiration date. Our goal was to keep administrative overhead low and keep the PIM eligibility permanent on the assigned groups. Without a fix, we'd be renewing role assignments every 365 days, which at scale is untenable

Prerequisites

Understanding the components

PIM for Azure resources vs. Entra roles

PIM can be enabled for Entra roles such as Global Administrator, Security Reader, etc., and the scope is tenant-wide.

But PIM can also be enabled for Azure resources that handle Azure RBAC roles such as Owner, Contributor, etc., and the scope can be set to RG, subscription, or management group level.

My scenario covers PIM eligibility for Azure resources.

Active vs. Eligible

An active assignment means the user has the role right now and can use it without any activation step. This is what a normal azurerm_role_assignment grants, and also what azurerm_pim_active_role_assignment gives but under PIM governance.

An eligible assignment means the user is allowed to hold the role but does not have it until they explicitly activate it in PIM, also known as the just-in-time (JIT) model. This is what my scenario covers, with azurerm_pim_eligible_role_assignment.

Role management policy

A crucial component to understand is the role management policy. This ruleset governs how an eligible assignment or activation behaves. This policy handles multiple controls, one of which is eligibility expiration. This is set at the RG, subscription, or management group level and covers all assignments under the respective scope.

Key observations

Provider version in lock file

We had a lot of back and forth with azurerm_pim_eligible_role_assignment because of an older version of azurerm pinned in our lock file. That version's resource block didn't support all arguments — pin at least 4.79.0 (or latest) and you won't need to think about it.

Existing management policy on the target scope

Before editing, check the management policy already set at your target scope. I was never able to find a dedicated portal view for the underlying policy object itself — the closest is Microsoft docs on Azure resource role settings, which covers the same settings from the role-settings UI. A policy applied at a higher scope, like the subscription, is inherited by every resource group beneath it; it isn't scoped to just the one resource you're editing. That inheritance might make you wonder whether a permanent eligible assignment weakens protection further down. It doesn't: permanent eligibility only changes how long a principal is allowed to stay eligible, not what happens at activation — MFA, approval, and any narrower policy set at a lower scope still apply. What changes is who's responsible for cleaning up stale eligibilities, not which controls fire.

Dependencies

Terraform's apply order comes from resource attribute references, and here the two resources don't reference each other — they each just take scope and role_definition_id as separate input variables. Without an explicit dependency, Terraform is free to create the azurerm_pim_eligible_role_assignment before the azurerm_role_management_policy update has landed, which means the assignment gets created under whatever policy is already active on that scope. If that policy still requires an expiration, the apply fails on the same 365-day constraint from the introduction. Add depends_on = [azurerm_role_management_policy.management_policy] to the role assignment resource block so the policy is guaranteed to apply first.

Terraform automation

Below is an example of how to create:

• Entra ID group

• Management policy with no expiration

• PIM eligible role assignment with no expiration

Group creation

resource "azuread_group" "group" {
  display_name     = var.group_name
  owners           = var.owners
  security_enabled = true
}

Management policy creation with no expiration for PIM role assignments

resource "azurerm_role_management_policy" "management_policy" {
  scope              = var.subscription_id
  role_definition_id = var.role_definition_id

  eligible_assignment_rules {
    expiration_required = false # Ensures expiration is not required in role assignment
  }
}

PIM eligible role assignment creation without expiration

resource "azurerm_pim_eligible_role_assignment" "pim_role_assignment" {
  scope              = var.subscription_id
  role_definition_id = var.role_definition_id
  principal_id       = var.principal_id
  depends_on         = [azurerm_role_management_policy.management_policy] # ensures assignment is compliant with new management policy
}

IAM overview in portal

The screenshot below shows both assignments in the Azure portal's IAM blade. One active permanent, one eligible permanent:

Conclusion

If I did this again, I would understand and check the existing role management policy before touching anything. This is the most crucial part of the setup and requires a good understanding of the backend governance that is not visible in the Entra ID portal.

That upfront effort only pays off if you're repeating it: I'd recommend this approach to any team managing role assignments at scale, but not necessarily for a single role assignment — such a setup would be overkill.