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.