AWS cost optimization

AWS VPC Costs: What Actually Costs Money for Small Teams

AWS VPC costs usually come from attached resources, not the VPC label itself. Learn what creates charges and how to review them safely before changing things.

Published 2026-05-18 Updated 2026-05-18 By Cloud Cost Clinic

Quick takeaway

AWS VPC cost is usually not the networking container quietly plotting against you. The surprise usually comes from the things around it: NAT Gateways, public IPv4 addresses, VPC endpoints, data transfer, VPN, Transit Gateway, PrivateLink, load balancers, and IPAM advanced features.

So when someone asks, "Do VPCs cost money in AWS?", the practical answer is: the base networking container is not usually the problem, but the choices you attach to it can absolutely create recurring spend. Networking costs are architecture diagrams with money arrows.

The VPC is often innocent. The traffic path may need a conversation.

Network cables in a server room used as a visual cue for VPC cost review

Common VPC-related cost drivers

Small AWS accounts often see VPC-related spend from:

  • NAT Gateway hourly charges and data processing.
  • Public IPv4 addresses, including Elastic IP addresses.
  • Interface VPC endpoints.
  • Gateway Load Balancer endpoints.
  • Load balancers.
  • Data transfer across Availability Zones.
  • Data transfer out to the internet.
  • Transit Gateway, Site-to-Site VPN, and PrivateLink.
  • VPC Flow Logs, depending on destination and volume.
  • IPAM advanced features where used.

These costs can be legitimate. The goal is not to remove networking controls blindly. The goal is to make the traffic path explainable. Expensive can be valid. Mysterious is the problem.

Free vs paid VPC components

When people ask whether a VPC costs money, they usually need this split:

  • VPC, subnets, route tables, and network ACLs: usually not the direct surprise line item, but they shape paid traffic paths.
  • NAT Gateway: billed for availability and data processing; also consider standard data transfer charges.
  • Public IPv4 addresses: AWS charges for in-use and idle public IPv4 addresses; review current VPC pricing.
  • Interface endpoints and PrivateLink: can add hourly and data processing costs, but may reduce some NAT/data transfer patterns.
  • Gateway endpoints for S3/DynamoDB: often useful for avoiding NAT processing for supported service traffic; still check the current docs and architecture.
  • Load balancers: common VPC-adjacent recurring cost with traffic and hourly dimensions.
  • Transit Gateway, VPN, peering, and IPAM advanced features: review separately because each has its own pricing model and traffic implications.
  • VPC Flow Logs: the VPC setting may be simple, but log destination, volume, and retention can create costs.

This table is a starting point, not a pricing sheet. For exact rates, use the current AWS VPC pricing page and the pricing pages for the attached services.

NAT Gateway is often the loudest signal

NAT Gateway cost can surprise teams because the bill is not only "a gateway exists." AWS documentation says NAT Gateway pricing includes each hour the gateway is available and each gigabyte processed.

Before changing NAT architecture, check:

  • Which private subnets route through each gateway.
  • Whether traffic crosses Availability Zones.
  • Whether high-volume traffic goes to AWS services that could use VPC endpoints.
  • Whether fewer gateways would reduce resilience.
  • Whether the traffic is production, staging, batch, backup, or observability.

Do not delete a NAT Gateway because it looks expensive. Route tables usually get a vote. So do users, batch jobs, monitoring, and the rollback plan.

The NAT Gateway surprise is a common small-team pattern. Workloads move into private subnets, the architecture gets more private, and the bill develops a steady toll-road habit. The review is not "NAT Gateway bad." The review is "which traffic path are we paying for, and is that path intentional?"

Public IPv4 is now part of the review

AWS documentation says AWS charges for all public IPv4 addresses, including public IPv4 addresses associated with running instances and Elastic IP addresses. That makes public IP inventory worth reviewing, even in small accounts.

For each public address, check:

  • Associated resource.
  • Region and account.
  • DNS records.
  • Security group and firewall dependencies.
  • External allowlists.
  • Monitoring checks.
  • Owner and environment.

An unassociated Elastic IP is a strong review signal. It is still not proof that release is safe. Public IP cleanup can be a networking and access-control task, not just a billing task.

How to find VPC-related spend

Start in Cost Explorer:

1. Group by service. 2. Look for Amazon VPC, EC2-Other, NAT Gateway, public IPv4, Elastic Load Balancing, Transit Gateway, and PrivateLink-related spend. 3. Group by usage type. 4. Filter by linked account and Region. 5. Compare daily trends to see whether the cost is hourly baseline or traffic-driven.

Then map the billing signal back to infrastructure:

  • Route tables for NAT paths.
  • Endpoint lists for interface and gateway endpoints.
  • Elastic IP and public IPv4 inventory.
  • Load balancers and target groups.
  • Transit Gateway attachments and route tables.
  • Flow logs, if enabled.
  • Account, Region, and owner tags.

How to verify before changing networking

Networking cleanup can break production quickly. Before changing routes, endpoints, public addresses, load balancers, or gateways, confirm:

  • Which application depends on the path.
  • Whether traffic is production, batch, backup, monitoring, or user-facing.
  • Whether DNS, security groups, route tables, allowlists, or vendor integrations depend on it.
  • Whether the path is part of failover or disaster recovery.
  • Whether an Availability Zone change affects resilience.
  • Whether rollback has been tested.

Use a change window for production network changes.

This is where the cleanup advice needs a seatbelt. A dashboard cannot attend the change review for you, and a lower networking bill is not a rollback plan.

Safer ways to reduce VPC cost

  • Release clearly abandoned public IPv4 addresses after ownership review.
  • Remove stale endpoints or load balancers after checking traffic and DNS.
  • Add gateway endpoints or interface endpoints only when the traffic pattern supports the tradeoff.
  • Revisit NAT Gateway placement for high-volume private subnet traffic.
  • Keep chatty resources in the same Availability Zone where the architecture allows it.
  • Send high-volume logs to the destination that fits the use case and cost pattern.
  • Tag networking resources with owner, app, environment, and purpose.

The safest fix may be smaller than the first idea. Sometimes it is a route change. Sometimes it is a tag. Sometimes it is accepting the cost because the resilience tradeoff is worth it. Do not turn a networking review into an outage rehearsal.

What not to do

Do not collapse networking across Availability Zones just to reduce cost without understanding resilience impact.

Do not replace NAT Gateway with endpoints without checking which services are actually driving traffic and what the endpoint will cost.

Do not remove public access from a workload without confirming users, automation, vendors, monitoring, and recovery paths.

Do not treat "networking" as one bucket. Split it by usage type and traffic path.

Do not make resilience cheaper by accident. If fewer gateways, endpoints, or paths change availability, say that out loud before calling it optimization.

Checklist

  • Group VPC-related spend by usage type in Cost Explorer.
  • Identify NAT Gateway, public IPv4, endpoint, load balancer, and transfer costs.
  • Map each cost signal to account, Region, route, endpoint, or address.
  • Confirm owner and workload.
  • Check DNS, allowlists, route tables, and security groups before changes.
  • Use a change window for production networking.
  • Recheck Cost Explorer after the change.

FAQ

Does an AWS VPC cost money by itself?

The VPC container is usually not the cost surprise. Charges often come from VPC-related resources and traffic patterns such as NAT Gateway, public IPv4 addresses, endpoints, load balancers, VPN, Transit Gateway, and data transfer.

Why is my VPC cost high?

Common reasons include NAT Gateway processing, public IPv4 addresses, VPC endpoints, load balancers, data transfer, Transit Gateway, and logs. Group by usage type before guessing.

Can VPC endpoints reduce cost?

Sometimes. Endpoints can reduce certain NAT traffic patterns, but interface endpoints have their own hourly and data processing costs. Compare the actual traffic path before adding them.

Is it safe to delete a NAT Gateway?

Only after checking route tables, private subnet traffic, application dependencies, resilience impact, and rollback. A NAT Gateway can be expensive and still required.

Sources

Reader question

Which VPC-related cost is hardest to explain in your account: NAT, endpoints, public IPv4, load balancers, or data transfer?