DAM Egress and Bandwidth Cost: The Invisible Line Item

Storage gets budgeted. Everyone knows what a terabyte costs, and finance signs off on it once a year. Egress, the cost of bytes leaving your storage every time an asset is requested, gets budgeted almost nowhere. It shows up as a variable line on a cloud bill that grows quietly with traffic.

That is the trap. Egress is not a one-time cost. It recurs on every request, every image on every page view, forever. A library that is 30% larger than it needs to be is not 30% more expensive once. It is 30% more expensive on every byte it ships, month after month.

This post is about reading that number honestly, best case and typical, and about the one lever that actually moves it.

Key Takeaways

• Egress is a recurring cost that scales with traffic, not a fixed storage line, so oversized assets are taxed on every request.
• Images are roughly 40 to 60% of page weight, which makes them the dominant driver of the media portion of your bandwidth bill (Web Almanac, 2022).
• Major clouds charge per gigabyte of data transfer out, so byte reduction converts directly into invoice reduction (AWS, 2026).
• Photographic sources can reach up to 95% neural compression savings, but the honest planning number is the median, not the best case.
• Every optimized byte still clears a perceptual floor of 0.975 structural similarity, so savings do not come from shipping worse images.

Why is egress the cost nobody budgets?

Because it hides in a variable line that scales with success. Storage is a number you choose once and forecast easily. Egress is a number your customers choose for you, one request at a time, and it climbs precisely when traffic is going well. Nobody approves it in advance, so nobody feels responsible for it.

The structure makes it worse. Cloud providers bill data transfer out per gigabyte, with the first tier priced highest and volume discounts arriving only at scale (Google Cloud, 2026). Every oversized image is taxed at that per-gigabyte rate on every single delivery, so the waste is not a rounding error. It is a coefficient on your entire traffic volume.

The reason egress escapes scrutiny is organizational, not technical. Storage has an owner in infrastructure. Bandwidth has no owner, because the bytes were shaped by a marketer who uploaded a hero and a developer who wrote the delivery code, and neither sees the bill. The cost lives in the gap between them.

How much of the bill is actually images?

Most of the media portion of it. Images make up roughly 40 to 60% of page weight on the typical page, which means they dominate the bytes your DAM ships to browsers. Video can exceed that on specific pages, but across a broad content library, images are the steady, unglamorous majority of transferred weight.

That concentration is good news for anyone trying to cut the bill. You do not need to touch a hundred small things. You need to fix the one category that is most of the transfer, and that category responds well to per-asset optimization. The framing is in why file size is the wrong metric: the goal is not smaller files for their own sake, it is shipping only the bytes the eye needs.

A digital asset management platform is where that fix belongs, because it is the one place that sees every asset before it enters delivery.

What does a CDN do to egress, and what does it not?

A CDN reshapes where egress happens, not how much of it there is. Caching at the edge reduces origin egress and improves latency, which is real value. But the bytes still travel from edge to user, and that transfer is still billed. A CDN moving an oversized image quickly is still moving an oversized image.

This is the distinction we make in why your CDN isn't solving your image problem. The CDN executes delivery. It does not decide how many bytes each asset should be. Hand it a bloated library and it will deliver that bloat efficiently to every edge on earth, and bill you for the privilege at each hop.

The lever that actually shrinks egress is upstream: reduce the bytes before they ever enter the delivery path. That is a decision, and it has to be made per asset.

How much can optimization actually cut? (median vs best case)

Honestly? It depends on the source, and you should plan on the median, not the headline. Photographic sources, which carry the most redundant detail, can reach up to 95% neural compression savings. That is the best case, and it is real, but it is not the number to put in a forecast.

The number to forecast with is your library's median, because a real library is a mix. Photographs compress hard. Flat graphics, screenshots, and already-optimized assets compress far less, and some should not be touched at all. The Neural Media Orchestrator evaluates each asset and selects the optimal path from 352 possibilities, so the aggressive path only applies where it belongs. It is Pareto-safe by routing, so no asset is ever delivered larger than the strongest adaptive baseline.

We have found that the fastest way to lose a finance team's trust is to quote the 95% figure against a whole library. Quote the median, show the distribution, and let the best case be the pleasant surprise on the photographic assets. The honesty is what makes the ROI credible. The measurement discipline behind both numbers is in how we benchmark.

Doesn't cutting bytes mean cutting quality?

Not when every result is verified. This is the fear that keeps oversized libraries oversized, and it is a reasonable one, because blunt compression does exactly that. The safeguard is a perceptual quality floor: every optimized asset is checked against structural similarity of 0.975 or higher against the original before it ships.

Anything that cannot clear that floor is not shipped in a degraded form. It falls back instead. So the savings are not coming from accepting worse images, they are coming from removing bytes the eye was never going to see. That is the whole argument in compress without losing brand integrity, and the format context, that AVIF routinely runs 30 to 50% smaller than equivalent-quality JPEG, is well established (web.dev, 2026).

Because the savings recur on every request, the perceptual floor is what makes them safe to bank. You are not trading quality for a one-time discount. You are removing waste permanently.

How do you turn this into a real ROI number?

Multiply the recurring nature of egress by the median byte reduction, then apply it to your actual monthly transfer. Because egress is billed per gigabyte and recurs on every request, a median reduction across your image library compounds monthly, not once. That is what makes image weight one of the highest-leverage line items in a media budget.

The practical path is a library scan that projects savings per asset before anything changes, so you can model the invoice impact against your own traffic. Running this at scale is its own discipline, covered in optimizing a million images without breaking your site, and rollback keeps the whole operation reversible if any result is disputed.

Frequently Asked Questions

What is egress in the context of a DAM?

Egress is the cost of data transferred out of your storage each time an asset is requested and delivered. Unlike storage, it recurs on every request and scales with traffic, which is why oversized images are taxed repeatedly rather than once.

How much can image optimization reduce egress cost?

It depends on the source. Photographic assets can reach up to 95% neural savings, but the honest planning number is your library's median, because flat graphics and already-optimized files compress far less. Per-asset routing applies the aggressive path only where it fits.

Does a CDN reduce egress cost?

Partly. A CDN cuts origin egress through edge caching and improves latency, but edge-to-user transfer is still billed. It delivers bytes efficiently without deciding how many bytes each asset should be. Byte reduction has to happen upstream, per asset.

Will cutting bytes to save egress hurt image quality?

Not with a verified perceptual floor. Every optimized asset must clear structural similarity of 0.975 or higher against the original, and anything that cannot falls back rather than shipping degraded. Savings come from removing bytes the eye never sees.

Why should I plan with the median instead of the best case?

Because a real library mixes photographs, graphics, and pre-optimized files, and only photographic sources approach the best case. Forecasting with the median keeps the ROI credible, and lets the up-to-95% figure be a pleasant surprise on the assets that hit it.

The point

Egress is the media cost that grows in the dark. It is not on the annual budget, it has no clear owner, and it scales with exactly the traffic you were hoping for. That combination is why oversized libraries persist: the cost is real but diffuse, and no single person feels it.

The fix is upstream and per asset. Reduce the bytes before they enter the delivery path, verify each result against a perceptual floor, and forecast with the median rather than the headline. Do that and the invisible line item becomes visible, controllable, and a good deal smaller, permanently, because the savings recur on every request. The wider framework is in media optimization for digital asset management, and the companion piece on delivery is multi-channel asset delivery.