A vendor says "negligible overhead." You deploy. Two weeks later the infra team is staring at a node whose p99 climbed, a build that runs slower, an order path that picked up jitter it did not have before. The word was marketing. The cost showed up in the graphs.
So when a data movement monitoring vendor says negligible, answer with two questions. What is the number? And where do you sit relative to my traffic? The first answer can be faked. The second one cannot, because it decides the first.
Here is the number for a collector that watches data movement at the kernel: roughly 0.1% of one core and 4 to 8 MB of memory per host. The footprint is small for a reason that has nothing to do with clever optimization and everything to do with where the collector stands.
Overhead is a position, not a quality
Monitoring does not cost anything by itself. Standing in the way costs.
Put a control inline, between your data and where it is going, and every packet, every request, every file write has to pass through it and wait for a verdict before it moves on. The wait is the overhead. The wait is also the whole point of an inline control: it earns its latency by being able to stop the move. That cost is not bad engineering. It is what inline means.
Which is why latency-sensitive teams throw most security tooling out before it ships. A trading firm does not bolt a control onto the order path. A platform team does not wedge an agent between its services and its database. Security does not get to overrule that, and should not try. So stop asking how to make the inline tool cheaper. Ask whether you have to be inline at all.
Off the path is a different cost class
A collector that watches a move instead of standing in it lives in another cost class.
It reads the metadata of the move as it happens. Which process. Which user. Where it went, how much, when. It never holds the move while it thinks. The data does not wait on the collector because the collector is not in front of it. Picture a camera on a loading dock: it records what leaves and never stops a truck.
That is where 0.1% of a core comes from. Bounded, read-only work on a stream of metadata events, off to the side, gating nothing. No verdict for traffic to block on means no wait to measure. The footprint stays small because the architecture refuses the expensive job. The collector does not block, drop, or alter traffic, so it never pays for blocking, dropping, or altering traffic.
The 4 to 8 MB is the resident memory that collector holds on the host. Small enough that it does not fight the workloads you care about, flat enough that it does not balloon under load. It runs single-tenant inside your own cloud, so the events stay in your account and never route through a vendor's SaaS.
Reading content is the cost you avoid
Parse a payload, scan a file, inspect the body of every request, and you pay real CPU. Worse, that cost scales with your data volume, which is the one thing you do not want it tied to.
The collector is metadata-only by default. To see that a pattern is wrong it does not crack open the move. It needs to know that this user, on this job, is touching high-value paths in a short window and pushing an unusual volume to a destination that does not fit the work. Those are facts about the move, not its contents. None of them require reading what is inside.
Here the privacy story and the performance story collapse into one fact. The collector does not have to read your data, so it does not pay to read your data, and you do not carry the risk of a tool that does. Content inspection is there when a move earns it. You reach for it on purpose. It is not a tax the whole deployment pays by default.
You can measure this yourself
Defensible overhead has one property marketing overhead never does. You can reproduce it, and the vendor wants you to try.
Put the collector on a representative host. Watch CPU and RSS under your real load, not a demo. Then run the control test that actually settles it: the same workload with the collector and without it, side by side, and look at your p99. For an off-the-path collector the p99 does not move in any way you can tell from noise, because the collector was never in the path to move it.
That test is the whole argument. An inline tool bends the latency curve of the thing it sits in front of, and a careful run will catch it. An off-the-path collector nudges the host's resource use by a small, bounded amount and leaves the traffic's own timing alone. "Roughly 0.1% of one core and 4 to 8 MB per host" is not a claim you are asked to trust. It is a measurement you are invited to repeat.
What "negligible" has to mean before you believe it
Negligible is not a feeling. It is a claim with three parts, and you can hold a vendor to each one.
A bounded resource cost. A real CPU and memory number per host, given as a range, that holds under your load instead of the demo. Roughly 0.1% of a core and 4 to 8 MB is the answer here. A vendor who will not name a number is naming a hope.
No latency tax on the workload. The collector sits off the path, so the data never waits on it. The thing that makes overhead hurt, a verdict your traffic blocks on, does not exist in this design. When a pattern turns dangerous the response is host-level network isolation, quarantine from the control plane, not a filter your packets thread through.
A cost that does not track your data volume. Metadata-only means the footprint follows the rate of moves, not the size of payloads. Your data can grow without dragging the monitoring cost up with it, because the collector was never reading the volume to begin with.
Meet all three and you can run the collector everywhere, including the latency-sensitive hosts that have lived with partial coverage because every control on offer was too heavy to put there. Those hosts are the payoff. You stop trading a slow node for a blind one.
The danger was never one move. Every move is permitted. The pattern across moves is the breach. A monitor too expensive to run on the path is a monitor you switch off exactly where it matters, and a pattern you cannot see everywhere is a pattern you cannot see at all. A collector that costs almost nothing, off the path, is one you leave on.
If you want real numbers behind that, the fastest path is a short engineer-to-engineer call. Thirty minutes: your architecture, our footprint, and how to measure it on your own hosts.