Application Dependency Mapping in Azure

Most Azure architecture diagrams are wrong. Not because the author was careless, but because they were drawn once, at a point in time, and systems change faster than diagrams are updated. A microservices application deployed a year ago has service relationships nobody documented, because they were added incrementally by different teams and the central view was never updated.

Application dependency maps built from live traffic tell you what is actually happening in production. They are used for three things: incident investigation (what does this service depend on, and which of those dependencies could cause this symptom), migration planning (what do I need to move together with this workload), and cost analysis (who generates cross-region or cross-zone traffic).

This guide covers the Azure tools that build dependency maps from real telemetry.

Application Insights Application Map

Application Insights Application Map is the simplest starting point for application-layer dependency mapping. If your services are instrumented with the Application Insights SDK, the map is automatically built from distributed trace data.

Each node on the map represents a component: a service, a database, an external API call, or an Azure service your application calls. Edges represent calls between components, annotated with call rate, failure rate, and average response time. Clicking a node opens the detailed performance and failure metrics for that component. Clicking an edge shows the calls between the two components with distribution of response times and failures.

The map updates in near real-time as traces arrive. For a service experiencing an incident, the map immediately shows which upstream callers are affected and which downstream dependencies are the likely cause.

For the map to be complete, every service in the call chain needs to be instrumented with Application Insights. A service that is not instrumented appears as an external dependency node with limited detail: you can see that calls are going to it, but not what is happening inside it. In heterogeneous environments (some services instrumented, some not), the map is partial, which is better than nothing but needs to be understood as incomplete.

To enable Application Map in Application Insights: 1. Instrument your services with the Application Insights SDK and configure distributed tracing (this uses the W3C Trace Context standard by default) 2. Navigate to your Application Insights resource > Investigate > Application Map 3. Set the time range to the period you want to analyse

For multi-instance services where many nodes represent the same logical service, use the cloud_RoleName telemetry property to group instances. This collapses multiple pod or instance traces into a single logical node on the map.

Azure Monitor Service Map (VM Insights)

Service Map is part of VM Insights and builds dependency maps for virtual machines by analysing actual network connections. Unlike Application Insights, it does not require application instrumentation: it operates at the OS/network layer using the Log Analytics Agent (or Azure Monitor Agent).

The map shows each monitored VM as a node, with edges representing active network connections between VMs and to external endpoints. For each VM node, you can see: - Inbound processes (what is listening and accepting connections) - Outbound connections (what the VM is connecting to) - Dependencies on Azure services (SQL, Storage, etc.) - Connections to external endpoints

This is particularly valuable for VMs running applications that are not instrumented at the application layer, or for infrastructure components (message queues, databases, caches) that appear as targets of application connections but are not themselves application-instrumented.

To enable VM Insights and Service Map: 1. Navigate to Azure Monitor > Insights > Virtual Machines > Enable 2. Select the VMs to monitor and configure the Log Analytics workspace 3. The Dependency Agent is installed alongside the Log Analytics Agent to capture network connection data 4. Service Map is accessible via VM Insights > Map tab

Service Map data retains for 30 days in Log Analytics. For historical dependency analysis, query the VMConnection table in Log Analytics.

Azure Migrate dependency analysis

For workloads being assessed for cloud migration, dependency mapping serves a different purpose: understanding which VMs and servers must be migrated together because they communicate with each other.

Azure Migrate provides two methods:

Agent-based dependency analysis uses the Service Map agents (Log Analytics Agent and Dependency Agent) installed on on-premise servers. It produces detailed per-process dependency data, showing which processes on which servers communicate with which other servers and on which ports.

Agentless dependency analysis uses VMware snapshot data without agent installation. It captures connection data from vCenter/ESX hosts and maps VM-to-VM and VM-to-external connections. Less detailed than agent-based analysis (no per-process breakdown) but available without agent deployment.

In both cases, the output in Azure Migrate shows discovered dependencies between servers, allowing you to group servers into migration waves based on their communication patterns. Servers that communicate frequently should be in the same migration wave to avoid breaking dependencies during migration.

For regulated businesses, dependency analysis also surfaces compliance-relevant connections: a workload that communicates with a third-party external endpoint is a relevant discovery for data flow mapping under UK GDPR.

Building a live dependency map with Datadog

For organisations running Datadog, the Service Map feature within Datadog provides a real-time dependency map built from distributed traces, with richer detail than Application Insights for polyglot environments and more customisation than Service Map.

Datadog's map: - Visualises services discovered from traces, independent of what language or framework they use - Annotates edges with real-time request rate, error rate, and p99 latency - Integrates with Azure infrastructure metrics on the same node (combine the service's call rate with the pod's CPU usage) - Shows dependency paths that cross cloud boundaries (Azure to AWS, Azure to on-premise)

For environments already using Datadog for observability, the service map is the natural destination for dependency mapping rather than building a separate capability in Azure Monitor.

Using dependency maps operationally

A dependency map that is only viewed during migrations or architecture reviews is an underused asset. Integrate it into incident response:

When an alert fires on a service, open the dependency map for that service immediately. Look at its downstream dependencies: are any showing elevated error rates or latency? If a downstream database is responding slowly, the upstream service's degradation follows. Check the upstream callers: are other callers experiencing the same pattern? If the dependency is failing, all callers should be affected similarly.

Dependency maps also improve runbooks. A runbook that says "restart this service" is better when it also says "this service is depended on by these three other services, which will see increased error rates during the restart window."

Where Critical Cloud comes in

Dependency maps built from live telemetry, integrated with incident response tooling, are the difference between knowing your architecture and knowing how your architecture actually behaves in production. We operate observability for technology-led businesses as the world's first Powered by Datadog accredited partner, with service maps, distributed tracing, and infrastructure monitoring built into a single correlated view. If your incident response starts with "what does this service depend on," see how Critical Support works.