A field-tested approach to running Fabric entirely through private endpoints and managed connectivity.
As an Infra Architect working with large, security-sensitive enterprise environments, one principle consistently guides infrastructure architects:
If a platform can't operate inside a private network boundary, it won’t make it to production.
This became very real when our Data Engineering team sent me a simple-looking request:
“We need Microsoft Fabric deployed next quarter.
Please ensure it works only through private access — no public endpoints allowed.”
My first reaction was curiosity.
Fabric is a modern, unified analytics SaaS platform — but we were asking it to behave like a tightly governed, network-isolated service inside a Zero-Trust Azure landing zone.
Modern enterprises consistently aim to adopt Microsoft Fabric while ensuring that all analytics workloads operate within strict network boundaries. One of the most common challenges architects and infrastructure teams encounter is enabling Fabric to function securely inside private-only, Zero-Trust environments—where public endpoints are either restricted or completely disabled.
As Fabric evolves into a central analytics platform, infrastructure teams increasingly need clear guidance on how its components—Lakehouse, Warehouse, Spark, Pipelines, and Workspaces—interact with private networks, enterprise firewalls, and hub–spoke landing zones.
Understanding What “Private Fabric” Really Means
Before drawing any diagrams, I needed clarity on how Fabric components interact with enterprise networks.
Under the hood, Fabric includes:
- Workspaces for security and lifecycle boundaries
- Lakehouse backed by ADLS
- Data Warehouse with dedicated compute
- Spark runtime for big data workloads
- Pipelines, KQL Databases, and Real-Time analytics engines
- Capacities managing performance and isolation
Fabric lives as a SaaS service — but enterprise workloads that use Fabric do not.
That separation is where the architecture work begins.
Mapping Fabric into Our Existing Hub–Spoke Environment
Our Azure landing zone follows a strict hub-spoke model:
- Hub VNet with firewall, private DNS, resolver, inspection
- Spoke VNets for application tiers
- Private endpoints for all PaaS services
- Hybrid connectivity through ExpressRoute
- Routing enforced through central NVA
So the question became:
How does Fabric — which sits outside any of our VNets — securely interact with workloads inside them?
After reviewing Fabric’s network features, the answer emerged through four key mechanisms.
The Four Pillars of Private Access in Fabric
1. Private Access to Fabric Workspaces
Some Fabric experiences support private endpoints, allowing internal clients to access Fabric without touching the public internet.
2. Managed Private Endpoints (MPE)
This is where Fabric reaches into our network:
- Lakehouse accessing private ADLS
- Dataflows connecting to SQL
- Pipelines reaching Event Hub or Key Vault
The private endpoint gets deployed inside our VNet, and we approve it — keeping full control.
3. VNet Data Gateways
Needed particularly by:
- Warehouse (for ingestion from private SQL)
- Dataflows Gen2 (for hybrid sources)
- Spark (for private connectivity paths)
4. DNS as a Security Control
Every component must resolve Fabric-related FQDNs privately:
- privatelink.fabric.microsoft.com
- Storage private zones
- SQL private zones
Without correct DNS, private networking collapses.
The Architecture That Finally Worked for Us
Once everything clicked, we designed an end-to-end pattern that aligned Fabric with our enterprise architecture.
On-Prem (ER/VPN)
│
▼
┌────────────────────┐
│ Hub VNet │
│ - Firewall / NVA │
│ - Private DNS │
│ - DNS Resolver │
└─────────┬──────────┘
│
┌─────────┼──────────┬─────────────────────┐
│ │ │ │
▼ ▼ ▼ ▼
App Spoke Data Spoke Compute Spoke Gateway Spoke
APIs ADLS, SQL Spark runtime VNet Data GW
And connected externally to:
MICROSOFT FABRIC
(Workspaces, Spark,
Warehouse, Lakehouse)
|
Managed Private
Endpoints
This structure gave us:
- Full network inspection
- Private ingestion and egress
- Isolated workspace boundaries
- Clear routing paths
- No public traffic
- Predictable governance
Solving the Lakehouse, Warehouse, and Spark Scenarios
Lakehouse needed private reads/writes from ADLS.
Managed Private Endpoints solved this elegantly.
Warehouse required private ingestion, which we routed through:
- VNet Data Gateways
- Private DNS
- Region-specific endpoints
Spark was the most sensitive.
It interacts with multiple services, and any wrong DNS entry pushes Spark back to public endpoints.
We enforced:
- Private DNS only
- Firewall-controlled outbound
- Route tables pushing all egress through the hub
Once configured, Spark executed entirely through private paths.
Workspaces: The Security Boundaries
To maintain strong separation:
- Each domain/team received its own workspace
- Network rules restricted public access were supported
- Managed identities enforced identity boundaries
- Capacities defined performance and cost isolation
Workspaces became the perfect mix of logical and network governance.
Governance and Production-Readiness
Our eventual checklist included:
- Private-only Fabric configurations
- Pre-approved network topologies
- CI/CD validations preventing public exposure
- Centralized private DNS integration
- Auto-approval workflows for MPE
- Logging through Firewall logs and NSG flow logs
Once these constraints were in place, Fabric operated like a model citizen inside a Zero-Trust environment.
Provisioning with Terraform -
Terraform supports core Fabric components—including Workspaces, Capacities, Lakehouse items, and Managed Private Endpoints—while advanced or emerging features such as workspace networking configuration and gateway integrations can be automated using the AzAPI provider.
Capabilities such as workspace creation, capacity assignment, item provisioning (Lakehouse, Warehouse, KQL DB, Spark), and Fabric role assignments are available through native Terraform resources.
Where Fabric networking features are still being expanded—such as private workspace access modes, network configuration policies, and advanced ingestion controls—Terraform can be extended through the AzAPI provider to call the latest ARM and Data Plane APIs. This allows infrastructure teams to automate new Fabric capabilities as soon as they become available, without waiting for provider updates.
The Day Everything Went Live
When the first private-only Fabric workspace went live, we saw:
- Lakehouse accessing ADLS privately
- Warehouse ingesting data with no internet exposure
- Spark running transformations entirely through private endpoints
- VNet Gateway enabling hybrid SQL ingestion
- All DNS entries resolving privately
- Firewall logs clean — exactly what we wanted
At that moment, Fabric no longer felt like a distant SaaS platform.
It felt like a secure, well-integrated part of our enterprise architecture.
Closing Thoughts
Architecting Microsoft Fabric for private-only access isn’t about “turning on a toggle.”
It’s about understanding how Fabric interacts with your network, and designing guardrails that complement how your organization already works.
In our case, combining:
- Hub-spoke architecture
- Private endpoints
- Managed Private Endpoints
- VNet data gateways
- DNS controls
- Identity governance
…allowed Fabric to operate seamlessly inside a Zero-Trust environment while preserving all the capabilities of Lakehouse, Warehouse, Spark, and Workspaces.
With the right architecture, Fabric becomes not just a SaaS tool — but a trusted citizen inside even the most regulated enterprise networks.
Microsoft