The Real Reason NAT Gateway Is Expensive - How Data Processing Charges Work and How to Avoid Them
Break down the mechanisms behind NAT Gateway's high hourly and data processing charges, and explore practical cost-reduction strategies including VPC endpoints, NAT instances, and IPv6 migration.
NAT Gateway's Double-Charging Structure
NAT Gateway pricing consists of two components. The hourly charge is billed for the time a NAT Gateway exists. In ap-northeast-1, it costs $0.062 per hour, which translates to approximately $45 per month (as of August 2026). You are charged just for having it, even if it is not being used. The data processing charge is billed for the volume of data passing through the NAT Gateway, at $0.062 per GB. This charge is added on top of standard data transfer charges. In other words, when an EC2 instance in a private subnet calls an API on the internet, the total charge is $0.176/GB: NAT Gateway data processing ($0.062/GB) + internet data transfer ($0.114/GB). In a multi-AZ configuration with a NAT Gateway in each AZ, hourly charges alone amount to $135/month (3 AZs). Since NAT Gateway costs $135/month even when idle, its share of total costs can become large in small environments.
Patterns Where Data Processing Charges Balloon
There are patterns where NAT Gateway data processing charges become unexpectedly high. A typical case is when private subnets call AWS service APIs. When all communication to AWS services, such as S3 file uploads, CloudWatch Logs log delivery, and SQS message sending, routes through the NAT Gateway, data processing charges accumulate. For example, if a Lambda function is placed in a VPC and uploads 100 GB of data to S3 per day, the NAT Gateway data processing charge alone reaches approximately $186/month (100 GB x 30 days x $0.062). Another pattern is cross-AZ NAT Gateway usage. When an instance in AZ-a uses a NAT Gateway in AZ-c, inter-AZ data transfer charges also apply between the instance and the NAT Gateway. By placing a NAT Gateway in each AZ and configuring route tables to use the NAT Gateway in the same AZ, you can avoid inter-AZ transfer charges.
Cost Reduction with VPC Endpoints
One way to reduce NAT Gateway costs is to route AWS service traffic through VPC endpoints. Gateway endpoints are available for S3 and DynamoDB at no additional charge, bypassing the NAT Gateway. Gateway endpoints work simply by adding an entry to the route table, with no data processing charges. In environments with heavy data transfer to S3, introducing a gateway endpoint can reduce NAT Gateway data processing charges. For other AWS services (CloudWatch, SQS, SNS, KMS, ECR, etc.), use interface endpoints (PrivateLink). Interface endpoints also incur hourly and data processing charges, so they are chosen by comparing them against NAT Gateway charges based on traffic volume. One approach is to introduce interface endpoints starting with the services that carry more data. CloudWatch Logs, ECR (container image pulls), and Systems Manager are examples of services that tend to carry a lot of traffic.
NAT Instances as an Alternative
Instead of a NAT Gateway, you can use an EC2 instance configured for NAT functionality, known as a NAT instance. Configuring NAT on a small instance such as a t4g.nano can reduce costs compared to NAT Gateway's hourly charge ($45/month). NAT instances have no data processing charges; only standard EC2 data transfer charges apply. However, NAT instances have drawbacks. Availability management becomes your responsibility. NAT Gateway is a managed service with automatic redundancy, but a NAT instance is a single EC2 instance, and you must design automatic recovery in case of failure yourself. Throughput is also limited by the EC2 instance's network bandwidth. NAT Gateway scales up to 100 Gbps, while a NAT instance's bandwidth depends on the network performance of the instance type you choose. NAT instances are a reasonable choice for development environments or low-traffic environments, but for production environments, one approach is to choose the managed redundancy of NAT Gateway. The fck-nat open-source AMI can simplify NAT instance setup.
Migration to IPv6 - A Future Without NAT Gateway
Using IPv6 can potentially reduce the traffic that goes through NAT Gateway. IPv6 addresses are globally unique, so NAT (Network Address Translation) is unnecessary. By assigning IPv6 addresses to EC2 instances in private subnets and using an Egress-Only Internet Gateway, outbound communication from instances to the internet becomes possible. The Egress-Only Internet Gateway itself has no charge, but data transfer charges apply to the instances. However, full migration to IPv6 has hurdles. Not all AWS services support IPv6, and if the destination server does not support IPv6, IPv4 communication is still required. A practical approach is to gradually migrate to IPv6 with a dual-stack (IPv4 + IPv6) configuration: route AWS service traffic through VPC endpoints, IPv6-compatible external service traffic through the Egress-Only Internet Gateway, and only IPv4-only external service traffic through the NAT Gateway. This reduces traffic passing through the NAT Gateway.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.