Ask any application owner to draw a diagram of their application's dependencies and they'll produce something reasonably accurate for the components they know about. Ask a network engineer to draw the same diagram and you'll get something different. Ask the flow data and you'll get the truth.
Application dependency mapping — understanding which systems communicate with which, and which communication is necessary for an application to function — is foundational to security and operations in any complex environment. It's also one of the most persistently difficult problems in enterprise IT, because the answer changes constantly and documentation never keeps pace.
Why Traditional Dependency Documentation Fails
Every organization has some version of application dependency documentation. Architecture diagrams in Confluence, CMDB records in ServiceNow, Visio drawings on shared drives. The problem isn't that these artifacts don't exist — it's that they diverge from reality almost from the moment they're created.
The gap grows faster in hybrid cloud environments. Cloud resources spin up and down dynamically. Microservices evolve independently. Application teams make configuration changes that create new dependencies without updating documentation. Infrastructure teams move workloads without notifying application owners. The result: documented dependencies are the intended architecture; actual dependencies are the operational architecture. These are rarely the same.
The consequences are significant:
- Security teams can't scope segmentation policies accurately because they don't know what needs to talk to what
- Incident response teams can't predict blast radius because they don't have an accurate dependency graph
- Platform teams miscalculate migration complexity because undocumented dependencies surface as breaking failures mid-migration
- Compliance audits require scrambling because evidence of isolation can't be produced on demand
Flow-Based Dependency Discovery
Network flow data is the most reliable source of actual dependency information because it records what's happening, not what was intended. Every TCP connection, every UDP exchange, every application-layer conversation leaves a record in the flow telemetry — and that record is authoritative.
The process for building a flow-based dependency map:
-
Collect flow data from all relevant infrastructure. This means on-premises routers and switches, cloud VPC/VNet flow logs, and any perimeter devices.
-
Identify application hosts. Associate IP addresses with application roles — this can be done via CMDB integration, asset inventory, or manual tagging.
-
Aggregate flow data by application pair. Rather than looking at individual connections, aggregate by source application, destination application, protocol, and port.
-
Filter by frequency and volume thresholds. A single connection between two systems might be noise; persistent, high-frequency connections are genuine dependencies.
-
Build the graph. Visualize the resulting dependency relationships as a directed graph, with edge weights reflecting traffic volume or connection frequency.
The output is a dependency map derived entirely from observed behavior — representing the real operational architecture of the application, not the documented one.
Hybrid Cloud Specifics
Hybrid cloud environments add complexity because the dependency map spans multiple administrative domains with different flow telemetry sources.
On-premises to cloud. Traffic crossing the on-prem/cloud boundary appears in both the on-premises edge device flow data and the cloud gateway logs. Correlating these records correctly requires consistent timestamp handling and IP address normalization (particularly for NATted traffic).
Cloud to cloud. In multi-cloud or multi-VNet architectures, inter-cloud traffic may traverse peering connections, VPN gateways, or ExpressRoute/Direct Connect circuits. Each of these generates its own flow telemetry that needs to be included in the dependency analysis.
Container and serverless workloads. Container orchestration platforms (Kubernetes) and serverless environments may not export traditional flow records. Many Kubernetes CNI plugins support flow telemetry; cloud-native telemetry (AWS VPC Flow Logs, Azure NSG Flow Logs) captures traffic at the VNet boundary even for containerized workloads.
NAT and IP reuse. Cloud environments frequently reuse IP addresses as workloads scale and cycle. Dependency mapping needs to account for this — associating flows with the workload identity (instance ID, pod name) rather than the ephemeral IP address.
Using Dependency Maps for Security
Once you have an accurate dependency map, several security use cases become dramatically more tractable.
Segmentation policy design. The dependency map tells you exactly which communication paths must be permitted. Anything not on the map should be denied. This eliminates the guesswork that leads to overly permissive segmentation policies.
Blast radius estimation. When a system is compromised, the dependency graph tells you which downstream systems were reachable from it. This is the information incident response needs to scope the investigation and notify affected teams.
Change impact analysis. Before making a network change (firewall rule modification, VLAN restructuring, security group change), the dependency map lets you predict which application flows will be affected — without manual documentation review.
Anomaly detection. After a baseline dependency map is established, new connections that appear outside the known dependency graph become immediately suspicious. An application server opening a connection to a database it doesn't normally talk to is a meaningful signal.
Keeping the Map Current
A dependency map is a point-in-time artifact the moment it's generated. The value comes from keeping it current. Flow-based maps can be updated continuously — as new flow patterns emerge, the dependency graph updates to reflect them. When a connection disappears (perhaps because an old integration was decommissioned), the graph reflects that as well.
FlowSight continuously builds and maintains application dependency maps from collected flow data, with automatic topology discovery that surfaces new relationships as they appear. In hybrid environments, it normalizes telemetry from on-premises infrastructure and cloud flow logs into a unified dependency view — giving operations and security teams an accurate, current picture of what's actually communicating in their environment.