Base Fabric Data Platform: Service Description¶
This page describes what the Base Fabric Data Platform offers, how changes are made and where the boundaries are. The other pages go into the details: Request and change, Access and roles, Connectivity, Monitoring and Cost optimisation.
Optional offering, set per platform
The service is delivered by the platform team under an agreement (Operating models). Support hours, response times, SLA targets, contacts and fees are part of that agreement and are not in this documentation. Where this page names a default, it is the usual value of the solution. Your platform can differ.
In short¶
Data teams get a production-ready, fully managed Microsoft Fabric environment without needing infrastructure expertise. The platform team maintains the platform as infrastructure as code with Terraform and deploys it through CI/CD pipelines. Every environment has its own isolated resources. All connectivity runs through the private network of the platform: data is not transported over the public internet. Exceptions are named explicitly (see Network and security) and approved by the service delivery manager and the customer.
| Value | What it means |
|---|---|
| Day 1 productivity | Pre-configured workspaces with capacity, OneLake, Lakehouses and Warehouses, and automated provisioning |
| Monitoring and alerting | Availability and performance of the platform components are monitored, deviations are signalled |
| Governance and security | Entra ID groups with role-based access, private endpoints, network isolation and encrypted storage |
| Time to value | Shared infrastructure and standard configurations let new environments and workspaces deploy quickly and consistently |
What is offered¶
The platform has four groups of components. See Architecture for how they fit together.
Platform services¶
| Component | Description |
|---|---|
| Fabric capacity | The compute and billing unit of all Fabric workspaces. Capacities are created in a shared deployment so that several environments can reuse one, which lowers the cost. The SKU is configurable across the Fabric F-series and can be changed. |
| VNet data gateway | A gateway that gives Fabric outbound connectivity to data sources in the spoke network and, through ExpressRoute or VPN, to on-premises systems. It activates on first use and goes to sleep after a period of inactivity to save cost. |
Workspace services¶
| Component | Description |
|---|---|
| Fabric workspace | The container for all data items. Access is controlled with Entra ID groups for the roles Admin (optional), Contributor, Member and Viewer. Each workspace has a system-assigned managed identity and can be linked to a Git repository. |
| OneLake | The default data lake storage of every workspace. |
| Lakehouses | Storage for analytical workloads in open formats (Delta). Schema support can be enabled per Lakehouse. Several per workspace. |
| Warehouses | Relational storage for SQL-based analytics. The collation is configurable. Several per workspace. |
Connectivity¶
| Connection type | Description |
|---|---|
| ADLS | To containers of the environment's storage account, through the VNet data gateway, with a service principal whose credentials come from the Key Vault |
| SQL | To SQL Server databases, through the gateway, with a service principal or with basic credentials from the Key Vault |
| Oracle Cloud Storage | To Oracle Cloud Storage, through the gateway, with basic credentials from the Key Vault |
| Workspace to workspace | Managed private endpoints between workspaces, so that Lakehouses and Warehouses of another workspace can be used |
| Managed private endpoints | Direct private connections from a workspace to specific Azure resources through Private Link |
Details and request fields: Connectivity.
Storage¶
| Component | Description |
|---|---|
| Storage account (data lake) | One per environment. Premium block blob storage with hierarchical namespace, zone-redundant, encrypted with a customer-managed key plus infrastructure encryption, reachable through private endpoints for blob and dfs. Containers are created for the ADLS connections you configure. |
| Key Vault | Holds the encryption key of the storage account and the credentials that connections refer to. It is the Key Vault of the spoke. |
Optional building blocks¶
| Component | Description | Page |
|---|---|---|
| Capacity auto-pause | Pauses capacities on a daily schedule to save cost, resume is manual by default | Cost optimisation |
| Observability (Managed Grafana) | Dashboards and alerts on pipeline failures from Log Analytics | Monitoring |
| Governance (Microsoft Purview) | Catalog, classification and lineage for the Fabric workspaces | Governance |
These are separate deployments. Ask the platform team whether they are part of your agreement.
Network and security¶
The platform uses defence in depth: network isolation, encryption and access management together.
| Aspect | Description |
|---|---|
| Inbound | Each workspace gets a Private Link Service for Fabric and a private endpoint in the spoke's private endpoint subnet |
| Outbound | Blocked by default (outbound Deny). Allowed only through the designated VNet data gateway or managed private endpoints. See Workspace network policy for how this is set per workspace and for its limits. |
| Gateway restriction | Per workspace, gateway use is denied by default and only the gateway of the environment is allowed |
| Git exception | A workspace with a Git link gets a named outbound exception for Git traffic. Workspaces without Git do not. |
| DNS | Private endpoint names resolve through the private DNS zones of the platform |
| Developer access | Through VPN or ExpressRoute. There is no public internet path for developers. |
| Data protection | Description |
|---|---|
| Customer-managed key | RSA 4096-bit key in the Key Vault with automatic rotation, used for the storage account |
| Infrastructure encryption | Enabled in addition to the customer-managed key (double encryption at rest) |
| Soft delete | Blobs 90 days, containers 95 days |
| Replication | Zone-redundant (ZRS) |
| Authentication | Shared access keys are disabled on the storage account. Access is through Entra ID only. |
| Credentials | Connection credentials are stored in the Key Vault, never in code or configuration files |
Alignment with frameworks¶
The technical configuration aligns with the CIS Microsoft Azure Foundations Benchmark 2.0, ISO 27001 and the Microsoft Cloud Security Benchmark. This concerns the technical configuration only. Formal certification is an organisational process and stays with the customer.
How changes are made¶
The code repository is the single source of truth. Changes are made as a pull request on the Terraform configuration and deployed by the pipeline. Manual changes in the Azure portal or the Fabric portal to resources under Terraform management are not allowed: the next pipeline run reverts them. See Request and change.
Standard changes¶
Standard changes are pre-defined and automated through the Terraform configuration. Each follows the controlled change process, and the platform team records the pull request and the time to restore (MTTR) in the SLA reporting.
| Standard change |
|---|
| Create a new Fabric workspace |
| Modify workspace role groups (admins, contributors, members, viewers) |
| Create or delete a Lakehouse |
| Create or delete a Warehouse |
| Add, modify or delete an ADLS connection |
| Add, modify or delete a SQL connection |
| Add, modify or delete an Oracle Cloud Storage connection |
| Configure a workspace-to-workspace connection |
| Add or remove a managed private endpoint |
| Configure or modify the Git link |
| Scale the Fabric capacity or change the SKU |
| Add a storage container through an ADLS connection |
SLA metrics¶
The availability of the platform is measured with the metrics below. The targets are agreed per customer and recorded in the overarching SLA, not in this documentation.
| Metric | Measures |
|---|---|
| Fabric capacity availability | The provisioned capacity can run workloads |
| VNet data gateway availability | Network connectivity between Fabric and data sources |
| Storage account availability | The storage accounts used as data landing |
| Connection availability | The configured connections (ADLS, SQL, Oracle Cloud Storage, workspace to workspace) |
Recovery objectives¶
| Metric | Target | Basis |
|---|---|---|
| RPO | at most 1 hour | Zone-redundant storage replicates synchronously across three availability zones. Platform configuration is in Git as Terraform. The hour covers edge cases such as in-flight pipeline runs or uncommitted metadata at the time of an incident. |
| RTO | at most 4 hours | The infrastructure can be redeployed from Terraform in roughly 30 to 90 minutes. The rest covers validation, re-establishing connections, activating the gateway and checking end-to-end connectivity. For an availability zone failure that Azure handles transparently, recovery is typically well under 1 hour. |
Scope of the objectives
RPO and RTO apply to the platform infrastructure and the data in the storage account. Recovery of data workloads (pipelines, notebooks, semantic models, data products) is the responsibility of the workload team and needs its own workload-level recovery planning.
Incident process¶
- Detection: platform monitoring signals a deviation, or you report it.
- Triage: the platform team assesses impact and urgency.
- Resolution: the platform team works on recovery and keeps you informed.
- Closure: you are told the root cause and the measures taken.
Severities, response times and support hours come from your agreement. In the self-managed model they are defined by your own platform team (Incident management).
Boundaries¶
| Platform team | Workload team |
|---|---|
| Capacity, gateway, storage account, key rotation, private endpoints, role groups and connections as code | OneLake content, the data in Lakehouses and Warehouses |
| Platform monitoring (capacity, gateway, storage, connections) | Workload monitoring: query performance, data quality and freshness |
| Retry of failed baseline pipelines | Solving the data issue when a retry does not help |
| Terraform pipelines, modules and code | Git repositories of the workload |
| Technical alignment with the frameworks | Formal compliance and certification |
The complete split is on Responsibilities.