Architecture

This page describes the high-level design of the Base Fabric Data Platform: how the deployments are split over subscriptions, what each tier creates, and how network, encryption and identity work. It is written for the platform team, and for workload teams that want to understand what runs on their behalf.

Reference design, your deployment may differ

The design below comes from the solution code and the HLD of the solution. Names, SKUs and optional parts depend on your deployment.

Overview

flowchart TB
    subgraph shared["Shared subscription (spoke)"]
        cap["Fabric capacities"]
        pause["Logic Apps: pause / resume (optional)"]
        purview["Microsoft Purview (optional)"]
    end
    subgraph env["Environment subscription (spoke), one per environment"]
        gw["VNet data gateway"]
        st["Storage account (data lake, CMK)"]
        pep["Private endpoints"]
        graf["Managed Grafana (optional)"]
    end
    subgraph fabric["Microsoft Fabric tenant"]
        ws["Workspaces: OneLake, Lakehouses, Warehouses, pipelines"]
    end
    kv["Spoke Key Vault: key + connection secrets"]
    law["Spoke Log Analytics"]
    src["Data sources: Azure, on-premises"]

    cap -->|"capacity assigned"| ws
    ws -->|"outbound only via"| gw
    gw --> src
    ws -->|"managed private endpoints"| src
    pep --> ws
    ws --> st
    st --> kv
    pause --> cap
    graf --> law

Subscriptions and tiers

The platform uses one subscription per environment and one shared subscription. Every subscription is a spoke of the platform (Spoke canvas) and provides the virtual network, the private endpoint subnet, the Key Vault, the storage account and the Log Analytics workspace that the solution builds on.

Tier	Subscription	Terraform root	What it creates
Shared	Shared	infra/deploy/shared	Resource group, one or more Fabric capacities, the custom role Fabric Capacity Operator, optional capacity pause and resume Logic Apps with alerts
Workload	One per environment	infra/deploy/workload	Resource group, one VNet data gateway per capacity key, the Fabric workspaces and their items and connections, the data lake storage account, the key and the private endpoints
Governance	Shared	infra/deploy/governance	Microsoft Purview account (Governance)
Observability	Per environment	infra/deploy/observability	Azure Managed Grafana, alert rules and optionally tiered log storage (Observability)

Each root module has its own Terraform state. The shared tier deploys first, because the workload tier looks up the capacities by name. The capacities live in the shared subscription on purpose: one capacity can serve one or more environments, which gives a lower cost footprint, and a separate capacity per environment stays possible because each workspace names the capacity it uses (capacity_key).

Naming and tags

Names follow the Azure naming module with a suffix of <workload>, a short environment name and a short region name.

Item	Value
Workload name	At most 8 characters
Environments	development, test, acceptance, production (shared for the shared and governance tiers), shortened to dev, tst, acc, prd, shrd
Regions	westeurope, northeurope, swedencentral, uksouth (shortened to weu, neu, sec, uks)
Fabric capacity	fc + workload + environment + region + capacity key
Workspace	<workload>-<env>-<region>-<workspace key>
Gateway	VNet Gateway - <environment> - <capacity key>
Private Link Service for Fabric	privateLinkServicesForFabric-<workspace name>
Tags	Environment, Workload and CostCentre. The module sets CostCentre to a fixed value, check it for your platform (Naming and tags).

Fabric capacity

A capacity is created per entry in fabric_capacities of the shared tier, with a SKU from F2 up to F2048. The capacity administrators are set from a list of principal IDs: the service principals of the spokes that deploy workspaces, and optionally users. Fabric allows only service principals and users in this role, not groups, so a team that needs capacity admin rights must be added person by person.

Capacities can be paused to save cost, see Cost optimisation and Capacity auto-pause.

Workspaces

Each workspace is created with a system-assigned managed identity and assigned to a capacity. The workload tier adds, per workspace:

• role assignments for up to four Entra ID groups (Access and roles),
• a private endpoint to the workspace (Private Link Service for Fabric, workspace sub-resource) in the private endpoint subnet,
• a network communication policy and a gateway rule (Workspace network policy),
• optional Lakehouses (with or without schema support) and Warehouses (with a collation from a fixed list),
• optional connections (Connectivity),
• an optional Git link.

In the basic setup the development workspace is linked to Git and the production workspace is not. Production receives its content through CI/CD pipelines, which gives a more controlled setup than a direct Git integration.

Data pipelines

The workspace module can create empty Fabric data pipelines (data_pipelines), but the workload root module does not pass that setting on. Pipelines are normally created by the data team in the workspace.

Networking

flowchart LR
    dev["Developer (VPN / ExpressRoute)"] --> pe["Private endpoint (spoke PE subnet)"]
    pe --> ws["Fabric workspace"]
    ws -->|"VNet data gateway"| spokenet["Spoke VNet"]
    spokenet --> azsrc["Azure data sources"]
    spokenet -->|"ExpressRoute / VPN"| onprem["On-premises sources"]
    ws -->|"managed private endpoint"| azres["Azure resource (Private Link)"]
    ws -->|"managed private endpoint"| ws2["Other Fabric workspace"]

• Fabric to data source, option 1: the VNet data gateway. It gives outbound connectivity into the spoke VNet, and from there to on-premises systems. Connections are configured to use the gateway, and the workspace is restricted to the designated gateway. The gateway uses a dedicated subnet of the spoke and is created with one member gateway and a sleep after 30 minutes of inactivity.
• Fabric to data source, option 2: managed private endpoints. A direct private connection per resource (for example Storage or SQL) through Private Link. It usually does not need the gateway.
• Azure to Fabric. Private endpoints connect the spoke VNet to the workspaces. DNS resolution of these endpoints is done by the private DNS zones that the platform manages (by policy).
• Developers. The workspaces are isolated in the platform network, so developers need VPN or ExpressRoute.
• Git. A link to GitHub needs an outbound exception, which the platform applies only to workspaces with a Git link.

Storage account and encryption

The workload tier creates one storage account per environment:

Setting	Value
Kind and tier	BlockBlobStorage, Premium, hierarchical namespace on
Replication	ZRS
Encryption	Customer-managed key in the spoke Key Vault (RSA 4096) through a user-assigned identity with the role Key Vault Crypto Service Encryption User, plus infrastructure encryption
Key rotation	Rotation policy with a lifetime of one year, automatic rotation one month before expiry
Authentication	Shared access keys disabled, OAuth by default
Network	Default action Deny with bypass for Azure services, private endpoints for blob and dfs
Data protection	Blob soft delete 90 days, container soft delete 95 days, change feed on, versioning off
Containers	One private container per ADLS connection

Public network access flag

The code sets public_network_access_enabled = true on the storage account together with a default firewall action of Deny. In practice the firewall blocks the public path, but check what your platform policy expects.

Identity

• Workspace access is by Entra ID groups per role. See Access and roles.
• Deployment identity: the service principal of the spoke deploys the solution. It needs, among others, rights to create keys and read secrets in the spoke Key Vault, and the role Storage Blob Data Contributor on the data lake (the module assigns it to the current caller). For the capacity administrators it needs Microsoft Graph application permissions, see Prerequisites.
• Access to data sources: for sources with Entra ID authentication (Azure Storage, SQL) a service principal is used. By default it is the service principal of the spoke, but a separate one can be referenced. It is granted access to the source outside this solution. For sources without Entra ID authentication, basic credentials or keys are stored in the Key Vault and referenced by name.
• Automation identities: the pause and resume Logic Apps use a managed identity with the custom role Fabric Capacity Operator. See Decisions.

Deployment order

1. Prerequisites and tenant settings (Platform configuration).
2. Shared tier (capacities, optional auto-pause).
3. Governance tier (optional). It only needs the spoke Log Analytics workspace and storage account, so it can run before or alongside the workload tier.
4. Workload tier per environment (gateway, workspaces, connections, storage).
5. Observability tier per environment (optional).

Related

• Service description
• Platform configuration
• Spoke canvas