Base Fabric Data Platform¶
Data teams want to build in Microsoft Fabric without running the network, encryption, access and cost controls around it. The Base Fabric Data Platform is a packaged solution on top of the MCP platform that delivers Microsoft Fabric workspaces with a fixed baseline: private connectivity, outbound protection, customer-managed encryption for the data lake, access through Entra ID groups, connections to data sources, cost control of the capacity and monitoring. All of it is deployed as infrastructure as code with Terraform.
Optional offering, reference design
The Base Fabric Data Platform is not part of the core MCP hub and spoke. It is a solution that is delivered under an agreement (Service types). Which parts your platform runs, and with which settings, depends on your deployment. The names, defaults and values on these pages come from the solution code and service description and are the usual values. Your deployment may differ. Ask your platform team.
Who it is for¶
| You are | Start with |
|---|---|
| A data engineer or analyst who uses the workspaces | Service description, Access and roles, Connectivity |
| A team that needs a change (new workspace, connection, Lakehouse, capacity size) | Request and change |
| A team that wants to design its data layers | Data architecture (reference pattern) |
| The platform team that deploys and operates the solution | Architecture, Responsibilities, Platform configuration |
The platform team is XMMS under a managed-service contract, or the customer's own team when the platform is self-managed. See Operating models. Pages say "the platform team" and "the workload team" for that reason.
How it relates to the platform¶
The solution is built on top of a spoke of the Managed Cloud Platform (the spoke canvas, see Spoke canvas and What you get). It uses what the spoke already provides: the virtual network with a private endpoint subnet, the Key Vault, the storage account, the Log Analytics workspace, the service principal of the spoke and the central private DNS. The solution adds the Fabric resources and the glue around them. It does not replace the platform baseline.
flowchart TB
subgraph mcp["MCP platform"]
hub["Hub: firewall, DNS, VPN / ExpressRoute"]
spoke["Spoke canvas: VNet, Key Vault, storage, Log Analytics"]
end
subgraph fdp["Base Fabric Data Platform"]
shared["Shared tier: Fabric capacities, auto-pause"]
workload["Workload tier: gateway, workspaces, connections, data lake"]
extras["Optional: Purview governance, Grafana observability"]
end
hub --> spoke
spoke --> workload
shared --> workload
workload --> extras
What is documented¶
| Area | What it covers | Page |
|---|---|---|
| Scope | Components, standard changes, SLA metrics, recovery objectives, incident process | Service description |
| Requests | How a change is requested and delivered, field lists per change | Request and change |
| Access | Workspace roles, the optional Admin group, capacity and Grafana access | Access and roles |
| Connectivity | Connection types, managed private endpoints, outbound rules, Git | Connectivity |
| Monitoring | Platform monitoring, workload monitoring, the Grafana dashboards and alerts | Monitoring |
| Cost | Capacity auto-pause and manual resume, sizing | Cost optimisation |
| Data layers | Reference medallion pattern with dbt | Data architecture |
| Design | Subscriptions, tiers, network, storage, identity | Architecture |
| Operating model | Who does what, RACI | Responsibilities |
| Deployment | Repository layout, tiers, variables, prerequisites | Platform configuration |
| Runbooks | Outbound protection, capacity auto-pause, Grafana, Purview | Workspace network policy, Capacity auto-pause, Observability, Governance |
| Decisions | RBAC model and the main design decisions | Decisions |
Not documented here¶
- Contract terms: support hours, response times, SLA targets and fees. The service description leaves SLA targets "to be agreed" per customer.
- The CI/CD pipeline definitions. They are not part of the source of this solution and live in the configuration repository of the deployment.
- Fabric itself. Microsoft Learn documents workspaces, Lakehouses, Warehouses and pipelines.
Related documentation¶
- Operating models: the platform team is XMMS (managed service) or the customer's own team (self-managed)
- Service types: core, direct and additional services, spoke variants
- Architecture reference: layers, management groups, hub and spokes
- Consumers: what a workload team gets from the platform
- Responsibilities: the generic split between platform team and workload team