FinOps Chargeback for Cross-Zone Kubernetes Costs with Linkerd

Oct 2026

TL;DR

AWS Split Cost Allocation Data assigns EC2 compute costs to EKS pods using CPU and memory. It doesn’t assign cross-zone data transfer charges to workloads.
Linkerd’s byte counters and workload identity provide the missing traffic signal. You can join them with Kubernetes node zone labels to identify cross-zone flows. HAZL adds zone-aware routing in Buoyant Enterprise for Linkerd.
To build a per-team chargeback report, join cross-zone bytes with ownership labels and AWS transfer rates.
Linkerd supplies traffic attribution alongside Kubecost or CloudZero, which can handle dollar rollups and reporting.

Why cloud billing can’t tell you which service caused a cross-zone charge

AWS Split Cost Allocation Data for EKS gives you pod-level attribution for EC2 compute costs. AWS compares each pod’s CPU and memory requests with the instance’s capacity, then assigns the pod a share of the instance cost. You can use fields such as namespace and workload name to charge that compute cost to an owner.

Cross-zone data transfer uses a different meter. AWS charges for bytes crossing an Availability Zone boundary, but a pod’s share of an instance’s CPU or memory tells you nothing about which pod sent those bytes. The compute allocation ratio can’t assign a network charge to the service that caused it.

A Cost and Usage Report can show the data-transfer charge without identifying the Kubernetes Service behind the traffic. AWS meters network use at infrastructure resources such as instance network interfaces. Service identity lives inside the cluster, beyond what those billing records capture. More billing tags on the same records can’t reconstruct the service-to-service traffic that produced the charge.

The telemetry a chargeback model actually needs

A cross-zone chargeback record needs 4 data points. You need the source zone, destination zone, bytes transferred, and the service responsible for the traffic. Linkerd’s proxies emit tcp_write_bytes_total and tcp_read_bytes_total, while workload labels identify the meshed service. You can use those counters without standing up a separate traffic-observability layer.

Zone attribution takes an extra join. Map each pod to its node, then read the node’s topology.kubernetes.io/zone label for both ends of a flow. Keep destination information at pod or endpoint level until you’ve assigned zones. A service name alone won’t tell you which zone received the bytes when its pods run across several zones.

Count each flow once when you build the chargeback record. Adding the sender’s write counter to the receiver’s read counter would count the same transfer twice. If your collected metrics can’t identify a destination endpoint, leave those bytes unattributed rather than guess a zone. HAZL can change where traffic goes by favoring local endpoints, but the chargeback model still needs measured bytes and the zone join.

Validating the approach: the ecosystem already reaches for mesh metrics

CloudBolt’s Kubernetes cost allocation guide recommends using Istio cross-zone traffic metrics to split AZ-to-AZ egress costs by namespace. The guide treats mesh traffic as an allocation key because cloud bills don’t identify the pods behind those charges.

Linkerd gives you workload traffic metrics for the same approach. HAZL adds native zone-aware routing, so you don’t have to bolt on separate routing logic to keep eligible traffic local. You still need to join Linkerd’s metrics with Kubernetes zone and ownership labels before you can assign costs to a team.

Building a per-team chargeback report, step by step

Pull Linkerd’s tcp_write_bytes_total or tcp_read_bytes_total counters for meshed workloads. Calculate each counter’s increase over the reporting period, and count each transfer once. Adding the sender’s write bytes to the receiver’s read bytes would roughly double the same traffic.
Match each transfer to the actual source and destination pods, then join each pod to its node’s topology.kubernetes.io/zone label. Equal zones mean in-zone traffic. Different zones mean cross-zone traffic. Check the labels in your exported metrics before building the join. A destination service name alone can’t tell you which pod received the bytes, so you’ll need endpoint-level data if that’s all the counter provides.
Assign the cross-zone bytes to an owner using the pod’s namespace, team label, and application label. Pick a chargeback rule before you aggregate. For example, you can charge the calling team for bytes its pods send across zones, then group those bytes by team and application. Preserve pod ownership and node-zone records for the reporting period so a pod that moved or disappeared doesn’t lose its attribution.
Apply the AWS rate that matches the billed transfer. At an illustrative $0.02 per GB round-trip rate, 500 GB of counted one-way cross-zone traffic produces a $10 team line item. Check the applicable AWS pricing and invoice entries before treating that figure as an actual charge.

Architecture diagram

Linkerd proxy → metrics endpoint → pod and node-zone join → ownership label join → AWS pricing join → per-team chargeback report

The report can then show each team’s cross-zone GB, rate, and allocated dollars for the same billing period. Keep transfers that lack a confirmed destination zone in an unallocated line item rather than assigning them to a team by guesswork.

Where Linkerd ends and your FinOps platform begins

Linkerd supplies traffic measurements for meshed workloads. To turn those measurements into a chargeback figure, you need to join them with pod zones and ownership labels, apply AWS pricing, and reconcile the allocation with the billed total. Traffic outside the mesh needs its own allocation rule because Linkerd can’t measure it.

Keep Kubecost or CloudZero in your existing cost-reporting workflow. If your platform accepts external cost allocations, you can pass it the per-team figures for rollups, budgets, and alerts. Check its import options before building that connection. Otherwise, publish the cross-zone line item alongside your existing reports.

Comparing the three approaches to cross-zone attribution

The approaches start with different evidence. Linkerd and Cilium observe traffic inside Kubernetes, while FinOps platforms organize costs. For cross-zone chargeback, you need to connect traffic volume and workload ownership to the applicable cloud price.

Approach	Native signal	Zone-aware?	What you still need for chargeback	Best for
Mesh-native metrics (Linkerd)	Workload identity, service metrics, and TCP byte counters for meshed traffic.	HAZL in Buoyant Enterprise for Linkerd routes with zone awareness. To classify measured bytes, join each pod to its node’s zone.	Join source and destination workloads to ownership labels and zones, then apply AWS pricing. Check that your exported byte counters have the labels needed to pair the workloads.	Best for clusters already running Linkerd that want to attribute meshed service traffic.
eBPF network visibility (Cilium)	Hubble exposes network flows and endpoint identities, including traffic outside a service mesh.	Zone classification requires a join to node topology data.	Collect byte volumes at the needed granularity, then join flows to zones, owners, and pricing.	Best for clusters using Cilium that need network-level visibility beyond meshed services.
FinOps platforms (Kubecost or CloudZero)	Cloud spending and cost allocation data for reporting.	Billing data can identify transfer charges, but it doesn’t identify both services in a cross-zone exchange.	Supply traffic attribution and ownership data, then use the platform for dollar rollups.	Best for reporting charges across your cloud estate.

Getting started

Accurate chargeback starts with identifying which workloads exchanged bytes across zones. Your AWS bill records the charge, and Linkerd’s traffic counters give you workload-level byte counts that you can join with Kubernetes zone and owner labels.

Deploy Linkerd on the workloads behind your cross-zone traffic, then verify those joins before assigning charges to a team. If you’re already paying substantial AWS cross-zone bills, evaluate HAZL in Buoyant Enterprise for Linkerd to favor zone-local traffic while retaining cross-zone failover.

FAQs

Can AWS billing tags attribute cross-zone costs to a Kubernetes service?

AWS bills for cross-zone transfer, but its billing data doesn’t identify the service that sent the bytes. Split Cost Allocation Data for EKS assigns EC2 compute costs to pods using CPU, memory, and accelerator requests usage. It doesn’t assign data transfer costs to pods.

Do I need Linkerd if I already use Kubecost or CloudZero?

You need a source of workload-level traffic measurements to allocate cross-zone costs. Linkerd can supply byte counts and service identity for meshed traffic, which you can join to pod and node labels. If you already collect that information elsewhere, you may not need Linkerd for chargeback.

What does HAZL add to plain Linkerd metrics?

Linkerd records traffic metrics, including TCP byte counts. You can join workload identities to node zone labels to estimate cross-zone traffic. HAZL, available in Buoyant Enterprise for Linkerd, routes traffic to local zones when possible and expands to other zones when needed. HAZL controls routing. It doesn’t produce a chargeback report.

What’s the difference between showback and chargeback?

Showback reports an estimated cross-zone cost to the team responsible for the traffic. Chargeback assigns that cost to the team’s budget. You can build either report with the same traffic and ownership data, but chargeback also requires an agreed rule for pricing and assigning shared traffic.