Log Analytics Workspace Design Gotchas

Hello Folks,

Lately I've had a few conversations regarding Log Analytics workspace design.  More specifically, questions like:

  1. Do I create one central workspace with all data?
  2. Should I create one workspace per application?
  3. Should each team have their own workspace?

Design conundrum

Figuring out how many workspaces, you need is determined by one or more of the following requirements:

  • Which region do you need to store the data; do you have data sovereignty or compliance issues we need to comply with?
  • Data Retention. How long do you need to keep the data?
  • Data Access. The workspace is the security boundary for Log Analytics. If you have log data from two different teams, that are not allowed to see each other's data, you'll need to setup different workspaces.
  • Data Collection.  Solutions and data collection settings are set on workspace level. So, if you turn on collection of warnings in the Application log on Windows servers, that setting will be applied to all connected Windows servers, even if we only need it from some of your servers.

These items are really important to figure out since Log Analytics workspace provides by design:

  • A geographic location for data .
  • Data security by being able to grant different users different access rights to the data.
  • Scope for configuration of settings like pricing tierretention, and data capping.

IT shops these days are setup either in a centralized, decentralized, or an in-between hybrid of both structures. Therefore, the following workspace deployment models have been commonly used to map to one of these organizational structures:

  • Centralized: All logs are stored in a central workspace and administered by a single team, with providing differentiated access per-team.
    • This scenario is easier to manage, search across resources, and cross-correlate logs
  • Decentralized: Each departments or teams runs their own workspaces in a resource group they own and manage. In this scenario, the workspace can be kept secure and access control is consistent with resource access, but it's difficult to cross-correlate logs.
    • I know in that past I wrote about “Querying multiple Log analytics workspace at once” however I have come to realize that when your organization grow and new resources are added if you are adding new Workspaces, you have to edit all your existing cross-workspace queries.
  • Hybrid: Both deployment models in deployed in parallel.
    • This commonly results in a complex, expensive, and hard-to-maintain configuration with gaps in logs coverage.
    • To achieve this we can use the Log Analytics workspace data export method to export from all resource Workspaces to a central account.


  • Configuration can currently only be performed using CLI or REST requests. You cannot use the Azure portal or PowerShell.
  • The –export-all-tables option in CLI and REST isn't supported. You will have to provide the list of tables in export rules explicitly.
  • Your Log Analytics workspace can be in any region except for the following:
    • Switzerland North
    • Switzerland West
    • Azure government regions
  • The destination account or event hub must be in the same region as the Log Analytics workspace.
    • However, there are a few limitations at this point:

So, I really think that a central Workspace is a more reasonable solution for most organizations that have a need for querying all resources.  If you don't or seldom require cross-workspace queries, then a decentralized approach may be appropriate.

Manage access to log data and workspaces.

When deploying a centralized model.  You need to manage access to the logs and to administer the workspaces, including grant access to:

  • The workspace using workspace permissions.
  • Users who need access to log data from specific resources using Azure role-based access control (Azure RBAC) – also known as resource-context
  • Users who need access to log data in a specific table in the workspace using Azure RBAC.

You can view the access control mode configured on a workspace from the Azure portal or with Azure



The 2 Access options are:

Workspace-context: with this access, you can view all logs in the workspace you have permission to. Queries in this mode are scoped to all data in all tables in the workspace. And are queried in the Log Analytics workspace itself. By accessing the workspace, selecting Logs from the left side menu and writing your query in the editor.




Resource-context: this model is aimed at Application teams. Administrators of Azure resources being monitored.  When you access the workspace for a particular resource, resource group, or subscription, such as when you select Logs from a resource menu in the Azure portal, you can view logs for only resources in all tables that you have access to.


Queries in this mode are scoped to only data associated with that resource. This mode also enables granular Azure RBAC.

For more information about designing your Logs deployment there is more information in the following documentation.




This article was originally published by Microsoft's Azure Blog. You can find the original article here.