Five architectural rules to cut your AWS networking bill

Published September 2, 2026

When engineering teams budget for AWS, they usually start with compute: count the vCPUs and gigabytes of RAM, multiply by hourly on-demand rates, and apply Savings Plans.

Networking rarely receives the same scrutiny. Yet in production environments, network charges routinely become the second or third largest category on the bill. The reason is structural: AWS charges for idle infrastructure (NAT Gateways, load balancers, public IPv4 addresses) and then charges again when data actually flows (data processing fees, inter-AZ transfer, and internet egress).

A standard three-AZ VPC running redundant managed NAT Gateways, public load balancers, and distributed services will incur over $150 a month before processing meaningful user traffic. As traffic scales, unoptimized routing between internal services and AWS APIs can inflate that number into thousands.

Here are five architectural rules to eliminate network waste while preserving resilience.

1. Deploy S3 and DynamoDB Gateway Endpoints on day one

The most common and expensive networking mistake in AWS is paying NAT Gateway processing fees on traffic destined for AWS’s own storage services.

By default, subnets configured with a default route (0.0.0.0/0) pointing to a NAT Gateway will send all external traffic through that gateway. Because Amazon S3 and Amazon DynamoDB use public IP ranges, requests from private EC2 instances or container tasks travel through the NAT Gateway.

AWS charges $0.045 per gigabyte for NAT data processing. However, data transfer between EC2 and S3 within the same region is $0.00 per gigabyte.

Default Private Subnet Routing (The Tax):
[ EC2 / EKS Pod ] --- (Private Subnet) ---> [ NAT Gateway: $0.045/GB ] ---> [ S3 Endpoint ]
Total Fee: $0.045/GB ($45 per TB)

With Gateway VPC Endpoint:
[ EC2 / EKS Pod ] --- (Route Table Prefix List) ---> [ S3 Gateway Endpoint: $0.00 ]
Total Fee: $0.00/GB (Free)

If a night batch job or backup process writes 10 TB of database snapshots to an S3 bucket in the same region, routing through a NAT Gateway costs $450 in data processing fees for traffic that AWS would otherwise carry for free.

The Fix

Create a Gateway VPC Endpoint for both com.amazonaws.[region].s3 and com.amazonaws.[region].dynamodb.

Gateway endpoints do not use Elastic Network Interfaces (ENIs). They add prefix list routes directly to your VPC route tables. They carry zero hourly cost and zero data processing fees.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-0123456789abcdef0

2. Stop running Multi-AZ NAT Gateways in non-production

AWS Well-Architected whitepapers correctly recommend placing one NAT Gateway in each Availability Zone for production high availability. If an availability zone suffers an outage, subnets in other zones retain independent internet egress.

Applying this pattern uncritically to development, testing, and staging environments is pure waste.

According to our AWS networking dataset, a single NAT Gateway in us-east-1 costs:

• Provisioned hourly fee: $0.045/hr × 730 hrs = $32.85/month
• Public IPv4 address: $0.005/hr × 730 hrs = $3.65/month
• Total standby cost per gateway: $36.50/month

Running three NAT Gateways across three AZs costs $109.50/month in standby fees alone. If an engineering organization maintains separate VPCs for development, QA, and staging, they spend over $325 a month before a single byte of test traffic passes through.

3-AZ Production VPC:
  AZ-a: NAT Gateway ($36.50/mo)  <-- Necessary redundancy
  AZ-b: NAT Gateway ($36.50/mo)
  AZ-c: NAT Gateway ($36.50/mo)
  Total: $109.50/month

3-AZ Dev/Staging VPC (Unoptimized):
  AZ-a: NAT Gateway ($36.50/mo)  <-- Unnecessary standby cost
  AZ-b: NAT Gateway ($36.50/mo)
  AZ-c: NAT Gateway ($36.50/mo)
  Total: $109.50/month

Optimized Dev/Staging VPC (Single Gateway or fck-nat):
  All private subnets route to AZ-a NAT Gateway ($36.50/mo)
  OR
  All private subnets route to t4g.nano fck-nat instance (~$3.50/mo)
  Savings: $73.00 to $106.00/month per VPC

The Fix

For non-production VPCs, choose one of two patterns:

1. Single shared NAT Gateway: Route all private subnets across AZs to a single NAT Gateway in AZ-a. You pay $36.50/month instead of $109.50. You will incur standard cross-AZ data transfer ($0.01/GB) for instances in AZ-b and AZ-c, but in low-traffic test environments, this amounts to pennies.
2. NAT Instance with fck-nat: Deploy a community-maintained fck-nat AMI on a t4g.nano Graviton instance. It handles up to 5 Gbps of burst throughput and costs roughly $3.50/month, eliminating the $0.045/GB data processing fee.

3. Enforce topology-aware routing in Kubernetes and microservices

In a multi-AZ deployment, traffic within the same Availability Zone using private IPs is completely free ($0.00/GB).

However, as soon as packets cross an Availability Zone boundary inside the same region, AWS charges $0.01/GB for data out of the source AZ and $0.01/GB for data in to the destination AZ. That equals a $0.02 per gigabyte round-trip tax ($20 per TB).

Same-AZ Call:
[ Pod A (us-east-1a) ] -------- (Free: $0.00/GB) --------> [ Pod B (us-east-1a) ]

Cross-AZ Call:
[ Pod A (us-east-1a) ] -- $0.01/GB out --> [ AZ Boundary ] -- $0.01/GB in --> [ Pod B (us-east-1b) ]
Total: $0.02/GB round-trip ($20 per TB)

In microservice architectures or Kubernetes clusters with default round-robin service routing, traffic is distributed randomly across pods. In a 3-AZ cluster, roughly 67% of all service-to-service requests cross an AZ boundary.

For a platform where internal services exchange 50 TB of data monthly between API gateways, caches, message queues, and backend workers, cross-AZ data transfer adds $1,000 every month to the AWS bill without generating any external value.

The Fix

1. Enable Topology-Aware Hints in Kubernetes: Add the following annotation to your Kubernetes Service definitions:

   apiVersion: v1
   kind: Service
   metadata:
     name: backend-api
     annotations:
       service.kubernetes.io/topology-mode: Auto
   spec:
     ...

   This instructs kube-proxy to route requests to endpoints in the same zone whenever sufficient capacity exists, falling back to other zones only during imbalance or failover.
2. Co-locate primary databases with heavy write workloads: Ensure write-heavy application pods run in the same AZ as your primary RDS or Aurora instance, leaving cross-AZ replication solely to the database engine’s replication stream.

4. Audit public IPv4 address allocations

Effective February 1, 2024, AWS introduced a charge of $0.005 per hour ($3.65 per month) for every public IPv4 address attached to an AWS resource.

Prior to this change, public IPv4 addresses assigned to running EC2 instances were free, and only unattached Elastic IPs incurred idle penalties. Under the current pricing model, every public IPv4 address incurs charges:

• Every managed NAT Gateway uses one public IPv4: $3.65/month
• An internet-facing Application Load Balancer spanning 3 AZs uses three public IPs: $10.95/month
• Fifty dev/test EC2 instances with auto-assigned public IPs: $182.50/month
• Unattached Elastic IPs left behind after resource deletion: $3.65/month each

The Fix

Run an inventory check across all regions using the AWS CLI or Amazon VPC IP Address Manager (IPAM):

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' \
  --output table

Release any unassociated Elastic IPs immediately.

For compute workloads:

• Disable MapPublicIpOnLaunch on subnets containing application servers or workers. Instances should live in private subnets and access external APIs via a shared egress gateway or VPC endpoint.
• For internal tools and admin dashboards, use AWS Systems Manager Session Manager or private VPNs rather than exposing public IPs on individual instances.
• If communicating between modern microservices, adopt dual-stack IPv6 subnets. Egress-Only Internet Gateways for IPv6 are entirely free.

5. Shield public internet egress with CloudFront

Standard internet data transfer out (DTO) from Amazon EC2 is expensive. In us-east-1 and us-west-2, rates follow a tiered schedule:

• First 100 GB/month: Free
• Next 9.9 TB/month: $0.090 per GB
• Next 40 TB/month: $0.085 per GB
• Next 100 TB/month: $0.070 per GB

Sending 5 TB of public traffic directly from EC2 instances costs roughly $441 every month.

Direct EC2 Egress:
[ EC2 Instance ] ---> [ Internet Gateway ] ---> (Public Internet)
Rate: $0.090/GB (after first 100 GB)

CloudFront Egress:
[ EC2 / S3 Origin ] --- ($0.00/GB origin transfer) ---> [ CloudFront Edge ] ---> (Public Internet)
Rate: First 1 TB Free, then $0.085/GB

The Fix

Place Amazon CloudFront in front of internet-facing APIs, web applications, and S3 media buckets.

1. Origin data transfer to CloudFront is free: Moving bytes from EC2 or S3 to CloudFront edge locations costs $0.00/GB.
2. CloudFront includes an ongoing Free Tier: You receive 1 TB per month of free data transfer out and 10,000,000 HTTP/HTTPS requests every month.
3. Cheaper base rates: Beyond the free tier, CloudFront’s starting egress rate is $0.085/GB compared to EC2’s $0.090/GB, with steeper discounts at higher tiers.

Even for dynamic APIs where response caching is minimal, routing through CloudFront eliminates the first 1 TB of egress charges entirely and terminates TLS closer to your end users.

Summary of optimization rules

To model combined NAT Gateway hours, load balancer capacity units, and regional egress rates for your specific architecture, use our interactive AWS Networking Pricing Calculator.