Cannot create VipAvailability metric over my AKS load balancer

Hello Azim Sobitov,

Greetings!

Thanks for raising this question in Q&A forum.

The error you are seeing when trying to create a VipAvailability metric alert on your AKS Load Balancer is most likely happening because of one of two reasons: either the Load Balancer resource being targeted is managed by AKS (and Azure restricts direct metric alert creation on AKS-managed resources through the portal/Bicep in certain ways), or there is a mismatch in how the metric name is being referenced in your Bicep template or portal configuration. Let me walk you through the correct approach.

First, an important thing to understand about VipAvailability

VipAvailability is actually the CLI metric name for a metric whose display name in the Portal and ARM/Bicep is "Data path availability". When specifying the metric name via the --metric CLI parameter, VipAvailability is used — for example, the metric "Data path availability" maps to --metric VipAvailability in CLI. However, in Bicep and ARM templates, you must use the correct internal metric name. This mismatch is a very common source of confusion.

Step 1: Confirm the correct metric name for your resource

Run this CLI command to list all available metric definitions on your AKS Load Balancer, and find the exact metric name to use:

az monitor metrics list-definitions \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.Network/loadBalancers/<lb-name>

Look for the metric with localizedValue of "Data path availability" — the value field next to it is the exact name you must use in Bicep.

Step 2: Use the correct metric name in your Bicep template

The correct CLI metric name for Data path availability is VipAvailability, with a recommended aggregation of Average. In Bicep/ARM, use it like this:

resource metricAlert 'Microsoft.Insights/metricAlerts@2018-03-01' = {
  name: 'vip-availability-alert'
  location: 'global'
  properties: {
    description: 'Alert on Data Path Availability'
    severity: 2
    enabled: true
    scopes: [
      '/subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.Network/loadBalancers/<aks-lb-name>'
    ]
    evaluationFrequency: 'PT1M'
    windowSize: 'PT5M'
    criteria: {
      'odata.type': 'Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria'
      allOf: [
        {
          name: 'VipAvailabilityCheck'
          metricName: 'VipAvailability'
          metricNamespace: 'Microsoft.Network/loadBalancers'
          operator: 'LessThan'
          threshold: 90
          timeAggregation: 'Average'
          criterionType: 'StaticThresholdCriterion'
        }
      ]
    }
    actions: []
  }
}

Step 3: Target the correct Load Balancer resource

AKS creates and manages its own Load Balancer inside the node resource group (typically named MC_<resourcegroup>_<clustername>_<region>). Make sure your metric alert scope points to the Load Balancer inside that node resource group — not a custom one. To find it:

az network lb list --resource-group MC_<rg>_<clustername>_<region> --query "[].{Name:name, ID:id}" -o table

Use the ID returned here as the scope in your Bicep alert.

Step 4: Verify via Portal

If you prefer the Portal:

1. Go to Azure Monitor → Alerts → Create Alert Rule.
2. Under Scope, click Select resource → filter by resource type Load Balancers → navigate to the AKS node resource group and select the AKS Load Balancer.
3. Under Condition, search for "Data path availability" (not VipAvailability — that is only for CLI).
4. Set aggregation to Average, threshold to your desired value, and complete the setup.

Step 5: If the metric still does not appear

This could be because the AKS Load Balancer has not yet emitted any metric data (new clusters take a few minutes to start populating metrics). Wait 5–10 minutes after the cluster is active and retry. Also confirm the Load Balancer SKU is Standard VipAvailability and other diagnostic metrics are only available on Standard Load Balancer, not Basic SKU.

Quick Summary: Use "Data path availability" as the display name in the Portal and VipAvailability as the metric name in Bicep/CLI. Always target the AKS-managed Load Balancer inside the node resource group (MC_...), not a custom resource group. Make sure your Load Balancer is Standard SKU and has been active long enough to emit metrics.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

resource aks_lb_alert 'Microsoft.Insights/metricAlerts@2018-03-01' = {
  name: '${CONFIG.SUB_DOMAIN}_lb_alert'
  location: 'global'
  tags: {
    tagName1: 'tagValue1'
    tagName2: 'tagValue2'
  }
  properties: {
    actions: [
      {
        actionGroupId:actionGroupId
      }
    ]
    autoMitigate: true
    criteria: {
      'odata.type': 'Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria'
      allOf:[
        {
          threshold:95
          criterionType:'StaticThresholdCriterion'
          metricName:'VipAvailability'
          operator:'LessThan'
          timeAggregation:'Average'
          skipMetricValidation:true
          name:'Metric1'
          metricNamespace:'Microsoft.Network/loadBalancers'
        }
      ]
    }
    description: 'vanta'
    enabled: true
    evaluationFrequency: 'PT1M'
    scopes: [
      kube_internal.id
    ]
    severity: 3
    targetResourceRegion: CONFIG.LOCATION
    targetResourceType: 'Microsoft.Network/loadBalancers'
    windowSize: 'PT5M'
  }
}

my current bicep module. As you can see I am referencing the right metric
I can create the same metric on my other AKS Load Balancers

On my screenshot, you can I am choosing Data path availability

Thank you for the clarification, Azim Sobitov! That is really helpful your Bicep is correctly structured and you are already selecting "Data path availability" in the Portal. Since the same metric alert works on your other AKS Load Balancers but fails only on this specific one, the issue is almost certainly specific to this particular Load Balancer resource rather than your code or configuration.

Here are the focused next steps based on your update:

1. Check if this specific Load Balancer has ever emitted metric data

Since it works on your other AKS Load Balancers, the problem may be that this particular Load Balancer has not yet generated any metric data points. Azure Monitor metric alert creation can sometimes fail or behave unexpectedly when the target resource has no historical metric data. Try running this command to verify:

az monitor metrics list \
  --resource <kube_internal_resource_id> \
  --metric VipAvailability \
  --aggregation Average

If the result returns an empty timeseries, the Load Balancer has not emitted data yet. Give it some time with active traffic and retry.

2. Check if skipMetricValidation: true is actually being honoured

You already have skipMetricValidation: true in your Bicep, which is the correct flag to bypass metric validation for resources with no data yet. However, note that this flag only skips validation — it does not guarantee creation succeeds if there is a resource-level issue. Confirm that your Bicep deployment is not silently falling back to an older API version that ignores this flag. The 2018-03-01 API version does support it, so this should be fine.

3. Verify the kube_internal.id is resolving to the correct resource

Since the same Bicep works on other Load Balancers, the most likely issue now is that kube_internal.id is resolving to a resource ID that is either incorrect, in a different subscription, or in a resource group where you do not have the right permissions to create alert rules. Double-check by running:

az network lb show --ids <kube_internal_resource_id> --query "{name:name, id:id, sku:sku.name}" -o table

Confirm it returns the expected Load Balancer name and that the SKU is Standard.

4. Check for a missing Reader role on this specific Load Balancer

Even though your Bicep syntax is correct, Azure Monitor needs Reader access on the scoped resource to create metric alerts. It is possible that this particular Load Balancer's resource group has a different RBAC setup compared to your others. Verify by going to the Azure Portal → the Load Balancer resource → Access Control (IAM) → and confirming your deployment identity has at least Reader role and Monitoring Contributor role on this resource.

5. If everything looks correct — raise an Azure Support ticket

Since your code is right and it works on other Load Balancers, this is most likely a platform-side inconsistency with this specific resource. Please open a support request and share the exact error message from the portal screenshot along with the resource ID of kube_internal. The support team can investigate whether this Load Balancer has any backend registration issues with Azure Monitor.

Hi Azim Sobitov,

Could you please share the requested details via private message?