Every private subnet needs a way out. The default answer is a NAT gateway, and it is the right answer for general internet egress. It is the wrong answer for traffic that never needed to leave the AWS network in the first place.
The decision comes down to three questions: where the destination lives, how much traffic there is, and whether the endpoint has a monthly charge.
Gateway endpoints: free, and limited to two services
Gateway endpoints cover S3 and DynamoDB. They are attached to a route table, carry no hourly charge and no per-gigabyte processing fee, and keep the traffic on the AWS backbone.
If a workload reads assets from S3, writes uploads, stores backups or streams logs to a bucket, that traffic should not pass through a NAT gateway. Adding the gateway endpoint is a route-table change, and it is the least risky saving available.
Interface endpoints: powerful, and priced
Other AWS services are reached through interface endpoints, which place an elastic network interface in your subnet. They are charged per hour per endpoint per availability zone, plus a processing rate per gigabyte.
That pricing is not a reason to avoid them, but it is a reason to count. Three zones multiply the hourly component by three, and an endpoint nobody calls still bills. Enabling a dozen endpoints “for security” without checking traffic is how a small saving becomes a new line item.
Choosing per service, not per account
Work through the services in order of traffic volume:
- S3 and DynamoDB — gateway endpoint, always.
- ECR and CloudWatch Logs — interface endpoints pay for themselves quickly on container-heavy workloads, because image pulls and log shipping are constant.
- SSM, KMS, Secrets Manager — small traffic, but an endpoint removes the need to give a private instance a route to the internet at all.
- Third-party APIs, package registries, webhooks — these genuinely need the NAT gateway, because they are not AWS services.
The last category is the one that keeps a NAT gateway in the design. It is also usually much smaller than teams assume.
The architecture that usually wins
Private subnets route S3 and DynamoDB through a gateway endpoint, AWS service traffic through a small set of interface endpoints, and everything else through one NAT gateway per zone for availability. That keeps the hourly cost to the number of zones and the processing cost to genuine internet egress.
A single shared NAT gateway across zones looks cheaper and is not: cross-zone traffic is billed, and an availability-zone failure takes outbound access with it.
Measuring the change
Compare the NAT gateway’s processed-bytes metric before and after adding endpoints. The difference is the traffic you moved, and the hourly component stays visible separately. If the NAT charge barely moves, the traffic was never going to AWS services.
Do this in staging first. A missing endpoint in production looks like a timeout on a random API call, which is a poor way to learn.
The security argument, briefly
Endpoints are often justified as a security control: traffic stays on the private network, and the resource can have no internet route at all. That is true, and it is a good reason to add the endpoints a workload actually uses.
It is not a good reason to route everything through endpoints and keep a NAT gateway for the rest while paying for both paths. Pick the path per service and remove the one you do not need.
If the network layer is where your bill is going, a cloud cost review starts there. The account and network structure behind it is covered in cloud landing zone setup, and the AWS-specific pieces sit under AWS cloud services.
