Azure Private Link is a private connection to Azure PaaS services. However to really understand private link, you need to understand what is happening under the covers - with DNS.
Before you enable Private Link for a PaaS service e.g. Azure SQL, if you had an Azure PaaS service URL e.g. Sql321.database.windows.net (a global zone), the following would be the DNS resolution that would occur:
- You had a virtual machine that made a request to Sql321.database.windows.net
- This DNS request resolved to a DNS CNAME record and was forwarded by using a redirect (CNAME) to another regional DNS zone of westeurope1-a.control.database.windows.net – as this database was deployed into West Europe
- Another lookup would take place of westeurope1-a.control.database.windows.net, which would then resolve to a DNS A record comprising of the public IP address of the SQL database
This would be great if the SQL database was open to the public internet, but this is not good as far as security goes…..
To fix this, use Private Link.
After you turn on Private Link for the Azure SQL database. Rather than having the initial CNAME redirect to a regional lookup, we insert a a different CNAME redirect which is Sql321.privatelink.database.windows.net – this is for both external DNS resolution and internal Azure DNS resolution. The first two DNS resolution steps are as follows:
- You had a virtual machine that made a request to Sql321.database.windows.net
- This DNS request resolved to a DNS CNAME record and was forwarded by using a redirect (CNAME) to another regional DNS zone of Sql321.privatelink.database.windows.net
From here, the DNS forwarding & resolution this does exactly the same as before. However, the only difference here means that you can make use of split DNS, leverage an Azure internal DNS zone. Rather than Sql321.privatelink.database.windows.net resolving to a public CNAME record, you can have Sql321.privatelink.database.windows.net resolving to a private IP address (Private Link).
This diagram below walks you through the process:
https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns
While this exact Private Link DNS redirection is true for most Azure PaaS services, it’s slightly different for Azure Monitor/Log Analytics, due to other underlining URLs in which the MMA (Microsoft Management Agent) uses and the generic nature of the other primary Azure Monitor URLs. Azure Monitor is slightly unique whereas some of the Azure Monitor URLs are global DNS entries the same for all customers and are not customer specific (e.g. monitor.azure.com), hence the reason to use the AMPLS (Azure Monitor Private Link Scope) which then makes it more customer specific. In comparison from above, the URL Sql321.privatelink.database.windows.net is customer specific.
In the Azure Portal, when you setup the Azure Monitor Private Link Scope resource (Microsoft.Insights/PrivateLinkScopes), you then choose the relevant workspace on the one side, then you tell it to setup a Private Endpoint on the other side.
When creating the Private Endpoint, this process also creates the necessary Azure DNS private zones and links the Azure DNS zones to a vNet that you choose.
The AMPLS glues both sides (workspace & private endpoint) together from a backend networking perspective.
Some URLs for Azure Monitor are customer specific, and as you only enter in the workspace ID & key into the MMA, the MMA adds the workspace ID as the prefix to the URL in which it connects to:
- {workspace_ID}.oms.opinsights.azure.com
- e.g. b5cd151b-34c5-4aa0-9447-3aa3d7b2c4ed.oms.opinsights.azure.com
- {workspace_ID}.ods.opinsights.azure.com
- e.g. b5cd151b-34c5-4aa0-9447-3aa3d7b2c4ed.ods.opinsights.azure.com
- {workspace_ID}.agentsvc.azure-automation.net
- e.g. b5cd151b-34c5-4aa0-9447-3aa3d7b2c4ed.agentsvc.azure-automation.net
The DNS conditional forwarding aspect of AMPLS uses 4 primary URLs, and these should be setup like the following for the DNS private zones which ultimately map to the private endpoint:
- privatelink.oms.opinsights.azure.com
- privatelink.ods.opinsights.azure.com
- privatelink.agentsvc.azure-automation.net
- privatelink.monitor.azure.com
As for the other URLs for Azure Monitor (Log Analytics) & Application Insights that the MMA uses, the following discusses their behaviour when AMPLS is setup:
- oioms(mds).blob.core.windows.net
- Not needed if Azure Monitor is setup for Private Link. Without Private Link, MMAs use this URL to download their configuration, however with Private Link enabled for Azure Monitor (AMPLS) the MMA configuration is sent directly to the MMA bypassing the storage account.
- Although this URL is only used without Azure Monitor Private Link, this is regional, e.g.
seauoiomsmds.blob.core.windows.net for Australia Southeast workspaces or ccanoioms.blob.core.windows.net for Canada Central workspaces
- scadvisorcontent.blob.core.windows.net
- This is to allow the MMA to download solution packs, the storage account from which MPs are downloaded
- This is also used for updates, bug fixes or feature updates to existing solution/management packs.
- At the time of writing, this is a temporary limitation with Private Link and as a result, customers will need to allow this URL outbound to the internet from each MMA as per this link.
- advisor33083311296362384.blob.core.windows.net (example URL)
- If Azure Monitor Private Link is not used, we create a storage account on behalf of customers for each workspace. This URL will be different for each customer.
- This URL is used if you setup and use custom logs & IIS logs. However with Azure Monitor Private Link, this is not used.
- To ingest custom logs on Azure Monitor Private Link, you must use your own storage accounts and associate them with Log Analytics workspace(s) as per this link.
If you're using the Update Management solution for Azure Monitor/Log Analytics, then one component of this is Azure Automation - here's the article for Private Link for Azure Automation.
More details for AMPLS here https://docs.microsoft.com/en-gb/azure/azure-monitor/platform/private-link-security and a diagram below which walks you through it.
https://docs.microsoft.com/en-us/azure/azure-monitor/platform/private-link-security
A good test, once you turn on Private Link for an Azure PaaS service, from outside using a tool like https://tools.dnsstuff.com/ do a DNS Lookup on the CNAME of the name one of the PaaS service URLs turned on for private link e.g. Sql321.database.windows.net, you'll notice that it will resolve to Sql321.privatelink.database.windows.net. which will then ultimately resolve to a public IP address as there's no association with the Azure DNS private zones.
As for the minimum MMA (Microsoft Management Agent) to use for Private Link, its agent version 10.20.18038.
More information, here's some videos all about Azure Private Link:
https://www.youtube.com/watch?v=Z0Xuvwi0838
https://www.youtube.com/watch?v=aVFV1_ZwAEY
https://www.youtube.com/watch?v=--ri7oy0Cgw
And of course, our very own docs site on the topic - https://docs.microsoft.com/en-us/azure/private-link/