What Is Data Egress? A Practitioner’s Guide to the Cloud Cost That Hides in Plain Sight

Key Takeaways

• Egress is billed at the network boundary, not the workload that caused it; the charge arrives months after the decision that generated it.
• FinOps Foundation's State of FinOps 2025 identifies network & data transfer as one of the fastest-growing unmanaged cloud cost categories.
• Cross-AZ traffic & NAT gateway pass-through silently dominate Kubernetes egress bills; pods & their network charges live in separate billing layers.
• Workload-level cost attribution is the precondition for any egress action: without it, FinOps teams see the charge but not which pod created it.

Look at your cloud bill long enough, & you'll find "Data Transfer" as a line item you haven't touched in months. The number keeps growing. The charge isn't mapped to a service, a team, or a decision.

The FinOps Foundation's State of FinOps 2025 found that unmanaged network & data transfer costs are compounding quarter over quarter at organizations running multi-region or microservices-heavy architectures. The reason is attribution: cloud providers charge for data leaving a network boundary, but they don't tell you which workload crossed it.

This guide explains what data egress is, where it comes from, why it compounds, & why standard visibility tools miss the root cause.

Summary

In This Article

• What Is Data Egress?
• What Is Data Egress, & Why Doesn't It Show Up Like Compute?
• Where Does Data Egress Cost Actually Come From?
• Why Does Egress Compound with Architecture Decisions Made Months Ago?
• What "Visibility" Actually Means for Egress (and Why Most Tools Miss It)
• How Sedai Surfaces Egress Waste at the Workload Level
• Egress Is an Architecture Problem That Looks Like a Bill
• FAQs About Data Egress
• Sources

What Is Data Egress?

Data egress is the transfer of data out of a cloud network boundary (a region, Availability Zone, or VPC) to the internet or another cloud. AWS charges up to $0.09 per GB for internet egress; Azure & GCP charge $0.087–$0.12/GB for internet egress. The workload that caused the transfer does not appear on the bill.

What Is Data Egress, & Why Doesn't It Show Up Like Compute?

Data egress is any data that leaves a cloud network boundary. That boundary can be a region (data leaving us-east-1 for eu-west-1), an Availability Zone (a pod in us-east-1a making a call to a service in us-east-1b), a Virtual Private Cloud (traffic leaving a VPC to the internet), & a cloud provider's network entirely (inter-cloud transfer).

Cloud providers charge per GB whenever data crosses the boundary. AWS charges up to $0.09 per GB for the first 10 TB/month of internet egress, with tiered reductions at higher volumes. Azure charges $0.087/GB for the first 10 TB of outbound data transfer. GCP's VPC network pricing adds cross-region & internet egress charges on top of per-project network costs.

What makes egress different from compute is attribution. An EC2 instance appears on the bill because AWS creates a resource record for it. A NAT gateway charge appears because data crossed a VPC boundary. The charge is attached to the boundary, not to the application that generated the traffic. You know how much you paid. You don't know which workload spent it.

This attribution gap is the root cause of the cost visibility problem. Egress grows with every new service, every replication job, & every cross-region API call. The bill captures the aggregate cost at the network edge, three levels removed from the decisions that generated it.

Where Does Data Egress Cost Actually Come From?

Egress costs are split across five traffic types. The largest production charges come from the lowest-rate categories.

• Internet egress is the most visible line item: data leaving the cloud to end users, external APIs, or on-premises systems. At AWS's standard rate of $0.09/GB for the first 10 TB, a workload that pushes 10 TB/month to end users incurs $900 in data transfer costs before any other cloud costs. Gartner forecasts worldwide public cloud spending to reach $723.4 billion in 2025; at that scale, data transfer charges compound with every new workload added.
• Cross-region egress runs $0.02–$0.08/GB depending on the provider & region pair. Multi-region active-active writes, disaster-recovery replication, & global content distribution all generate cross-region egress. Each additional replication region multiplies the total egress cost proportionally.
• Cross-AZ egress is the silent one. AWS charges $0.01/GB for traffic crossing Availability Zones inside the same region. The rate looks small until a Kubernetes deployment spreads pods across AZs (which it does by default for fault tolerance), & every pod-to-pod call that crosses an AZ boundary generates a charge.
  At production call rates, cross-AZ charges accumulate faster than cross-region charges: pod-to-pod call frequency dwarfs replication frequency. See multi-cloud cost management strategies for how this problem scales when the same pattern repeats across providers.
• NAT gateway pass-through charges for every byte that routes through a NAT gateway: $0.045/GB processed on AWS, plus the per-hour gateway charge. Private subnets that need internet access, internal services calling AWS APIs, & Kubernetes nodes fetching container images all route through NAT by default. None of these traffic sources appears anywhere on the bill except as a NAT gateway line item.
• Inter-cloud egress bills on both sides of the transfer. Moving data between AWS & Azure or GCP costs $0.08–$0.09/GB egress on the source side, plus the destination provider's ingress charges. Inter-cloud replication for backup or analytics accrues charges from the moment the job starts. The bill reflects a decision made months earlier.

Why Does Egress Compound with Architecture Decisions Made Months Ago?

Egress is a downstream cost of architecture decisions. The decision that creates the charge (where data lives, where compute runs, how services communicate) is made at deployment time. The bill arrives continuously, for as long as that architecture is in production.

Consider a Kubernetes deployment spread across three AZs for fault tolerance: two services communicating on every request, one in us-east-1a, one in us-east-1b. The architecture is correct for availability. The cross-AZ charge accumulates on every API call with no pointer back to the service-to-service pattern that generated it.

AWS announced free data transfer for customers leaving its network in March 2024. The concession acknowledged a structural pricing reality: data movement costs are embedded in the choice to use a cloud provider's network, not any individual application decision. That's data gravity: once data is in a region, compute follows, & moving it anywhere compounds with every new service that depends on it.

Three architectural patterns generate the most compounding egress:

• Multi-region write fan-out. Active-active databases replicate every write to every region. Replication cost scales with write volume & region count. Traffic growth means replication charges grow at the same rate, invisibly, because the pattern is set once & never revisited.
• Service mesh cross-AZ communication. In Kubernetes, the scheduler places pods across AZs by default. A service that makes 10 downstream calls per request, with each call crossing an AZ boundary 50% of the time, generates cross-AZ charges on every request at production traffic. Cloud architecture choices drive costs directly, & egress is the category where the cost-consequence lag is longest.
• CDN bypass. A CDN fronts a static content service, but dynamic API calls go directly to the origin. Every dynamic request that bypasses the CDN crosses the internet boundary, generating egress charges. The CDN bill looks low, & the egress bill looks high, with neither dashboard pointing to the cause.

Data Egress Costs That Stay Hidden Until the Bill Arrives

See how Sedai attributes data egress to the workloads that create it, uncovers hidden cross-AZ and NAT gateway costs, and autonomously reduces network spend before it compounds.

Book a Demo

What "Visibility" Actually Means for Egress (and Why Most Tools Miss It)

Cloud billing tools attribute egress to the network resource that processed the transfer: a NAT gateway, a VPC, an internet gateway, & a transit gateway. That's where the charge lives in the billing hierarchy. The decision that caused the charge was made at the workload layer: a pod making a cross-AZ call, a Lambda function replicating to another region, an ECS task fetching container images through NAT.

Google's SRE Book defines traffic as one of four golden signals (latency, errors, traffic, & saturation) measurable at the workload level. Cloud billing measures traffic at the boundary, not the workload. The pod generating 50 GB/day of cross-AZ traffic & the pod generating 2 GB/day are both invisible from the billing layer.

Standard FinOps dashboards surface egress at the account or resource tag level. Cloud cost visibility at the billing level tells you how much a service group costs. It doesn't tell you which workload within that group caused a specific cross-AZ charge or whether that charge is structural or incidental.

Until egress is attributed to the specific pod, service, or job that generated the transfer, FinOps teams can see the charge but cannot act on it. Cloud workload optimization starts with a workload-level signal. That distinction is the prerequisite for any egress reduction that isn't just a traffic cap.

How Sedai Surfaces Egress Waste at the Workload Level

The Challenge: Standard Billing Tools Attribute Egress to the Network, Not the Workload

Egress appears on the bill as a network line item. The cause is application-level: which pod talks to which database, which service crosses an AZ, which job replicates data across regions. Network-level cost tools see the charge at the boundary but cannot reach the workload that caused it. FinOps teams hold a number that they can describe but cannot act on.

Sedai’s Approach: Application-Aware Egress Attribution at the Workload Level

Sedai reads workload-level signals (latency, throughput, error rate, & resource utilization) from CloudWatch, Prometheus, & equivalent sources. It combines these with VPC Flow Logs & billing data to construct a workload-to-egress map: which pods generate which traffic, at which boundary, & at what cost. That map is what makes attribution actionable rather than informational.

Workload-level attribution drives three decisions: 

• Which service to move regions?
• Which Kubernetes deployment generates cross-AZ chatter beyond its fault-tolerance requirement? 
• Which replication target can be relaxed without affecting DR posture? 

Sedai verifies each optimization against the workload's SLOs before committing & rolls back gradually if performance degrades; egress reduction is a downstream effect of right-placing workloads, not a separate pass.

The Outcome: Workload Attribution Turns Egress Visibility Into Actionable Decisions

Workload-level autonomy compounds across every cloud line item, not just compute. Egress reduction follows workload-aware attribution: know which workload created the charge, understand its behavior, & act on it.

Book a demo to see Sedai run in your environment →

Egress Is an Architecture Problem That Looks Like a Bill

By the time egress is visible in billing, the architectural decisions that caused it are months old & load-bearing. The pod topology is set, & the replication targets are configured. The bill is not telling you what to change. It is telling you what you already decided.

The fix is not a better dashboard. It is workload-level cost attribution paired with the ability to safely change where workloads run. Attribution without action is a more expensive version of the same problem. Action without attribution is a guess.

Egress compounds because architecture compounds. Every new service adds potential cross-AZ traffic. Every replication target adds cross-region charges. The only way to stop the compounding is to make the workload the unit of cloud cost optimization: not the VPC, not the gateway, not the account.

FAQs About Data Egress

What Is Data Egress?

Data egress is data leaving a cloud network boundary, such as a region, Availability Zone, VPC, or the public internet. Cloud providers charge per GB transferred across these boundaries.

Why Is Data Egress Expensive?

Cloud providers charge for outbound traffic while inbound traffic is usually free. Costs increase with internet, cross-region, and cross-AZ transfers, making egress charges add up quickly as data volumes grow.

What's the Difference Between Data Egress and Data Transfer?

Data transfer is the billing category for network traffic charges. Data egress specifically refers to outbound or cross-boundary traffic. In practice, most data transfer charges on cloud bills are egress charges.

Where Do Egress Costs Hide in Kubernetes?

The biggest hidden sources are cross-AZ pod communication and NAT gateway traffic. Both generate per-GB charges but are rarely attributed to individual workloads in billing reports.

How Can You Reduce Egress Costs?

Start by identifying which workloads generate the most egress. Use VPC endpoints to avoid NAT gateway fees, enable topology-aware routing to reduce cross-AZ traffic, and review replication strategies to limit unnecessary cross-region transfers.

Why Do Egress Costs Keep Growing?

Egress costs compound as architectures expand. New services, replication targets, and NAT-routed workloads create additional data transfer paths, increasing charges over time unless they are actively monitored and optimized.

Sources

1. FinOps Foundation, State of FinOps 2025 (2025): https://data.finops.org/2025-report/
2. AWS, Amazon EC2 On-Demand Pricing — Data Transfer (2025): https://aws.amazon.com/ec2/pricing/on-demand/
3. Microsoft Azure, Bandwidth Pricing (2025): https://azure.microsoft.com/en-us/pricing/details/bandwidth/
4. Google Cloud, VPC Network Pricing (2025): https://cloud.google.com/vpc/network-pricing
5. AWS, Free Data Transfer Out to Internet When Leaving AWS (March 2024): https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-leaving-aws/
6. Gartner, Worldwide Public Cloud End-User Spending to Total $723 Billion in 2025 (November 2024): https://www.gartner.com/en/newsroom/press-releases/2024-11-19-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-total-723-billion-dollars-in-2025
7. Google SRE Book, Monitoring Distributed Systems: Four Golden Signals: https://sre.google/sre-book/monitoring-distributed-systems/