Skip to main content

Command Palette

Search for a command to run...

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

Published
3 min read
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.com and 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.com gets DNS rewritten to github-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.