Cloud Networking Costs: Save 50%+

Introduction: The Invisible Cost Center That's Draining Your Cloud Budget

Ask any engineering team where their cloud money goes, and they'll rattle off compute, storage, and maybe databases. Ask them about networking costs? You'll get blank stares. Yet data transfer and networking charges routinely account for 10–20% of total cloud spend — and in data-intensive architectures, that figure can climb to 30% or higher. It's the line item nobody budgets for properly, and honestly, it's the one that delivers the nastiest billing surprises.

Here's what makes networking costs uniquely treacherous: they're diffuse, hard to attribute, and deeply entangled with your architecture. A single misconfigured route table can funnel terabytes of internal traffic through a NAT gateway at $0.045 per GB. A microservices architecture that spans availability zones racks up cross-AZ charges on every single service-to-service call. An application that pulls container images through a NAT gateway instead of a VPC endpoint quietly burns hundreds of dollars a month — and nobody notices.

The scale of this problem is growing fast. With public cloud spending projected to surpass $1 trillion in 2026, networking costs are scaling in lockstep — often faster than compute, because modern architectures generate more east-west traffic between services than ever before. The explosion of microservices, multi-region deployments, and hybrid cloud setups means data is constantly in motion, and every byte in transit has a price tag.

This guide breaks down every major cloud networking cost lever across AWS, Azure, and GCP. We'll cover NAT gateway optimization, VPC endpoints, cross-AZ and cross-region transfer strategies, CDN economics, egress reduction techniques, and the monitoring infrastructure you need to keep these costs visible. Whether you're running a handful of EC2 instances or orchestrating a multi-region Kubernetes fleet, these strategies can realistically cut your networking bill by 50% or more.

Anatomy of Cloud Networking Costs: Understanding Your Bill

The Five Cost Components

Cloud networking costs are notoriously opaque because they're spread across multiple billing line items. To optimize effectively, you need to understand the five distinct cost components that show up on your cloud bill:

Internet egress (data transfer out): The most visible networking cost. Charges apply when data leaves a cloud provider's network to the public internet. AWS, Azure, and GCP all charge $0.085–$0.09 per GB for standard internet egress, with volume discounts kicking in above 10 TB/month. AWS now offers 100 GB/month free (up from 1 GB), while Azure provides 5 GB and GCP offers 1 GB free.
Cross-AZ data transfer: This is the sneaky one. Every time data moves between availability zones within the same region, you pay $0.01–$0.02 per GB — in both directions. That's $0.02 per GB round-trip. For a microservices architecture with dozens of services calling each other across AZs, this adds up with alarming speed.
Cross-region data transfer: Moving data between regions costs $0.02–$0.09 per GB depending on the source and destination regions. Replicating databases, syncing data lakes, or serving users from multiple regions all incur these charges.
NAT gateway processing: On AWS, NAT gateways charge $0.045 per GB of data processed plus $0.045 per hour (~$32.40/month just for the gateway to exist). Every byte of outbound traffic from private subnets passes through this toll booth.
Load balancer and managed service fees: Application Load Balancers, Network Load Balancers, and similar services charge hourly fees plus per-GB or per-connection processing fees that are effectively networking costs hidden under different categories.

Why Networking Costs Scale Non-Linearly

Here's the thing that catches teams off guard: networking costs don't scale linearly with your application growth. They scale with your architecture's communication patterns, which often grow quadratically. Add one more microservice and it potentially talks to every existing service. Deploy to a second AZ for redundancy and you've just doubled your cross-AZ transfer. Set up a disaster recovery region and you've added continuous replication costs.

I've seen this play out firsthand — a team added three new microservices and their cross-AZ bill jumped by 40%, way more than anyone expected.

A typical three-tier web application with 10 microservices, deployed across 3 AZs in 2 regions, can easily generate 5–10 TB/month of internal data transfer before a single user request hits the internet. At $0.01–$0.02 per GB, that's $50–$200/month just in cross-AZ fees — and that's a modest deployment.

Strategy 1: Eliminating NAT Gateway Waste

The NAT Gateway Tax

NAT gateways are one of the single largest networking cost drivers on AWS. They're the default mechanism for allowing resources in private subnets to reach the internet or AWS services, and they charge for every byte that flows through them. For a busy workload processing 10 TB/month through a NAT gateway, you're looking at $450/month in data processing charges alone — on top of the hourly gateway fee and standard data transfer charges.

The worst part? A huge percentage of traffic flowing through NAT gateways doesn't need to. Much of it is destined for AWS services like S3, DynamoDB, ECR, CloudWatch, and STS — services that support VPC endpoints, which bypass the NAT gateway entirely.

VPC Endpoints: The Free Alternative (Almost)

AWS offers two types of VPC endpoints that can dramatically reduce NAT gateway costs:

Gateway Endpoints (S3 and DynamoDB): These are completely free — no hourly charge, no per-GB charge. Traffic to S3 and DynamoDB routes through the gateway endpoint instead of the NAT gateway, eliminating the $0.045/GB processing fee. Given that S3 access is often the single largest source of NAT gateway traffic, this one change can reduce NAT gateway costs by 40–60%.

Interface Endpoints (most other AWS services): These cost $0.01 per hour per AZ (~$7.30/month) plus $0.01 per GB of data processed. Compare that to NAT gateway pricing of $0.045/GB and you're looking at a 78% per-GB savings. Interface endpoints are available for services including ECR, CloudWatch, SQS, SNS, Secrets Manager, KMS, and dozens more.

Here's a concrete example. Say you're pulling container images from ECR through a NAT gateway for a Kubernetes cluster that deploys frequently. If you're pulling 500 GB of container images per month:

# NAT Gateway cost for ECR pulls:
# 500 GB × $0.045/GB = $22.50/month in NAT processing
# Plus standard data transfer charges

# VPC Interface Endpoint cost for ECR:
# $7.30/month (hourly fee) + 500 GB × $0.01/GB = $12.30/month
# Savings: $10.20/month (45% reduction)

# But wait — for S3 (where layers are actually stored), use a Gateway Endpoint:
# Cost: $0.00
# Full savings vs NAT for S3 traffic: 100%

Setting Up VPC Endpoints for Maximum Savings

So, let's get practical. Here's how to deploy the most impactful VPC endpoints using Terraform:

# Gateway Endpoint for S3 — completely free
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_a.id,
    aws_route_table.private_b.id,
    aws_route_table.private_c.id,
  ]

  tags = {
    Name        = "s3-gateway-endpoint"
    CostCenter  = "networking"
    Purpose     = "nat-gateway-cost-reduction"
  }
}

# Gateway Endpoint for DynamoDB — also free
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_a.id,
    aws_route_table.private_b.id,
    aws_route_table.private_c.id,
  ]

  tags = {
    Name = "dynamodb-gateway-endpoint"
  }
}

# Interface Endpoint for ECR (API)
resource "aws_vpc_endpoint" "ecr_api" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${var.region}.ecr.api"
  vpc_endpoint_type   = "Interface"
  private_dns_enabled = true

  subnet_ids = [
    aws_subnet.private_a.id,
    aws_subnet.private_b.id,
  ]

  security_group_ids = [aws_security_group.vpc_endpoints.id]

  tags = {
    Name = "ecr-api-endpoint"
  }
}

# Interface Endpoint for ECR (Docker)
resource "aws_vpc_endpoint" "ecr_dkr" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${var.region}.ecr.dkr"
  vpc_endpoint_type   = "Interface"
  private_dns_enabled = true

  subnet_ids = [
    aws_subnet.private_a.id,
    aws_subnet.private_b.id,
  ]

  security_group_ids = [aws_security_group.vpc_endpoints.id]

  tags = {
    Name = "ecr-dkr-endpoint"
  }
}

# Interface Endpoint for CloudWatch Logs
resource "aws_vpc_endpoint" "cloudwatch_logs" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.${var.region}.logs"
  vpc_endpoint_type   = "Interface"
  private_dns_enabled = true

  subnet_ids = [
    aws_subnet.private_a.id,
    aws_subnet.private_b.id,
  ]

  security_group_ids = [aws_security_group.vpc_endpoints.id]

  tags = {
    Name = "cloudwatch-logs-endpoint"
  }
}

Pro tip: Only provision interface endpoints in AZs where your workloads actually run. Each endpoint incurs hourly charges per AZ, so deploying to all three AZs when your workloads only use two wastes $7.30/month per unnecessary endpoint. It sounds small, but across 10–15 endpoints, that's $75–$110/month for nothing.

Azure and GCP Equivalents

Azure uses Private Endpoints and Service Endpoints to achieve the same result. Service Endpoints are free and route traffic to Azure services over the Microsoft backbone network, avoiding internet egress. Private Endpoints create a private IP address in your VNet for the target service, with pricing at approximately $0.01 per hour per endpoint.

GCP offers Private Google Access, which allows VM instances without external IP addresses to reach Google APIs and services. It's enabled at the subnet level at no additional cost — making it honestly the simplest and most cost-effective approach of the three providers.

Strategy 2: Minimizing Cross-AZ Data Transfer

The Hidden $0.02/GB Round-Trip Tax

Cross-AZ data transfer is the most insidious networking cost because it's almost invisible. Every time Service A in AZ-1 calls Service B in AZ-2, you pay $0.01/GB in each direction — $0.02/GB round-trip. For a chatty microservices architecture, this can easily reach hundreds or thousands of dollars per month.

Consider a typical scenario: a Kubernetes cluster with 20 pods distributed across 3 AZs, where each pod handles 1,000 requests/second with an average payload of 5 KB. If only 33% of requests stay within the same AZ (random distribution), the math gets ugly fast:

# Cross-AZ traffic calculation
# 20 pods × 1,000 req/s × 5 KB/req = 100 MB/s total traffic
# 67% crosses AZ boundaries = 67 MB/s cross-AZ
# 67 MB/s × 86,400 s/day × 30 days = ~174 TB/month cross-AZ
# 174 TB × $0.02/GB (round-trip) = $3,480/month

# That is $41,760/year in cross-AZ transfer alone!

Yeah, that number is not a typo.

Topology-Aware Routing

The most effective strategy for reducing cross-AZ costs is topology-aware routing — ensuring that service-to-service traffic stays within the same AZ whenever possible. Kubernetes supports this natively through topology-aware hints:

apiVersion: v1
kind: Service
metadata:
  name: api-service
  annotations:
    service.kubernetes.io/topology-mode: Auto
spec:
  selector:
    app: api-service
  ports:
    - port: 80
      targetPort: 8080

When topology-aware routing is enabled, kube-proxy routes traffic to endpoints in the same zone whenever sufficient capacity exists. In practice, this can keep 80–95% of traffic within the same AZ, compared to the default round-robin distribution where only ~33% stays local (in a 3-AZ setup).

For non-Kubernetes workloads, you can achieve similar results by:

Deploying AZ-aware service discovery: Configure your service mesh or load balancer to prefer same-AZ backends. Envoy, Istio, and Linkerd all support locality-aware routing.
Database read replicas per AZ: Deploy read replicas in each AZ so read queries hit the local replica instead of crossing AZ boundaries.
Caching per AZ: Run a Redis or Memcached instance in each AZ rather than sharing a single cache across all AZs. The cache hit rate improvement often pays for the additional instances (and then some).

Architecture-Level Cross-AZ Reduction

Sometimes the best optimization is architectural. Consider these patterns:

Single-AZ for non-critical workloads: Development, staging, batch processing, and other non-production workloads don't need multi-AZ redundancy. Running them in a single AZ eliminates cross-AZ costs entirely.
Colocate tightly-coupled services: If two services exchange large volumes of data, make sure they're always deployed to the same AZ. Use pod affinity rules in Kubernetes or placement groups in EC2.
Compress inter-service payloads: Enabling gzip or zstd compression on service-to-service calls can reduce payload sizes by 60–80%, directly cutting cross-AZ transfer costs proportionally.

Strategy 3: CDN and Edge Optimization

How CDNs Slash Egress Costs

Content Delivery Networks are one of the most powerful tools for reducing internet egress costs, yet many teams underutilize them. The economics are straightforward: CDN data transfer pricing is typically 40–60% cheaper than standard cloud egress, and for cached content, you avoid hitting your origin servers entirely — eliminating both the compute cost and the egress cost of serving that content.

Here's a pricing comparison for serving 10 TB/month from a US region:

Direct from EC2/S3: 10 TB × $0.085/GB = $850/month
Via CloudFront: 10 TB × $0.085/GB (first 10 TB) = $850/month — but with a cache hit ratio of 90%, you're only transferring 1 TB from origin, so origin egress drops to $85. CloudFront's total effective cost is often lower when factoring in the Security Savings Bundle.
Via CloudFront with Security Savings Bundle: Up to 30% discount on CloudFront charges when committed.
CloudFront flat-rate plans: AWS now offers flat-rate tiers — Free ($0/month), Pro ($15/month), Business ($200/month), and Premium ($1,000/month) — with no overage charges, which can be dramatically cheaper for predictable workloads.

Beyond Static Content: Dynamic Content Acceleration

Many teams only use CDNs for static assets like images, CSS, and JavaScript, missing the opportunity to cache and accelerate dynamic content. This is a missed opportunity. Modern CDNs support:

API response caching: Cache GET responses with appropriate cache-control headers. Even a 60-second TTL on popular API endpoints can dramatically reduce origin traffic.
Edge computing: Run lightweight functions at the edge (CloudFront Functions, Lambda@Edge, Cloudflare Workers, Azure Edge Functions) to handle simple requests without hitting your origin at all.
Connection optimization: CDNs maintain persistent connections to your origin, reducing TLS handshake overhead and improving latency for uncached requests.

# CloudFront distribution with aggressive caching
# Terraform configuration
resource "aws_cloudfront_distribution" "api" {
  origin {
    domain_name = aws_lb.api.dns_name
    origin_id   = "api-origin"

    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "https-only"
      origin_ssl_protocols   = ["TLSv1.2"]
      origin_keepalive_timeout = 60
      origin_read_timeout      = 30
    }
  }

  enabled = true

  # Cache static assets aggressively
  ordered_cache_behavior {
    path_pattern     = "/static/*"
    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "api-origin"

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }

    min_ttl     = 86400    # 1 day
    default_ttl = 604800   # 7 days
    max_ttl     = 2592000  # 30 days

    viewer_protocol_policy = "redirect-to-https"
    compress               = true  # Enable automatic compression
  }

  # Cache API responses with shorter TTL
  ordered_cache_behavior {
    path_pattern     = "/api/v1/public/*"
    allowed_methods  = ["GET", "HEAD", "OPTIONS"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "api-origin"

    forwarded_values {
      query_string = true
      cookies {
        forward = "none"
      }
    }

    min_ttl     = 0
    default_ttl = 60      # 1 minute
    max_ttl     = 300     # 5 minutes

    viewer_protocol_policy = "redirect-to-https"
    compress               = true
  }

  # Default behavior — pass through to origin
  default_cache_behavior {
    allowed_methods  = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "api-origin"

    forwarded_values {
      query_string = true
      cookies {
        forward = "all"
      }
    }

    min_ttl     = 0
    default_ttl = 0
    max_ttl     = 0

    viewer_protocol_policy = "redirect-to-https"
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

Multi-CDN Strategies for Large-Scale Deployments

Organizations serving more than 50 TB/month should seriously consider a multi-CDN strategy. By routing traffic across multiple CDN providers based on cost and performance, enterprises have achieved 12–15% additional cost reductions beyond single-CDN optimization. Tools like Cedexis (now part of Citrix), NS1, and Cloudflare Load Balancing can intelligently route users to the cheapest or fastest CDN based on real-time performance data.

Strategy 4: Cross-Region Transfer Optimization

The Cost of Global Architecture

Multi-region deployments are increasingly common for latency reduction, compliance, and disaster recovery. But cross-region data transfer costs are steep — typically $0.02–$0.09 per GB depending on the regions involved. A database replication stream moving 1 TB/day between US East and EU West costs roughly $600–$2,700 per month in transfer charges alone. That's before you even think about storage or compute.

Reducing Cross-Region Transfer Volume

Several strategies can dramatically reduce the volume of data flowing between regions:

Application-level filtering: Instead of replicating entire databases between regions, replicate only the data that each region actually needs. Use change data capture (CDC) with filters to sync specific tables or rows.
Compression for replication streams: Enable compression on database replication, message queues, and data pipelines that cross region boundaries. PostgreSQL logical replication, Kafka MirrorMaker, and most data pipeline tools support compression natively.
Summarization at the source: Rather than shipping raw event data to a central analytics region, pre-aggregate data at the source region and ship only summaries. A 1,000:1 compression ratio is common when aggregating individual events into hourly or daily summaries.
S3 Replication with filters: When using S3 Cross-Region Replication, apply prefix or tag filters to replicate only critical objects rather than entire buckets.

# AWS S3 Replication rule with filtering to reduce cross-region costs
resource "aws_s3_bucket_replication_configuration" "filtered" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-critical-only"
    status = "Enabled"

    filter {
      and {
        prefix = "critical-data/"
        tags = {
          ReplicationRequired = "true"
        }
      }
    }

    destination {
      bucket        = aws_s3_bucket.destination.arn
      storage_class = "STANDARD_IA"  # Save on destination storage too
    }
  }
}

Using Private Connectivity for High-Volume Transfer

For organizations transferring large volumes of data between on-premises infrastructure and the cloud (or between cloud providers), private connectivity options offer both cost and performance benefits:

AWS Direct Connect: Reduces data transfer out charges to $0.02/GB (compared to $0.09/GB for internet egress) and provides consistent, low-latency connectivity. The break-even point for a 1 Gbps connection is roughly 5–10 TB/month of egress.
Azure ExpressRoute: Similar economics to Direct Connect, with metered and unlimited data plans. The unlimited plan eliminates per-GB charges entirely for a flat monthly fee.
Google Cloud Interconnect: Dedicated Interconnect pricing starts at $0.02/GB for egress, with a 15% price reduction announced in 2025. Partner Interconnect offers similar pricing at lower bandwidth commitments.

Strategy 5: Monitoring and Visibility

You Can't Optimize What You Can't See

The number one reason networking costs spiral out of control is lack of visibility. Most teams discover networking cost problems only when the monthly bill arrives — weeks after the damage is done. Building proactive monitoring and alerting for networking costs isn't optional; it's essential.

AWS: VPC Flow Logs and Cost Explorer

VPC Flow Logs capture metadata about network traffic flowing through your VPC. Combined with AWS Cost Explorer and the Cost and Usage Report (CUR), they provide the visibility needed to identify and fix networking cost issues:

# Enable VPC Flow Logs with cost-optimized settings
resource "aws_flow_log" "cost_analysis" {
  vpc_id          = aws_vpc.main.id
  traffic_type    = "ALL"
  log_destination = aws_s3_bucket.flow_logs.arn
  log_format      = "$${version} $${account-id} $${interface-id} $${srcaddr} $${dstaddr} $${srcport} $${dstport} $${protocol} $${packets} $${bytes} $${start} $${end} $${action} $${log-status} $${az-id} $${flow-direction}"

  # Include az-id and flow-direction for cross-AZ analysis
  # Store in S3 with Intelligent-Tiering for cost efficiency

  tags = {
    Name    = "cost-analysis-flow-logs"
    Purpose = "networking-cost-optimization"
  }
}

# Query flow logs with Athena to find top cross-AZ talkers
# Create Athena table first, then run:
#
# SELECT
#   srcaddr, dstaddr, az_id, flow_direction,
#   SUM(bytes) as total_bytes,
#   SUM(bytes) / 1073741824.0 as total_gb,
#   SUM(bytes) / 1073741824.0 * 0.01 as estimated_cost_usd
# FROM vpc_flow_logs
# WHERE az_id != '' AND flow_direction = 'egress'
# GROUP BY srcaddr, dstaddr, az_id, flow_direction
# ORDER BY total_bytes DESC
# LIMIT 20;

Building a Networking Cost Dashboard

A practical networking cost dashboard should track these key metrics:

NAT gateway data processing (GB/day): Trend this over time and set alerts when it exceeds expected baselines. A sudden spike usually indicates a misconfigured service or a runaway process.
Cross-AZ transfer volume by service: Identify which services generate the most cross-AZ traffic so you can target optimization efforts where they'll actually make a difference.
Egress by destination: Understand whether your egress goes to the internet, other AWS regions, other clouds, or on-premises. Each destination has different optimization strategies.
VPC endpoint utilization: Verify that traffic destined for AWS services actually flows through your VPC endpoints. Low endpoint utilization suggests routing issues.
CDN cache hit ratio: Track origin pull rates. A declining cache hit ratio means more origin egress and higher costs.

Automated Cost Anomaly Detection

AWS Cost Anomaly Detection can automatically flag unusual spikes in networking costs. Set it up once and it'll save you from those unpleasant end-of-month surprises. Configure it with granular monitors for data transfer specifically:

# CloudFormation for Cost Anomaly Detection on networking
AWSTemplateFormatVersion: "2010-09-09"
Resources:
  NetworkingCostMonitor:
    Type: AWS::CE::AnomalyMonitor
    Properties:
      MonitorName: "networking-cost-anomaly-monitor"
      MonitorType: "DIMENSIONAL"
      MonitorDimension: "SERVICE"

  NetworkingCostSubscription:
    Type: AWS::CE::AnomalySubscription
    Properties:
      SubscriptionName: "networking-cost-alerts"
      Threshold: 100  # Alert on anomalies > $100
      Frequency: "DAILY"
      MonitorArnList:
        - !Ref NetworkingCostMonitor
      Subscribers:
        - Address: "[email protected]"
          Type: "EMAIL"

Strategy 6: Application-Level Optimization

Compression: The Lowest-Hanging Fruit

Data compression is the simplest and most universally applicable networking cost optimization. Every byte you compress is a byte you don't pay to transfer. Modern compression algorithms like zstd and Brotli achieve 60–80% compression ratios on typical API payloads with minimal CPU overhead.

If you only do one thing after reading this article, do this:

Enable gzip/Brotli on all HTTP responses: This is a one-line configuration change in most web servers and reverse proxies. Nginx, Apache, Caddy, and cloud load balancers all support it natively.
Compress gRPC and Protobuf traffic: gRPC supports built-in compression. Enable it for inter-service communication to reduce cross-AZ transfer costs.
Use binary protocols instead of JSON: Switching from JSON to Protocol Buffers or MessagePack can reduce payload sizes by 50–70% before compression is even applied.

# Nginx configuration for aggressive compression
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 256;
gzip_types
  text/plain
  text/css
  text/xml
  text/javascript
  application/json
  application/javascript
  application/xml
  application/rss+xml
  application/atom+xml
  image/svg+xml;

# Enable Brotli for even better compression (requires ngx_brotli module)
brotli on;
brotli_comp_level 6;
brotli_types
  text/plain
  text/css
  text/xml
  text/javascript
  application/json
  application/javascript
  application/xml;

Reducing Chatty Service Communication

Microservices architectures are notorious for generating excessive inter-service traffic. Every API call between services is a potential cross-AZ transfer charge. Here are strategies to reduce the chattiness:

Batch API calls: Instead of making 100 individual requests, batch them into a single request. GraphQL and gRPC streaming are excellent for this.
Event-driven architecture: Replace synchronous request-response patterns with asynchronous events. A single event published to SNS/SQS/EventBridge can replace multiple API calls to downstream services.
Local caching with short TTLs: Cache frequently-accessed data from other services locally. Even a 30-second TTL cache can reduce inter-service traffic by 90% for hot data paths. That's a massive reduction for very little effort.
API gateway aggregation: Use an API gateway to aggregate multiple downstream calls into a single response, reducing the number of cross-AZ hops.

The 2025–2026 Egress Fee Landscape: Regulatory Tailwinds

Major Pricing Changes

The cloud egress fee landscape is shifting, driven largely by EU regulatory pressure from the Data Act and related legislation. All three major providers have made notable changes:

AWS: Increased the free egress tier from 1 GB to 100 GB/month. Waived egress fees for customers migrating data off AWS. CloudFront egress charges decreased by 15%.
Azure: Eliminated egress charges for customers leaving Azure. Reduced standard egress pricing by 10%. Introduced free egress for Private Endpoint traffic within the same region.
Google Cloud: Reduced egress fees by 12%. Eliminated CDN ingress charges entirely. Cut Cloud Interconnect pricing by 15%.

While these changes are welcome, they primarily benefit migration and CDN scenarios. The fundamental cost structure for cross-AZ transfer, NAT gateway processing, and standard internet egress remains largely intact. Don't count on provider pricing changes to solve your networking cost problems — architectural optimization is still the primary lever.

What to Watch for in 2026 and Beyond

Several trends suggest networking costs will keep evolving:

Continued regulatory pressure: The EU Data Act may force further egress fee reductions. The UK and other jurisdictions are following with similar regulations.
Multi-cloud networking solutions: Services like Aviatrix, Alkira, and cloud-native multi-cloud networking offerings are simplifying and potentially reducing the cost of inter-cloud traffic.
IPv6 adoption: AWS charges for public IPv4 addresses ($0.005/hour per address since 2024) but IPv6 is free. Migrating to IPv6-only architectures eliminates this cost and can simplify networking.
FinOps tooling maturity: Tools like Vantage, CloudZero, and Kubecost are improving their networking cost attribution capabilities, making it easier to identify and fix waste.

Quick-Win Checklist: 10 Actions for Immediate Savings

Here's a prioritized checklist of networking cost optimizations, ranked by effort-to-impact ratio. Bookmark this — it's the TL;DR of the whole guide:

Deploy S3 and DynamoDB gateway endpoints — Free to create, immediate NAT gateway savings. Seriously, do this today.
Enable compression on all HTTP traffic — One-line config change, 60–80% payload reduction.
Audit NAT gateway traffic with VPC Flow Logs — Find out what's flowing through your NAT gateways and whether it needs to.
Deploy interface endpoints for ECR, CloudWatch, and STS — These three services are typically the heaviest NAT gateway users after S3.
Enable topology-aware routing in Kubernetes — Keeps 80–95% of traffic within the same AZ.
Put CloudFront in front of public-facing APIs — Reduces origin egress and improves latency.
Move dev/staging to single-AZ deployment — Eliminates cross-AZ costs for non-production environments.
Compress database replication and cross-region pipelines — Reduces cross-region transfer volume by 60–70%.
Set up Cost Anomaly Detection for data transfer — Catch spikes before they hit your bill.
Evaluate Direct Connect or ExpressRoute — If you're transferring more than 5 TB/month to/from on-premises, the break-even usually favors private connectivity.

Conclusion: Make Networking Costs Visible and Accountable

Cloud networking costs are the last major frontier of cloud cost optimization. While compute right-sizing, storage tiering, and reserved instance purchasing have become standard FinOps practices, networking costs remain poorly understood and underoptimized in most organizations.

The strategies in this guide — VPC endpoints, topology-aware routing, CDN optimization, cross-region transfer reduction, compression, and monitoring — can collectively reduce networking costs by 50% or more. The key insight is that networking cost optimization is fundamentally an architecture problem, not a purchasing problem. You can't buy your way out of a chatty microservices architecture that's generating terabytes of cross-AZ traffic.

Start with visibility. Deploy VPC Flow Logs, set up Cost Anomaly Detection, and build a networking cost dashboard. Once you can see where the money goes, the optimization path becomes clear. Then work through the quick-win checklist — starting with free gateway endpoints and compression, and progressing to architectural changes like topology-aware routing and CDN deployment.

The organizations that get this right don't just save money — they build architectures that are faster, more efficient, and more resilient. Because the same patterns that reduce networking costs (keeping traffic local, caching aggressively, compressing data) also reduce latency and improve reliability. That's the rare win-win-win in cloud engineering: cheaper, faster, and more reliable all at once.