Distribuée
AWS Advisory
← All insights

FinOps

AWS Egress Fees: Mapping and Cutting Your Data Transfer Costs Before January 2027

Internet egress, cross-AZ, NAT Gateway: how to map your AWS data transfer costs and cut them before the EU Data Act bans all switching fees on 12 January 2027.

· 6 min · #finops#aws#data-transfer#egress#networking#data-act

The “EC2-Other” or “Data Transfer” line on an AWS bill is almost always the least understood one. There’s no dedicated console dashboard for it, it’s spread across dozens of usage types (DataTransfer-Out-Bytes, DataTransfer-Regional-Bytes, NatGateway-Bytes…), and nobody on the team can confidently say which flow pays for what. In Distribuée engagements, it’s the line that triggers the most “wait, that costs how much?” moments during a FinOps audit.

The topic is getting more urgent in 2026: the EU Data Act requires cloud providers to eliminate switching fees entirely — including egress charged when moving to another provider — starting 12 January 2027, a little under five months from now. AWS got ahead of part of this in March 2024 by waiving exit fees for customers leaving the platform entirely, but that waiver isn’t automatic, isn’t total, and changes nothing about the core issue: the operational outbound traffic that runs your production workloads every day is still billed exactly as before, and that’s what actually weighs on an SMB’s bill.

Why this line stays invisible

Three reasons come up in every audit:

  1. Outbound traffic has no owner. Unlike EC2 or RDS, which map to a team or project, data transfer cuts across every layer — nobody looks at it first.
  2. Cost Explorer fragments it by default. Without an explicit filter on usage_type, network costs get buried inside the compute costs of whichever service generated them.
  3. Multi-AZ architectures and chatty microservices multiply internal flows that look free because they never leave the VPC — except a flow between two AZs is still billed.

The first step before any optimization lever: isolate what you’re actually paying for.

aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{
    "Dimensions": {
      "Key": "SERVICE",
      "Values": ["EC2 - Other", "Amazon Virtual Private Cloud", "Amazon CloudFront"]
    }
  }' \
  --query "ResultsByTime[0].Groups[?contains(Keys[0], 'DataTransfer') || contains(Keys[0], 'NatGateway')]"

This query isolates the usage_type values tied to data transfer and NAT Gateway for the past month — the starting point of every network audit we run at Distribuée.

Map of AWS data transfer flows and their cost

The 4 cost categories that make up the bill

Internet egress (DataTransfer-Out-Bytes). 100 GB free per month per account (pooled across all services), then $0.09/GB up to 10 TB, $0.085/GB for the next 40 TB, $0.07/GB for the next 100 TB, $0.05/GB beyond 150 TB. Rates run higher in some Asia-Pacific regions (up to $0.12/GB in Singapore) — worth checking if you serve traffic from Asia.

Cross-AZ transfer (RegionalDataTransfer-*). $0.01/GB in each direction whenever a packet crosses two availability zones — including between two EC2 instances in the same VPC, between an app and its Multi-AZ RDS database, or between microservices split for resilience. It’s the sneakiest cost: it grows with architectural decoupling, not with external traffic.

NAT Gateway (NatGateway-Bytes). $0.045/GB processed, on top of $0.045/hour per NAT Gateway deployed — and that cost stacks on top of the underlying internet egress if the flow then goes out to the internet. An architecture with one NAT Gateway per AZ (a standard resilience practice) mechanically multiplies the hourly charge by the number of AZs, regardless of traffic volume.

CloudFront and Direct Connect. Excluded from the March 2024 exit-fee waiver — these are the two services AWS explicitly carved out of that offer. CloudFront does, however, have its own pricing structure, which is structurally favorable (see below).

5 concrete levers, ranked by ease of implementation

1. VPC Gateway Endpoints for S3 and DynamoDB — free, enable everywhere

Gateway Endpoints to S3 and DynamoDB are free: no hourly charge, no per-GB charge. Without them, S3 access from a private subnet routes through the NAT Gateway — you pay both NAT processing ($0.045/GB) and potentially egress. This is the best effort-to-gain ratio lever in this article: a few minutes of Terraform, zero risk.

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.eu-west-3.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = [aws_route_table.private.id]
}

2. CloudFront in front of static assets — 1 TB free every month, permanently

CloudFront’s free tier (1 TB of outbound transfer + 10 million HTTP/HTTPS requests per month) is permanent, not capped at 12 months like the rest of the AWS free tier. For an SMB serving static assets, exports, or a moderate-traffic API directly from EC2 or S3, routing that traffic through CloudFront often turns a billable egress line into a $0 one. It’s literally the setup hosting this site: S3 + CloudFront, a few euros a month.

Unlike Gateway Endpoints, Interface Endpoints (PrivateLink) to other AWS services (ECR, Secrets Manager, CloudWatch Logs…) cost $0.01/hour per AZ plus $0.01/GB processed. They only pay off if the NAT Gateway volume avoided ($0.045/GB) exceeds that fixed cost — typically above a few hundred GB/month per endpoint. Audit actual volume before rolling them out everywhere: an underused PrivateLink endpoint costs more than the NAT it replaces.

4. Co-locate chatty resources in the same AZ

For high-throughput internal flows (cache replication, data pipelines, Kafka/EKS clusters), single-AZ placement eliminates cross-AZ cost — at the price of a resilience trade-off. This isn’t a default choice: reserve it for flows whose volume justifies the risk, with a documented failover plan in case that AZ goes down.

5. Compress and use binary formats before egress

Simple and often overlooked: enabling compression (gzip/brotli) on API responses and preferring binary formats (Parquet over CSV/JSON for large exports) directly cuts the billed volume — no architecture changes required.

The 12 January 2027 deadline: what actually changes

The EU Data Act (Regulation 2023/2854) sets a two-stage timeline for cloud providers serving EU customers:

  • Since January 2024: switching fees (including egress charged during a provider switch) must be reduced to a “cost-covering” rate — no margin on top.
  • From 12 January 2027: a total ban on charging switching fees, egress included, for any customer changing provider or repatriating data in-house.

What doesn’t change: operational outbound traffic — the kind serving your users every day, outside of an exit migration — stays billed at standard rates. AWS’s March 2024 offer only applies to full platform exits, requested explicitly through support, and excludes CloudFront and Direct Connect. For an SMB with no migration plan on the horizon, the 2027 deadline won’t shave a cent off the bill — it just de-risks the exit if one becomes necessary someday.

In practice, if multicloud or a future migration is on your roadmap, there are two things worth preparing before January 2027: document precisely the data volume that would need to move (to size the transfer window), and check contractually that your target provider doesn’t have equivalent ingress fees that would cancel out the benefit.

What we check first in an audit

Across the FinOps audits Distribuée has run this year, the priority order is almost always the same: missing S3/DynamoDB Gateway Endpoints (immediate gain, zero risk), unanticipated cross-AZ traffic in a recent microservices architecture, then underused CloudFront for content that could ride the permanent free tier. Combined, these three levers account for 15 to 30% of the data transfer line on the architectures we audit — without touching resilience or performance.

If your network bill looks opaque or has climbed without a clear explanation, that’s exactly the kind of thing covered in a DevSecOps audit: a full map of your data flows, prioritized levers, and hands-on implementation through a retainer if needed.

Found this useful? Share it.

Go further

A topic, a project, a question?

Distribuée supports demanding SMBs on AWS audit, FinOps and security.

Book 15 min