At Epitec, we’ve been working toward ISO compliance. One of the key steps is securing our infrastructure using private endpoints. Since we were already setting this up for our Azure Storage accounts, we decided to do the same for our Azure SQL Databases.
The initial setup was smooth. But then we hit a new challenge:
We use Power BI and Microsoft Fabric. So how do we access our private Azure SQL Database from Fabric?
Trying Managed Private Endpoints in Fabric
We first tried using Managed Private Endpoints in Fabric (Workspace Settings → Network Security), following Microsoft’s documentation:
👉 Create and use managed private endpoints in Microsoft Fabric
These endpoints are easy to create and support secure access for Spark jobs notebooks, but not for Power BI datasets or pipelines.
Limitation: Fabric’s managed private endpoints only support data engineering workloads. They do not support the Power BI service.
Deploying a VNet Data Gateway
Next, we deployed a Power BI VNet Data Gateway using Microsoft’s guidance:
👉 Create virtual network (VNet) data gateways
The gateway showed up under Manage Connections and Gateways -> Virtual network data gateways, and we were able to:
- Set up SQL mirroring
- Create data pipelines
- Publish reports
Everything worked until we hit another issue.
Roadblock: Licensing and Capacity Limits
We discovered that VNet Data Gateways don’t work with Power BI Pro. They require:
- A Power BI Premium license, or
- A Fabric Capacity workspace
Switching our reports to a Fabric workspace initially worked, then failed with:
HTTP Status Code 429 – Too Many Requests
Our F2 capacity was being throttled, most likely because the gateway used most of the available compute.
Even after upgrading to F4 and F8, performance didn’t improve. That’s when we realized the problem wasn’t just about compute. The real issue was the concurrency limit of a single VNet gateway node (6 parallel queries). Without scaling out the gateway cluster, the bottleneck stayed in place.
Root Cause: Parallel Query Limits
According to Microsoft documentation:
- A single VNet gateway node supports 6 concurrent queries
- You can scale up to 7 nodes per cluster
- By default, only 1 node is created
In our case: - We had 5 import-mode reports refreshing 6 times per day
- One DirectQuery report
- Multiple pipelines
This likely exceeded the 6-query limit and caused throttling and refresh failures.
Pricing Surprise: Gateway Node Cost
Each VNet gateway node consumes 4 Capacity Units (CUs) per hour. At approximately $0.18 per CU, that totals $0.72 per hour.
- You are billed based on runtime uptime, starting from the first use or connection test
- Nodes automatically shut down when idle, which helps reduce costs
- If left running continuously, one node would cost around $518 per month, in addition to your Fabric capacity
Solution: Optimize SQL Access Inside Fabric
Instead of scaling up the gateway, we simplified our approach.
We created a new Fabric workspace that included only:
- The mirrored SQL database
- Two pipelines
This stayed within the 6-query limit and ran smoothly.
To reduce load even further, we reconfigured our Power BI reports to connect directly to the mirrored database inside Fabric, bypassing the VNet Gateway entirely.
Now we are running with: - One gateway node
- Stable performance
- No errors
Final Takeaways
- Managed Private Endpoints only work for Spark and notebooks, not for Power BI or pipelines
- VNet Data Gateway requires Power BI Premium or Fabric Capacity
- A single gateway node supports only 6 concurrent queries
- Node cost is $0.72 per hour when active, and auto-shutdown helps limit that
- When possible, bypass the gateway by connecting to mirrored SQL inside Fabric
