Cloud Data Transfer Costs: NAT, PrivateLink, Interconnect and Egress

A surprising number of cloud bills are dominated not by compute or storage but by bytes that moved: a NAT gateway that processed terabytes of S3 traffic it never needed to see, a chatty microservice mesh that hops availability zones on every call, a replication job crossing regions at three in the morning. These lines are small per gigabyte and enormous in aggregate, and they rarely have an owner.

This matters now because architectures keep getting more distributed. Multi-AZ Kubernetes, managed AI APIs, event streaming, SaaS integrations and cross-cloud analytics all convert design decisions into per-gigabyte meters. Unlike an idle instance, a transfer charge scales with success: the busier the product, the larger the line.

You will leave with a model of the five transfer meters, dated list prices with sources, a worked and clearly illustrative cost model, and a playbook covering gateway endpoints, interface endpoints, zone-aware routing, CDN offload, private interconnect and detection from billing and flow-log data. Managing cloud data transfer costs is mostly a topology problem, not a negotiation problem.

What this covers: the meter taxonomy, AWS, Google Cloud and Azure price points, NAT and PrivateLink economics, Kubernetes zone-aware routing, interconnect versus internet, exit waivers, detection queries, failure modes and a checklist.

Context and Background

Every major provider charges for data leaving its network and for several kinds of movement inside it. Inbound internet traffic is free on the large clouds. What differs is the internal meters: AWS charges for cross-AZ and inter-region movement and for processing through NAT gateways and endpoints; Google Cloud charges inter-zone and inter-region movement and Cloud NAT processing; Azure has its own bandwidth meters whose rules vary by region and zone. The headline “egress fee” is one line in a longer list.

Two forces shaped 2024 to 2026. First, regulatory and competitive pressure produced exit waivers: Google Cloud announced in January 2024 that it would waive transfer fees for customers leaving, AWS followed in March 2024, and Microsoft followed soon after, with the EU Data Act’s switching provisions reinforcing the direction. Second, private connectivity became cheaper per gigabyte than the public internet, which moved interconnect economics from a telecom specialty into mainstream architecture.

Pricing pages are the primary sources for every number below, fetched on 10 November 2026. AWS does not print every rate on the page you would expect, so a few figures come from a secondary price tracker that states it was verified in September 2026; those are flagged. Rates vary by region and change over time, so treat each dollar figure as a dated list price to re-verify, never as a quote.

For adjacent depth, our post on AWS VPC networking with Transit Gateway, PrivateLink and VPC peering covers the connectivity topologies themselves, and the CDN architecture guide on edge caching and origin shield covers offload mechanics. This post takes the cost-accounting angle: which meter fires for which path, and what to change.

The AWS-side reference is the AWS architecture blog overview of data transfer costs for common architectures, which names the meters but points to service pages for rates.

The Five-Meter Model of Cloud Data Transfer Costs

Cloud data transfer costs come from five distinct meters: internet egress, inter-region transfer, cross-AZ transfer, managed-path processing (NAT gateways, load balancers, transit gateways) and private-link fees. Each fires on a different path, carries a different price, and has a different fix. Classify every flow by meter before optimizing anything.

Figure 1: The five transfer meters and the network paths that trigger them in a typical multi-AZ VPC.

The diagram shows a workload VPC spread over three zones. Workloads in private subnets reach three kinds of destination: provider services such as S3, third-party SaaS and the internet, and other zones or regions inside the provider network. Each arrow crosses a different billable boundary, and the cheapest path is almost never the default one.

Meter 1: Internet egress

Internet egress is the best-known meter and, per gigabyte, the most expensive. AWS lists a free allowance of 100 GB per month aggregated across services and regions, then tiered pricing. The price tracker egresscost.com (verified 2026-09, not an AWS page) shows about $0.09 per GB for the first 10 TB after the free allowance, $0.085 for the next 40 TB, $0.07 for the next 100 TB and $0.05 above 150 TB. The AWS EC2 pricing page describes tiers but does not print per-GB rates, so confirm in the pricing calculator.

Google Cloud publishes Premium Tier internet egress to North America at $0.12 per GiB for the first TiB of the month, $0.11 up to 10 TiB and $0.08 beyond, with the first GiB free. Standard Tier gives 200 GiB free per month. Google’s page warns that some Premium Tier SKUs changed on 1 February 2024.

The design consequence: pay egress once, at the edge, for bytes that cannot be cached. Anything cacheable belongs behind a CDN. I do not quote CloudFront or Cloud CDN delivery rates because I could not verify them on official pages; check them before modelling. AWS does document a standing 1 TB per month free allowance from CloudFront.

Meter 2: Inter-region transfer

Moving data between regions is billed per GB at a rate that depends on source and destination. Google Cloud lists North America to North America at $0.02 per GiB. The tracker puts AWS us-east-1 to most regions at $0.02 per GB and to us-east-2 at $0.01, with a $0.01 to $0.02 range across corridors. AWS says only that the rate depends on the regions.

Inter-region punishes careless disaster-recovery and analytics designs. Replicating a 50 TB dataset once costs roughly $1,000 at $0.02 per GB, but continuous replication of a high-churn dataset can cost that every few days. Change-only replication, compression, and replicating the smaller derived dataset rather than the raw one are the standard levers.

Meter 3: Cross-AZ transfer

Cross-AZ traffic inside a region is where most surprises live, because it is invisible in architecture diagrams. AWS VPC pricing states that for VPC peering, same-region traffic crossing an AZ is $0.01 per GB in both directions, and the tracker reports the same $0.01 each-way rate generally. A gigabyte that crosses a zone boundary therefore costs about $0.02 in total, split between sender and receiver lines. Same-AZ traffic over private IPs is free.

Google Cloud charges $0.01 per GiB for different-zone traffic in the same region within a VPC and nothing for same-zone internal traffic. For Azure I could not verify current inter-zone pricing from an official page, so check the Azure bandwidth pricing page for your region before assuming either way.

High-fanout internal protocols are the expensive ones: service meshes, Kafka replication, distributed databases and shuffle-heavy analytics. This is cross az data transfer as a design property, not a mistake: spreading across zones is how you get availability, and the bill is the price of that choice.

Meter 4: Managed-path processing

This is the meter family most teams mis-attribute. A NAT gateway charges an hourly fee plus a per-GB processing fee on everything passing through it, regardless of source or destination. The AWS VPC pricing page lists $0.045 per NAT gateway-hour and $0.045 per GB processed (its examples use US East), and states that standard data transfer charges apply on top. That layered charge is the nat gateway cost that surprises people: processing is added to, not instead of, any egress fee. Partial hours bill as full hours.

AWS also offers a regional NAT gateway at $0.045 per hour per AZ with the same per-GB fee. Transit Gateway adds a per-attachment hourly charge plus a per-GB processing charge for data sent into it, and for peered transit gateways charges apply on only one side. Google Cloud NAT lists $0.005 per hour for the IP addresses it uses; the gateway and per-GiB processing rates were not on the page I read, so verify them on the Cloud NAT pricing page.

Meter 5: Private-link fees

PrivateLink and Private Service Connect trade a per-GB fee for security and path control. The AWS PrivateLink pricing page publishes interface endpoint data processing at $0.01 per GB for the first petabyte per month in a region, $0.006 for the next 4 PB and $0.004 beyond. Hourly billing is per endpoint per AZ; the page’s worked example uses $0.01 per hour per endpoint network interface, which is an example rather than a stated regional rate, so confirm before budgeting.

Google Cloud lists Private Service Connect consumer processing at the same $0.01, $0.006 and $0.004 tiers per GiB, with endpoints at $0.01 per hour. Gateway endpoints for S3 and DynamoDB carry no hourly or processing charge; the AWS VPC page says so plainly and recommends them specifically to avoid NAT processing on S3 traffic. That one fact is the highest-return change in most accounts.

A path-selection principle

For any flow, the cheapest compliant path crosses the fewest billable boundaries. For traffic from a private subnet to an AWS service, rank the options: gateway endpoint (free), interface endpoint (roughly a fifth of the NAT processing rate plus a fixed hourly fee), NAT to the public service endpoint, and NAT out to the internet. The ranking depends on volume, because interface endpoint hourly fees are fixed while the per-GB saving scales with traffic.

Figure 2: Decision flow for choosing the cheapest compliant path from a private subnet to a destination.

Read the decision flow top to bottom. Destinations that support gateway endpoints exit first, because they are free. Other AWS services with high volume justify interface endpoints once the processing saving exceeds the hourly fee. Everything left goes through NAT, and that residue is the traffic worth inspecting for further offload.

Walk-Through: NAT Gateways and Endpoints in Practice

NAT gateways are rarely the problem by design; they become the problem by default. A private subnet’s route table sends 0.0.0.0/0 to NAT, so every flow that lacks a more specific route, including S3, DynamoDB, ECR image pulls, CloudWatch Logs, STS and SaaS calls, pays $0.045 per GB. Teams add a NAT gateway for outbound patching and forget it is also the path for their heaviest data flows.

Fix 1: Gateway endpoints for S3 and DynamoDB

A gateway endpoint adds a prefix-list route to the route table, so S3 traffic never touches NAT. There is no hourly or processing charge. The change is almost risk-free for same-region access, and the main gotchas are policy and region: the endpoint only serves the VPC’s own region, and endpoint policies or bucket policies that reference VPC endpoint IDs must be updated. A minimal Terraform sketch:

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

resource "aws_vpc_endpoint" "dynamodb" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.dynamodb"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

Expect the NAT processing line to drop immediately by whatever fraction of NAT traffic was S3. In accounts that run data pipelines or pull large container layers from S3-backed registries, that fraction is often the majority, though I will not claim a typical figure because it varies widely. Measure first, as shown in the detection section below.

Fix 2: Interface endpoints, with the break-even in mind

For services without gateway endpoints (ECR, CloudWatch Logs, STS, Secrets Manager, KMS, SQS and many more), an interface endpoint places an elastic network interface in each subnet you choose. The saving per GB is the NAT rate minus the endpoint rate: $0.045 minus $0.01 is $0.035 at the published tier. The cost is fixed: endpoints times AZs times hours.

Using the example $0.01 per ENI-hour, one endpoint in three AZs costs about $21.90 per month (3 x 730 x $0.01). Break-even against NAT is then 21.90 / 0.035, roughly 626 GB per month per endpoint. Below that, NAT wins on cost, though endpoints may still win on security because traffic stays on the AWS network and can be restricted by endpoint policy. Above it, the endpoint wins on both. This aws privatelink cost calculation is why a blanket “endpoint everything” policy is wasteful: a tiny-volume service should keep using NAT.

Two tricks reduce the fixed side. Deploy the endpoint into only the AZs that host the workload (cross-AZ calls to an endpoint ENI cost $0.02 per GB, which can erase the saving), and share endpoints across VPCs through a central inspection or shared-services VPC only when the cross-VPC hop is itself cheap, which depends on Transit Gateway processing fees.

Fix 3: One NAT per AZ, and keep traffic zonal

A single shared NAT gateway forces workloads in the other two AZs to cross zones to reach it, adding the cross-AZ meter on top of the NAT meter. One NAT gateway per AZ, with each private subnet routing to its own zone’s gateway, removes that hop at the price of two more hourly fees (about $33 each per month at $0.045 per hour over 730 hours). At non-trivial volume the hourly fees are noise against $0.02 per GB of avoided cross-AZ transfer.

Fix 4: Replace NAT where egress is the product

Workloads that legitimately push large volumes to the internet, such as web scrapers, CI artifact uploads or media distribution, pay NAT processing plus egress. Where IPv6 is feasible, an egress-only internet gateway has no per-GB processing fee in the standard AWS model (verify for your configuration), and public subnets with security groups can bypass NAT for fleets that tolerate public IPs. Note that AWS now charges for public IPv4 addresses at about $0.005 per hour per address according to the tracker I used, so removing NAT by assigning public IPs has its own fee; a fleet of 1,000 public IPv4 addresses costs roughly $3,650 per month.

Kubernetes: keeping service traffic in its zone

Kubernetes spreads pods across zones for availability, and by default a Service load-balances across all ready endpoints, so with three zones about two thirds of requests cross a zone boundary. Two mechanisms narrow that. Topology-aware routing uses EndpointSlice hints so the proxy prefers same-zone endpoints; it is enabled per Service with the service.kubernetes.io/topology-mode: Auto annotation. The newer spec.trafficDistribution field expresses a preference such as PreferClose. I could not retrieve the current value list or the version in which each value graduated from the Kubernetes documentation this run, so check the Service page for your cluster version before relying on a specific value.

apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  selector:
    app: orders
  ports:
    - port: 80
      targetPort: 8080
  trafficDistribution: PreferClose   # verify value and version support

The catch is load imbalance. A zone-preferring policy sends traffic to local endpoints even when one zone has far more clients than pods, so autoscaling and topology spread must be zone-aware too. Our guide to topology spread constraints and the scheduler framework covers pod placement, and the comparison of managed Kubernetes on EKS, GKE and AKS covers how each platform meters cross-zone traffic.

Stateful systems need their own treatment. Kafka consumers can fetch from the closest replica (follower fetching, configured through rack awareness), and many databases support zone-local read replicas. Each converts a cross-AZ read stream into a same-AZ one, while writes still replicate across zones by design.

Interconnect, CDN Offload and Exit Waivers

Once internal paths are tight, the remaining meters are internet egress and hybrid connectivity. Both are about replacing a high per-GB public path with a cheaper or cached one.

Private interconnect versus the internet

Dedicated connectivity (AWS Direct Connect, Google Cloud Interconnect, Azure ExpressRoute) charges a port fee and a per-GB egress rate that is below internet rates. AWS states that inbound Direct Connect transfer is $0.00 per GB in all locations; outbound depends on source region and Direct Connect location, plus an hourly port fee, and I did not verify specific outbound or port rates. Google Cloud publishes Interconnect egress at $0.02 per GiB for US and Canada connections to US and Canada regions, $0.02 for Europe, $0.042 for Asia (excluding a few countries), $0.042 for Australia, $0.045 for India and $0.11 for South America, with inbound free.

Compared with Premium Tier internet egress at $0.08 to $0.12 per GiB, the Interconnect rate is a fraction, which creates a break-even: monthly port and circuit costs divided by the per-GB difference. Using the published Google figures, each GiB moved over Interconnect rather than the public internet saves roughly $0.06 to $0.10 before port fees. If your port-plus-circuit bill is, illustratively, $2,000 per month, break-even lies somewhere around 20 to 33 TiB per month. Below that, a VPN or the public internet is cheaper; above it, the dedicated path wins and also gives predictable latency. Our primer on BGP for cloud engineers, covering Direct Connect and ExpressRoute routing explains the routing side.

CDN offload

A CDN reduces egress in two ways: cache hits never reach the origin, and delivery from the edge is priced separately from instance egress. The origin shield pattern collapses many edge misses into one fetch. Cacheable fraction is the whole game, so measure the cache hit ratio by bytes, not requests, because a few large objects dominate transfer. Treat any offload percentage as an assumption to measure rather than a given.

Large-object workloads (software updates, video segments, ML model artifacts) benefit most. API responses that are personalised or short-lived benefit least, though even there TLS termination and connection reuse at the edge can reduce origin cost. The surest way to lose the benefit is cache keys polluted by query strings or cookies, which fragment the cache and push the hit ratio toward zero.

Exit waivers and multi-cloud transfer

If you are leaving a provider, check the waiver rather than paying list rates. AWS’s published policy waives internet data transfer out for customers moving off AWS, through a request to AWS Support that results in credits for the migrated data. Outside the EU the move has a 180-day window, eligible accounts must be in good standing and be the paying account, and EU and UK customers follow separate addenda. Repeated requests from the same account get extra scrutiny. Google Cloud and Microsoft announced comparable programs in early 2024; I cite those from news coverage rather than official terms, so verify the current terms with each provider. These waivers cover leaving, not ongoing multi-cloud operation, and an architecture that continuously moves data between clouds still pays the normal meters.

Worked Example: An Illustrative Cost Model

The numbers below are illustrative, built from the dated list prices above, and are not measurements of a real account. The scenario is a three-AZ Kubernetes platform in us-east-1 with per-month volumes of 40 TB through NAT (30 TB to S3, 4 TB to AWS APIs such as ECR and CloudWatch, 6 TB to SaaS and internet), 60 TB of cross-AZ service traffic, and 10 TB of inter-region replication. For arithmetic simplicity 1 TB equals 1,000 GB. Rates used: NAT $0.045 per hour and per GB, cross-AZ $0.02 per GB round (both directions), inter-region $0.02 per GB, interface endpoint processing $0.01 per GB and $0.01 per ENI-hour.

Figure 3: Illustrative cost model showing where each optimization removes spend from the monthly data transfer bill.

Line item	Baseline	Optimized	Change applied
NAT processing	$1,800.00	$270.00	S3 gateway endpoint; 4 TB to interface endpoints; 6 TB remains
NAT hourly, 3 gateways	$98.55	$98.55	Unchanged, one per AZ
Interface endpoint hourly	$0	$109.50	5 endpoints x 3 AZ x 730 h x $0.01
Interface endpoint processing	$0	$40.00	4 TB x $0.01
Cross-AZ service traffic	$1,200.00	$360.00	70% kept in-zone via zone-aware routing
Inter-region replication	$200.00	$200.00	Unchanged
Total	$3,298.55	$1,078.05	Saving $2,220.50, about 67%

Two assumptions carry most of the weight: that 30 TB of the NAT traffic is S3, and that zone-aware routing keeps 70 percent of cross-AZ traffic local. Both must be measured in your own environment. The 70 percent figure in particular is a plausible target for read-heavy request paths and unrealistic for replication traffic that must cross zones.

Internet egress is deliberately excluded. With 20 TB per month at the tracker’s tiers, direct egress would be about $1,741 (9,900 GB at $0.09 plus 10,000 GB at $0.085), and CDN offload changes that by a cache-hit fraction and a delivery rate I could not verify, so model it separately with your own hit ratio. The structural lesson is independent of the exact numbers: the two biggest levers here cost almost nothing to implement, and the endpoint change has a positive return only above its break-even volume.

Detection: Finding the Meters in Billing and Flow Data

You cannot optimize what you cannot attribute. Billing data tells you which meter is large, flow logs tell you which flows cause it, and Kubernetes cost tooling tells you which workload owns the flow. The three layers join on resource identifiers.

Figure 4: Detection pipeline that joins billing line items, flow logs and workload metadata to attribute transfer cost to owners.

The pipeline starts with the billing export (the AWS Cost and Usage Report, or a FOCUS-normalised dataset), which carries a usage type per line. Transfer-related usage types are identifiable by name: NAT gateway bytes, regional and inter-region bytes, data transfer out, and endpoint bytes. Flow logs supply source, destination, bytes and the interface that carried them. The join key is the network interface or NAT gateway ID, which both datasets expose.

Step 1: Rank transfer usage types

In Athena over a CUR table, group transfer-related lines by usage type and resource. The column names below follow the standard CUR schema; adjust them to your table.

SELECT line_item_usage_type,
       line_item_resource_id,
       SUM(line_item_usage_amount)        AS gb,
       SUM(line_item_unblended_cost)      AS cost_usd
FROM   cur_table
WHERE  line_item_usage_start_date >= date_add('day', -30, current_date)
  AND (line_item_usage_type LIKE '%NatGateway-Bytes%'
    OR line_item_usage_type LIKE '%DataTransfer-Regional-Bytes%'
    OR line_item_usage_type LIKE '%DataTransfer-Out-Bytes%'
    OR line_item_usage_type LIKE '%VpcEndpoint-Bytes%')
GROUP  BY 1, 2
ORDER  BY cost_usd DESC
LIMIT  25;

The top rows usually identify one or two NAT gateways and one regional-bytes line responsible for most of the transfer spend. The regional-bytes usage type is the cross-AZ and inter-VPC meter, and the NAT bytes type is the processing meter. This is also where an anomaly detector should watch; see our post on cloud cost anomaly detection over billing data for seasonality-aware alerting, and the FOCUS billing normalization pipeline for comparing the same meters across clouds.

Step 2: Attribute NAT bytes to destinations

Enable VPC flow logs on the NAT gateway’s network interface (or on the subnets), with the fields that matter for attribution: source and destination address, bytes, and the packet destination. Then sum bytes by destination and map destinations to services. S3 and other AWS service ranges are published by AWS in its IP range file, which lets you classify a flow as “S3 in this region” and so a gateway endpoint candidate.

SELECT dstaddr,
       SUM(bytes)/1e9 AS gb
FROM   vpc_flow_logs
WHERE  interface_id = 'eni-NATGATEWAY0000'   -- NAT gateway ENI
  AND  flow_direction = 'egress'
  AND  day >= date_format(date_add('day', -7, current_date), '%Y/%m/%d')
GROUP  BY dstaddr
ORDER  BY gb DESC
LIMIT  50;

Resolve the top destinations against AWS published ranges and reverse DNS. In most investigations a handful of addresses account for the majority of bytes, and they are typically S3, ECR, a package mirror, or one SaaS vendor. That list is your offload backlog, ordered by money.

Step 3: Attribute cross-AZ bytes to workloads

Billing cannot tell you which service generates cross-AZ bytes. Flow logs can, if you tag the zone of each endpoint. Kubernetes cost tooling closes the loop at the workload level: the post on OpenCost for Kubernetes cost allocation and showback covers allocation, and network cost allocation features in such tools can separate in-zone, cross-zone and internet traffic per pod. Whichever tool you use, validate its output against the billing total: allocated network cost should reconcile with the regional-bytes line within a few percent, and a large gap means unlabelled traffic.

Step 4: Make it a guardrail

Detection should become policy. Useful guardrails include a budget alert on the NAT bytes usage type, a monthly report of the top-10 NAT destinations, a CI check that rejects Terraform which creates a private route table without S3 and DynamoDB gateway endpoints, and a design-review question: which zone does this call land in? Charging transfer cost back to the owning team, even as showback, changes behaviour faster than any technical control, because it gives the line an owner.

Trade-offs, Gotchas, and What Goes Wrong

Every optimization above has a failure mode, and several are expensive precisely because they look like free wins.

Endpoint sprawl. Creating interface endpoints for twenty services in three AZs costs on the order of $440 per month in hourly fees at the example $0.01 rate (20 x 3 x 730 x $0.01 = $438), before any traffic. If most carry little volume you pay more than NAT would have cost. Endpoint only where volume or security policy justifies it.

Zone-local routing imbalance. Preferring same-zone endpoints concentrates load. If one zone holds most clients, its pods saturate while others idle, and latency worsens. Pair routing preferences with zone-aware autoscaling and spread constraints, and watch per-zone saturation after rollout.

Reduced availability if misconfigured. Strict node-local policies (internalTrafficPolicy: Local) drop traffic when no local endpoint exists. Preference-style policies fall back; strict ones do not. Know which one you enabled.

Cross-region endpoint access. Interface endpoints reached across regions add PrivateLink processing and hourly fees on top of inter-region transfer rates, according to the AWS page. A “private” path is not automatically a cheap path.

Interconnect lock-in and under-utilisation. Dedicated circuits are annual-scale commitments. If traffic falls below break-even, you pay a fixed cost for a path that the internet would have served for less. Size on measured steady-state volume, not forecast peaks.

Cache-hit fantasies. Offload models assume a hit ratio that cache-key design may never deliver. A CDN configured with per-user cookies in the key behaves like an expensive proxy.

Measurement drift. Prices, regions and free allowances change. A model built from a 2026 page is stale by the next repricing, which is why the model belongs in code with dated constants rather than in a slide.

Security versus cost. Sometimes the expensive path is correct. Routing egress through a central inspection VPC costs Transit Gateway and NAT processing on every byte, but it enforces policy. The goal is to make the trade-off explicit and priced, not to eliminate it.

Practical Recommendations

Start with measurement, because the top three lines usually explain most of the bill. Then act in order of effort-to-return: free changes first, fixed-cost changes only where volume clears break-even, and architecture changes last.

First, put gateway endpoints for S3 and DynamoDB in every VPC that has private subnets. They have no hourly or processing charge, and the only work is policy review. Second, rank NAT destinations from flow logs and place interface endpoints only for services above roughly 600 GB per month per endpoint under the example rates, recomputing the break-even with your own numbers. Third, run one NAT gateway per AZ and keep subnets routing to their local gateway.

Fourth, enable zone-aware service routing for read-heavy, latency-sensitive internal services after confirming zone-balanced replicas and autoscaling, and use follower fetching or zone-local replicas for streaming and databases. Fifth, put cacheable bytes behind a CDN and measure the hit ratio by bytes. Sixth, evaluate dedicated interconnect only when steady-state hybrid or egress volume clears the break-even by a comfortable margin.

[ ] Rank the last 30 days of transfer usage types by cost and assign an owner to each.
[ ] Add S3 and DynamoDB gateway endpoints to all private route tables.
[ ] Rank NAT destinations from flow logs; offload the top five.
[ ] Compute per-endpoint break-even before adding any interface endpoint.
[ ] One NAT gateway per AZ, with zonal routing.
[ ] Enable and validate zone-aware routing for chatty internal services.
[ ] Track CDN hit ratio by bytes and fix cache keys.
[ ] Alert on transfer usage types; show cost back to owning teams.
[ ] Re-verify every price constant quarterly against official pages.

Frequently Asked Questions

Why is my NAT gateway bill larger than my EC2 bill?

A NAT gateway charges $0.045 per GB processed (US East example on the AWS VPC page) on every byte that passes through it, plus an hourly fee, and standard transfer charges apply on top. High-volume flows such as S3 reads, container image pulls and log shipping can therefore cost more in NAT processing than the instances generating them. A gateway endpoint for S3 removes that portion at no charge.

Is cross-AZ traffic really charged in both directions on AWS?

AWS documents $0.01 per GB in each direction for same-region cross-AZ traffic over VPC peering, and the price tracker I used reports the same rate generally, so a gigabyte that crosses a zone costs about $0.02 in total. Same-AZ traffic over private addresses is free. Confirm the rate for your region and traffic type on the AWS pricing pages, since the EC2 page does not print it.

When is a PrivateLink interface endpoint cheaper than NAT?

When monthly volume exceeds the fixed hourly cost divided by the per-GB saving. At $0.045 NAT processing versus $0.01 endpoint processing, the saving is $0.035 per GB. With the example $0.01 per ENI-hour across three AZs (about $21.90 per month), break-even is near 626 GB per month per endpoint. Below that, NAT is cheaper, though endpoints may still be justified for security.

Do gateway endpoints really cost nothing?

For S3 and DynamoDB, the AWS VPC pricing page states there are no data processing or hourly charges for gateway endpoints, and recommends them to avoid NAT processing for S3 traffic. They serve same-region access from your VPC, and you may still pay normal S3 request and storage charges. Cross-region S3 access does not benefit and incurs inter-region transfer.

Can I get free egress when leaving a cloud provider?

AWS waives internet data transfer out for customers who move off AWS, via a request to AWS Support that yields credits; non-EU customers have 180 days, and eligible accounts must be in good standing and be the payer. EU and UK customers follow separate addenda. Google Cloud and Microsoft announced similar programs in 2024; check their current official terms, since I verified AWS only.

How do I stop Kubernetes traffic from crossing zones?

Use topology-aware routing (the service.kubernetes.io/topology-mode: Auto annotation) or the Service trafficDistribution field with a preference such as PreferClose, and confirm the supported values for your Kubernetes version in the documentation. Ensure each zone has enough replicas and autoscaling, because zone preference can overload a small zone. Use follower fetching for Kafka and zone-local replicas for databases.

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories