5.2 Workspace Architecture Decisions
Workspace Architecture Decisions
By the end of this subsection, you will be able to choose between single and multi-workspace architectures, understand geo-residency requirements, and design a workspace topology for a given organization.
These decisions are made once and are painful to change. Moving data between workspaces requires re-ingestion — you cannot transfer existing data. Choose carefully.
Single workspace vs multi-workspace
Single workspace (recommended for most organizations):
One Log Analytics workspace with Sentinel enabled. All data sources ingest into this workspace. All analytics rules, hunting queries, and automation run against one unified dataset.
Advantages: simplest to manage, all data in one place for cross-source correlation, single set of analytics rules, single incident queue. The overwhelming majority of organizations — up to 5,000 users — run a single workspace.
Multi-workspace (required for specific scenarios):
| Reason | Example | Architecture |
|---|---|---|
| Data residency | EU data cannot leave the EU region | EU workspace (EU region) + US workspace (US region) |
| Tenant boundaries | MSSP managing 10 client tenants | One workspace per client, central workspace for cross-tenant visibility |
| Access control | HR investigation data must be restricted from general SOC | Restricted workspace for HR data, main workspace for everything else |
| Cost separation | Business units need separate Azure billing | Workspace per billing entity |
Each workspace needs its own analytics rules, its own retention configuration, and its own connector setup. Cross-workspace queries are possible (using the workspace() function in KQL) but are slower and subject to throttling. Do not create multiple workspaces unless you have a concrete reason from the table above.
Dev/test vs production
Create a separate dev/test workspace for testing analytics rules before deploying them to production. This avoids alert noise from broken rules hitting your production incident queue.
The dev workspace does not need full data ingestion — connect only the data sources you are testing against, and use minimal retention (30 days).
Naming conventions
Consistent naming across your Azure environment prevents confusion as the workspace count grows:
law-{company}-{purpose}-{region}
Examples:
law-northgate-sentinel-eastus(production Sentinel workspace, East US)law-northgate-sentinel-dev-eastus(dev/test workspace)law-northgate-sentinel-eu-westeurope(EU-resident data workspace)
Place the Log Analytics workspace and Sentinel in a dedicated resource group: rg-sentinel-prod. Do not mix them with application resources. This makes access control, cost tracking, and lifecycle management cleaner. Apply a resource lock (CanNotDelete) to prevent accidental workspace deletion.
Region selection
Choose the Azure region closest to your primary data sources. Sentinel’s performance is optimized when data does not cross regions during ingestion. For US-based organizations, East US or East US 2 are common choices. For EU-based organizations requiring GDPR data residency, West Europe or North Europe.
A Log Analytics workspace is created in a specific Azure region. You cannot move it to a different region later. If you choose incorrectly and need to change regions, you must create a new workspace and re-configure all data connectors. Verify your region choice against any data residency requirements before creating the workspace.
Architecture decision: how many workspaces?
Check your understanding
1. A 200-person company with M365 E5 and no third-party tools asks whether they need multiple workspaces. What do you recommend?
2. You created a workspace in East US but your organization just acquired a German subsidiary with GDPR data residency requirements. What do you do?