Glossary
Egress cost
Also: Data transfer out · Outbound traffic
Charges for data leaving an AWS region, an availability zone or the cloud. Inbound data is usually free.
The basic rule is simple and still rarely planned for: data in costs nothing, data out costs. The price is tiered by destination. Most expensive is the path to the open internet, cheaper between regions, cheaper again between availability zones, and traffic within a zone is free.
That creates an asymmetry which shapes architecture decisions: an application that reads a lot and delivers little is cheap. One that delivers large files, media or exports pays per user. Noticing that only after launch is a business model problem, not a cost problem.
The second place where egress arises unnoticed is multi-zone deployment. An application in zone A talking to a database in zone B creates traffic in both directions, and both directions cost. With chatty protocols and high frequency this adds up.
The most effective lever against internet egress is a content delivery network. CloudFront has lower outbound rates than S3 or EC2 directly, and traffic from S3 to CloudFront is free. Delivering static content straight from S3 means paying the highest rate for data that could have been cached.
In a migration, egress belongs in the cost model that exists before the move. The path back out of the cloud is the most expensive data path there is, and anyone building a hybrid architecture with constant data flow between data centre and cloud pays for that decision permanently.
How you notice it
- Large files, media or exports are delivered directly from S3 or from EC2.
- The bill contains substantial data transfer out positions.
- There is a permanent link between data centre and cloud with regular data flow.
- Nobody can say what a customer or a transaction costs in traffic.
Not to be confused with
- NAT fees
- A special case that applies even when the data never leaves the region. Traffic to S3 in the same region through a NAT gateway costs money although it is not egress in the strict sense.
- Storage cost
- What data costs while it sits. Egress is what it costs when it moves. Archive classes are cheap to store and expensive to retrieve, which is where the two meet.
- Request cost
- Charges per access, independent of volume. With many small objects they can exceed the data share.
When it fits
- Before any architecture that delivers large volumes: media, exports, backups to third parties.
- In a migration, as part of the cost model before the move.
- For multi-zone deployments with chatty communication between zones.
When it does not
- As an argument against resilience. What needs to be multi-zone stays multi-zone.
- For applications that mostly read and deliver little, the item is usually insignificant.
How to approach it
- Break outbound traffic down by destinationSeparate by usage type in the Cost and Usage Report: internet, inter-region, inter-zone, NAT. The four items have completely different solutions.
- Put static delivery behind a CDNCloudFront in front of S3 lowers the outbound rate and makes the path from S3 to the network free. The single largest lever for media-heavy applications.
- Set gateway endpointsSo that traffic to S3 and DynamoDB does not run through the NAT gateway. Free and fast.
- Check cross-zone chattinessWhere application and database sit in different zones for no reason, correct it. Where multi-zone is intended, accept and name the item as the price of resilience.
- Compress what you deliverCompression and appropriate formats reduce the byte count directly. The cheapest egress is the one that never happens.
Frequently asked
Why is inbound traffic free?
Because it attracts and retains customers. Getting data in is cheap, getting it back out costs, and that is a deliberate part of the pricing model of every large provider. Anyone building an architecture where large volumes flow back and forth permanently should keep that in view.
Does CloudFront really lower cost?
For static delivery, usually considerably. The outbound rates are lower than S3 or EC2 directly, the path from S3 to CloudFront is free, and cached content produces no origin traffic at all. For dynamic responses that cannot be cached the effect is smaller.
Is it worth avoiding cross-zone traffic?
Only where the multi-zone layout serves no purpose. If application and database sit in different zones for historical reasons, the correction is right. If multi-zone carries the resilience, the traffic is the price for it and not waste.