In this blog post, I am going to walk through how I created a Private Link in Microsoft Fabric so that access routes over Microsoft’s private backbone network instead of the public internet.

NOTE: It is a bit of a longer blog post as there are quite a few things that need to be configured.

NOTE II: In the next blog post I will show you how to connect from a Public Workspace to a Private Link Workspace using a Managed Private Endpoint

I wanted to document the end-to-end process because there are a few moving parts across Microsoft Fabric and the Azure Portal. The key items I needed to configure were the Fabric tenant setting, the Fabric private link service, the virtual network, a test virtual machine, the private endpoint, and finally DNS testing from inside the virtual network.

What is a Private Link in Microsoft Fabric?

A Private Link in Microsoft Fabric is a secure connectivity feature that uses Azure Private Link and private endpoints to route traffic between my virtual network and Fabric resources over Microsoft’s private backbone network, instead of the public internet.

Prerequisites

Before I started, I made sure I had the following in place:

  • A Microsoft Fabric Capacity
  • A running Fabric F SKU Capacity
  • Access to the required Fabric tenant settings
  • Fabric Workspace Admin permissions
  • Azure permissions to create resources, at minimum Contributor on the subscription or resource group
  • An existing Azure subscription that I would use to create the Azure resources
  • A Fabric workspace that would be used with the Private Link
  • The Workspace ID / GUID from the Fabric workspace URL
  • My Tenant ID

Fabric tenant setting

The first thing I checked was that the Fabric tenant setting was enabled.

Important: I recommend using the same Azure subscription, resource group, and region for all the items created. This keeps the setup simpler and helps avoid potential network issues.

Example configuration

Below is the example configuration I used throughout this setup:

  • Azure Subscription name: Azure subscription 1
  • Resource Group name: MVP_East
  • Location / Region: Australia East
  • Fabric Capacity: Running F Capacity
  • Workspace GUID / ID: 5d7b4573-f0dc-45d8-9f85-d3f03cbb1c1c
  • I also gathered the Workspace ID / GUID from the Fabric workspace URL, which looks like this:
  • https://app.fabric.microsoft.com/groups/{workspace-id}/…

Azure Portal configuration

I first completed the required configuration in the Azure Portal.

Checking the resource provider for Microsoft.Fabric

The first Azure step I completed was making sure that the Microsoft.Fabric resource provider was registered in my tenant

I logged into the Azure Portal and went to my subscription.

Once I was in the subscription, I completed the following steps:

  1. I expanded Settings.
  2. I clicked Resource providers.
  3. I searched for Microsoft.Fabric.
  4. I confirmed that the status was Registered.

Note: If Microsoft.Fabric is not registered, register it before continuing.

Creating the Private Link Service in Azure using an ARM template

Next, I created the Private Link Service in Azure by using an ARM template.

In the Azure Portal, I searched for Deploy a custom template.

I then clicked Build your own template in the editor.

I pasted the following ARM template:

{
  "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.Fabric/privateLinkServicesForFabric",
      "apiVersion": "2024-06-01",
      "name": "pl-workspacename-fabric",
      "location": "global",
      "properties": {
        "tenantId": "<your-tenant-id>",
        "workspaceId": "<your-workspace-id>"
      }
    }
  ]
}

I then updated the highlighted sections:

  • name — I used a meaningful name and prefixed it with pl for private link.
  • tenantId — I used my Tenant ID.
  • workspaceId — I used my Fabric workspace GUID.

Example below

After that, I clicked Save.

On the Basics screen, I selected the subscription, resource group, and instance details.

[Keep existing image: Custom deployment basics]

I clicked Review + create, and once validation completed, the deployment was successful.

Creating the VNET

The next step was creating the virtual network that would be used for the private link.

In the Azure Portal, I searched for Virtual Networks. Once I was in the Virtual Networks blade, I clicked Create.

On the Create virtual network screen, I entered the required details.

  1. I used the same subscription as before.
  2. I selected the same resource group.
  3. I gave the virtual network a meaningful name, for example fabric-vnet.
  4. I made sure the region matched the other resources, in this example Australia East.

I then clicked through to the Address space section and configured the subnet.

I changed the subnet to /24, which allows for 256 addresses.

After that, I clicked Review + create. Once validation passed, I clicked Create.

Once the deployment completed, I could see the virtual network.

Creating a virtual machine inside the virtual network

To test the Private Link, I created a virtual machine inside the virtual network.

In the Azure Portal, I searched for Virtual Machine.

I clicked Create, then selected Virtual machine.

I then entered the virtual machine details.

  1. I used the same subscription as before.
  2. I selected the same resource group.
  3. I gave the virtual machine a name, for example fabric-private-link.
  4. I made sure the VM was in the same region as the virtual network.
  5. I left the default availability option.
  6. I left the default availability zone.
  7. I changed the security type to Standard, because I was only using this VM for initial Private Link testing.
  8. I selected a Windows Server image so that I could RDP into the server to test connectivity.

I entered the administrator account details.

Note: Make sure the administrator credentials are secure.

For my initial testing, I selected inbound port 3389 so that I could connect to the virtual machine using RDP.

I clicked Next: Disks.

For the disk, I changed the option to Standard SSD, because this VM was only being used for testing.

I then clicked Next: Networking.

Important: This section is critical because the virtual machine must be in the same virtual network as the Private Link.

  1. I selected the virtual network created earlier.
  2. I confirmed that it used the same subnet as configured earlier.

I left the rest of the defaults, clicked through to Review + create, and then clicked Create once validation was successful.

Creating the private endpoint

Next, I created the private endpoint that would connect Azure to Fabric.

In the Azure Portal, I searched for Private Endpoints.

I clicked Create.

On the Basics page, I entered the required details.

  1. I used the same subscription as before.
  2. I selected the same resource group.
  3. I entered a meaningful name, for example pe-fabric-workspace.
  4. The network interface name was created automatically.
  5. I selected the same region as the other resources, in this example Australia East.

Note: I kept a note of the private endpoint name because it was useful later.

I clicked Next: Resource.

On the Resource page, I configured the following:

  1. I used the same subscription as before.
  2. For Resource type, I searched for Microsoft.Fabric and selected Microsoft.Fabric/privateLinkServicesForFabric.
  3. For Resource, I selected the private link service that I created earlier using the ARM template.
  4. The Target sub-resource defaulted to workspace.

On the Virtual Network page, I accepted the defaults.

Note: The virtual network should default to the one I created earlier.

I then clicked Next: DNS.

For DNS, I left the defaults.

Note: Make sure the Private DNS zone is set to privatelink.fabric.microsoft.com.

I then clicked through the remaining screens and created the private endpoint.

Note: The private endpoint creation can take up to 5 minutes.

Once complete, I could see the private endpoint.

The key items shown were:

  1. The private endpoint name
  2. The resource name
  3. The virtual network

Testing connectivity using the Private Link

The final and most important step was testing the Private Link from the virtual machine I created earlier.

Note: The goal here was to make sure the workspace name resolved to the internal DNS entry.

First, I needed to get the DNS name to test and confirm what it should resolve to.

I opened the private endpoint by clicking on its name. Then I expanded Settings and clicked DNS Configuration.

Where it showed Customer Visible FQDNs, I looked for the FQDN that ended with:

2.api.fabric.microsoft.com

For my example workspace ID:

5d7b4573-f0dc-45d8-9f85-d3f03cbb1c1c

I needed to remove the dashes.

Important: Make sure to remove the dashes from the workspace GUID.

The FQDN format is:

{workspaceguid}.z.{first 2 workspaceguid characters}.w.api.fabric.microsoft

Using my example, the FQDN became:

5d7b4573f0dc45d89f85d3f03cbb1c1c.z5d.w.api.fabric.microsoft.com

I then logged into the virtual machine I created earlier, opened Command Prompt, and ran:

nslookup 5d7b4573f0dc45d89f85d3f03cbb1c1c.z5d.w.api.fabric.microsoft.com

This should return the internal IP address. If this works, then I have successfully created the Fabric Private Link.

Summary

In this blog post, I showed how I created a Private Link in Microsoft Fabric without relying on public access.

For me, the most important part was confirming that the Fabric workspace FQDN resolved internally from the virtual machine. Once that worked, I knew the Private Link configuration was successful.