Edit

Design your Microsoft Sentinel workspace architecture

  • Article

This article provides a decision tree to help you make key decisions about how to design your Microsoft Sentinel workspace architecture. For more information, see Microsoft Sentinel sample workspace designs and Microsoft Sentinel workspace architecture best practices. This article is part of the Deployment guide for Microsoft Sentinel.

Prerequisites

Before working through the decision tree, make sure you have the following information:

Prerequisite Description
Regulatory requirements related to Azure data residency Microsoft Sentinel can run on workspaces in most, but not all regions supported in GA for Log Analytics. Newly supported Log Analytics regions might take some time to onboard the Microsoft Sentinel service.

Data generated by Microsoft Sentinel, such as incidents, bookmarks, and analytics rules, might contain some customer data sourced from the customer's Log Analytics workspaces.

For more information, see Geographical availability and data residency.
Data sources Find out which data sources you need to connect, including built-in connectors to both Microsoft and non-Microsoft solutions. You can also use Common Event Format (CEF), Syslog or REST-API to connect your data sources with Microsoft Sentinel.

If you have Azure VMs in multiple Azure locations that you need to collect the logs from and the saving on data egress cost is important to you, you need to calculate the data egress cost using Bandwidth pricing calculator for each Azure location.
User roles and data access levels/permissions Microsoft Sentinel uses Azure role-based access control (Azure RBAC) to provide built-in roles that can be assigned to users, groups, and services in Azure.

All Microsoft Sentinel built-in roles grant read access to the data in your Microsoft Sentinel workspace. Therefore, you need to find out whether there's a need to control data access per data source or row-level as that will impact the workspace design decision. For more information, see Custom roles and advanced Azure RBAC.
Daily ingestion rate The daily ingestion rate, usually in GB/day, is one of the key factors in cost management and planning considerations and workspace design for Microsoft Sentinel.

In most cloud and hybrid environments, networking devices, such as firewalls or proxies, and Windows and Linux servers produce the most ingested data. To obtain the most accurate results, Microsoft recommends an exhaustive inventory of data sources.

Alternatively, the Microsoft Sentinel cost calculator includes tables useful in estimating footprints of data sources.

Important: These estimates are a starting point, and log verbosity settings and workload will produce variances. We recommend that you monitor your system regularly to track any changes. Regular monitoring is recommended based on your scenario.

For more information, see Azure Monitor Logs pricing details.

Decision tree

The following image shows a full decision tree flow chart to help you understand how to best design your workspace.

Microsoft Sentinel workspace design decision tree.

The following sections provide a full-text version of this decision tree, including the following notes referenced from the image:

Note #1 | Note #2 | Note #3 | Note #4 | Note #5 | Note #6 | Note #7 | Note #8 | Note #9 | Note #10

Step 1: New or existing workspace?

Do you have an existing workspace that you can use for Microsoft Sentinel?

  • If not, and you'll be creating a new workspace in any case, continue directly with step 2.

  • If you have an existing workspace that you might use, consider how much data you'll be ingesting.

    • If you'll be ingesting more than 100 GB / day, we recommend that you use a separate workspace for the sake of cost efficiency.

    • If you'll be ingesting less than 100 GB / day, continue with step 2 for further evaluation. Consider this question again when it arises in step 5.

Step 2: Keeping data in different Azure geographies?

  • If you have regulatory requirements to keep data in different Azure geographies, use a separate Microsoft Sentinel workspace for each Azure region that has compliance requirements. For more information, see Region considerations.

  • If you don't need to keep data in different Azure geographies, continue with step 3.

Step 3: Do you have multiple Azure tenants?

  • If you have only a single tenant, continue directly with step 4.

  • If you have multiple Azure tenants, consider whether you're collecting logs that are specific to a tenant boundary, such as Office 365 or Microsoft Defender XDR.

    • If you don't have any tenant-specific logs, continue directly with step 4.

    • If you are collecting tenant-specific logs, use a separate Microsoft Sentinel workspace for each Microsoft Entra tenant. Continue with step 4 for other considerations.

      Decision tree note #1: Logs specific to tenant boundaries, such as from Office 365 and Microsoft Defender for Cloud, can only be stored in the workspace within the same tenant.

      Although it's possible to use custom collectors to collect tenant-specific logs from a workspace in another tenant, we don't recommend this due to the following disadvantages:

      • Data collected by custom connectors will be ingested into custom tables. Therefore, you won’t be able to use all the built-in rules and workbooks.
      • Custom tables aren't considered by some of the built-in features, such as UEBA and machine learning rules.
      • Additional cost and effort required for the custom connectors, such as using Azure Functions and Logic Apps.

      If these disadvantages aren't a concern for your organization, continue with step 4 instead of using separate Microsoft Sentinel workspaces.

Step 4: Splitting billing / charge-back?

If you need to split your billing or charge-back, consider whether the usage reporting or manual cross-charge works for you.

  • If you do not need to split your billing or charge-back, continue with step 5.

  • If you do need to split your billing or charge-back, consider using manual cross-charge. In order to get accurate costs per entity, you can use a modified version of the Microsoft Sentinel Cost workbook that breaks down the cost by entity.

    • If usage reporting or manual cross-charging works for you, continue with step 5.

    • If neither usage reporting or manual cross-charging will work for you, use a separate Microsoft Sentinel workspace for each cost owner.

    Decision tree note #2: For more information, see Microsoft Sentinel costs and billing.

Step 5: Collecting any non-SOC data?

  • If you are not collecting any non-SOC data, such as operational data, you can skip directly to step 6.

  • If you are collecting non-SOC data, consider whether there are any overlaps, where the same data source is required for both SOC and non-SOC data.

    If you do have overlaps between SOC and non-SOC data, treat the overlapping data as SOC data only. Then, consider whether the ingestion for both SOC and non-SOC data individually is less than 100 GB / day, but more than 100 GB / day when combined:

    • Yes: Proceed with step 6 for further evaluation.
    • No: We don't recommend using the same workspace for the sake of cost efficiency. Proceed with step 6 for further evaluation.

    In either case, for more information, see note 10.

    If you have no overlapping data, consider whether the ingestion for both SOC and non-SOC data individually is less than 100 GB / day, but more than 100 GB / day when combined:

    • Yes: Proceed with step 6 for further evaluation. For more information, see note 3.
    • No: We don't recommend using the same workspace for the sake of cost efficiency. Proceed with step 6 for further evaluation.

Combining your SOC and non-SOC data

Decision tree note #3: While we generally recommend that customers keep a separate workspace for their non-SOC data so that non-SOC data isn't subject to Microsoft Sentinel costs, there might be situations where combining SOC and non-SOC data is less expensive than separating them.

For example, consider an organization that has security logs ingesting at 50 GB/day, operations logs ingesting at 50 GB/day, and a workspace in the East US region.

The following table compares workspace options with and without separate workspaces.

Note

Costs and terms listed in the following table are fake, and used for illustrative purposes only. For up-to-date cost information, see the Microsoft Sentinel pricing calculator.

Workspace architecture Description
The SOC team has its own workspace, with Microsoft Sentinel enabled.

The Ops team has its own workspace, without Microsoft Sentinel enabled.		 SOC team:
Microsoft Sentinel cost for 50 GB/day is $6,500 per month.
First three months of retention are free.

Ops team:
- Cost of Log Analytics at 50 GB/day is around $3,500 per month.
- First 31 days of retention are free.

The total cost for both equals $10,000 per month.
Both SOC and Ops teams share the same workspace with Microsoft Sentinel enabled. By combining both logs, ingestion will be 100 GB / day, qualifying for eligibility for Commitment Tier (50% for Sentinel and 15% for LA).

Cost of Microsoft Sentinel for 100 GB / day equals $9,000 per month.

In this example, you'd have a cost savings of $1,000 per month by combining both workspaces, and the Ops team will also enjoy 3 months of free retention instead of only 31 days.

This example is relevant only when both SOC and non-SOC data each have an ingestion size of >=50 GB/day and <100 GB/day.

Decision tree note #10: We recommend using a separate workspace for non-SOC data so that non-SOC data isn't subjected to Microsoft Sentinel costs.

However, this recommendation for separate workspaces for non-SOC data comes from a purely cost-based perspective, and there are other key design factors to examine when determining whether to use a single or multiple workspaces. To avoid double ingestion costs, consider collecting overlapped data on a single workspace only with table-level Azure RBAC.

Step 6: Multiple regions?

  • If you are collecting logs from Azure VMs in a single region only, continue directly with step 7.

  • If you are collecting logs from Azure VMs in multiple regions, how concerned are you about the data egress cost?

    Decision tree note #4: Data egress refers to the bandwidth cost for moving data out of Azure datacenters. For more information, see Region considerations.

    • If reducing the amount of effort required to maintain separate workspaces is a priority, continue with step 7.

    • If the data egress cost is enough of a concern to make maintaining separate workspaces worthwhile, use a separate Microsoft Sentinel workspace for each region where you need reduce the data egress cost.

      Decision tree note #5: We recommend that you have as few workspaces as possible. Use the Azure pricing calculator to estimate the cost and determine which regions you actually need, and combine workspaces for regions with low egress costs. Bandwidth costs might be only a small part of your Azure bill when compared with separate Microsoft Sentinel and Log Analytics ingestion costs.

      For example, your cost might be estimated as follows:

      • 1,000 VMs, each generating 1 GB / day;
      • Sending data from a US region to an EU region;
      • Using a 2:1 compression rate in the agent

      The calculation for this estimated cost would be: 1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost

      This sample cost would be much less expensive when compared with the monthly costs of a separate Microsoft Sentinel and Log Analytics workspace.

      Note

      Listed costs are fake and are used for illustrative purposes only. For up-to-date cost information, see the Microsoft Sentinel pricing calculator.

Step 7: Segregating data or defining boundaries by ownership?

  • If you do not need to segregate data or define any ownership boundaries, continue directly with step 8.

  • If you do need to segregate data or define boundaries based on ownership, does each data owner need to use the Microsoft Sentinel portal?

    • If each data owner must have access to the Microsoft Sentinel portal, use a separate Microsoft Sentinel workspace for each owner.

      Decision tree note #6: Access to the Microsoft Sentinel portal requires that each user have a role of at least a Microsoft Sentinel Reader, with Reader permissions on all tables in the workspace. If a user doesn't have access to all tables in the workspace, they'll need to use Log Analytics to access the logs in search queries.

    • If access to the logs via Log Analytics is sufficient for any owners without access to the Microsoft Sentinel portal, continue with step 8.

    For more information, see Permissions in Microsoft Sentinel.

Step 8: Controlling data access by data source / table?

  • If you do not need to control data access by source or table, use a single Microsoft Sentinel workspace.

  • If you do need to control data access by source or table, consider using resource-context RBAC in the following situations:

    • If you need to control access at the row level, such as providing multiple owners on each data source or table

    • If you have multiple, custom data sources/tables, where each one needs separate permissions

    In other cases, when you don't need to control access at the row level, provide multiple, custom data sources/tables with separate permissions, use a single Microsoft Sentinel workspace, with table-level RBAC for data access control.

Considerations for resource-context or table-level RBAC

When planning to use resource-context or table level RBAC, consider the following information:

Next steps

In this article, you reviewed a decision tree to help you make key decisions about how to design your Microsoft Sentinel workspace architecture.

Microsoft Sentinel sample workspace designs