Data transfer is the third-largest line item on the average AWS bill, behind compute and storage, and it is the one almost nobody can explain. Compute maps to instances you can list. Storage maps to volumes and buckets you can see. But network charges are spread across NAT Gateways, cross-AZ traffic, internet egress, and a dozen per-GB rates that compound in ways the console never shows you in one place. The result is a large, opaque number that teams learn to treat as a fixed cost of doing business.
It is not fixed. A meaningful share of it comes from a handful of recurring patterns: idle resources still billing, NAT Gateways doing work that a free endpoint could do, traffic crossing Availability Zones for no reason. This article walks through six network quick wins, in the order we apply them on an audit, with the service, the detection method, the order of magnitude saved, and the risk for each.
None of them is exotic. All of them are documented by AWS. The difficulty, as always, is that network spend is the hardest part of the bill to read, so nobody goes looking until someone is paid to.
Six network quick wins, in execution order. Releasing idle Elastic IPs (billed at about $3.60/month each even when unused), consolidating idle NAT Gateways in non-production VPCs, deleting dead load balancers with no healthy backend, adding VPC endpoints to route S3, DynamoDB, and AWS API traffic off the NAT path, fixing cross-AZ traffic caused by poor placement, and fronting high-egress origins with CloudFront for cheaper transfer and caching.
The numbers behind these are stark. A NAT Gateway costs about $32/month just to exist, plus $0.045/GB processed, stacking on top of $0.09/GB internet egress for a true $0.135/GB on internet-bound traffic. Cross-AZ transfer adds $0.01/GB each direction. Gateway endpoints for S3 and DynamoDB cost nothing. Every lever here uses native tooling (Cost Explorer, the Cost and Usage Report, VPC Flow Logs, CloudWatch metrics) and the first three carry no production risk at all.
Every other part of an AWS bill maps cleanly to something you can point at. An instance, a volume, a bucket. Network charges do not work that way. A single gigabyte leaving a private subnet for the internet can touch a NAT Gateway hourly charge, a NAT data processing charge, a cross-AZ transfer charge, and an internet egress charge, each on its own line, each at its own rate. The console shows you the totals but rarely the story. So the network bill becomes the part everyone scrolls past, a big number with no obvious handle.
The audit work here is about reassembling that story. You pull the Cost and Usage Report, group by usage type, and trace where the per-GB charges are actually coming from. Once the traffic is mapped, the fixes are usually obvious, and several of them are simply deleting things that should not be billing in the first place.
This is the smallest line item on the list, but it is the purest form of waste, so it goes first. Since February 2024, AWS charges about $0.005 per hour, roughly $3.60 per month, for every public IPv4 address, including Elastic IPs that are allocated but not associated with anything. An EIP reserved for a project that never shipped, or left behind when an instance was terminated, bills every hour it exists for exactly zero benefit.
Detection is a one-liner: aws ec2 describe-addresses filtered on addresses with no association ID returns the idle ones. On a single account the saving is trivial, a few euros. Across an organization with dozens of accounts and forgotten IPs scattered through them, it adds up to real money, and releasing them is a release-address call with no risk once you have confirmed nothing references them.
NAT Gateways are the single most underestimated cost on most AWS bills. Each one costs about $32 per month just to exist, before a single byte passes through, and AWS best practice of one gateway per Availability Zone means a three-AZ VPC starts at roughly $97 per month in hourly charges alone. That is defensible in production, where the high availability is worth paying for. It is much harder to defend in pre-production, staging, and sandbox VPCs, where teams routinely run three NAT Gateways for environments that do not need AZ-level resilience at all.
The fix in non-production is to consolidate to a single NAT Gateway, accepting that if its AZ goes down the dev environment loses internet egress for a while, which is almost always an acceptable tradeoff. Detection runs through describe-nat-gateways cross-referenced with environment tags, and the saving is roughly $65 per month per VPC brought down from three gateways to one. On an account with several non-production VPCs, that alone often covers a meaningful slice of the audit.
Load balancers from abandoned projects keep billing long after the project is gone. An Application or Network Load Balancer charges a minimum of roughly $16 to $22 per month in hourly fees plus its LCU usage, whether or not any healthy target sits behind it. The classic pattern is a load balancer left pointing at a target group whose instances were terminated months ago, quietly invoicing for a service that no longer exists.
Detection: run describe-target-health across every target group and flag the ones where no target has been healthy for more than 30 days, then cross-reference the parent load balancers. Before deleting, check that no Route 53 record still points at the load balancer, since an active DNS entry is a sign someone may still expect it to work. Once confirmed dead, deletion is immediate and risk-free, and the saving is $50 to $300 per month depending on how many have accumulated.
Here is the one that surprises most teams. Every API call from a private subnet to S3, DynamoDB, ECR, or CloudWatch Logs travels through the NAT Gateway by default, and gets charged the NAT data processing rate of $0.045 per GB for the privilege. That is money paid to route AWS traffic to AWS services, over the AWS backbone, through a billable middleman that adds nothing.
VPC Gateway Endpoints for S3 and DynamoDB cost absolutely nothing and route that traffic off the NAT path entirely. There is no hourly charge and no data processing fee, just a route table entry. For other services, Interface Endpoints carry a small hourly charge per AZ plus about $0.01 per GB, still roughly 78% cheaper than the NAT rate, and worth it for high-volume traffic like ECR image pulls or CloudWatch Logs ingestion. Detection means looking at what the NAT Gateway is actually processing via VPC Flow Logs, then adding endpoints for the heaviest AWS-service destinations. The change is a route table or endpoint addition with no application impact.
This is the most common hidden network cost, and the easiest to picture with a concrete case. Take an EC2 instance in eu-west-3 talking to an RDS database also in eu-west-3. Same region, so most people assume the traffic between them is free. It is only free if they sit in the same Availability Zone. If the EC2 is in eu-west-3a and the RDS is in eu-west-3b, every gigabyte between them costs $0.01 in each direction, $0.02 round-trip, purely because they landed in different AZs within the same region. For a chatty application doing constant database reads, that adds up fast, and nothing in the architecture diagram makes it visible.
The same mechanism shows up across microservices and EKS clusters, where pods spread across AZs talk to each other constantly. A busy cluster pushing 10 TB per month of inter-AZ traffic pays around $200 per month in transfer fees alone, for a networking pattern nobody chose deliberately. Detection runs through VPC Flow Logs, grouping traffic by source and destination AZ to see how much of it is crossing boundaries unnecessarily.
The fix carries one important caveat. For stateless components, colocating the chatty services in the same AZ removes the charge cleanly. But for the EC2-to-RDS case specifically, the picture is more subtle, because a Multi-AZ RDS deliberately keeps its standby in a second AZ for resilience. You can point your application at the primary in the same AZ to minimize normal-operation cross-AZ traffic, but during a failover the primary moves to the other AZ and the cross-AZ cost returns until you rebalance. That is the tradeoff: the cross-AZ data charge is partly the price of the availability you are paying Multi-AZ for. The right move is to minimize avoidable cross-AZ chatter, not to fight the resilience design that is doing its job.
The last one targets internet egress directly. Data served straight from an EC2 instance or an S3 bucket to the public internet is billed at the standard egress rate of $0.09 per GB for the first 10 TB per month. Routing that same content through CloudFront is cheaper at every tier, and the caching layer means a large share of requests never hit the origin at all, cutting both egress and origin load at once.
The strongest candidates are static and semi-static content with repeat access: images, downloads, video segments, API responses that can tolerate short cache windows. Detection is a matter of finding the highest-egress origins in the Cost and Usage Report, then checking which of them serve cacheable content. Putting CloudFront in front is a configuration change, not an application rewrite, and on a high-traffic content origin it routinely cuts the egress bill by a third or more while improving latency for end users through the edge network.
“The network bill is the one part of AWS that hides in plain sight. Same region does not mean free, a NAT Gateway charges you three times over, and an idle Elastic IP bills every hour for nothing. None of it shows up in the architecture diagram, which is exactly why it survives for years.”
Julien MAUCLAIR
CTO, Co-Foundeur Stralya
The six quick wins above cover the network waste that comes from neglect and default behavior. They are fast, mostly risk-free, and they map to clear line items once you trace the Cost and Usage Report. But they leave aside three deeper network topics that deserve a dedicated effort, because they touch architecture and need coordination across teams.
The first is VPC topology and Transit Gateway design. Many accounts grow a tangle of VPC peering connections and redundant NAT paths over time, and rationalizing that into a clean hub-and-spoke topology with a Transit Gateway can cut both cost and operational complexity. But it is a network redesign, not a one-week cleanup, and it needs careful migration planning to avoid outages.
The second is egress architecture at scale. For workloads moving very large volumes of data out of AWS, the conversation moves beyond CloudFront into Direct Connect, dedicated egress strategies, and in some cases renegotiated commitments with AWS. These decisions have large financial stakes and belong in a capacity and commercial discussion, not a quick-win pass.
The third is service mesh and AZ-aware routing for large microservice estates. Tools that route traffic preferentially to same-AZ endpoints can systematically reduce cross-AZ charges across a whole cluster, but introducing them is a platform engineering project with its own operational learning curve, not a configuration toggle.
These three, we leave in their place, in an optimization roadmap over three to six months, after the quick wins. Redesigning VPC topology on an account that still has idle NAT Gateways and unattached Elastic IPs is, once again, starting the marathon at the last kilometer.
Network is the part of the AWS bill that teams give up on first, precisely because it is the hardest to read. The charges are spread thin, the rates compound invisibly, and the architecture diagram never shows you that two services in the same region are quietly paying to talk across an AZ boundary. That opacity is exactly why the savings are still there, untouched, years after they could have been claimed.
On an account of meaningful size, the cumulative effect of these six actions commonly lands around 15% to 30% of the network bill, with the first three carrying no production risk at all. It takes someone willing to pull the Cost and Usage Report, group by usage type, and follow the per-GB charges back to their source. That is the whole job: making the invisible bill visible, then deleting or rerouting what should never have been billing in the first place.
Get this detailed PDF about this articles
By submitting your email you agree to receive this case study and occasional updates from Stralya. We don’t share your data — see our privacy policy.
A project, an infra drifting, a bill spiraling. Tell us what's blocking you in Dubai, we'll come back with a plan.
