Skip to content

Understanding Agent Deployment Topology

An Agent can be deployed in one of two ways relative to the business applications it serves: co-located with them, in the same runtime context, or in a decentralized runtime context of its own. This choice is made per-agent, on the Agent Deployment Topology field of the Security Internal tab, and it determines how the interceptors embedded in your applications actually reach the Agent to deliver their captured telemetry.

Co-located Deployment

The Agent runs in the same cluster as the business applications it instruments. The interceptors capture traffic from the different applications, consolidate and filter it, and then upload the consolidated batch of metrics to the Agent that corresponds to the environment. They reach it through the Agent's in-cluster Kubernetes Service (ClusterIP), with no other component in between: no ingress, no load balancer, no extra hop.

Co-located topology — applications, interceptors and agents in the same cluster, communicating through a Kubernetes Service

Because applications, interceptors, and Agents all live inside the same cluster, this traffic never leaves the cluster's own network boundary. Securing the internal traffic is therefore not necessary in this topology: there is no TLS to configure for this hop, and no certificate to manage. The Agent still delivers the curated metrics to the BizMetry platform over the network, as in any topology.

Requires a Kubernetes runtime

Co-located deployment assumes your applications run on Kubernetes, in the same cluster the Agent is deployed to. If your applications are standalone processes — not deployed on Kubernetes — co-located deployment isn't an option, and you'll need Decentralized Deployment instead.

Choose co-located deployment when:

  • Your application runs on Kubernetes.
  • There's no reason to keep the Agent and your business applications apart — both can comfortably share the same runtime.
  • You want to keep the deployment as simple as possible — no ingress hostname, DNS entry, or certificate to manage for this hop.
  • You want to maximize network performance: lower round-trip latency between your interceptors and the Agent, and higher effective throughput between them.

Decentralized Deployment

The interceptors stay close to the applications, inside the application cluster, while the Agents are deployed in a separate telemetry cluster. The interceptors reach the Agents through a dedicated ingress load balancer.

Decentralized topology — interceptors in the application cluster reaching agents in a separate telemetry cluster through an internal ingress load balancer

Separating the Agent this way can be a deliberate choice to reduce blast radius: if the cluster running your business applications goes down, the Agent — running independently elsewhere — keeps operating unaffected.

Because the traffic sent to the Agent crosses different security contexts and may contain sensitive information, it is encrypted in flight: all communication between the interceptors and the Agent goes exclusively through a TLS-secured, certificate-protected load balancer. There is no direct, same-network shortcut available, since the two sides genuinely don't share a network boundary.

Choose decentralized deployment when:

  • You want the Agent and your applications to remain genuinely independent — if one cluster fails, the other stays up.
  • Your applications are standalone processes that don't run on Kubernetes at all.
  • Your organization's operational security posture requires business applications to stay isolated from other infrastructure, whether for general security hygiene or to protect sensitive data.
  • Network latency between interceptor and Agent isn't a concern for your workload.

At a Glance

Co-located Decentralized
Runtime relationship Same cluster/runtime as your applications A separate cluster/runtime from your applications
Path from interceptor to Agent Direct, via the Agent's in-cluster Kubernetes Service — no network hop Through a TLS-secured Ingress load balancer
Traffic encryption for this hop Not needed — traffic never leaves the cluster network Required — TLS certificate managed on the Agent Internal Gateway
Setup effort Minimal — no ingress type, hostname, DNS, or certificate to configure Requires an ingress type, an internal hostname registered in DNS, plus a generated key pair
Network latency Lowest possible Higher — crosses cluster/network boundaries
Blast radius if one side fails Shared — an outage affecting the cluster affects both Isolated — one side can fail independently of the other
Requires Kubernetes Yes, for both the Agent and the applications No — works with standalone (non-Kubernetes) applications too

Where This Is Configured

The choice between co-located and decentralized lives on the Agent Deployment Topology field of the Security Internal tab. Selecting Co-Located Topology: Same cluster as my applications configures co-located deployment; selecting Decentralized Topology: Different cluster than my applications configures decentralized deployment and reveals the additional fields — Ingress Type, internal gateway address, key pair, and certificate chain — that deployment needs. The ingress controller selection is only relevant here: a co-located agent is reached directly inside the cluster, so it is never asked for.

Agent Deployment Topology selector on the Security Internal tab

The Agent Details dialog reflects whichever choice is active for a deployed agent, as a Co-located / Decentralized pill next to its Internal Gateway.