Sooner or later, every company reaches a point where its infrastructure needs to be reassessed: moving a service, adding a backup environment, connecting a new region, changing providers, or building a hybrid architecture. It may be AWS, Hetzner, Servermall, or any other provider. However, in almost any of these scenarios, one thing quickly becomes clear: during the estimation stage, teams usually calculate compute resources, storage, licenses, and capacity buffers, while data transfer is left in the background.
That is why, a month later, the bill often brings an unpleasant surprise: data transfer costs. Outbound traffic turns from a technical detail into a separate cost item that was barely discussed during the design phase.
The problem is not limited to a user downloading a file from the cloud. Money can be spent on routes that look perfectly normal on an architecture diagram: a CDN pulls content from the origin storage, backups are copied to another region, a database replicates changes, an API regularly sends data to partners, and private servers access the outside world through a NAT gateway.
The same volume of data may cost different amounts depending on the direction, region, network, and services involved. That is why it is not enough to calculate “10 TB of traffic per month.” You need to calculate specific data routes:
- Traffic leaving the cloud for the internet;
- Data transfer between regions;
- Connections between availability zones;
- Routes through CDN, NAT gateways, and other paid networking services;
- Regular transfers used for API integrations, backups, and replication.
Costs can be reduced not by disabling protection and redundancy, but by cutting unnecessary data movement: configuring CDN caching, using incremental backups, limiting the scope of replication, sending changes instead of full exports, using private routes, and checking where cross-zone communication is actually needed.
Below, we will look at what counts as egress traffic, why total data volume says very little about cost, and which routes most often turn into a hidden line item in the cloud bill.
What Is Egress Traffic, and Why Does It Become a Hidden Cost?
After the first cloud bill, it often becomes clear that “data transfer” is not one simple line item, but a set of different routes. In billing, what matters is not only how much data was transferred, but also which boundary it crossed: a service, an availability zone, a region, a private network, or the public perimeter.
Ingress traffic is data that enters the cloud or a specific service. For example, a user uploads a file to object storage, an application receives events, or a database gets updates. This type of traffic is often not charged separately, but that does not mean the further movement of the same data will remain free.
Egress traffic is outbound traffic — data that leaves a defined environment. This does not necessarily mean a user downloading a file. The same gigabyte can first enter the cloud without a separate charge and then become billable if:
- An object from storage is retrieved by a service in another region;
- An application sends a response to the public internet;
- A private server accesses an external service through a NAT gateway;
- An external partner regularly receives data through an API.
This is where the hidden cost appears. From a product perspective, it may look like normal system behavior: a CDN refreshed its cache, a backup was copied to another region, an analytics platform pulled data, or a service synchronized with a partner. For the cloud bill, however, these are no longer “just data.” They are specific routes with their own pricing rules.
That is why it is not enough to know that the system transferred an abstract 10 TB over the month. You need to understand which terabytes were inbound, which stayed within the same environment, and which crossed a paid boundary.
Why You Should Calculate the Data Route, Not the Total Volume
The abstract figure mentioned in the previous section says almost nothing about cost on its own, because it does not show where the data actually moved. In the cloud, 10 TB is not one universal pricing unit. It could mean 10 TB from a region to the internet, 10 TB between regions, 10 TB through a CDN, or 10 TB through a NAT gateway. For architecture, all of this may be “data transfer.” For billing, these are different routes with different pricing rules.
The basic calculation logic is therefore simple: first, break traffic down by route; then, for each route, check the price per gigabyte, data processing fees, request charges, and any possible fixed fees.
For example, a hypothetical service transferred the following over a month:
- 4 TB to users over the internet;
- 1 TB to another region;
- 500 GB through a NAT gateway.
These volumes cannot simply be added together and multiplied by a single rate. Internet traffic, inter-region transfer, and NAT traffic may be billed differently. If we use an illustrative rate of $0.08 per GB for internet traffic, then 4 TB to the internet alone would cost about $327: 4,096 GB × $0.08. The remaining routes would be added as separate line items.
To avoid mixing different types of data transfer, it is useful to divide routes into at least a few basic categories:
| Route Type | Example | What May Be Billed |
| Cloud → internet | An application sends data to users | Outbound volume, requests |
| Region A → Region B | A service transfers data to another region | Inter-region transfer |
| Zone A → Zone B | Components communicate between availability zones | Cross-zone traffic |
| Private subnet → internet through NAT | A server accesses an external service | NAT gateway processing, volume |
| Cloud → external SaaS/API | An integration sends data to a partner | Outbound volume, requests |
The conclusion is simple: to control costs, you need to look not at total traffic, but at the actual path the data takes. The route determines whether the flow appears as a separate line item in the bill and which additional charges are added to it.
Next, it is worth looking at typical scenarios where this traffic appears quietly: CDN, backups, inter-region replication, and API integrations.
Common Egress Traffic Scenarios
Hidden costs often appear not because of a mistake, but because of a useful feature. A team speeds up content delivery, configures backups, enables replication, or connects external analytics — and all of this looks like normal engineering work. For billing, however, the intention does not matter. The data route does: where the data goes, how often it moves, and which services it passes through.
Below are four scenarios where outbound traffic is most often underestimated during the design phase.
CDN: Caching Helps Users, but Not Always the Bill
A CDN is used to deliver content closer to users and reduce the load on the origin server or storage. When an object is already in the cache, everything works well: the user receives the file faster, and the origin does not have to participate in every request.
The problem begins when the cache misses too often. For example, an e-commerce team regularly clears the cache after every catalog update, while users keep requesting large product images again and again. Each time, the CDN goes back to the origin storage, pulls the file, and then delivers it to the user. As a result, traffic appears not only on outbound content delivery, but also on requests to the origin.
Large files and frequent invalidations create a separate risk. If videos, archives, images, or documents are constantly pulled from the origin storage, the CDN remains useful for performance, but it no longer looks like a “free accelerator.” In this case, it is important to monitor the cache hit ratio, caching rules, headers, and file versioning.
Backups: Insurance That Moves Suitcases Every Day
Backups are easy to think of as an internal safety measure: they do not seem directly related to users and do not look like a product feature. However, if copies are regularly sent to another region, another account, or separate storage, they create a constant flow of data.
Imagine a database that is several terabytes in size. If the team creates a full copy every day and sends it to a remote region, costs will grow together with the size of the database, even if only a small portion of the data changes during the day. Formally, the team is “just making backups,” but the bill now includes a recurring data transfer route.
Optimization here should not mean giving up recovery. You cannot cut costs in a way that leaves you with nothing to restore from after a failure. Instead, the backup model can be revised: where full copies are truly needed, where incremental backups are sufficient, how long older versions should be retained, and whether all data really needs to be transferred to a remote region at the same frequency.
Inter-Region Replication: The Second Region Needs a Budget Too
Replication differs from backups because it transfers changes continuously. It is used for resilience, disaster recovery, and meeting target RPO/RTO requirements. RPO defines how much data loss is acceptable during an incident, while RTO defines how quickly the service must be restored.
On an architecture diagram, a second region often looks like calm insurance: the database is replicated, storage is synchronized, and the service can be recovered faster. For the budget, however, this is not just a “reliability checkbox.” The more active the system is, the more changes have to be transferred between regions: transactions, files, logs, events, and queue messages.
The budget risk appears when everything is replicated without separating data by criticality. Temporary data, cacheable objects, diagnostic logs, and entities that can be recreated may be sent to another region together with truly important data. As a result, resilience becomes more expensive than expected, even though part of the transferred volume is not actually needed for real recovery.
API Integrations: “A Few Requests” Turned into a Daily Export
An integration with a SaaS platform, BI system, CRM, or partner often looks harmless: after all, it is just a few API requests. In practice, the cost is not created by the integration itself, but by the exchange pattern: frequent calls, large responses, full exports instead of change-based transfers, and communication between systems located in different regions.
For example, an external analytics system may pull the full list of orders every hour, even though only new statuses and a few line items have changed during that time. From a product perspective, this looks like ordinary synchronization. For the cloud bill, it is the repeated transfer of the same data again and again.
These costs are especially easy to miss because they hide inside “service” activity. The user did not download anything, and the team did not run a separate export function, but the API is still regularly sending large volumes of data outward. That is why integrations should be designed from the start around change-based transfers, filters, pagination, compression, and a clear exchange frequency.
These scenarios show the same pattern: egress traffic appears wherever data starts crossing boundaries on a regular basis. Sometimes it is the boundary between the cloud and the internet, sometimes between regions, and sometimes between the cloud and an external system. The next step, therefore, is not to disable useful functions, but to understand where unnecessary data movement can be reduced without sacrificing reliability.
How to Reduce Costs Without Sacrificing Reliability
Optimizing outbound traffic should not mean disabling protective mechanisms. You cannot simply remove replication, stop making backups, or move all components into a single availability zone if that violates recovery and availability requirements.
The right approach is different: reduce unnecessary data movement while preserving the resilience layers the service actually needs. In other words, the goal is not to “turn off everything expensive,” but to understand where data is being transferred repeatedly, too frequently, or through an inefficient route.
Reduce Unnecessary Data Movement
The first group of measures concerns routes where data moves more often, or in larger volumes, than necessary. Typical examples include CDN configurations with frequent cache misses, full backups instead of incremental ones, overly broad replication, and API integrations that repeatedly pull the same data.
| Where the Cost Appears | What to Check | What Can Be Done |
| CDN | Cache hit ratio, frequency of origin requests, invalidations | Configure cache lifetimes, headers, and file versioning |
| Backups | Full copies, retention period, transfer to remote regions | Combine full and incremental backups, test recovery |
| Inter-region replication | Which data is actually needed for recovery | Separate critical and non-critical data, avoid replicating temporary data |
| API integrations | Request frequency, response size, full exports | Send changes, use filters, pagination, and compression |
A CDN is usually needed to improve delivery speed and reduce the load on the origin server. The goal is not to abandon the CDN, but to make it go back to the origin storage less often. If large objects are constantly pulled from the origin because the cache is cleared too frequently, costs may appear twice: when the CDN retrieves data from the origin and when it delivers it to the user.
The logic is similar with backups. Full backups are easier to reason about, but they quickly create excessive transfer volume. Reliability does not suffer if periodic full backups are combined with incremental ones and recovery is tested regularly — not just the fact that backups were created.
Replication should also be configured based on data criticality. Not everything stored in the primary region necessarily has to be transferred to the backup region at the same frequency. Temporary, cacheable, and reproducible data can often be excluded, as long as this does not break the target RPO and RTO.
API integrations should be reviewed separately. If an external system pulls a full dataset every hour even though only a few records have changed, the cloud bill includes repeated transfer of the same volume. In most cases, change-based transfer, filters, pagination, compression, and a more reasonable exchange frequency help reduce this cost.
Optimize Routes Without Breaking Resilience
The second group of measures concerns the network path. Sometimes data travels through public addresses, a NAT gateway, or between zones simply because the routes were configured that way historically. At the same time, network cost optimization has to be handled carefully: cheaper does not always mean more reliable.
| What You May Want to Do | What the Risk Is | Safer Approach |
| Send internal traffic through public addresses because “it works” | Unnecessary costs and a larger attack surface | Check private routes, DNS, and endpoints |
| Route all private resources through NAT for external access | Large volumes may pass through a paid network service | Use private endpoints where they are available |
| Move everything into one zone to save money | A zone failure can affect all components at once | Place frequently communicating components closer together without abandoning redundancy |
| Disable replication to reduce traffic | RPO/RTO violations and risk of data loss | Replicate only what is needed to restore the service |
If cloud resources communicate through public addresses, traffic may follow a more expensive route even when both services are hosted by the same provider. In such cases, it is worth checking DNS, routing tables, and how services address each other.
For managed services, private endpoints are often available. They allow applications to access storage, databases, or queues through the cloud provider’s internal network, without going through the public internet and without unnecessary processing on a NAT gateway. This can reduce data transfer costs while also shrinking the attack surface.
With cross-zone traffic, it is important not to go to the other extreme. If an application, database, and supporting services communicate across availability zones, some costs can be reduced through more careful component placement. However, moving everything into a single zone purely to save money is risky: a zone failure may affect the entire service.
The guiding principle is simple: reduce unnecessary routes, not useful reliability. Optimization is sound when recovery, availability, and security requirements remain intact, while data stops moving through paths where there is no practical need for it.
Conclusion
Data transfer costs rarely appear out of nowhere. More often, they remain invisible for a long time: the architecture includes a CDN, backups, replication, integrations, NAT gateways, and cross-zone communication, but during the estimation stage these are treated as technical details rather than separate routes with their own price.
That is why egress traffic should be accounted for as early as the infrastructure design stage. For each major data flow, it is important to understand its direction, frequency, volume, the services involved, and the applicable pricing rules. Then data transfer stops being a surprise in the bill and becomes a manageable part of the budget.
A good model does not try to save money at any cost. It shows where data genuinely needs to cross boundaries, and where the system is simply paying for repeated transfers, unnecessary exports, or inefficient routes. The earlier these routes are documented, the easier it is to control cloud costs without sacrificing performance, security, or service resilience.
FAQ
Why is ingress traffic often free, while egress traffic is charged?
Inbound data usually does not create the same external network costs for the provider as delivering data out of the cloud or to another region. However, the exact terms depend on the service, region, and transfer direction.
Does a CDN always reduce traffic costs?
No. A CDN can reduce the load on the origin server, but data delivery from edge locations, requests, and origin fetches during cache misses may be billed separately.
Why does “inside the same cloud” not mean free?
Because data may still cross billable boundaries: regions, availability zones, public routes, or managed networking services. For billing, the actual data path matters.
Where should a data transfer cost review start?
Start by breaking traffic down by route: internet, another region, another zone, NAT gateway, CDN, external API, and backups. Then match the volume on each route with the pricing rules of the specific cloud service.
Can egress costs be reduced without risking resilience?
Yes, as long as the optimization does not break RPO, RTO, SLA, or security requirements. Typical starting points include incremental backups, compression, change-based transfers instead of full exports, private endpoints, and better cache configuration.
Sources
1. AWS Global Infrastructure / Global Network FAQ
3. Amazon CloudFront Developer Guide
5. AWS Well-Architected Framework: Cost Optimization / Data Transfer
