Databricks Community

JessieLi

Introduction

For enterprise groups deploying Azure Databricks, the Azure Tenant — Databricks Account relationship is a foundational architectural decision. It shapes data isolation between subsidiaries, governance scope, and operational overhead for years to come. Getting it wrong typically means a full rebuild rather than a configuration change — which makes this a decision that platform architects, security leads, and compliance teams should align on before the first Workspace is provisioned.

In corporate group structures — financial holding companies, manufacturing conglomerates, retail groups — multiple legally independent subsidiaries often share a common Azure Active Directory (Entra ID) Tenant. When these organizations adopt Azure Databricks, the relationship between Azure Tenant and Databricks Account introduces architectural constraints that differ significantly from AWS and GCP.

This article provides an overview of the architecture options, key design considerations, and recommended practices for deploying Azure Databricks in multi-subsidiary environments.

Azure Databricks and the 1:1 Azure Tenant Constraint

Cloud	Databricks Account ↔ Cloud Identity	Workspace Alignment
AWS	One Databricks Account can span multiple AWS Accounts; multiple Databricks Accounts also possible if stronger separation is required	Workspace typically aligned to a single AWS Account
GCP	One Databricks Account can span multiple GCP projects	Workspace typically aligned to a single GCP Project
Azure	One Databricks Account = One Azure Tenant (a fixed 1:1 relationship)	Workspaces can span multiple Subscriptions / Resource Groups but inherit the same Databricks Account and—per region—the same Unity Catalog Metastore

This means: if multiple subsidiaries share the same Azure Tenant, they inherently share the same Databricks Account and, within each region, the same Unity Catalog Metastore and System Tables. Operating fully separated Databricks Accounts requires separate Azure Tenants (Option A).

Why Subsidiaries Share an Azure Tenant

Shared Azure Tenants are common across enterprise groups:

Unified identity — SSO through a shared Entra ID
Cost consolidation — Aggregated Azure consumption for volume discounts
IT governance — Centralized security policies and compliance management
M&A history — Acquired entities integrated into the parent's existing Tenant

These are sound decisions. However, architects must understand how a shared Tenant maps to the Databricks Account model before finalizing the platform design.

Architecture Options

Option A: Separate Tenants Per Subsidiary (Full Isolation)

Each subsidiary operates its own Azure Tenant with an independent Databricks Account.

Recommended: when regulatory requirements mandate strict data isolation between legal entities, or each subsidiary has independent compliance policies.

Key trade-offs: no volume discount aggregation, cross-tenant data sharing requires Azure B2B or external layers, Entra ID redesign if SSO is currently unified, and multiplied operational overhead.

Option B: Shared Tenant with Separate Workspaces (Practical Isolation)

All subsidiaries share the Azure Tenant and Databricks Account, with dedicated Workspaces per subsidiary.

Recommended: when a shared Entra ID is already in place and identity redesign is not feasible, or a balance of cost efficiency and security isolation is required.

This is the more common pattern in enterprise deployments. It works well, provided the following design considerations are properly addressed.

Note: Stronger UC-level separation is sometimes achieved by spanning multiple Azure regions (one Metastore per region by default); however, cross-region deployments must account for data residency and sovereignty requirements. Deploying multiple Metastores within a single region requires explicit Databricks approval and is not the default supported pattern.

Key Design Considerations for Option B

1. Account Admin Governance

The Account Admin role has authority over all Workspaces in the account. Limit assignments to a small, designated group, establish formal governance policies, and audit activity regularly.

2. Entra ID Group Design

Workspace access is controlled through Entra ID group assignments. Misconfigured group mappings can result in unintended cross-subsidiary access. Define clear naming conventions per subsidiary, map each group to a specific Workspace, and review assignments periodically — especially after M&A.

3. Catalog-Workspace Binding

Unity Catalog supports binding specific Catalogs to specific Workspaces. Bind each subsidiary's Catalogs exclusively to their Workspace, and avoid shared Catalogs unless there is a clear cross-subsidiary data sharing requirement. Note that binding restricts Catalog usage at the Workspace level but does not prevent Metastore or Account Admins from accessing the data.

4. System Tables and Cross-Workspace Visibility

Because all Workspaces in a region share a single Metastore, System Tables aggregate data across all Workspaces within that region. This requires explicit management — covered in detail below.

5. Cross-Subsidiary Delta Sharing and Clean Rooms

Cross-subsidiary data sharing via Delta Sharing or Clean Rooms becomes more complex within a shared Metastore — the Metastore ID is identical across subsidiaries, and Clean Room quotas are enforced at the Metastore level. Establish naming conventions for Clean Rooms and Recipients (e.g., <subsidiary>-<usecase>-cr), and manage quotas centrally at the platform-team level since all subsidiaries share the same pool.

Deep Dive: System Tables in a Multi-Subsidiary Account

System Tables collect operational metadata from every Workspace under the shared account. While designed for centralized observability, this creates cross-subsidiary visibility that must be addressed. Note that certain System Tables, including system.query.history, are currently in Public Preview.

Key Risks

Risk 1: Query Text Exposure via `system.query.history`
statement_text stores the verbatim SQL of every query executed across all Workspaces:

User Query Example
SELECT customer_id, national_id, date_of_birth, annual_income FROM catalog_a.customers.profile WHERE region = 'US'

This query text — including column names that reveal what sensitive data is being accessed — is visible to Account Admins, Metastore Admins, and any user with explicit GRANT access, regardless of which Workspace they belong to.

Risk 2: Audit Trail Exposure via `system.access.audit`
system.access.audit logs user actions across all Workspaces — including who accessed which tables, when, and from where. This can reveal a subsidiary's data access patterns and user activity to administrators outside that subsidiary.

Note: with Verbose Audit Logs enabled, system.access.audit also captures full notebook and SQL command text, which can contain sensitive data values — broadening cross-subsidiary exposure beyond access metadata.

Mitigation Strategies

Mitigation 1: Customer Managed Keys (CMK) for Query Text
Enabling CMK for Databricks Managed Services encrypts the statement_text and error_message fields so they appear empty in system.query.history unless you additionally configure data encryption settings on the system catalog to decrypt these fields:

CMK for Managed Services enabled on workspace 
→ system.query.history.statement_text = "" (encrypted, appears empty) 
→ To decrypt: configure data_encryption_settings on `system` catalog per Metastore (requires MANAGE; up to 24h propagation)

Trade-offs: CMK is configured per-Workspace, but System Tables are shared at the Metastore (region) level — so statement_text remains visible across subsidiaries unless CMK is enabled on every Workspace. Azure Key Vault management overhead also applies. Note that CMK encrypts text fields only; access metadata (executed_by, workspace_id, timestamps, compute used) remains visible.

Mitigation 2: Restrict GRANT Access to System Tables
By default, only Account Admins and Metastore Admins can access System Tables. Do not extend access broadly. If subsidiary teams need operational metrics, provide curated views instead of direct access.

Mitigation 3: Curated Views with Workspace-Level Filtering
Create filtered views that restrict each subsidiary to their own Workspace data:

CREATE VIEW shared_ops.subsidiary_a.query_history AS 
SELECT statement_id, executed_by, start_time, execution_status, workspace_id 
FROM system.query.history WHERE workspace_id = '<subsidiary_a_workspace_id>';

GRANT SELECT ON VIEW shared_ops.subsidiary_a.query_history 
TO `subsidiary_a_admins`;

Note: this view deliberately excludes statement_text. Apply the same pattern for system.access.audit as needed.

Mitigation 4: Admin Governance Policy
Account Admins and Metastore Admins have inherent access to all System Tables, so technical controls alone are not sufficient. Require these roles to be held by the central platform team, not subsidiary-level staff, and include System Table access in internal security audits.

Mitigation 5: Treat Verbose Audit Logs as Sensitive
If Verbose Audit Logs are enabled for compliance reasons, restrict access to the system.access.audit table using the same curated-view pattern, and apply per-workspace filtering before granting subsidiary admins read access.

Summary of Mitigations

Mitigation	What It Addresses	Scope
CMK for Managed Services	statement_text / error_message encrypted (appears empty; decryptable via system catalog key)	Per-workspace setting; System Tables shared at region level
Restrict GRANT access	Prevents broad System Table access	Access control layer
Curated views with workspace filtering	Subsidiary-scoped data without cross-visibility	Per-subsidiary
Admin governance policy	Controls admin-level bypass	Organizational layer
Treat Verbose Audit Logs as sensitive	Command-body exposure when Verbose Audit Logs capture notebook/SQL text	Conditional — when Verbose Audit Logs are enabled

Comparison

Criteria	Option A (Separate Tenants)	Option B (Shared Tenant)
Security isolation	Highest (physical separation)	High (Workspace + Catalog boundary), shared System Tables
Cost	Highest	Medium
Cross-subsidiary data sharing	Difficult (cross-tenant)	Moderate (cross-Workspace governance required)
Entra ID integration	Requires redesign	Works as-is
System Tables visibility	Fully isolated	Cross-Workspace — mitigate with CMK + views
Best for	Regulated industries	Most enterprise groups (with governance + CMK)

Migration Between Options

The choice between Option A and Option B is difficult to reverse. There is no native Databricks feature for tenant-to-tenant Workspace migration. Moving from Option A (separate Tenants) to Option B (shared Tenant) — a common scenario during M&A consolidation — requires:

Rebuilding Workspaces under the target Tenant
Manually migrating notebooks, jobs, clusters, and configurations
Re-establishing Unity Catalog objects (catalogs, schemas, tables, permissions)
Reconfiguring network infrastructure (VNet injection, Private Link)
Coordinating Entra ID identity changes across both Tenants

The reverse — splitting from Option B to Option A — carries similar overhead.
Treat this as an early, strategic decision. Revisiting the architecture post-deployment is operationally expensive and disruptive. When in doubt, consider the organization's 3–5 year M&A and restructuring outlook before committing.

Recommendations

Option B is the practical choice for most corporate groups. With Workspace isolation, Catalog binding, Entra ID governance, and CMK, it meets the majority of enterprise requirements.
Option A when regulation demands it. The additional cost and complexity are justified by compliance obligations.
Address all five design considerations explicitly — Account Admin governance, Entra ID group design, Catalog-Workspace binding, System Tables visibility, and cross-subsidiary Delta Sharing / Clean Room constraints.
Enable CMK for Managed Services if any Workspace processes queries containing PII or sensitive business data.

Conclusion

The 1:1 relationship between Azure Databricks and Azure Tenant is a platform-specific constraint that does not exist on AWS or GCP. When subsidiaries share an Azure Tenant, they share a Databricks Account — and with it, within each region, a Unity Catalog Metastore and all System Tables.

Understanding this constraint and its implications is the starting point for a secure multi-subsidiary deployment. The architecture options are straightforward; the critical factor is ensuring that shared-account considerations are addressed explicitly in the platform design.

Beyond the deployment decision itself, Unity Catalog — together with Delta Sharing for controlled cross-entity data exchange — provides the governance foundation that lets enterprise groups scale data collaboration across subsidiaries while preserving clear boundaries.

———

This article is based on deployment experience from the Databricks Field Engineering team. We hope it serves as a useful reference for architects designing Azure Databricks platforms in corporate group environments.