Azure Monitor Private Link

By Ronnie Quan


Why we care about Azure monitor private link

  • Connect privately to Azure Monitor without opening up any public network access
  • Ensure your monitoring data is only accessed through authorized private networks
  • Prevent data exfiltration from your private networks by defining specific Azure Monitor resources that connect through your private endpoint
  • Keep all traffic inside the Microsoft Azure backbone network

It’s not endpoint per resource

Azure monitor private link seems complicated, it’s not similar to other Azure PaaS services, there are at least ten Azure endpoints involved, and some of them are global.

When configure private endpoint target resource, instead of using existing application insight or log analytics workspace, Azure monitor private link scope has to be created as the target resource.

Furthermore, DNS configuration is also challenging, there is an issue called DNS override.

I read MS doc, did a lab in order to better understand product feature.

Feature Assessment

Lab Environment

  • Connect activity log to a log analytics workspace for injection test
  • Teams SSO bot web app is linked to an application insight
  • Azure Window Sever 2019 Virtual Machine for private link validation from Azure portal
    (To save cost, I provisioned spot instance Standard_A2_V2 SKU VM, which is listed as 1/6 of the regular price, even though the actual charged price is around $0.08/hour, but it still saves a lot)

Working Scenario — All In

In this test, assume all application insight and all log analytics works are converted to private endpoint at same time, network isolation is configured to deny public injection and public query.

Follow MS Doc

From a public network device (e.g my home PC), I lost the access to both the application insight and log analytics workspace, but from the Azure VM running from the vnet, all works.

Log Analytics Workspace Only Scenario

Given the all or nothing challenge of application insight, I experimented the Azure monitor private link for log analytics only.

When configure DNS records for Azure monitor private endpoint, I omit *, only configure workspace FQDN.

Allow public network access for application insights

The network isolation for log analytics workspace denies public network access.

From my private network, I’m not able to query log analytics any more from Azure portal. Even though application insight has workspace specific FQDN, it still relies on the global Azure monitor endpoint.

Server: UnKnown
Non-authoritative answer:

Is log analytics workspace injection still working via private link? Now let’s allow query from public network, so we can validate if recent log is captured.

Now from my Azure VM, I’m able to query the log from workspace, and it shows most recent log entries.

Allow public network access to application insight works fine.


Application Insight, All or Nothing

As MS document says, once turned on Azure monitor private link, it’s all or nothing for application insight, since both query and injection endpoint are global.

Log Analytics Workspace, Partially All or Nothing

Given the all or nothing challenge of application insight, can we turn on Azure monitor private link for just log analytics and leave application insight for future phases?

When workspace specific FQDN points to private IP, and leave * FQDN unchanged as public, Azure portal log analytics query stops working, since query depends on Azure monitor global FQDN, e.g (Part of CNAME chain

Log analytics workspace query works with compromise when Allow public network access for queries in log analytics workspace network isolation blade.

AMPLS Limits and DNS Override

Azure monitor component has to be connected to AMPLS in order to access via private link, but one AMPLS can only connect to maximum 50 resources.

Each VNet can only connect to one AMPLS.

Not sure these limits are hard limit or soft limit. If we design based on the documented limit, when have hundreds or thousands of workspace or app insights, we will need multiple Azure monitor private endpoint and multiple private link scope.

That means following global FQDNs, each one will need to be resolved to different private IP, depends on the specific VNet.

Now we are facing DNS override issue

For a pure Azure cloud environment, this can be resolved by linking VNet to a specific zone and separate the networks at the DNS level. However in corporate environment, it’s hybrid cloud environment, there are private cloud and multiple public cloud adoptions, seems to me it’s an impossible mission to make Azure monitor private link work, just think about the coordination among multiple teams, this task is already a big deal.




All blogs are strictly personal and do not reflect the views of my employer, focus on cloud networking, cloud security, web and API security.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Cloud Journey

All blogs are strictly personal and do not reflect the views of my employer, focus on cloud networking, cloud security, web and API security.