Why eBPF for cost
Compute cost needs no eBPF. metrics-server already reports per-pod CPU and memory, and the Kubernetes API already says what each pod requested. That is enough to build the whole cost model.
Network is different, and the reason is worth being precise about.
The attribution gap
Two systems each hold half the answer:
- AWS knows exactly how many bytes crossed an AZ boundary and bills you for them. It has no idea which pod sent them.
- Kubernetes knows every pod, namespace and owner. It does not count bytes at all — bandwidth is not a schedulable resource and no controller tracks it.
Nothing in either system joins the two. That join is the whole problem.
Why the obvious alternatives do not close it
| Approach | What breaks |
|---|---|
| VPC Flow Logs | per-ENI, no pod identity. On shared-ENI CNIs many pods sit behind one ENI, so attribution is impossible. High-volume logging also costs real money. |
| Service mesh telemetry | only covers mesh-managed traffic. Misses DNS, node-level traffic, anything outside the mesh, and requires a sidecar per pod. |
/proc/net/dev per container | totals per interface with no peer address, so you cannot tell same-AZ from cross-AZ — which is the entire cost question. |
conntrack polling | samples, so short-lived connections vanish between polls. No byte accounting per flow. |
tcpdump / raw sockets | copies every packet to userspace. Accurate and unaffordable at production volume. |
| Application instrumentation | requires every team to instrument consistently, in the same units, forever. |
What eBPF gives that none of them do
A TC program sees each packet with its skb metadata, which includes the interface index. In Kubernetes, a pod's traffic crosses that pod's veth interface — so ifindex is a direct key to pod identity.
That single fact produces:
- Per-pod byte accounting, both directions, without touching the application
- Peer addresses, so a flow's destination can be classified by zone and priced
- Complete capture, not sampled — short-lived connections are counted
- Kernel-side aggregation, so cost scales with flows rather than packets
- No application changes, no sidecar, no code
Aggregation happens in the kernel or immediately on read, so userspace never sees raw packets. That is the difference between "affordable at production volume" and tcpdump.
What it costs you
Honest accounting of the tradeoff:
| Cost | Detail |
|---|---|
| Privileges | a DaemonSet with BPF, PERFMON, NET_ADMIN capabilities on every node |
| Kernel floor | 6.6+ for TCX attachment |
| Platform | Linux only |
| Overhead | a small per-packet cost in the kernel; see the eBPF agent for its resource requests |
| Coverage | IPv4 TCP/UDP only today; IPv6, ICMP, SCTP and QinQ are unaccounted |
This is why the eBPF agent is a separate, optional DaemonSet rather than part of the free agent. Everything except network works without it, and bundling would force every user to accept the privileged footprint to get CPU and memory numbers.
Current state, stated plainly
The agent measures and attributes bytes per pod, flows are classified by the zone at each end, and two buckets are priced against the rate table: cross-AZ (intra-region) transfer at a flat per-GB rate, and internet egress on tiered rates, egress direction only. Same-AZ is free. Those dollars are folded into the cluster's daily cost.
What that figure is not
Cluster-level and daily. Network dollars are not attributed per workload; per workload the output is bytes split by zone.
A floor, not a total. Bytes whose peer has no resolvable zone are not priced — the classifier refuses to assume same-AZ for an unknown end — and NAT gateway and inter-region transfer are not produced at all. coverage.networkUnclassifiedBytes says how much was left out. See What we measure.
Next
- The eBPF agent — hooks, maps, enrichment, deployment
- AWS network costs — the charges and how to reduce them