We’re excited to announce the public preview of resource-scope query for Azure Monitor Workspaces (AMWs)—a major step forward in simplifying observability, improving access control, and aligning with Azure-native experiences.
This new capability builds on the successful implementation of resource-scope query in Log Analytics Workspaces (LAWs), which transformed how users access logs by aligning them with Azure resource scopes. We’re now bringing the same power and flexibility to metrics in AMWs.
What is resource-scope query?
Resource-scope query has been a frequently requested capability that allows users to query metrics scoped to a specific resource, resource group, or subscription—rather than needing to know which AMW the metrics are stored in. This means:
- Simpler querying: users can scope to the context of one or more resources directly, without knowledge of where metrics are stored.
- Granular Azure RBAC control: if the AMW is configured in resource-centric access mode, user permissions are checked against the resources they are querying for, rather than access to the workspace itself - just like how LAW works today. This supports security best practices for least privileged access requirements.
Why use resource-centric query?
Traditional AMW querying required users to:
- Know the exact AMW storing their metrics.
- Have access to the AMW.
- Navigate away from the resource context to query metrics.
This created friction for DevOps teams and on-call engineers who do not necessarily know which AMW to query when responding to an alert.
With resource-centric querying:
- Users can query metrics directly from the resource’s Metrics blade.
- Least privilege access is respected—users only need access to the resource(s) they are querying about.
- Central teams can maintain control of AMWs while empowering app teams to self-monitor.
How does it work?
All metrics ingested via Azure Monitor Agent are automatically stamped with dimensions like Microsoft.resourceid, Microsoft.subscriptionid, and Microsoft.resourcegroupname to enable this experience. The addition of these dimensions does not have any cost implications to end users.
Resource-centric queries use a new endpoint:
https://query.<region>.prometheus.monitor.azure.com |
We will re-route queries as needed from any region, but we recommend choosing the one nearest to your AMWs for the best performance.
Users can query via:
- Azure Portal PromQL Editor
- Grafana dashboards (with data source configuration)
- Query-based metric alerts
- Azure Monitor solutions like Container Insights and App Insights (when using OTel metrics with AMW as data source)
- Prometheus HTTP APIs
When querying programmatically, users pass an HTTP header:
x-ms-azure-scoping: <ARM Resource ID> |
Scoping supports a single:
- Individual resource
- Resource group
- Subscription
At this time, scoping is only support at a single-resource level, but comma-separated multi-resource scoping will be added by the end of 2025.
Who Can Benefit?
- Application Teams: Query metrics for their own resources without needing AMW access.
- Central Monitoring Teams: Maintain control of AMWs while enabling secure, scoped access for app teams.
- DevOps Engineers: Respond to alerts and troubleshoot specific resources without needing to locate the AMW(s) storing the metrics they need.
- Grafana Users: Configure dashboards scoped to subscriptions or resource groups with dynamic variables without needing to identify the AMW(s) storing their metrics.
When Is This Available?
- Microsoft. dimension stamping* is already complete and ongoing for all AMWs.
- Public Preview of the resource-centric query endpoint begins October 10th, 2025.
- Starting on that date, all newly created AMWs will default to resource-context access mode.
What is the AMW “access control mode”?
The access control mode is a setting on each workspace that defines how permissions are determined for the workspace.
- Require workspace permissions. This control mode does NOT allow granular resource-level Azure RBAC. To access the workspace, the user must be granted permissions to the workspace.
When a user scopes their query to a workspace, workspace permissions apply. When a user scopes their query to a resource, both workspace permissions AND resource permissions are verified.
This setting is the default for all workspaces created before October 2025.
- Use resource or workspace permissions. This control mode allows granular Azure RBAC. Users can be granted access to only data associated with resources they can view by assigning Azure read permission.
When a user scopes their query to a workspace, workspace permissions apply. When a user scopes their query to a resource, only resource permissions are verified, and workspace permissions are ignored.
This setting is the default for all workspaces created after October 2025.
Read about how to change the control mode for your workspaces here.
Final Thoughts
Resource-centric query brings AMWs in line with Azure-native experiences, enabling secure, scalable, and intuitive observability. Whether you’re managing thousands of VMs, deploying AKS clusters, or building custom apps with OpenTelemetry, this feature empowers you to monitor in the context of your workloads or resources rather than needing to first query the AMW(s) and then filter down on what you’re looking for.
To get started, simply navigate to your resource’s Metrics blade after October 10th, 2025 or configure your Grafana data source to use the new query endpoint.