Data Egress Costs: Causes, Challenges & Optimization Strategies

One of the tricky things about managing cloud computing costs is that cloud providers charge not just for infrastructure, but also for data egress. In other words, not only do you pay a fee for the cloud servers, databases and so on that you use, you also pay – in many cases – for the data that flows to and from those cloud resources.

What’s more, although data egress fees are typically very low (just a few pennies) on a per-gigabyte basis, they can add up quickly, especially in cloud environments that are not designed to minimize egress fees.

Hence the importance of understanding how data egress costs work, how to calculate them and how to avoid unnecessary egress spending. Read on for a deep dive into all of the above as we unpack the role of data egress costs in modern software environments.

What are data egress costs?

Data egress costs are fees that users incur when transferring data out of a cloud environment. In this context, environment can refer to an availability zone (AZ), a cloud region or an entire cloud platform.

As we mentioned, egress costs are billed separately from (and in addition to) other cloud computing charges, like the cost of having a cloud server or database turned on.

Ingress vs. egress costs in cloud infrastructure

It’s important not to conflate data egress with data ingress:

• Egress refers to data that moves out of a cloud environment (for example, from Amazon Web Services into Azure or into a private data center).
• Ingress occurs when data flows into a cloud environment (for example, when you upload data from an on-prem server into AWS).

Ingress is almost always free (which makes sense because cloud providers want to incentivize businesses to move data onto their platforms).

Egress, however, is usually not free. All of the major public cloud service providers (and most of the smaller ones, too) impose a per-gigabyte fee for data that moves out of their clouds and into another cloud provider's network (or to a private data center or on-prem environment). They also typically charge for movement of data into different cloud availability zones (AZs) or regions, even if it stays within the same overall cloud platform, as we explain in more detail below.

How data egress costs work in cloud and Kubernetes environments

Exact egress fees vary depending on factors like which cloud platform and region you use. In general, however, egress costs work based on the following principles:

• Cloud service providers monitor the flow of data into and out of cloud environments.
• At the end of every month, the providers send each customer a bill that includes a charge for the total egress fees that the customer incurred that month.
• In some cases, cloud providers allow a certain amount of egress at no cost. For example, in most AWS environments, you can use up to 100 gigabytes per month of egress at no cost.
• In general, egress fees aren’t impacted by which types of workloads you operate; they are based simply on the total amount of data transferred. Thus, egress for a cloud server hosted on a service like Amazon EC2 costs the same as egress from a Kubernetes cluster.

An important nuance related to that last point is that complex platforms, like Kubernetes, have a tendency to generate more egress traffic because they include more components that are constantly moving data. This is especially true in complicated architectural scenarios, such as a Kubernetes cluster that includes nodes spread across multiple availability zones or regions. The per-gigabyte cost for traffic in this scenario would be the same as for other types of workloads, but the total amount of data transferred is likely to be higher due to the nature of Kubernetes.

Data egress pricing by cloud provider

An apples-to-apples comparison of data egress costs between cloud service providers is somewhat tricky because the per-gigabyte prices usually vary between cloud regions (for instance, egress is usually cheaper in cloud regions based in North America and Europe than in other parts of the world). In addition, each provider offers various types of free tiers or credits that can reduce (or eliminate) egress costs under certain scenarios.

That said, as a general summary, the following are egress costs for the US East Coast regions of each of the “Big Three” cloud providers:

• AWS data egress costs: $0.09 per gigabyte.
• Google Cloud platform egress costs: $0.12 per gigabyte.
• Azure data egress costs: $0.05 per gigabyte.

There are a couple of important caveats about these price figures:

• They don’t include free egress tiers. Often, each of these providers offers up to 100 gigabytes of egress per month at no cost.
• The prices above reflect egress costs for the first monthly 350-1000 gigabytes after the free tier ends. Per-gigabyte egress costs usually get lower when customers consume egress in volumes higher than 1000 gigabytes per month.

Why data egress costs are a growing problem for cloud-native teams

Egress fees have existed since the early days of cloud computing. But in a cloud-native world characterized by distributed architectures, loosely coupled systems and microservices, the challenge of managing egress costs has become especially pronounced. The reason why is simple: Cloud-native systems include more moving parts, and those parts typically exchange data with each other continuously. More data movement means a higher potential for egress.

Of course, egress fees only apply if the data from cloud-native systems actually moves outside a cloud availability zone, region or platform. Kubernetes Pods talking to each other won’t incur egress fees if the Pods all reside in the same cloud data center.

But increasingly, in a bid to improve availability and/or performance, businesses are shifting toward more complex architectures that involve practices like deploying Kubernetes clusters across availability zones. This can dramatically reduce the risk of downtime (since both zones would have to fail for the cluster to fail), but it also tends to lead to much higher egress costs.

Key drivers of data egress costs

While any type of data movement outside of a cloud availability zone, region or platform will trigger egress fees, the following types of events or patterns are typically among the most significant causes of egress costs.

Cross-region and cross-AZ traffic

As we mentioned, spreading workloads across cloud regions or availability zones can boost reliability and performance (by making it possible to deploy workers closer to end-users who are concentrated in diverse geographical areas). But it also results in higher egress rates because whenever workloads in different regions or zones talk to each other, egress fees apply.

Internet egress and external API calls

Generic connections to endpoints, applications or APIs located on the Internet also lead to egress costs. This means that any workloads that need to respond to end-user requests, send data to external databases or integrate with third-party apps will trigger egress costs.

Logging, monitoring and telemetry pipelines

Logging, monitoring and observability data are critical for managing application performance. But they can contribute to egress costs when the data across telemetry pipelines that span cloud AZs, regions or platforms.

This challenge arises most commonly with observability tools that rely on agents to collect data from across disparate workloads or infrastructure, then forward it to a specific hub. If the agents and hub are in different parts of the cloud, egress fees will apply.

Data replication and backup transfers

Replicating and backing up data is critical for reliability. But here again, egress fees apply when the data moves across regions – which it often does because it’s common for businesses to host backup data using cloud storage within a separate AZ or region, since they want the backups to be available if the production environment fails.

Hidden costs and challenges of data egress

Egress might not be all that bad if it were easy to predict and manage costs. But it’s often not, due to challenges like:

• Unpredictable billing and cost spikes: Egress fees are usually stable (cloud providers rarely change them), but the costs incurred can nonetheless be difficult to predict because it’s challenging to know ahead of time exactly how much data you’ll transfer out.
• Vendor lock-in and data gravity: If egress fees become lower on a different cloud platform or in a different region, it can be tough to capitalize on the savings opportunity if you’re already wed to a specific cloud, due to the complexity of migrating.
• Limited visibility into network traffic: Monitoring egress in real time can be hard because network observability tools don’t always make this data easy to track.
• Inefficient data movement across services: Applications and services are rarely designed to be “egress-aware”; in other words, they don’t automatically minimize egress. They’ll happily keep sending data to each other without regard for the resulting egress costs.

How to calculate data egress costs

The formula for calculating egress costs is simple enough: You multiply the amount of data you transfer out of an AZ, region or cloud platform by the per-gigabyte cost of egress that your cloud provider imposes.

For example, imagine you have 900 gigabytes of egress per month, and your provider charges $0.10 per gigabyte for egress. Your total egress costs would be $90 in this case (which is low, but businesses with large-scale cloud environments often experience much more egress per month than 900 gigabytes).

There are a couple of important nuances that apply to egress coast calculations (which we didn’t factor into the example we just gave). We’ve touched on them above, but as a reminder:

1. You usually get a certain amount (often, 100 gigabytes) of free egress per month.
2. The per-gigabyte egress charges often go down after a certain threshold of usage. For example, a cloud provider might charge $0.10 per gigabyte for the first 1000 gigabytes of egress, then $0.07 per gigabyte for additional egress.

How to measure and monitor data egress costs

The easiest way to track egress spending is to use cost management tools offered by cloud providers, such as AWS Cost Explorer or Azure Cost Management + Billing. These tools provide estimates of your current monthly egress costs to date.

A downside of this approach is that the tools often don’t calculate data in real time. For instance, with AWS Cost Explorer, there is typically a 24-hour lag between when you incur data egress costs and when they appear in the tool.

For real-time tracking of data egress, you’d need to monitor data as it flows within your network infrastructure. You can do this using generic devices like network switches. You can also use platform-specific tools; for instance, for a Kubernetes cluster, Istio Egress Gateway combined with Prometheus can report egress statistics.

Best practices for reducing data egress costs in cloud environments

While some amount of egress is unavoidable, there are steps businesses can take to minimize egress “waste” (meaning unnecessary data transfers), such as:

• Minimize cross-AZ and cross-region traffic: When designing cloud environments, think about which workloads communicate most frequently and place them in the same AZ or region to avoid egress costs.
• Optimize multi-cloud and hybrid cloud setups: Similarly, when planning multi-cloud or hybrid cloud architectures, strive for data locality by keeping related workloads in the same cloud platform.
• Optimize data flows: Practices like deduplicating or compressing data before transferring it out of an AZ or cloud region can save on egress by cutting back on the amount of data transferred.‍
• Use CDNs and edge caching: Content Delivery Networks (CDNs) can cache content at the network edge. This reduces egress by decreasing the amount of time that data needs to flow from a central cloud data center to the edge.

Reducing data egress costs using eBPF-based observability with groundcover

As a next-generation network observability platform, groundcover can help teams cut down on egress costs in two key ways.

First, because groundcover can use the hyper-efficient eBPF platform to collect logs, metrics and traces, it dramatically reduces the amount of telemetry data that moves between workloads and observability hubs. In other words, with groundcover, there’s simply less data to transfer – and in turn, less egress to pay for.

Second, by comprehensively monitoring data flows across microservices, servers, containers, Pods and more, groundcover offers real-time visibility into how much data businesses are moving. It can also help highlight inefficiencies like redundant data transfers. Using these insights, teams can optimize their architectures to reduce data egress costs without sacrificing performance.

Getting ahead of egress waste

Egress is a fact of life for virtually any organization that deploys workloads in the cloud. But just because it’s unavoidable doesn’t mean it has to be wasteful. With the right tools and practices, businesses can keep data egress fees under control.