The Need for a Kubernetes NAT Gateway
When Kubernetes workloads need to connect to the outside world, whether to access external APIs, integrate with external systems, or connect to partner networks, they often face a unique challenge. The problem? Pod IP addresses inside Kubernetes clusters are dynamic and non-routable. For external systems to recognize and trust this traffic, workloads need a consistent, dependable identity. This means outbound connections require fixed, routable IP addresses that external services can rely on. This is where Network Address Translation (NAT) becomes essential. It assigns Kubernetes pods with a static, consistent IP for all outbound traffic, ensuring those connections work properly.
If you’re running Kubernetes in the cloud, a common solution is to use your cloud provider’s managed NAT gateway service. These are easy to use, but they can come at a cost. In AWS, Azure, and Google Cloud, cloud-managed NAT gateways charge both an hourly fee and a per-gigabyte data processing fee. For high-traffic deployments, those charges can quickly add up, sometimes even exceeding your compute costs.
The good news: with Calico, you can handle NAT from inside your Kubernetes cluster, avoiding cloud NAT gateway fees and giving you more control over how egress works.
The Challenge With Cloud NAT Gateways
Managed NAT gateways from cloud providers are designed for convenience, but they come with a few limitations:
- Ongoing hourly charges – even if you’re not sending much traffic.
- Data processing costs – usually per GB and applied on top of hourly fees
- Limited flexibility – most cloud managed NATs have few options, like the ability to exempt specific destinations from the NAT.
For organizations with high-volume traffic or unpredictable traffic patterns, NAT gateway costs can add up quickly.
Calico’s Built-in NAT for Kubernetes Egress
Calico Egress Gateway can be used as a NAT gateway to provide Kubernetes pods with the static IPs they need to connect outside the cluster.
How Calico Egress Gateway works as a NAT gateway – a simple example:
- A pod sends a request to access an external API
- A pod in the namespace payments makes an HTTPS request to api.paymentprovider.com
- The pod making the request has a non-routable source IP of 192.168.1.42
- Calico routes traffic to an Egress Gateway
- Calico network policy is configured so that all outbound traffic from the payments namespace is sent to a specific Calico Egress Gateway pod.
- The Egress Gateway is configured to give all pods in the payment namespace a specific static IP address of 203.0.113.10 for sending external traffic. Note: with Calico it is possible to guarantee that your application (in this case pods in the payments namespace) will always get the same static IP address from the Egress Gateway.
- Calico Egress Gateway rewrites (translates) the pod’s source IP from 192.168.1.42 (pod IP) to the static, routable IP 203.0.113.10 before sending the traffic out.
- Traditional firewall in customer network allows traffic from 203.0.113.10
- This traditional IP-based firewall has a rule allowing traffic from the IP address 203.0.113.10 to the destination api.paymentprovider.com to pass through, giving the payment pod a recognizable “identity” so that traffic it sends can pass through the firewall
- The traffic then goes through the internet and is routed to the destination api.paymentprovider.com
- Traditional firewall at api.paymentprovider.com
- The traffic is routed to api.paymentprovider.com and there is an IP-based firewall that traffic needs to get through to get to the Payment Provide API. This firewall has a rule that allows traffic from the destination IP 203.0.113.10 to pass through.
- The payment provider API (at api.paymentprovider.com) processes the traffic it receives from the pod, which has a source IP of 203.0.113.10.
Advantages of Calico Egress Gateway Used as a NAT
Cost
With Calico Egress Gateway (with NAT) you can avoid potentially high cloud NAT gateway fees. You don’t pay the hourly and per-GB data processing costs that are typical of managed NAT gateways.
Scalability and Reliability
Traffic is translated at Calico egress gateways inside the cluster where the traffic originates. This consolidates and controls outbound traffic, providing distinct exit points. This design makes it easier to enforce security policies and gives outbound traffic a clear, recognizable “identity” for external services that require a specific source IP address.
Flexibility
Calico Egress Gateway (with NAT) can be enabled for specific IP pools, and you can easily exempt internal networks to avoid unnecessary translation. Calico Egress Gateway also works with Calico network policies and DNS policies and is an extremely configurable NAT gateway solution with many options available: Calico Egress Gateway configuration documentation.
Use Cases for Calico Egress Gateway and NAT
Calico Egress Gateway is a very flexible NAT gateway solution that can be useful in the following situations and more:
- Access external services: When your pods that use non-routable IP addresses need to access external APIs, systems, and SaaS services.
- Assign fixed egress IPs: Calico Egress Gateway allows you to assign fixed, routable IP addresses to outbound traffic from Kubernetes pods or namespaces. This enables consistent identification of source traffic and simplifies integration with external security tools and systems and firewalls that require static IPs for allow-listing.
- Policy-based routing: You can define Calico network policies to route outbound traffic through designated egress gateways based on the destination, providing flexibility and granular control over egress traffic management.
- Integration with traditional security tools: By assigning static egress IPs, Calico Egress Gateway enables seamless integration with traditional security tools (e.g., firewalls, DLP, CASB) and allows for precise, IP-based access control.
- Hybrid or on-prem environments: If your physical infrastructure already handles NAT, you can disable Calico NAT to avoid double translation.
- Granular Access Control: Calico Egress Gateway enforces security policies to regulate what traffic is allowed to leave the cluster, supporting zero-trust workload access control and reducing the risk of unauthorized outbound traffic.
- Audit and visibility: Routing traffic through specific gateways makes it easy to log, audit, and track the source of egress traffic for compliance and troubleshooting.
- Support for multiple external networks: Calico Egress Gateway can route traffic from different namespaces to different external networks, even if those networks have overlapping IP addresses.
- High availability and load balancing: Calico supports deploying multiple redundant egress gateway pods for high availability. Traffic can be load-balanced across these gateways, and health checks ensure only healthy gateways are used, improving reliability and minimizing downtime.
Examples of Calico Egress Gateway in Action
Preventing Data Exfiltration with Firewalls
Challenge: You want to ensure that only certain workloads in your Kubernetes cluster can connect to the internet, for example, a payment service that needs to reach a trusted API.
Solution: With Calico Egress Gateway, you can assign those workloads a fixed, recognizable IP address. Your firewall can then allow-list that IP, so only traffic from the approved workloads is able to leave the cluster.
How it works: Calico Egress Gateway works hand-in-hand with IP-based firewalls to protect your cluster from data leakage. And with Calico network policies, you can take it a step further: the payment service pods can be restricted to communicate only with the external payment API, while all other outbound connections are blocked. If a compromised pod tries to reach an unauthorized external system, that traffic is denied, effectively preventing command-and-control (C&C) attacks.
Enabling Trusted Access to Databases Behind a Firewall
Challenge: Many organizations run critical applications, like databases, behind traditional ip-based firewalls to tightly control who can connect.
Solution: With Calico Egress Gateway, you can give specific Kubernetes workloads a fixed, trusted IP address for outbound traffic. That IP can then be allow-listed on the firewall to protect the database.
How it works: This way, only the designated workloads in your cluster can establish connections to the database, while all other traffic is blocked. The result is secure, trusted communication between Kubernetes services and your protected applications, without having to weaken firewall rules or open broad network access.
The Bottom Line
By using Calico’s Egress Gateway (which can be used as a NAT gateway), you can cut costs, simplify egress control, and avoid the operational overhead of cloud-managed NAT gateways. Calico Egress Gateway puts you in control of how traffic leaves your cluster, without sacrificing security, scalability, or flexibility.
If you’re looking to reduce your cloud bill and streamline your Kubernetes networking, Calico Egress Gateway used as a NAT gateway is a simple, effective place to start.
To learn more about Kubernetes NAT Gateway and see them in action, schedule a demo.
