Disclaimer: This article serves as a foundational guide to understanding the basics of architecting Microsoft Fabric. While it provides insights into key considerations, it is not an exhaustive blueprint. The goal here is to offer a stepping stone—helping you uncover aspects you may not have considered and inspiring deeper exploration into how Fabric can be optimized for your organization’s unique needs.
Architecting Microsoft Fabric effectively requires aligning its capabilities with your organization’s specific needs, ensuring seamless integration and optimal performance. Instead of a one-size-fits-all approach, a well-designed architecture considers factors like data governance, workload distribution, security policies, and cost management. Key decisions include structuring data domains, defining access controls, and optimizing compute resources to balance performance with efficiency. This discussion will focus on practical strategies to tailor Microsoft Fabric Architecture to your business, ensuring it supports both current operations and future scalability.
Now, I know you’ve likely come across countless articles explaining what Microsoft Fabric is and what it can offer your organization. Rather than repeating the same information, I’ll keep those details to a minimum—focusing instead on the aspects that truly support the core focus of this article. The goal here is not to reiterate what’s already widely available but to provide a fresh perspective on how to architect Fabric in a way that aligns with your organization’s unique needs.
Which brings me to my first question …
Do I need Microsoft Azure to use Microsoft Fabric?
Short Answer: As many of you might already know, the answer is NO—you do not need Microsoft Azure to use Microsoft Fabric. Fabric is a Software-as-a-Service (SaaS) platform that runs in the cloud and can be accessed directly via Fabric Portal or Power BI Portal.
If your organization hasn’t purchased a Fabric license yet, you can sign in using an organizational email account to start a new license. However, I won’t be covering the sign-up process in detail, as it falls outside the scope of this article and has already been extensively documented by industry experts.
That said, I found this article particularly useful, as it provides valuable insights into what you should consider before setting up Fabric/Power BI in your organization.
Not-so-Short Answer: To fully leverage the features and services within Microsoft Fabric—such as Data Factory, Data Lakehouses, Warehouses, and other services collectively referred to as Workloads—organizations need a Fabric Capacity License. This license is essentially a resource that is created within an Azure tenant as an Azure resource. Therefore, for organizations to utilize these capabilities, having an Azure tenant is a requirement.
Note: One thing to note before moving to the diagram, Fabric Capacity provides the compute power behind all the workloads. The data that gets ingested into OneLake (storage layer) does not sit within the Capacity. It’s stored in your Power BI default Storage region and is billed separately.
Detailing Azure architecture design with Azure Subscriptions, resource groups, and other Azure resources, aside from Fabric Capacity, is beyond the scope of this article. While these concepts are integral to managing resources in Azure, they are not directly tied to the primary focus of our discussion on architecting Microsoft Fabric. For a deeper understanding of these foundational Azure concepts, numerous resources and documentation are readily available from Microsoft and other industry experts.
Spoiler alert: it’s going to get more technical from this point onwards, but I’ll try to be as simple as possible to support non-technical readers.
Organising the Fabric Capacities on Azure
Now let’s look at how an organization, depending on the level of maturity and volume of their data landscape can start to think of organising the Fabric Capacities to support their Fabric Journey.
- Single Azure Subscription for Fabric Capacity/Capacities
For small to mid-sized organizations planning to use a single Azure Subscription (no specific advice or criticism regarding subscription purchasing decisions here), the following patterns can help architect a Fabric Capacity setup effectively.
Above diagrams showcase, starting from a Single capacity (right-most diagram), serving all non-production (development and Testing environments) and production workloads to having separate Fabric Capacity for non-production and production (left most diagram) under one Azure Subscription.
In such scenarios, it’s crucial to decide on the Capacity SKU level and the decision around Pay-as-you-Go (PAYG) or Reservations to reduce the cost and to balance the workloads between capacities to gain optimum performance.
Pros
- Spend less on Fabric Capacity as there are a smaller number of capacities
- Less complex and easy to manage and administer
- Easy deployment of azure resources
- Separation between non-prod and prod workloads and cost can be managed separately.
- Helps to compartmentalise the Fabric Compute instances to add / remove in a structured way.
Cons
- Less Scalable as the requirements grow, the capacity can suffer from lack of Capacity units to accommodate.
- Less control over security as the same Capacity is shared across many different teams.
- Not suitable for organisations that have advance azure deployment standards and security principles.
- Prod & Non-Prod Azure Subscriptions Or Subscription for each Stage of deployment
For mid to large-sized organisations who may have adapted to using separate Azure Subscriptions for each life cycle stage on their data platform, below patterns can be leveraged in terms of setting up Microsoft Fabric.
This is just an extension from the previous architecture setup as this has more dedicated Subscriptions and hence Capacities to manage higher demand of compute power and administration (e.g. more granular yet more complex security controls around each Subscription & Resource group).
Pros
- This provides more control over security and role assignments
- Provides scalability to support increased data volumes and frequent consumption.
- Supports proper life cycle management practices (CI/CD)
- Can control SKU levels individually, hence have more control over the cost.
- Pausing and resuming of one capacity with minimum or no impact to other environments. (Pause Dev Capacity in period where less development happens)
Cons
- High overhead in managing Capacities
- Could incur higher cost due to the high number of Capacities
- Complexities around assigning security and managing resources.
So far, we’ve focused on one aspect of the architecture, which is set up on the Azure cloud. The second part, however, resides within Microsoft Fabric/Power BI.
2nd Spoiler Alert: This is where things can get really messy and complex. On Fabric, the key separation element that can be used to logically group things are Workspaces, and it can easily become uncontrollable and messy with lots and lots of Workspaces created for different departments or functions.
Organising the Fabric Workspaces on Fabric/Power BI
As mentioned earlier, the suggestions provided are intended to guide organizations in exploring perspectives they may not have considered before. There is no definitive “right” or “wrong” way to implement workspaces. The key is to adopt the approach that best aligns with the organization’s specific needs while meeting its security and governance requirements.
Note: Power BI reports and sematic models can still exist within workspaces that are not mapped to Fabric Capacities.
- Single Fabric Capacity usage across all Fabric Workspaces
An organization can leverage a single Fabric Capacity to manage all Fabric workspaces within Microsoft Fabric/Power BI if it has a higher SKU level (e.g., F64 Capacity SKU) or if the organization is dealing with smaller data volumes and lower usage frequency. This setup is also ideal for organizations with fewer staff consuming data or those just starting their Fabric journey. It offers a simple, cost-effective solution while still enabling the organization to explore Fabric’s capabilities.
Below architecture setup can be utilized as a starting point for such organizations.
Power BI reports can exist in their respective domain related workspace folder, which enables organizations to grant user permissions easily at the report level (App level, workspace level) without having users accessing the Data directly on Fabric Workspaces.
Rather than emphasise on the Pros, let’s look at Cons which might help understand what would prevent someone from utilizing the above architecture setup.
Cons
- The most obvious disadvantage of having all workloads consume Capacity Units (CUs) from the same Fabric Capacity is the risk of rapid exhaustion of resources, with multiple workloads competing for the same pool of CUs.
- According to Microsoft Fabric Technical Engineers, logically separating workloads using different workspaces can help minimize compute resource contention. For example, a Lakehouse query running on Lakehouse 1 within Workspace 1 will have minimal impact on a simultaneous query executed on Lakehouse 2 within Workspace 2, compared to both queries running within the same workspace. Above setup may not support this concept.
- Capacity Units usage ratio on Ingestions and consumption need to be assessed well and set to avoid query rejection when CU consumption is high.
- Concurrency limitations may prevent workload executions and may incur excessive queuing.
- Workload related workspaces split between Prod and Non-Prod Capacities
When multiple Fabric Capacities are used across different workload workspaces, it allows for better distribution of consumption units, optimizing resource utilization. In this setup, Non-Production workloads can have a dedicated Fabric Capacity, which can be a Pay-As-You-Go (PAYG) resource—allowing it to be paused and resumed based on usage needs. Meanwhile, the Production Capacity can be set up with a Reservation, ensuring it remains up and running to support continuous data consumption throughout the day. Ultimately, the decision depends on the organization’s usage frequency and data volume, allowing flexibility in balancing cost and performance.
Cons
- One potential drawback of this approach is the resource contention between workloads during data ingestion, transformation, and aggregation. Since the Medallion Architecture (Bronze, Silver, Gold layers) remains within the same workspace, workloads may compete for resources, leading to performance bottlenecks, especially during heavy processing times.
- Fabric Capacity region selection plays a critical role in this architecture, as workload deployments across environments must be managed within their assigned capacities. Currently, if Fabric Capacities are located in different Azure regions, the deployment process can become more complex and challenging to manage. As of the time of writing this article, this remains a key consideration when designing a multi-capacity architecture to ensure smooth workload transitions and optimal performance.
- Separate Fabric Capacities created and assigned to Fabric Dev, Test and Production workload Workspaces
At a high level, this setup—with additional Capacities provisioned as needed to balance workloads across different organizational hierarchies—can effectively support an enterprise-level data landscape with high data volumes and diverse data consumers. The architecture not only helps mitigate resource contention but can also be tailored to meet enterprise security requirements, ensuring a robust and compliant data platform.
However, implementing a similar architecture requires careful planning in collaboration with key stakeholders, including business leaders, technical architects, security and compliance officers. It is also essential to define data ownership and establish clear responsibilities to maintain governance, security, and operational efficiency.
Final Thoughts
Before wrapping up this article, it’s worth highlighting the importance of leveraging additional capabilities—such as Domains—to maximize the full potential of Microsoft Fabric. As discussed earlier, Domains can be highly effective in managing user security, governance, and access controls while also providing visibility into Capacity Unit (CU) utilization at a domain level. This insight helps organizations define capacity requirements and identify areas for optimization.
As mentioned at the beginning of this article, the architecture designs outlined here serve as a guide to help you establish a well-structured Fabric data landscape. Ultimately, it’s up to you to tailor these strategies in a way that best aligns with your organization’s unique requirements, ensuring scalability, efficiency, and governance.
Chathura Wijesinghe (Chat), Data Engineering Lead at Agile Insights
