A single Azure Log Analytics workspace is often a sensible starting point. It can reduce management and query complexity, and consolidating ingestion may support commitment-tier economics. But “one workspace” is not a governance principle by itself. It is a design choice that should follow explicit decisions about tenancy, access, region, retention, data residency, ownership, billing, and operational responsibility.
Microsoft’s guidance recommends starting with one workspace and adding only the minimum number required by documented requirements. The amount of data in a workspace does not impose a performance limitation, so volume alone is not a reason to split. Workspace count is a different matter: querying across a large number of workspaces is slow and does not scale beyond roughly 100 workspaces unless they share a dedicated cluster. The question is whether separation solves a defined problem without creating more operational work. Microsoft guidance
Start with the boundaries
Begin by mapping the boundaries that already exist:
- Which Microsoft Entra tenants are in scope?
- Which subscriptions and regions send data?
- Which data must remain in a particular jurisdiction or region?
- Which teams own operational data, security data, or both?
- Which parties need distinct billing or chargeback?
- Which workloads require regional resilience?
- Which monitoring agents are deployed, and can each reach every workspace it needs?
Most resources can send monitoring data only to a workspace in the same Microsoft Entra tenant. In a multi-tenant environment, that commonly means a workspace for each tenant, subject to documented exceptions for certain agents and service-provider scenarios. Microsoft guidance
Each workspace resides in one Azure region. Separate regional workspaces may be appropriate where data residency or regulatory requirements require regional placement. They may also be justified when cross-region bandwidth or egress costs from virtual machines are significant — though Microsoft characterizes those charges as usually minor relative to ingestion cost for most customers, and monitoring data sent through diagnostic settings does not incur egress charges at all. Without those requirements or a material cost impact, the guidance favors one workspace across regions. Microsoft guidance
Check the agents before committing to a multi-workspace design. Azure Monitor Agent and the Log Analytics agent for Windows can connect to multiple workspaces, but the Log Analytics agent for Linux can connect to only one. A separation that looks clean on paper can be unimplementable on the Linux estate until those machines migrate to Azure Monitor Agent. Avoid sending duplicate data to multiple workspaces to work around it: that adds ingestion charges for the same records. Microsoft guidance
Decide whether access requires separation
A workspace-level access model can expose all data in that workspace. Resource-context RBAC and table-level RBAC provide more granular options, so separation is not automatically required for every team or data type.
The decision should be based on the access model you can implement and operate. If operational and security teams can use the required resource- or table-level controls, consolidation may preserve useful cross-domain visibility. If ownership or security boundaries cannot be enforced adequately, separate workspaces may be the clearer control boundary. Microsoft guidance
This is also where Microsoft Sentinel ownership matters. Combining operational and security data can simplify queries and may help reach a commitment tier. Separating them can distinguish ownership and avoid applying Microsoft Sentinel pricing to operational data in the same workspace, but it can reduce cross-domain visibility. Weigh one more factor in that comparison: a workspace with Microsoft Sentinel enabled receives three months of free data retention instead of the standard 31 days, so a separate operational workspace loses that allowance. The pricing and access consequences should be validated against the current environment rather than assumed. Microsoft guidance
Test retention before creating another workspace
Different retention requirements do not always require different workspaces. Workspace- and table-level retention can be configured independently. A separate workspace becomes more relevant when resources writing to the same table require different retention settings that the existing configuration cannot accommodate.
Make this a data-class decision, not a blanket assumption. Identify the data owners, required retention for each class, and whether table-level settings are sufficient. Microsoft guidance
Separate ownership or billing only when reporting is insufficient
Subsidiaries, affiliates, or independent operating teams may need distinct ownership boundaries. Separate subscriptions and workspaces can support billing different parties. But Cost Management and log-query reporting by resource, resource group, or subscription may provide enough granularity to avoid creating workspaces solely for chargeback.
The decision right belongs with the owners of the financial and operational model. Document the required chargeback granularity first, then test whether current reporting meets it. Microsoft guidance
Account for the cost of both designs
Centralization can reduce ingestion cost because commitment tiers are based on committed daily ingestion in a workspace. Spreading equivalent volume across multiple workspaces can prevent access to the same tier unless a dedicated cluster combines the data. Microsoft puts a usable threshold on that: at 100 GB or more of daily ingestion across resources, a dedicated cluster becomes the recommended route, and it lets several workspaces pool their volume toward one commitment tier.
Multiple workspaces can still be justified, but they add integration and resilience work. Separate regional workspaces may improve availability after a regional failure, while requiring separate management of integrations, alerts, workbooks, and failover configuration. The value of that resilience should be weighed against the additional configuration and operational ownership. Microsoft guidance
Also review the table level. Workspace and table configuration affect access, data model, retention, ingestion, and cost. Creating another workspace is not the only way to change the economics or control model. Microsoft overview
A practical decision record
Before changing the design, capture:
- Proposed topology: tenants, subscriptions, regions, and workspaces.
- Boundary rationale: the documented tenancy, access, residency, retention, ownership, billing, cost, or resilience requirement.
- Alternatives considered: one workspace, separate workspaces, or table-level and resource-context controls.
- Operational impact: alerts, workbooks, integrations, failover, agent configuration, and runbooks.
- Cost assumptions: ingestion volumes, commitment-tier implications, cross-region transfer, and any duplicated ingestion.
- Decision rights: named owners for platform, security, data, finance, and regional operations.
- Validation plan: confirm current RBAC, retention, reporting, agent constraints, and regional behavior before implementation.
The right answer may be one workspace. It may also be several. The quality of the design depends less on the number than on whether each boundary is intentional, evidenced, and owned.
If workspace sprawl is creating uncertainty, Falstech can help review the current topology, document the decision criteria, and scope bounded Microsoft cloud engineering work around the changes your environment actually requires. Discuss your environment.