How We Reduced NAT Gateway Costs by Rerouting GitHub Traffic via a Nginx Proxy

Like many teams running workloads in Kubernetes on AWS, we rely on NAT gateways to let our private pods access the internet. NAT is convenient but notoriously expensive, and recently, we noticed our NAT costs were growing month over month.
The Problem
When we dug deeper into the billing reports, we realized the majority of traffic going through our NAT gateway wasn’t application traffic at all—it was GitHub API and package calls made by our workloads inside private pods.
This was surprising. GitHub calls are frequent (cloning repos, fetching dependencies, checking updates), and since they were all going via NAT, the costs piled up fast.
Investigation with Athena
Using Athena queries on the VPC Flow Logs, we broke down the traffic patterns and confirmed that:
A huge chunk of NAT traffic was destined for
github.comand related endpoints.These requests originated from private subnets where our workloads were running.
Since they didn’t have direct internet access, every call went through the NAT gateway.
The Solution
We realized there was no real need for GitHub traffic to flow through NAT. Instead, we could offload this traffic via the public subnet, while keeping the rest of our pods secure.
Here’s what we did:
1. Nginx Proxy with SSL Passthrough
We deployed a Nginx proxy in a public subnet.
It listens for requests to
github.com.It uses SSL passthrough so that HTTPS connections remain encrypted end-to-end.
Effectively, it just forwards traffic at the TCP level without terminating SSL.
Example Nginx Config (SSL Passthrough)
stream {
upstream github {
server github.com:443;
}
server {
listen 443;
proxy_pass github;
proxy_protocol on;
}
}
This way, Nginx forwards encrypted GitHub traffic directly, without interfering in the TLS handshake.
2. Updating CoreDNS for Routing
Next, we modified our CoreDNS configuration inside the cluster so that pods don’t resolve github.com directly. Instead, they resolve to the proxy service endpoint.
Example CoreDNS ConfigMap Snippet
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
rewrite name github.com github-proxy.default.svc.cluster.local
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
Here’s what happens:
Any pod trying to reach
github.comgets DNS rewritten togithub-proxy.default.svc.cluster.local.That service points to our Nginx pod in the public subnet.
From there, traffic goes directly to GitHub over HTTPS, bypassing NAT.
Results
After rolling this out:
NAT costs dropped significantly.
GitHub calls continued to work seamlessly without requiring any pod-level changes.
Since we used SSL passthrough, TLS security and integrity remained intact.
Key Takeaways
Always monitor your NAT gateway costs—they can creep up silently.
Use Athena + VPC Flow Logs to trace traffic patterns before applying optimizations.
For HTTPS traffic, SSL passthrough is the safest way to proxy without breaking encryption.
Not all traffic needs to go through NAT—sometimes, a smart reroute with a proxy is enough to save a lot of money.



