Fabric Architecture: Azure Tenants

Overview

Our Fabric Architecture journey starts with Azure Tenants (the kick-off blog in this series is here with a few jumping-off links to get started with thinking about Fabric Architecture). If you’re ready to spent time sketching out your Fabric Capacity planning, workspace strategy, domain topology, lakehouse/warehouse creation, data loading processes…you might want to stop for a minute and think about tenants. The question I’d like you to consider is “What do I need to know when working with a single or a multi-tenancy approach?” Let’s unpack this question because while it might sound like a simple list, it actually shapes your governance, scalability, and Fabric operational model. If you’re a seasoned Azure Architect veteran then you already know how to decide between single and multi-tenant cloud rollouts (also, please comment if you have anything to add please), if you work with Fabric/Data and don’t really dive into Azure architecture on a daily basis then please stick around. Hopefully this blog gets you thinking about single/multi-tenant architectures and the benefits/costs.

---

What Is a Tenant?

Let’s start at the top (literally). A tenant in Microsoft Entra ID is the highest-level boundary in your Azure cloud deployment. It’s tied to your Entra topology (Azure Active Directory) and defines the scope for identity, access control, governance, and resource management. A tenant is a dedicated and isolated instance of Microsoft Entra ID and it serves as the identity boundary for an organisation across Microsoft cloud services like Azure, Microsoft 365, and Dynamics 365.

Each tenant includes:

• A directory for managing users, groups, and applications
• A unique Tenant ID (GUID)
• Global scope: tenants are not tied to a specific Azure region

Think of a tenant as the top-level container for identity, security, and governance across your Microsoft cloud footprint. In the example image below, we have 2 tenants: 1 for Production resources and the other for Development resources. This architecture allows us to have 2 separate Fabric tenants (in that capacities, workspaces, workloads, & items are completely isolated from each other).

---

Single vs Multiple Tenants: What To Consider

When working with a single tenant or multiple tenants we can go through what this means in terms of a Fabric deployment. Having multiple tenants may also not be a choice due to acquisitions/mergers of multiple companies, or even company divisions.

Single Tenants

Starting with a single tenant is often the simplest way to get started. You only have 1 tenant to manage with all users and groups managed in a single place. Let’s see what having a single tenant can do for us.

• Centralised Identity Management: One Entra ID for all users, making access control simpler
• Unified Security Policies: Easier to enforce consistent Conditional Access, MFA, and compliance policies across the organisation.
• Simplified Licensing: All licenses (Microsoft 365, Power BI, Fabric, etc.) are pooled and managed centrally
• Cross-Service Integration: Easier integration between services like Microsoft 365, Power BI, Fabric, and Azure resources.
• Lower Administrative Overhead: Fewer directories to manage
• Easier Collaboration: Internal users share resources without guest accounts or cross-tenant complexities.
• Simpler Governance: Governance isn’t simple but having one set of compliance and audit controls for the entire organisation makes it simpler.

If your organisation is centralised, and you’re not dealing with acquisitions or strict compliance requirements then it’s likely you have one tenant. It’s simpler, cleaner, and easier to manage.

Multiple Tenants

Let’s look at some real-world scenarios where multiple tenants may make sense, or at least where they are understood in the context of why they exist and why you might have to work in a multi-tenant environment for your Fabric architecture.

• Business Acquisitions: You acquire another company. They’ve already got a tenant setup, do you rip it out and migrate everything? Probably not. Instead, you keep their tenant and set up cross-tenant access. This respects the different tenants existing governance
• Subsidiaries or Business Units: If you have a group structure with semi-autonomous subsidiaries? A dedicated tenant per unit allows each to manage their own governance, billing, and data strategy
• Compliance and Data Sovereignty: You might need separate tenants to meet legal obligations in certain industries
• Security Isolation: Some workloads are just too sensitive to share a tenant. If it’s financial data, healthcare records, or top-secret R&D, isolating them in a separate tenant helps to reduce risk
• Dev/Test Environments: This is the most common reason I see, if organisations really want totally separate environments then multi-tenants help to segregate resources.

Important: Tenants themselves are not region-specific, but services deployed within them (like Microsoft Fabric capacities) can be region-bound. For example, a Fabric capacity in a tenant can be deployed in UK South, but the tenant itself remains globally scoped.

---

Azure Tenants and Microsoft Fabric

How does the relationship between Azure tenants and Microsoft Fabric work? Well, if you only have a single tenant then when you login to Fabric all the workspaces created exist in that single tenant. Workspace security will dictate who can access which workspaces, that’s the degree of separation here. Yes, workspaces can be assigned to different capacities, but that doesn’t really factory here if ultimately access is governed by users and groups.

Key Relationships

• Fabric capacities are deployed in specific Azure regions (e.g. UK South, West Europe).
• Workspaces and items (Lakehouses, Warehouses, Notebooks, etc.) are tenant-scoped.
• Tenant-level settings control collaboration, security, and data access.
• Cross-tenant sharing is possible using Service Principals (see here)
• Users and Licensing can be shared across tenants using Multitenant Organizations settings in Entra (learn more here)

---

Multi-Tenant Example

Here’s an example of 3 tenants in my organisation, let’s say that my Enterprise Architect has decided to sub-divide dev/test/prod into different tenants, what would Fabric look like then? I have the main tenant for Production workloads, and the other 2 tenants for development & testing. I can share my Power BI license across all 3 tenants using my preferred method of Multitenant organisations.

When I login to Fabric and access my production (default) tenant then I’ll see all the relevant workspaces I have access to. As my own account is an admin, I can see all workspaces.

When I login to Fabric, I can switch between the tenants that I have access to using the Switch Tenant button under my profile:

Now I’m logged into the Development tenant and I have a completely separate environment to work in, isolated from the other Fabric tenants.

---

Conclusion

If you’re working with single or multi-tenant approaches then you’ll need to take into consideration the points above. Unless you’re organisation has a clear reason to go with multi-tenant and understand the extra administration involved then a single tenant is desirable. Fabric is powerful but with great power comes great architectural headaches depending on setup.

TL;DR: Azure tenants are global identity boundaries. Having single or multiple tenants based on organizational complexity and compliance needs affects Microsoft Fabric.

In part 2 of this tenant architecture blog we’ll dive into what happens when you are required to deploy Fabric across tenants, strap in!

Drop any questions in the comments please.