We're using AWS Activate credits and discovered that NAT Gateway charges—both the hourly fees and data-processing costs—make up roughly 80% of our total AWS spend. We knew options such as S3 and DynamoDB gateway endpoints, consolidating NAT gateways in non-production environments, NAT instances, and IPv6 could help, but we haven't changed the architecture yet.
For those who have dealt with this, how much did VPC endpoints actually reduce your bill? Were NAT instances or tools such as fck-nat worth the operational trade-off? Is having NAT represent 80% of the bill unusually high, or can it happen with relatively normal workloads? We'd also appreciate advice on figuring out whether the main cause is S3/ECR traffic, cross-AZ routing, public API calls, or something else before making changes.
4 Answers
Start by separating the NAT gateway hourly usage from the per-GB processing usage. In Cost Explorer, filter for the VPC service and group by usage type so you can distinguish NatGateway-Hours from NatGateway-Bytes. If hours dominate, you may simply have too many gateways. If bytes dominate, turn on VPC Flow Logs for the NAT interfaces and identify the biggest source and destination pairs.
S3 and DynamoDB gateway endpoints are free and are usually the first thing to add. They bypass NAT completely for those services. For container images, remember that ECR generally needs the ECR API endpoint, the ECR Docker endpoint, and an S3 gateway endpoint for image layers. Interface endpoints have their own hourly and per-GB fees, so check the traffic volume before adding them everywhere.
NAT traffic often becomes expensive because internal or cross-AZ traffic is taking an unnecessary detour. Check whether workloads are reaching private AWS services through public addresses, whether services in one AZ are using a NAT gateway in another AZ, and whether region-to-region traffic is crossing NAT. Keeping workloads and their NAT gateways aligned by AZ can avoid extra transfer charges, although consolidating to one gateway may still be reasonable for development environments where high availability is not required.
Also investigate repetitive downloads, such as container pulls, package installs, backups, log shipping, or CI jobs. Caching images and dependencies can reduce the processed-byte charge without changing the network design.
For low-traffic development or staging environments, a self-managed NAT instance or a managed bootstrap solution such as fck-nat can reduce costs substantially. The trade-off is that you now own patching, source/destination-check settings, forwarding rules, capacity, failover, and route recovery. A small instance in an Auto Scaling Group with startup automation and a stable network interface is safer than relying on a manually configured server.
I’d generally keep managed NAT gateways for production when availability and operational simplicity matter, and consider instances only after measuring the traffic and confirming the savings justify the maintenance.
Even a NAT instance that looks simple still needs automated startup configuration and recovery. Without that, an instance failure can turn a cost-saving change into an outage or a manual repair.
IPv6 can remove the need for NAT for workloads that can communicate over IPv6, using an egress-only internet gateway for outbound access. It is not a universal replacement because some third-party services and applications remain IPv4-only, so dual-stack support and compatibility need to be tested.
The main point is to map the traffic before replacing anything. If most bytes are going to S3 or DynamoDB, gateway endpoints may eliminate a large portion immediately. If the traffic is mostly public APIs or other external destinations, endpoints will only make a small dent and a NAT instance, caching, traffic reduction, or a redesigned private connection may be more appropriate.
This distinction is important because 80% of the total bill can sound worse when compute is covered by credits. I’d look at the absolute monthly amount as well as the percentage.