On a cloud transfer bill, a service uploads large video masters and ships finished renditions out to viewers — why is only one direction charged?
answer
- the meter has a direction
- one side lands, one side leaves
- arriving bytes are normally unmetered
- leaving to the internet is priced per gigabyte
- free inbound is not free storage
basics
~20 sTransfer is metered by direction. Bytes arriving from outside are normally unmetered; bytes leaving toward the internet are priced per gigabyte after a small monthly allowance. So delivery to viewers is the charge, not the upload of masters.
solid answer
~40 sData transfer pricing is asymmetric on purpose. Traffic arriving from outside into the platform is normally not metered at all, while traffic leaving toward the public internet is priced per gigabyte moved, usually after a small monthly free allowance. For a media pipeline that means the transfer line tracks what you hand back to viewers, not the far larger volume of masters you took in: ingest 40 TB and deliver 4 TB, and the outbound 4 TB is what carries the per-gigabyte charge. Two qualifications matter. Unmetered arrival covers the *transfer* line only — you still pay to store what landed and to run whatever processed it. And the internet boundary is not the only metered one: traffic crossing between zones or between regions is charged on its own schedule.
go deeper
Recall the asymmetry and say it plainly: bytes in are normally unmetered, bytes out to the internet are priced per gigabyte. Being able to point at the delivery side as the transfer charge is the whole first-screen answer.
Explain the mechanics behind the asymmetry and its limits: the free allowance is fixed rather than proportional, storage and processing start the moment data lands, and the internet boundary is only one of several metered crossings.
Show that you convert the line into a unit cost per delivered thing and can say which design choices move it. Name payload size, repeat delivery of identical bytes and response shape as the levers, and compute sizing as the lever that does not help.
Frame the asymmetry as a placement incentive rather than a rate card: cheap arrival and priced departure is what makes data accumulate where it lands, and any strategy that assumes data will move later is buying an obligation you have not costed.
## The meter looks at direction first Providers price network traffic on two questions: **which way are the bytes going**, and **which boundary did they cross**. Direction is the first and the simpler of the two. - Bytes arriving from outside into the platform — **inbound**, or ingress — are normally not metered. - Bytes leaving the platform toward the public internet — **outbound**, or egress — are priced **per gigabyte moved**, typically after a small monthly free allowance. A service whose job is to take large inputs and emit smaller outputs therefore has a transfer bill driven almost entirely by what it hands back. A pipeline that ingests 40 TB of camera masters and delivers 4 TB of finished renditions carries a transfer charge on roughly the 4 TB, not on the 44 TB it touched. Double the masters and the transfer line barely moves; double the audience and it doubles. ## Why the asymmetry exists - **Arrival is the acquisition step.** Charging for uploads would be charging you to become a customer. Once the data is resident, the storage meter and the compute meter run every month regardless. - **Data gravity favours the platform.** Data that is cheap to place and expensive to move out tends to stay, and the workloads that read it are built next to it. - **The published rate is stable and quiet.** Nothing in a deployment warns you that a design change just doubled the bytes leaving; the number shows up a month later. ## What "unmetered inbound" does not make free 1. **Storage.** Whatever landed now occupies a storage tier and is billed per gigabyte-month for as long as you keep it. 2. **Processing.** Decoding, scanning, indexing or transcoding the arriving bytes is compute, metered on its own dimension. 3. **The other boundaries.** Free arrival from the internet says nothing about traffic that later crosses a zone or region boundary inside the platform. 4. **The reply.** In a request/response service the request arriving is inbound and the response going back to an internet client is outbound — so a small-request, large-response API bills on the response side. ## A media pipeline, flow by flow | flow | direction and boundary | on the transfer line | what makes it grow | |---|---|---|---| | masters uploaded from the studio | inbound from the internet | normally nothing | nothing on this line | | intermediates moved between zones | across a zone boundary, inside one region | metered on platforms that price that crossing | hops per job, payload per hop | | a rendition copied to a second region | across a region boundary | metered, on its own schedule | how many regions you keep a copy in | | renditions delivered to viewers | outbound to the internet | metered at the headline rate | viewers multiplied by bytes per view | The table is the whole lesson in miniature: one flow is free, one is cheap but not free, and one is the line that grows with your success. ## Reading it on your own bill - Find the **transfer lines separately** from compute and storage; a bill that shows one lump for a service hides which boundary produced it. - For each transfer line, ask the two questions in order: **which direction**, and **which boundary**. - Convert it to a **unit cost** — charge per delivered view, per exported report, per active user. The absolute number grows with the business; the unit number is the one that tells you whether the design is getting better or worse. - Treat the **free outbound allowance** as a fixed monthly quantity, not a proportion. It hides the charge completely at prototype scale and becomes a rounding error at real scale, which is exactly why teams are surprised. ## The mistakes this question is really testing - Believing traffic is billed symmetrically, and therefore sizing the bill from the biggest flow rather than the outbound one. - Reading "inbound is free" as "the data is free", when storage and processing start the moment it lands. - Assuming the internet boundary is the only metered one, which is how a cross-zone or cross-region charge arrives unexplained. The useful mental model is a warehouse that will take your boxes in for nothing, store them for a monthly fee, and weigh every box on the way out.
- If arriving traffic is unmetered, does a small request with a large response cost anything on the transfer line?Yes. The request arriving from an internet client is inbound and normally unmetered, but the response travelling back out crosses the internet boundary and is charged per gigabyte. Chatty APIs that return large payloads bill almost entirely on the response side, which is why payload trimming and compression show up on the transfer line and not on the request count.
- What does the small monthly free outbound allowance actually change for a growing service?It is a fixed quantity of outbound bytes, not a proportion of usage, so it covers a prototype completely and then becomes negligible. That shape is why transfer cost tends to appear suddenly rather than gradually: the design was always charging, the allowance was simply absorbing it while volumes were small.
- Why does the per-gigabyte outbound rate usually matter more to a design than the compute rate?Compute scales with how much work you do and can be right-sized, while outbound bytes scale with what you deliver and are mostly fixed by the product. You can halve machines without changing a byte delivered, so once delivery volume is meaningful the transfer line responds only to payload size, caching and how many times the same bytes leave.
A warehouse that accepts your pallets at the door for nothing, charges rent every month they sit there, and weighs every pallet on the way back out.
saying these in an interview costs you the question
- Claims traffic is billed the same in both directions
- Reads unmetered inbound as meaning the landed data costs nothing
- Assumes internet egress is the only traffic that is ever metered
- Says a larger upload volume will raise the transfer bill
- Believes the free outbound allowance grows in proportion to usage