The cloud bill explained: A guide for finance and engineering

The cloud bill arrives at the end of every month, and somewhere in it sits a line item that nobody outside the infrastructure team really understands. It might be called "data transfer," "egress," or "outbound bandwidth," and it might be 5% of the total or even 25%. Whatever it is, it tends to be the line that finance asks engineering about, and engineering struggles to explain in a way that finance can act on.

The problem is that egress is a fee that hides in plain sight. It's not on the marketing page. It's not in the headline rate when capacity is being procured. It only shows up after the workload has been running for a while, and by then, the architecture is locked in, and the cost is structural.

This blog is for both audiences. The engineering team gets the architectural patterns that drive egress and the levers that reduce it. Finance gets a translation of the invoice and a framework for asking the right questions about it. Both end up with a working understanding of why egress fees exist, what they cost, and what alternatives look like.

What is egress? 

Egress is the charge for data leaving the provider's cloud. When your application serves a video file to a customer, that data is egress. When you back up a database to another location, that's egress. When you move a dataset to a different cloud provider for an analytics job, that's egress. The traffic in the other direction, ingress, is usually free.

The mechanism is straightforward. Every byte leaving the cloud is metered. The provider applies a per-gigabyte rate, often tiered so the rate drops at higher volumes, and the result appears on the bill as a single line that aggregates traffic across the whole environment.

The mechanism is straightforward. The economics are not. Egress charges have grown from a minor cost into one of the structural costs that determine whether a workload's economics work at scale. For organizations running modern, data-intensive applications, egress can be the single largest variable on the bill.

Why egress is contested

The reason egress generates so much friction is that it does two things at once. The first is to recover the provider's cost of operating network infrastructure. That's defensible. The second is creating switching costs. Once a workload's data lives at a particular provider, moving it elsewhere requires paying the egress meter on every byte. The bigger the dataset, the higher the switching cost. For workloads measured in petabytes, the egress bill alone can make migration economically unviable.

Civo's CEO Mark Boost has been direct about this. In Civo's analysis of how hyperscalers hurt customers and stifle innovation, the position is that punitive egress costs have made it prohibitively expensive for organizations to migrate between clouds or adopt multi-cloud strategies. The result, in his framing, is that companies get locked into the vendor they chose at the start, even when better options emerge later.

Mark Boost, CEO of Civo

The hyperscalers have responded to mounting regulatory pressure with partial reforms. Google Cloud and Microsoft Azure now remove egress fees for customers who completely leave their platforms and close their accounts. AWS does not require full account closure. Instead, AWS allows 100GB per month of free outbound data transfer; transfers beyond that require Amazon support approval to qualify for a migration waiver on egress fees, with the provider verifying whether the transfer is a legitimate migration or "normal business activity."

These changes are useful but limited. Multi-cloud and hybrid architectures, which require data to move between providers as a routine matter rather than as a one-time exit event, still face the full egress meter.

Translating the invoice for finance

For finance teams looking at a cloud bill, the practical translation of egress charges is straightforward once the categories are clear:

• What the line means: Charges for data leaving the cloud, applied per gigabyte transferred
• What drives it: The volume of outbound traffic from your applications - customer-facing responses, backups to other locations, multi-cloud workflows, data exports
• What changes it: Architectural decisions made by the engineering team about where data lives, how it moves, and what services it depends on
• What controls it: A combination of right-sizing the workload, minimizing unnecessary data movement, and choosing providers whose pricing structure doesn't rely on egress

The number to ask about, when reviewing the bill, is the ratio of egress to total cloud spend. IDC research found that 99% of cloud storage users have incurred egress fees averaging roughly 6% of their cloud storage costs. If your organization's ratio is materially higher, there's an architectural reason behind it that the engineering team should be able to explain.

The other question to ask is whether the egress charges are growing faster than the underlying workload. If the application's user base grew 20% and egress costs grew 50%, something has changed in the architecture or the platform's pricing that's worth investigating.

What drives egress, for engineering

For engineering teams, egress comes from a handful of architectural patterns:

Customer-facing traffic

Every byte your application serves to an end user is egress. For consumer applications, this is the dominant driver. Video streaming, image-heavy applications, API services, and any product where the value delivered to the user is large data payloads will see egress as a significant cost.

Multi-region replication

Replicating data across regions of the same cloud for resilience or latency typically counts as inter-region transfer, which is often priced at egress rates even though the data hasn't left the provider's network. For workloads with strong availability requirements, this can be a meaningful chunk of the bill.

Multi-cloud and hybrid architectures

Data moving between cloud providers, or between cloud and on-premises systems, is pure egress. For organizations operating multi-cloud setups intentionally - to use the best service for each workload or to avoid single-provider risk - the cost of crossing those boundaries can be significant.

Backup and disaster recovery

Backups going to a different provider, region, or service create egress traffic on every backup cycle. For workloads with frequent backups and large datasets, the backup egress alone can be substantial.

Service-to-service traffic within complex architectures

Microservices architectures with services in different regions, third-party integrations that pull data out of the cloud, and event-driven systems with external consumers all generate egress as part of normal operation.

Patterns that reduce egress (when egress is being charged)

For teams stuck on platforms that charge for egress, the levers that actually reduce the bill:

• Cache aggressively at the edge: CDN caching keeps content close to users and reduces origin egress
• Compress responses: Reduces the bytes that have to flow per request
• Consolidate regions: Fewer inter-region transfers reduce the bill
• Co-locate dependent services: Keeping services that talk to each other in the same region eliminates cross-region traffic
• Right-size backups: Deduplicated and compressed backups reduce backup egress
• Use the provider's CDN and edge services: These are often priced differently from raw egress

These patterns help, but don't solve the underlying issue. The structural cost is built into the pricing model, and engineering work can only do so much against it.

The alternative: Providers that don't charge for egress

The other lever, and the one that actually changes the structural economics, is choosing providers whose pricing model doesn't rely on egress fees. Civo's position, as announced in 2024, is the complete removal of all egress fees with no caveats, no approval processes, and no restrictions, as detailed in the official Civo announcement. Customers can move their data freely between Civo's platform and others whenever their needs evolve, whether they're staying or leaving.

Civo's published research, conducted alongside the announcement, found that 47% of businesses are now considering moving away from cloud entirely. Among users of the major hyperscale providers specifically, 64% have seen cloud costs rise in the last 12 months, with 69% of respondents reporting increases of up to 25%. Fifty-seven percent of hyperscaler users are taking active steps to manage or reduce their cloud service costs, with 28% admitting to hiring consultants specialized in cloud cost management.

The dynamic the numbers describe is structural rather than incidental. As Mark Boost has framed it, hyperscaler providers are chasing profits and inflating prices, with overinflated egress fees punishing company growth and serving the interest of shareholders rather than users. The position Civo has taken - abolishing egress fees entirely, with no caveats - is the operational consequence of that view.

For finance: The questions to ask

For CFOs and finance leaders looking at a cloud bill that includes substantial egress, the conversation with the infrastructure team should cover a few specific questions:

1. What percentage of the bill is egress, and how has that percentage changed over the last year?
2. Is the egress driven by customer-facing traffic, internal architecture, multi-cloud setup, or backups?
3. What would the engineering effort be to materially reduce egress on the current platform, and what's the expected return?
4. What would the cost picture look like on a provider that doesn't charge for egress, modeled against actual usage patterns?
5. Is the current setup creating switching cost that limits future flexibility? What would it cost to migrate elsewhere, including the egress charges to move the data out?

The honest answers to these questions usually surface that egress is not just a cost - it's also a constraint on architectural decisions and on future flexibility. Both deserve attention from finance, not just engineering.

For engineering: The question to ask back

For engineering teams responding to finance questions about egress, the productive direction is twofold:

1. Be specific about what's driving the egress, in plain terms. "Customer-facing video delivery" or "cross-region replication for the database" is a useful answer; "data transfer charges" is not.
2. Be honest about the alternatives. Reducing egress on the current platform is one option. Moving to a platform that doesn't charge for egress is another, and in many cases the more impactful one.

Both options should be on the table when the bill is being discussed. The point of the conversation isn't to defend the architecture or apologize for the cost. It's to give finance the information they need to make decisions about where the organization invests its infrastructure budget.

The structural case

Egress fees are not a fact of nature. They're a pricing choice. Some providers have chosen to charge for them as a major part of their business model. Civo has chosen not to. The choice has consequences in both directions: for providers that charge, egress is a revenue source and a customer retention mechanism; for providers that don't, the absence of egress is a structural feature that enables multi-cloud, hybrid, and migration patterns that the egress-charging providers make expensive.

For organizations evaluating where to run their workloads, the question isn't whether egress is fair. It's whether the structural cost is one they want to accept. For workloads that move significant data, the answer is increasingly that they don't.

Civo's transparent pricing has no egress fees, no charges for ingress, and no surprise meters for storage I/O or API calls. Egress fees stand in the way of that future. It’s time to move beyond them. And it’s time to set the cloud free.