Azure Observability in VNET Environments
- Your agent manages VNET resources through ARM control plane APIs — resource discovery, metrics, Activity Logs, and management operations always work
- Log queries (KQL on Log Analytics, Application Insights) work when observability services allow public network access (the default)
- When observability data is behind private endpoints, deploy an Azure Function inside your VNET as a query proxy — your agent calls the Function, and the Function queries private workspaces through the Private Endpoint
- No additional configuration is needed beyond standard RBAC for the default scenario
The problem: "will it work with my VNET?"
Most enterprise Azure environments deploy workloads inside Virtual Networks for network isolation. Container Apps, App Services, AKS clusters, and VMs run in VNET-isolated subnets with NSGs controlling traffic flow. Some organizations go further and place their observability data behind Azure Monitor Private Link Scope (AMPLS) with public query access disabled.
When evaluating SRE Agent, the first question is: "Can the agent investigate resources inside our VNETs?" The answer depends on two things:
- Whether your agent needs to query control plane data (always works) or data plane endpoints (depends on private link settings)
- Whether your Log Analytics and Application Insights resources allow public queries (default) or deny them (private link only)
If you haven't restricted public access on your Log Analytics or Application Insights resources, everything works with no changes. Jump to Scenario 1 — most enterprise deployments fall into this category.
How your agent accesses Azure resources
Your agent runs on managed infrastructure outside your VNET. It communicates with Azure through two distinct API surfaces.
Control plane (ARM) — always accessible
The Azure Resource Manager (ARM) control plane at management.azure.com is a public service accessible to any authenticated client. VNET isolation applies to the data plane of your resources, not to the ARM control plane.
Your agent uses ARM for:
| Operation | How it works | VNET impact |
|---|---|---|
| Resource discovery | Resource Graph queries across your subscriptions | None — ARM is always accessible |
| Azure Monitor metrics | Metrics API via ARM (/providers/microsoft.insights/metrics) | None — metrics retrieved through ARM |
| Activity Logs | ARM-based event query (/providers/microsoft.insights/eventtypes) | None — ARM is always accessible |
| Resource management | Restart, scale, read configuration, slot operations | None — ARM operations work regardless of VNET |
| Container App info | List revisions, check status, view configuration | None — ARM-based |
| App Service details | Health, deployment slots, configuration | None — ARM-based |
| Redis diagnostics | Cache info, server load, latency metrics | None — ARM SDK and Monitor metrics only |
Azure Monitor metrics, Activity Logs, Resource Graph, and most resource management operations go through ARM. These always work for VNET resources because ARM is not inside your VNET — it's Azure's public management surface.
Data plane — depends on network access settings
Data plane APIs serve log queries and service-specific connections. Unlike ARM, these endpoints can be restricted by private link configurations.
| Operation | Endpoint | Works when | Blocked when |
|---|---|---|---|
| Log Analytics KQL queries | api.loganalytics.io | Workspace allows public access (default) | Public access set to "Deny" |
| Application Insights queries | api.applicationinsights.io | App Insights allows public access (default) | Public access set to "Deny" |
| AKS kubectl operations | AKS API server | API server has public endpoint | Private AKS cluster (private API server) |
| Container App deep diagnostics | Container exec endpoint (WebSocket) | Container has public ingress | Internal-only Container Apps Environment |
| App Service CPU profiling | Kudu/SCM endpoint | SCM site is publicly accessible | Access restrictions block SCM |
| PostgreSQL SQL queries | *.postgres.database.azure.com | Server allows public access | Private endpoint only |
| Kusto (ADX) queries | *.kusto.windows.net | Cluster allows public access | Private endpoint only |
What "inside a VNET" actually means for your agent
A common misconception: "my resources are in a VNET, so nothing can reach them." In practice, VNET isolation has layers:
| Layer | What it is | SRE Agent access |
|---|---|---|
| Compute resources | Container Apps, AKS nodes, VMs, App Services running in VNET subnets | Managed via ARM (control plane) — always works |
| Observability data | Logs, traces, metrics emitted by compute resources to Log Analytics, App Insights, Azure Monitor | Queried via data plane — works when public access is enabled (default) |
| Network-restricted services | Resources that deny public access entirely (private link only on LAW, private AKS clusters, firewall-enabled Key Vaults) | Not directly accessible — use the proxy pattern below |
The important distinction: your compute resources emit logs and metrics to Azure Monitor services. These observability services are separate from your VNET. They have their own network access settings. By default, they accept connections from both public and private networks.
Scenario 1: VNET resources with public observability (default)
This is the most common and recommended configuration. Your compute resources run inside VNETs for network isolation, but your observability services accept connections from public and private networks.
What works
Everything documented in Azure Observability works with VNET resources in this scenario:
- Resource discovery and topology mapping via Resource Graph
- Azure Monitor metrics (CPU, memory, request rates, availability)
- Activity Logs (configuration changes, deployments, administrative actions)
- Application Insights queries (exceptions, traces, dependencies, request performance)
- Log Analytics KQL queries (custom logs, performance counters, diagnostic logs)
- Resource management (restart apps, scale instances, read configuration)
- Az CLI commands (executed via session pool — reads resource state through ARM)
Verify your configuration
Check that your observability services allow public access:
Log Analytics workspace:
- Azure Portal → your Log Analytics workspace → Networking
- Verify "Accept connections from public and private networks" is selected (this is the default)
Application Insights:
- Azure Portal → your Application Insights resource → Network isolation
- Verify public access is not disabled
If you haven't modified the network settings on your Log Analytics workspace or Application Insights resource, the default configuration supports SRE Agent. No firewall rules, private endpoints, or VNET peering is required.
RBAC requirements
Same permissions as standard Azure observability — no VNET-specific roles needed:
| Scope | Role | What it enables |
|---|---|---|
| Subscription | Reader | Resource discovery, Resource Graph, Activity Logs |
| Subscription | Monitoring Contributor | Azure Monitor alert management |
| Application Insights | Monitoring Reader | KQL queries on traces, exceptions, dependencies |
| Log Analytics workspace | Log Analytics Reader | KQL queries on workspace data |
Scenario 2: Observability data behind private endpoints (AMPLS)
When your organization requires Log Analytics to deny public network access (publicNetworkAccessForQuery: Disabled via AMPLS), your agent cannot query that data directly — queries to api.loganalytics.io from outside the VNET are rejected.
The workaround is to deploy a VNet-integrated Azure Function as a secure query proxy. The Function queries your private workspace through the Private Endpoint, and your agent calls the Function endpoints as custom PythonTools or via an MCP connector.
→ Sample: Query Private Log Analytics with Azure Functions (AMPLS pattern) — deployable with azd up, includes Bicep infrastructure, Function code, SRE Agent custom agent YAML, and Easy Auth configuration.
→ Blog: How Azure SRE Agent Can Investigate Resources in a Private Network — full step-by-step walkthrough.
Before and after
| Before | After | |
|---|---|---|
| VNET confidence | "I don't know if the agent works with our VNETs" | Clear understanding: control plane works, data plane depends on network access |
| Private LAW | "My workspace is behind AMPLS — SRE Agent can't help" | Deploy a Function proxy — query private workspaces through private endpoints |
| Debugging failures | Generic errors with no network context | Know exactly which operations are control plane (work) vs data plane (check network settings) |
| Architecture decisions | Uncertain how to configure observability for agent compatibility | Two paths: keep public access (simplest) or deploy proxy pattern (private) |
Known limitations
These data plane operations are not yet supported through private endpoints. Control plane operations for these resources continue to work.
| Resource | Blocked operation | Control plane alternatives |
|---|---|---|
| Private AKS clusters | kubectl operations (pod status, logs, describe) | ARM-based cluster info and metrics |
| Firewall-enabled Key Vault | Certificate and secret retrieval | — |
| Internal-only Container Apps | Deep diagnostics (CPU profiling, memory dump) | ARM-based revision listing, metrics, restart |
| App Service with SCM restrictions | CPU profiling via Kudu | ARM-based health, metrics, Activity Logs |
| Private endpoint PostgreSQL | SQL query execution | ARM-based health, Activity Logs, metrics |
| Private endpoint Kusto (ADX) | KQL queries to cluster | ARM-based cluster health and metrics |
Get started
For the default scenario (public observability), no additional setup is needed. Follow the standard Azure Observability permissions guide.
For private workspaces behind AMPLS, deploy the query proxy:
| Resource | What you'll learn |
|---|---|
| Sample: Query Private Log Analytics with Azure Functions | Deploy a query proxy for AMPLS-protected workspaces |
| Blog: Investigate Resources in a Private Network | End-to-end walkthrough of private network access |
| Set Up Kusto Connector → | Connect to Azure Data Explorer for custom queries |
Related capabilities
| Capability | What it adds |
|---|---|
| Azure Observability → | Full reference of built-in Azure diagnostic tools |
| External Observability → | Datadog, Splunk, and custom systems via MCP connectors |
| MCP Connectors → | Connect any MCP server for additional capabilities |
| Root Cause Analysis → | Hypothesis-driven investigation across available evidence |