Log Analytics workspace design: start with one, split only when you must
The question sounds architectural and important: how many Log Analytics workspaces should we have, one per team, one per environment, one per region? Microsoft's answer is refreshingly blunt — start with one, and only split when a concrete requirement forces you to. Most of the sprawl people build is complexity they never needed.
A Log Analytics workspace is the container your Azure Monitor logs land in and the thing you query with KQL. The moment you have more than a couple of teams and regions, someone proposes carving up workspaces along org-chart lines — and that instinct is usually wrong. Microsoft's guidance is unusually direct: "Your design should always start with a single workspace" and, as you find reasons to add more, "use the fewest number of workspaces to meet your requirements."
Why one is the right default
Two facts make a single workspace the sane starting point. First, size is not a problem: the amount of data in a workspace imposes no performance limit, and many services and sources can all send to the same one. Second, splitting has a real cost — querying across multiple workspaces is more awkward, dashboards and alerts have to know where to look, and every extra workspace is another thing to configure and govern. A single workspace keeps all your telemetry in one queryable place, which is exactly what you want when you are trying to correlate a spike in one service with an error in another at 2am. Complexity should have to justify itself; the default is one.
Data volume never forces a split — a workspace does not slow down as it fills. So the reasons to add workspaces are always about boundaries, not size.
The real reasons to split
You add workspaces when a specific requirement can only be met by a boundary. The ones that genuinely justify it:
- Data residency. Each workspace lives in one Azure region. If regulation says European data must stay in Europe, you need a workspace in that geography — this is often the first legitimate reason to have more than one.
- Access control. Granting someone access to a workspace grants access to all its data. If a team must be walled off entirely, a separate workspace is the cleanest boundary — though note you can often solve this within one workspace using table-level RBAC and resource-context access, before you reach for a split.
- Retention. You can set retention per workspace and per table. If two sets of data land in the same table but need different retention, that forces separate workspaces.
- Multiple Entra tenants. Most resources can only send to a workspace in their own tenant, so multiple tenants usually means at least one workspace each.
- Split billing / ownership. Placing workspaces in separate subscriptions lets you bill different parties or hard-segregate data ownership between subsidiaries.
Cost cuts both ways — so evaluate it deliberately
Cost is the criterion people get backwards, because it can argue for either direction. Consolidating into one workspace can qualify you for a commitment tier — commit to, say, 100 GB/day and get a discount you would not reach if the same volume were scattered across small workspaces. But splitting by region can reduce cross-region bandwidth charges. And a subtle trap: enabling Microsoft Sentinel on a workspace subjects all data in it to Sentinel pricing, so mixing plain operational logs into a Sentinel workspace can quietly raise the bill. Microsoft's advice is to evaluate each criterion independently and accept that some pull against each other — there is no single formula, only a weighing.
For most organizations: one central workspace for operational monitoring, in your primary region, with access managed by resource-context RBAC and table-level RBAC rather than by carving up workspaces. Add a second workspace only when a hard requirement appears — a data-residency rule, a security team that needs its own Sentinel workspace, a subsidiary that must be billed and isolated separately. Name every workspace with a meaningful indicator of its purpose. If you find yourself with a dozen workspaces and cannot say which requirement each one satisfies, that is the smell of a design that grew by org chart instead of by need.
The takeaway
Log Analytics workspace design is a discipline of restraint. Start with a single workspace, because data volume never forces a split and consolidation keeps your telemetry queryable in one place. Add workspaces only for concrete boundaries you cannot satisfy any other way — data residency, hard access separation, per-table retention differences, separate tenants, or split billing — and reach for table-level RBAC and commitment tiers before you reach for another workspace. "One central workspace, split only where residency or a dedicated security tenant demands it, named so anyone can tell what each is for" is the answer of someone who has untangled a workspace sprawl and would rather not build one.