A common scenario is a landing zone where several applications use Azure PaaS services such as Storage, Key Vault, and App Service. In that type of environment, NSP can help you define the trust boundary around sensitive resources and make access expectations more explicit.

A sample architecture pattern

A practical pattern might look like this:

• A shared platform layer with identity, monitoring, and shared services
• Application workloads deployed in different workspaces or subscriptions
• Protected services that should only be reachable from approved internal paths
• Access policies that align with business and security requirements

In this kind of setup, NSP provides a way to enforce the boundary without forcing every resource to be redesigned from scratch.

Implementation considerations

When implementing NSP in a real environment, it helps to start with a small scope. Choose a few critical resources, define their expected access pattern, and validate the policy before expanding it further. This approach tends to be more manageable than trying to secure everything at once.

You should also involve the teams that own the resources. They often know the legitimate access flows better than anyone else, and that context is essential for building accurate policies.

A more realistic Bicep example

In a landing zone, you can start with a simple perimeter definition and then extend it as your access rules become clearer:

targetScope = 'resourceGroup'

@description('Name of the perimeter used in the landing zone')
param perimeterName string = 'landingzone-prod-nsp'

@description('Key Vault instance to protect within the perimeter')
param keyVaultId string = '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-platform-prod/providers/Microsoft.KeyVault/vaults/kv-platform-prod'

@description('App Service that shares the same trust boundary')
param appServiceId string = '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-app-prod/providers/Microsoft.Web/sites/app-prod-api'

resource perimeter 'Microsoft.Network/networkSecurityPerimeters@2024-05-01' = {
  name: perimeterName
  location: 'global'
  tags: {
    Environment: 'prod'
    Platform: 'LandingZone'
    Owner: 'Platform Engineering'
  }
  properties: {
    accessRules: [
      {
        name: 'allow-platform-operations'
        properties: {
          direction: 'Inbound'
          access: 'Allow'
          description: 'Allow platform operations and automation services'
          addressPrefixes: [
            '10.30.10.0/24'
          ]
          destinationPortRanges: [
            '443'
          ]
        }
      }
    ]
    // Link protected resources and define approved inbound sources here.
  }
}

output perimeterId string = perimeter.id
output protectedResources array = [
  keyVaultId
  appServiceId
]

This skeleton is a good starting point for a shared platform environment. From there, you can refine the rules so that only the intended apps, identities, and services are allowed into the protected boundary.

The long-term benefit

The main benefit of NSP is not only stronger security. It is also better consistency. When access control is expressed in a clear and reusable way, it becomes easier to maintain over time and much simpler to explain to other teams.

If you are planning to strengthen your Azure networking posture, NSP is worth exploring as part of a broader strategy that includes private connectivity, identity controls, and monitoring.

Private endpoints are mainly focused on creating a private network path to a specific Azure service. They are often used to ensure that traffic stays within a virtual network and avoids the public internet. In contrast, NSP focuses on the security boundary around a resource and provides a broader access-control model for protecting groups of resources.

When private endpoints are a strong choice

Private endpoints are ideal when you want to:

• Ensure a resource is reachable only through a private network path
• Reduce exposure to the public endpoint
• Build strong network isolation for a specific service

When NSP is more appropriate

NSP is usually more relevant when you want to:

• Protect a set of related resources with shared access rules
• Apply resource-centric security policies consistently
• Improve governance across a broader Azure environment

A practical way to think about them

A useful way to frame the relationship is this: private endpoints focus on connectivity, whereas NSP focuses on perimeter-based access control. In many architectures, they complement each other rather than compete.

You might use private endpoints to isolate a critical service and NSP to enforce a consistent security boundary around a collection of resources that share the same protection requirements.

A Bicep comparison example

Here is a small example that shows the two patterns at a high level:

targetScope = 'resourceGroup'

@description('Storage account that should be reachable through a private path')
param storageAccountId string = '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-data-prod/providers/Microsoft.Storage/storageAccounts/stdataprod001'

@description('Subnet used for the private endpoint')
param privateSubnetId string = '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-network-prod/providers/Microsoft.Network/virtualNetworks/vnet-hub-prod/subnets/snet-private-endpoints'

resource privateEndpoint 'Microsoft.Network/privateEndpoints@2024-11-01' = {
  name: 'pe-stdataprod001'
  location: resourceGroup().location
  tags: {
    Environment: 'prod'
    Purpose: 'Private access'
  }
  properties: {
    subnet: {
      id: privateSubnetId
    }
    privateLinkServiceConnections: [
      {
        name: 'pe-stdataprod001-blob'
        properties: {
          privateLinkServiceId: storageAccountId
          groupIds: [ 'blob' ]
        }
      }
    ]
  }
}

resource perimeter 'Microsoft.Network/networkSecurityPerimeters@2024-05-01' = {
  name: 'app-prod-nsp'
  location: 'global'
  tags: {
    Environment: 'prod'
    SecurityBoundary: 'Shared services'
  }
  properties: {
    accessRules: [
      {
        name: 'allow-app-subnet'
        properties: {
          direction: 'Inbound'
          access: 'Allow'
          description: 'Allow application workloads to reach protected services'
          addressPrefixes: [
            '10.15.40.0/24'
          ]
          destinationPortRanges: [
            '443'
          ]
        }
      }
    ]
    // Use this when you need a resource-centric access control model
    // for a group of protected services.
  }
}

The private endpoint creates a private path, while the perimeter focuses on the access policy around protected resources. In many architectures, both are useful, but for different reasons.

Final recommendation

If you are still deciding between the two, start by asking what problem you are trying to solve. If you need private connectivity, private endpoints are the natural answer. If you need stronger and more centralized access control for protected resources, NSP deserves serious consideration.

In the next article, I will show how to apply these concepts in a realistic Azure architecture.

When you protect PaaS resources with NSP, you are not only controlling network paths. You are also shaping how the resource can be reached and by whom. This is especially valuable for services that store sensitive data or expose APIs to internal systems.

Typical use cases

NSP is a good fit when you want to:

• Limit access to Azure Storage accounts used by critical workloads
• Protect Key Vault instances from unnecessary public access
• Reduce exposure for web apps and other managed services
• Enforce consistent access controls across multiple resources in the same environment

Recommended approach

A practical deployment usually starts with identifying the resources that need the highest level of protection. Then you define the perimeter and decide which identities or services are allowed to connect. The goal is to avoid overly broad access rules while keeping the environment operational.

In many cases, NSP works best when it is combined with other Azure security mechanisms such as private endpoints, role-based access control, and centralized monitoring.

A Bicep skeleton for a protected PaaS perimeter

A simple way to represent the perimeter in infrastructure as code is shown below:

targetScope = 'resourceGroup'

@description('Name of the perimeter protecting shared PaaS resources')
param perimeterName string = 'shared-paas-prod-nsp'

@description('Storage account that should be protected by the perimeter')
param storageAccountId string = '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-app-prod/providers/Microsoft.Storage/storageAccounts/stappprod001'

resource perimeter 'Microsoft.Network/networkSecurityPerimeters@2024-05-01' = {
  name: perimeterName
  location: 'global'
  tags: {
    Environment: 'prod'
    Workload: 'FinanceApp'
    SecurityBoundary: 'PaaS'
  }
  properties: {
    accessRules: [
      {
        name: 'allow-shared-services'
        properties: {
          direction: 'Inbound'
          access: 'Allow'
          description: 'Allow requests from the shared services subnet'
          addressPrefixes: [
            '10.10.20.0/24'
          ]
          destinationPortRanges: [
            '443'
          ]
        }
      }
    ]
    // Link the protected resource and define any additional policy
    // associations as part of your deployment workflow.
  }
}

output perimeterResourceId string = perimeter.id
output protectedStorageAccountId string = storageAccountId

This shows the anchor point for your protected resource boundary. The next step is to define the specific rules that allow only the right identities and services to connect.

What to watch for

One of the main challenges when implementing NSP is keeping the policy understandable. If a perimeter becomes too permissive, the benefit is reduced. It is better to start with a focused scope and expand it carefully as you validate the access pattern.

This makes NSP especially appealing for teams that want to apply network controls without turning every resource into a custom networking project.

In the next article, I will compare NSP with private endpoints and show where each approach is strongest.

At a high level, NSP helps you define a boundary around a set of Azure resources and apply security rules that govern who and what can connect to them. Instead of relying only on traditional network controls, you can add an additional layer of protection that focuses on the resource itself.

This is especially useful when you are working with services such as Azure Storage, Azure Key Vault, or other PaaS resources that might otherwise be exposed by broad network access policies.

Why NSP matters

The main benefit of NSP is simplicity. You can apply a consistent access model to a group of resources without having to redesign the entire network topology. It complements existing tools such as private endpoints, VNets, and firewalls by giving you a resource-centric control plane.

For many teams, this means:

• Better control over inbound traffic to protected resources
• A clearer security posture for shared Azure environments
• Easier enforcement of least-privilege connectivity rules
• Stronger governance for multi-team or multi-subscription architectures

What makes NSP different

Traditional network security often focuses on network segments, subnets, or IP ranges. NSP shifts part of the conversation to the resources themselves. That makes it easier to reason about the security boundary around a target service and to prevent unnecessary exposure.

In practice, this can help organizations reduce the attack surface and make access decisions more explicit.

A simple Bicep example

A minimal starting point for an NSP deployment can look like this:

targetScope = 'resourceGroup'

@description('Name of the network security perimeter')
param perimeterName string = 'contoso-platform-prod-nsp'

@description('Environment tag applied to the perimeter')
param environment string = 'prod'

@description('Resource IDs that should be protected by the perimeter')
param protectedResourceIds array = [
  '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-platform-prod/providers/Microsoft.Storage/storageAccounts/stprodshared001'
  '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-platform-prod/providers/Microsoft.KeyVault/vaults/kv-platform-prod'
]

resource perimeter 'Microsoft.Network/networkSecurityPerimeters@2024-05-01' = {
  name: perimeterName
  location: 'global'
  tags: {
    Environment: environment
    Owner: 'Platform Engineering'
    SecurityBoundary: 'Production'
  }
  properties: {
    // Example rule shape for a production deployment
    accessRules: [
      {
        name: 'allow-platform-engineering'
        properties: {
          direction: 'Inbound'
          access: 'Allow'
          description: 'Allow management traffic from the platform engineering subnet'
          addressPrefixes: [
            '10.20.30.0/24'
          ]
          destinationPortRanges: [
            '443'
          ]
        }
      }
    ]
    // In a production deployment, define resource links and policy
    // associations here as well.
  }
}

output perimeterId string = perimeter.id
output protectedResourceCount int = length(protectedResourceIds)

This example is intentionally simple. In a real deployment, you would extend it with the resources you want to protect and the access rules that define who can reach them.

A good first step

If you are evaluating Azure security controls, NSP is a strong topic to explore early. It is a practical feature for teams that want to modernize their Azure landing zone and strengthen protection around critical services without adding excessive operational complexity.

In the next article, I will focus on how to apply NSP to PaaS resources and what the first implementation steps look like.

• Enable purge protection on your Key Vaults
• Enable soft delete on your Key Vaults
• Enforce network rules on your Key Vaults
• Deny creation of Key Vaults in specific regions
• Enforce the use of private endpoints on your Key Vaults

You are usually very happy with these policies. But now consider the following use case: a Key Vault was deleted by mistake and you want to restore it.

It is very likely that when you try to restore it, you get an error like this:

➜  $removeKeyvault | Undo-AzKeyVaultRemoval
Undo-AzKeyVaultRemoval: Resource 'kvipbd7f00' was disallowed by policy. Policy identifiers: '[{"policyAssignment":{"name":"Deny Key Vaults without IP rules","id":"/subscriptions/subId/resourcegroups/rg-kv-iprules-lab-20260624/providers/Microsoft.Authorization/policyAssignments/assign-keyvault-ip-rule-deny"},"policyDefinition":{"name":"Key Vaults must define at least one IP rule","id":"/subscriptions/subId/providers/Microsoft.Authorization/policyDefinitions/deny-keyvault-without-ip-rules","version":"1.0.0"}}]'.

So you followed Microsoft documentation to restore your Key Vault, but it still fails because of a policy. In this case, the policy checks that at least one IP is configured in the Key Vault network rules.

To work around this issue, the simplest solution is to disable the policy that blocks the Key Vault restoration, restore the Key Vault, and then re-enable the policy. Of course, this only works if you have permissions to disable the policy, and disabling a policy can impact your governance, especially if it affects a large number of resources on a heavily used platform.

There is another solution that is less simple, but more elegant and does not require disabling the policy. It consists of recreating the Key Vault through an ARM or Bicep template. Here I will do it with ARM, but you can convert it to Bicep if you want.

Let’s start by looking at what a deleted Key Vault looks like in JSON.

{
  "Id": "/subscriptions/subId/providers/Microsoft.KeyVault/locations/westeurope/deletedVaults/kvipbd7f00",
  "DeletionDate": "2026-06-24T12:07:06Z",
  "ScheduledPurgeDate": "2026-09-22T12:07:06Z",
  "PublicNetworkAccess": null,
  "VaultUri": null,
  "TenantId": "00000000-0000-0000-0000-000000000000",
  "TenantName": null,
  "Sku": null,
  "EnabledForDeployment": false,
  "EnabledForTemplateDeployment": null,
  "EnabledForDiskEncryption": null,
  "EnableSoftDelete": null,
  "EnablePurgeProtection": true,
  "EnableRbacAuthorization": null,
  "SoftDeleteRetentionInDays": null,
  "AccessPolicies": null,
  "AccessPoliciesText": "",
  "NetworkAcls": null,
  "NetworkAclsText": "",
  "OriginalVault": null,
  "ResourceId": "/subscriptions/subId/resourceGroups/rg-kv-iprules-lab-20260624/providers/Microsoft.KeyVault/vaults/kvipbd7f00",
  "VaultName": "kvipbd7f00",
  "ResourceGroupName": null,
  "Location": "westeurope",
  "Tags": {},
  "TagsTable": null
}

As you can see, there is not much information about the deleted Key Vault. There are no networkAcls and no network rules. Clearly, a lot of information is missing to recreate the Key Vault.

This helps explain why the Key Vault is restored in public mode: that information is lost. Now, if we dig a bit into the API documentation, we find the createMode option, which allows you to create a Key Vault in “Recover” mode.

So we can create a Key Vault using the following ARM template:

{
	"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
	"contentVersion": "1.0.0.0",
	"parameters": {
		"keyVaultName": {
			"type": "string",
			"metadata": {
				"description": "Name of the Azure Key Vault to create or recover."
			}
		},
		"location": {
			"type": "string",
			"defaultValue": "[resourceGroup().location]",
			"metadata": {
				"description": "Location for the Key Vault resource."
			}
		},
		"tenantId": {
			"type": "string",
			"defaultValue": "[subscription().tenantId]",
			"metadata": {
				"description": "Azure AD tenant ID for the Key Vault."
			}
		},
		"skuName": {
			"type": "string",
			"defaultValue": "standard",
			"allowedValues": [
				"standard",
				"premium"
			],
			"metadata": {
				"description": "SKU for the Key Vault."
			}
		},
		"ipRules": {
			"type": "array",
			"defaultValue": [],
			"metadata": {
				"description": "Array of public IPv4 CIDR strings allowed to access the Key Vault (for example: 203.0.113.10/32)."
			}
		},
		"defaultAction": {
			"type": "string",
			"defaultValue": "Deny",
			"allowedValues": [
				"Allow",
				"Deny"
			],
			"metadata": {
				"description": "Default network ACL action."
			}
		},
		"bypass": {
			"type": "string",
			"defaultValue": "AzureServices",
			"allowedValues": [
				"AzureServices",
				"None"
			],
			"metadata": {
				"description": "Traffic that can bypass network ACLs."
			}
		}
	},
	"variables": {
		"ipRuleObjects": "[map(parameters('ipRules'), lambda('ip', createObject('value', lambdaVariables('ip'))))]"
	},
	"resources": [
		{
			"type": "Microsoft.KeyVault/vaults",
			"apiVersion": "2023-07-01",
			"name": "[parameters('keyVaultName')]",
			"location": "[parameters('location')]",
			"properties": {
                "createMode": "recover",
				"tenantId": "[parameters('tenantId')]",
				"sku": {
					"family": "A",
					"name": "[parameters('skuName')]"
				},
				"enabledForDeployment": false,
				"enabledForDiskEncryption": false,
				"enabledForTemplateDeployment": false,
				"publicNetworkAccess": "Enabled",
				"networkAcls": {
					"bypass": "[parameters('bypass')]",
					"defaultAction": "[parameters('defaultAction')]",
					"ipRules": "[variables('ipRuleObjects')]",
				}
			}
		}
	],
	"outputs": {
		"keyVaultResourceId": {
			"type": "string",
			"value": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
		}
	}
}

This template can be called as follows:

New-AzResourceGroupDeployment -name "recover-keyvault" -ResourceGroupName $removekeyvault.ResourceId.split('/')[4] -TemplateFile .\recover-keyvault.json -keyvaultName $removeKeyVault.VaultName  -ipRules @("1.1.1.1/32")

Almost like magic, your Key Vault is properly restored without changing policies. Of course, this template should be adapted to the policies you use.

There is no longer any excuse to disable governance in your production environments. Of course, I recommend testing this template in a test environment before using it in production, especially not as an emergency fix in the middle of the night.

Of course, there is the classic inventory needed to answer simple questions such as:

• How many VMs are currently in use, by OS and SKU?
• How many databases are currently in production?
• How many storage accounts are available?

All of these inventory questions are very easy to answer through Azure Resource Graph.

Now let’s consider the following question:

• What is the total storage capacity across all Azure Storage accounts?

Well, this is where it gets a bit more complicated, because although the metric is available, it is exposed per storage account and, by default, not aggregated.

You can find this answer by looking at each storage account and summing the results of the “Used Capacity” metric.

Otherwise, there is another way through Azure Workbook, which I will show you.

So let’s start by creating a new one (the default one does not suit me in this specific context). We’ll do it through the portal, because building a workbook via infrastructure as code is more of an epic journey than a walk in the park.

Let’s start by adding two filters for subscriptions and resources, as shown below:

For the different resource pickers, make sure to select “Required” and “Allow multiple selection” for both filters, and include the “All” field.

Then it is possible to run a Kusto query to link resources and metrics.

Let’s start by generating a list with all the values for each storage account:

To make it readable, go to the advanced settings and modify the Value field to change the format to Bytes.

And to get an aggregate of the used capacity, simply sum all values using the Stat visualization and select “Sum” in the aggregation options.

There you go! If you would like me to write more articles related to workbooks, feel free to let me know in the comments.

And of course, here is a link to the workbook I created for this use case: Github link

Why, you may ask? For compliance, performance, or latency reasons, it can be crucial to know where your Azure resources are physically located. It can also be important for capacity planning, to verify whether the relevant zones have enough resources to host your infrastructure.

This also helps you manage your CI/CD settings to ensure resources are deployed in zones where capacity is available.

For example, Azure Firewall currently has capacity constraints, as shown here: Azure Documentation

You can find which zone your subscription uses with the following command:

az account list-locations --query "[?availabilityZoneMappings].{availabilityZoneMappings: availabilityZoneMappings, displayName: displayName, name: name}"

This command returns a list of all regions available for your subscription, along with the availability zone mappings for each region. You can then identify the physical zone that matches the logical zone used by your Azure resources.

If you prefer a graphical interface, I recommend App Scout, which lets you visualize different zones and their capacities in real time. It is a very practical tool for managing your Azure resources efficiently. Here is an example for the West Europe region:

A few years ago, I built an Azure Sandbox system that lets me create ephemeral resource groups. With a simple script, I could create a resource group, run my tests, and then deletion would happen automatically based on the date set in a tag. Nothing could be simpler.

Today, to do this, I mainly use a function in my PowerShell profile to create resource groups: the well-known New-AzTestResourceGroup function, which some of you may already have seen in my demos.

Now with AI, it is much faster to tell Copilot: “Create a resource group named demo-rg in France Central and add a storage account.” Great time savings, especially since it can also generate the deployment file for you. However, the resource group does not always include the right tags.

There is a very simple way to add this: just ask Copilot to add the tags you want each time you create a resource group. You can scope this to your workspace, or apply it globally by adding a file in your user directory.

Here is an example of a file you can add in your user directory so Copilot can automatically add tags whenever you create a resource group.

# Azure Resource Group Tagging Convention

## Mandatory Tags for Resource Groups
When creating Azure resource groups, always add the following tags:

- **AutoDelete**: `true`
- **ExpirationDate**: Current date in format `YYYY-MM-DD` (e.g., 2026-03-05)

## Implementation
- Apply these tags when using Bicep, Terraform, ARM templates, or Azure CLI
- Use `resourceGroup()` function in Bicep or equivalent in other IaC tools
- Set tags at resource group creation time, not as an afterthought

And the path is: C:\Users\YourUserName\AppData\Roaming\Code\User\globalStorage\github.copilot-chat\memory-tool\memories

And to finish, here is the article link for the sandbox (in french sorry): https://woivre.fr/blog/2018/11/sandbox-azure-pour-tout-le-monde

That is a small tip so you do not forget to clean up your resources after your tests.

If you have an Azure environment that is fairly standardized and spans multiple subscriptions, you may want to dismiss some recommendations or at least postpone them.

You can do this quickly with a PowerShell script (or another automation approach). To start, you can list the different recommendations with the following command:

Get-AzAdvisorRecommendation -SubscriptionId <SubscriptionId>

Then, you can filter the recommendations you want to dismiss or postpone. For example, if you want to postpone a recommendation for 90 days, you can use the following command:

Disable-AzAdvisorRecommendation -RecommendationName e33855d4-7579-e4d0-c459-23fad3665bd6 -Day 90

And if you simply want to postpone one recommendation type globally, you can use the following command:

get-azAdvisorRecommendation | Where { $_.RecommendationTypeId -eq $recommendationId } | % { $_ | Disable-AzAdvisorRecommendation -Day 120 }

Let’s make 2026 the year we manage recommendations at scale—and leave no active recommendation without a planned action!

For some time now, Microsoft has updated the boot diagnostics configuration for Azure virtual machines. From now on, you can configure boot diagnostics without creating a dedicated storage account. In other words, it is now fully managed by Microsoft.

Here is a Graph query to detect all your VMs that have not yet switched to this new boot diagnostics mode:

resources
| where type =~ "microsoft.compute/virtualMachines"
| where properties.diagnosticsProfile.bootDiagnostics.enabled == true
| where isnotnull(properties.diagnosticsProfile.bootDiagnostics.storageUri)

If this can help you avoid dedicated storage accounts for boot diagnostics, that is one less resource to manage and secure, and it simplifies the configuration of your virtual machines.