On a cloud transfer bill, which boundary crossings are metered, and why is the one inside a single region so easily missed?

## Two questions, not one A transfer charge is the product of two facts about the bytes: **which direction** they moved, and **which boundary** they crossed. Direction decides whether a meter runs at all — arriving traffic is normally unmetered, leaving traffic is priced. The boundary decides the **rate**, and it is where most of the surprise lives, because boundaries are invisible in the places engineers usually look: a service name, a deployment manifest, a dashboard. ## The boundaries, from nearest to farthest | crossing | typically metered | relative per-gigabyte rate | what puts traffic here | |---|---|---|---| | inside one zone, within your own private address range | normally not | none | co-located workloads talking to each other | | between availability zones of one region | on platforms that price that crossing | low, but not zero | spreading tiers across zones for resilience | | between regions of the same provider | yes | higher than cross-zone | replication, a second serving region, disaster recovery copies | | out to the public internet | yes | the headline rate, the highest of the four | anything a client, a viewer or a third party downloads | | through a managed gateway in the path | yes, per gigabyte **processed** | an additional charge, not a replacement | outbound paths forced through a shared exit component | The ordering is the thing to remember: **cost rises with distance from the workload**, and the gateway line sits on top of whichever boundary the same bytes also crossed rather than instead of it. How that gateway routes traffic, and what a route table decides about which path the bytes take, is a separate subject — here the point is only that a component in the path can carry a per-gigabyte meter of its own. ## Why the in-region crossing hides - **The design does not look distributed.** One region, one environment, one service: everything reads local, and a zone boundary has no name in the code. - **Resilience advice pushes you across it.** "Spread across at least two zones" is correct availability guidance, and it is also the instruction that puts a priced boundary in the middle of every inter-tier call. - **The rate is small per gigabyte, and the volume is not.** A crossing that costs a fraction of the internet rate still dominates when internal chatter is an order of magnitude larger than what you deliver to users. - **Load balancing randomises it.** When a caller can land on any zone, most calls cross a boundary by default rather than by choice, so the charged fraction is high without anyone having decided so. - **It appears as one line on the bill.** A single "regional data transfer" total carries no hint of which two services generated it. ## What to do with this at design time 1. **Draw the boundaries on the diagram**, not just the services. Every arrow that crosses a zone or region line is a priced arrow. 2. **Ask which crossing each hot path makes per request**, and multiply by request volume before you multiply by any rate. Volume of crossings, not the rate, is what you control. 3. **Keep replicas across zones and keep request paths inside one**, where the workload allows it: you keep the failure-domain benefit and stop paying for every internal hop. 4. **Treat a copy to another region as a transfer decision as well as a resilience decision.** The bytes are charged on the way across and stored again on arrival. ## Where providers genuinely differ This is one of the few places where the rate card shapes architecture, and the platforms do not agree. Some providers meter traffic between availability zones and others do not charge for it at all; among those that do, some count the bytes in both directions — once leaving the sending zone and once entering the receiving one — while others count them once. Free allowances, and whether traffic to the provider's own managed services over a private path is metered, also vary. The conceptual rule is stable everywhere: **a boundary is metered, a rate attaches to each boundary, and the rate rises with distance**. The specific schedule is something you look up for the platform you are on, and it is why an engineer moving between providers should re-check the in-region line rather than carry over an assumption. ## The failure this prevents The classic outcome is a team that optimises the outbound delivery path for months — smaller images, better caching, tighter payloads — while the largest transfer line on the bill was internal chatter crossing a boundary nobody had drawn. Direction told them where to look and the boundary is where the money actually was.