On a cloud bill, why can a single gigabyte of outbound traffic appear as more than one metered charge?
answer
- meters attach to paths, not to payloads
- each boundary bills separately
- a component in the path meters too
- a crossing can be counted on both sides
- gateway processing stacks with egress
basics
~20 sBecause meters attach to boundaries and to components, not to bytes. One gigabyte can be charged for crossing a zone boundary, again for being processed by a gateway in its path, and again at the internet boundary on the way out.
solid answer
~50 sA transfer charge is not "one price per gigabyte delivered". Each **metered boundary** the bytes cross bills separately, and each **component in the path that meters what it processes** bills separately again. So a gigabyte that starts in one zone, crosses to a shared exit component in another, is processed by a managed gateway there, and then leaves toward an internet client can produce three or four lines for the same payload. On platforms that count cross-zone traffic in both directions, the crossing itself contributes two. None of these replaces another: the gateway's per-gigabyte processing charge sits on top of the boundary rate rather than in place of it. The practical consequence is that the total effective rate for a flow depends on its path, and two designs delivering identical bytes to identical users can bill very differently.
code
json · 12 lines{
"billingPeriod": "one month",
"assumption": "this platform meters cross-zone traffic in both directions",
"flow": "workload in zone A -> shared exit in zone B -> internet client",
"transferLines": [
{ "boundary": "zone-to-zone", "direction": "out of zone A", "gigabytes": 900, "chargeBasis": "perGiBTransferred", "rateTier": "cross-zone" },
{ "boundary": "zone-to-zone", "direction": "into zone B", "gigabytes": 900, "chargeBasis": "perGiBTransferred", "rateTier": "cross-zone" },
{ "boundary": "managed-gateway", "direction": "outbound", "gigabytes": 900, "chargeBasis": "perGiBProcessed", "rateTier": "gateway-processing" },
{ "boundary": "internet", "direction": "out to clients", "gigabytes": 900, "chargeBasis": "perGiBTransferred", "rateTier": "internet-egress" }
],
"note": "the same 900 GiB is metered on four lines; each rateTier differs and none replaces another"
}go deeper
Remember that a transfer bill has several lines and that the same bytes can appear on more than one, because each boundary and each component in the path meters separately.
Explain the three stacking mechanisms — multiple boundaries crossed, a component metering what it processes, and a crossing counted on both sides — and say that these add rather than replace one another.
Show the method: take one representative flow, walk it from workload to client, name every boundary and metering component, and reconcile that list against the bill. An unexplained line means a crossing the diagram does not show.
Recognise that concentrating outbound traffic through one controlled exit trades a per-gigabyte charge for visibility and control, and decide that trade deliberately for the estate rather than letting each team rediscover it on its own bill.
## One flow, several meters The intuition that trips people up is that the bill charges for *delivery*: so many gigabytes to users, times a rate. It does not. Meters attach to two things: - **boundaries** — a zone edge, a region edge, the internet edge; and - **components in the path** that meter what passes through them, typically per gigabyte processed. A gigabyte can therefore be counted several times on its way out, once per meter it passes, and the lines are additive rather than alternative. ## The three ways the same bytes get counted twice 1. **A path that crosses more than one boundary.** A workload in one zone sends to a shared exit component in another, so those bytes cross a zone boundary *and* the internet boundary. Two different schedules, two lines, same payload. 2. **A component that meters what it processes.** A managed gateway that outbound traffic is forced through commonly charges per gigabyte handled, on top of whatever boundary rate applies. It does not absorb the egress charge; it adds to it. (What that gateway routes or translates, and how the path was chosen, is a separate subject — the billing point is simply that a meter sits on the component.) 3. **A crossing counted on both sides.** On platforms that price cross-zone traffic in both directions, the same bytes are metered leaving the sending zone and again entering the receiving one, so the effective rate for that hop is double the headline number for the crossing. ## Reading a decomposed transfer bill | line | what it meters | replaces another line? | |---|---|---| | zone-to-zone, outbound from zone A | bytes leaving the sending zone | no | | zone-to-zone, inbound to zone B | the same bytes arriving, where the platform counts both sides | no | | gateway processing | bytes handled by the component in the path | no | | internet egress | bytes crossing the public boundary | no | The useful habit is to read a transfer bill as a **path**, not a total. Take one representative flow, walk it from the workload to the client, and name every boundary and component it meets. Each of those is a candidate line. When the sum of your named lines does not match the bill, you have found a crossing your diagram does not show — which is usually the whole investigation. ## Why this changes design, not just accounting - **Effective rate is a property of the path.** Two services delivering the same bytes to the same users can differ by a multiple, purely on how many meters sit between the workload and the exit. - **Shared exit components concentrate the charge.** Forcing all outbound traffic through one place is often the right control decision, and it converts a diffuse cost into a single large, visible, per-gigabyte line. That visibility is a benefit; the extra charge is the price of it. - **A high-volume flow deserves its own path review.** Bulk flows that dominate the bill are worth walking end to end; low-volume flows are not, and chasing every line is how cost work becomes busywork. - **Removing one meter does not remove the others.** Taking a component out of the path of a flow removes its processing line and leaves every boundary rate exactly where it was. ## Where providers differ Whether cross-zone traffic is priced at all, whether it is counted once or on both sides, whether traffic to the provider's own managed services over an internal path is metered, and whether a gateway-style component charges per gigabyte processed are all platform-specific. Because of that, the *number* of lines a given flow produces is not portable knowledge; the *method* is. Walk the path, list the boundaries and the metering components, and look each one up for the platform you are actually on. An engineer who assumes the shape of the bill from a previous employer's platform will mis-estimate a design by a multiple, in either direction. ## The takeaway "How much does a gigabyte out cost?" has no single answer, because the question is under-specified. The answerable version is: *which boundaries does this gigabyte cross, and what meters what it passes through on the way?* Every line on the bill is one answer to that question, and the total is their sum.
- If all four lines meter the same 900 GiB, which one usually dominates?The internet egress line, because it carries the highest per-gigabyte rate of the four. The internal lines matter when internal volume is far larger than what is delivered outward, which is common in pipelines that shuttle intermediates. Work out which case you are in from bytes per line rather than assuming the external one is biggest.
- Does routing a flow around the shared exit component always save money?It removes that component's per-gigabyte processing line and nothing else; every boundary rate stays. It may also remove the inspection, filtering or address control that forcing traffic through one exit was there to provide, so it is a security and operations decision with a cost benefit attached, not a pure saving.
saying these in an interview costs you the question
- Assumes one gigabyte out can only ever produce one charge
- Reads a repeated volume on several lines as a billing error
- Thinks a gateway's processing charge replaces the egress charge
- Quotes an effective per-gigabyte rate without naming the path
- Believes every platform counts a cross-zone hop the same way