Designing for efficiency: How thoughtful VPC architecture reduces AWS spend
Introduction
At To The New, we work with all kinds of customers from fast-moving startups to huge enterprises, and one thing is always true: Nobody likes surprises on their AWS bill, nor Anyone likes downtime. When people think of saving money in AWS, they usually jump straight to EC2 instance rightsizing or removing idle resources. However, the architecture and design of your AWS Virtual Private Cloud (VPC) also play a significant role in your overall cloud spend.
How to optimize AWS network costs?
Here are 8 practical and sometimes surprising VPC-related facts that might help you reduce costs, based on what we see with our clients every day.
1. VPC Endpoints: Stop Paying So Much for NAT
A common pattern is placing workloads in private subnets so they stay off the public internet. Makes sense for security, but those private subnets always route traffic through a NAT gateway if they need to reach services like Amazon S3 or DynamoDB.NAT gateways aren’t cheap: they charge by the hour and per GB of data processed through them. For teams with a lot of traffic to AWS services, this can easily blow past hundreds or even thousands of dollars a month.
Need a better way? Use a VPC endpoint (either gateway endpoints for S3/DynamoDB, or interface endpoints for other services). This keeps the traffic inside the AWS backbone, with no data-processing fees, and no public IPs needed.
Example: One of our ad-tech customers used to push 10 TB per month through a NAT gateway for S3 uploads, paying over $200 just in data-processing charges. Switching to an S3 gateway endpoint brought that down to effectively zero.
2. PrivateLink: Connect to SaaS Providers Privately
If you rely on SaaS tools that support PrivateLink (many do these days), you can connect to them over a private interface endpoint inside your VPC. That means no public internet, no public data transfer fees, and fewer security worries. All the data flows through aws private network.
Example: A customer used PrivateLink to connect to a third-party compliance monitoring service, removing public exposure and saving on inter-AZ and egress costs that would have come from bouncing over the internet.
3. Clean Up Unused Elastic IPs
Elastic IP addresses don’t seem expensive (a tiny hourly charge), but now AWS is charging for each public IP you allocate irrespective of attached ot not. It’s easy to forget about them after an experiment or a POC. Over time, those pennies turn into dollars.
Tip: Run a periodic check for unattached Elastic IPs, and release them if you don’t need them. AWS VPC IPAM is a go-to service for this.
4. Subnet Sprawl Costs More Than You Think
People don’t always realize that every subnet comes with route tables, network ACLs, and sometimes additional routing or even Transit Gateway attachments. If you over-provision subnets “just in case,” you might incur extra costs you don’t need.
Tip: Plan subnets realistically based on growth, instead of huge, mostly unused CIDR blocks. That way, you keep routing simpler, avoid extra resource attachments, and reduce the operational overhead that also has a hidden cost in engineering time.
5. Transit Gateway vs. VPC Peering: One Size Doesn’t Fit All
Transit Gateway is a great tool to connect lots of VPCs at scale, but it comes with a price: you pay per VPC attachment, plus per GB of data processed. If you only need a couple of VPCs to talk to each other, plain old VPC peering is cheaper — there’s no per-GB fee with peering, just the data transfer cost itself.
Example: One of our clients with three small VPCs moved away from Transit Gateway back to peering, saving around $120 a month in Transit Gateway processing charges.
6. VPC Flow Logs: Great Visibility, Big Bills if You’re Not Careful
VPC Flow Logs are brilliant for monitoring and security audits. But remember, every log record you push to CloudWatch costs money. If you set flow logs to “ALL” and leave them running forever, the cost can quickly get out of hand.
Tip: Use filters to only capture accepted traffic or specific ports you care about, and send the logs to S3 if you don’t need instant querying — S3 storage is much cheaper than CloudWatch.
Example: A customer analyzing a security incident left flow logs on “ALL” for weeks, accidentally pushing 3 million records to CloudWatch. Their bill shot up by $300 in logging charges alone.
7. Think About AZ Placement for Data Transfer
Inter-AZ traffic in AWS costs money — roughly $0.02 per GB in most regions. When you place resources in different AZs, you pay for the traffic crossing those zones. If your app doesn’t need high availability across multiple AZs, keep things in a single AZ to save on inter-AZ charges.
Example: A customer had EC2 in one AZ and RDS in another, with 2 TB of monthly data transfer between them, leading to a $40 inter-AZ bill they didn’t expect. Moving both into the same AZ fixed that instantly.
8. Be Careful with Interface Endpoints (ENIs)
While VPC endpoints are great for cost savings, interface endpoints do have a per-hour cost per endpoint, plus data charges. If you deploy a huge number of them without a plan, it can quietly inflate your bill.
Example: A customer created 50 interface endpoints for testing but left them running for weeks, paying over $100 in endpoint hourly charges. Always clean up your testing stuff!
Final Thoughts
When it comes to AWS cost savings, the discussion often starts and stops with EC2 sizing, but the network layer is equally important. There’s major hidden cost potential in your VPC design, from NAT gateways to peering and flow logs. At To The New, we help organizations design VPCs that are secure, reliable, and budget-friendly. If you’re wondering how to trim your own AWS network costs, let’s connect — we’d love to share what we’ve learned.
