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.

New to cloud? CAMPUX is a free, build-first course. Start here →

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.

Figure — Workspace design is mostly a centralize-versus-sprawl decision. Sending logs from many subscriptions into one (or a few) Log Analytics workspaces lets you query across the whole estate with KQL, correlate incidents, and manage cost in one place. You then control the blast radius inside it: table-level RBAC grants teams only their data, and per-table retention plus cheap archive tiers keep the bill sane. Prefer a small number of shared workspaces over one-per-resource; split only for hard data-sovereignty or isolation needs.

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.

A sane default architecture

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. 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 design you settle on after inheriting a dozen workspaces nobody can account for and deciding not to hand that mess to whoever comes next.

Questions people also ask

How many Log Analytics workspaces should you have?

As few as possible. Start with a single workspace for your organization and add more only when a concrete requirement forces it - data residency, hard access separation, per-table retention differences, a second Entra tenant, or split billing. Data volume alone never justifies a second workspace.

What is a Log Analytics workspace used for?

It is the container Azure Monitor logs land in and the unit you query with KQL. Resources send diagnostic and telemetry data into a workspace, and you run queries, build dashboards, set alerts, and configure retention against that workspace as a whole.

Does the size of a Log Analytics workspace affect performance?

No. The amount of data stored in a workspace imposes no performance limit on queries or ingestion. This is exactly why Microsoft recommends starting with one workspace - you never need to split for scale, only for a boundary like residency, access control, or retention.

What is the default data retention for a Log Analytics workspace?

Interactive retention defaults to 30 days for most Analytics tables, though some tables default to 90 days. You can raise interactive retention up to two years per workspace or per table, and keep data in long-term retention for up to 12 years total, accessible through search jobs rather than live queries.

Should each Azure subscription have its own Log Analytics workspace?

Not by default. A workspace is not tied one-to-one with a subscription - resources across multiple subscriptions can send data to the same workspace as long as they share an Entra tenant. Split by subscription only when you need separate billing or ownership boundaries, not simply because resources live in different subscriptions.