Egress IP Addresses for Third-Party Allowlisting

This page explains how to get the static outbound (egress) IP addresses your applications call external services from, so a partner, bank, payment provider or other third-party API can add them to its allowlist (or whitelist).

What the egress IP address is

When an application calls a service on the internet, the request does not leave from the pod's private address. It leaves the Environment's network through a NAT gateway, and the third party sees the NAT gateway's public address:

flowchart LR
  A[Your application pod] --> B[NAT gateway of the Environment]
  B -->|public egress IP| C[Partner API allowlist]

Every workload in the Environment shares these addresses.

Each Environment has its own addresses

Each Environment runs in its own network. Depending on how your networks are set up, Environments either leave through their own addresses or share a central outbound gateway. The list you receive says which addresses belong to which Environment. Where they differ, a partner that allowlisted your production addresses still blocks calls from your test Environment.

When you ask a partner to allowlist you, give them the addresses for every Environment that calls them. Many partners have a separate sandbox and production system, each with its own allowlist: match your test Environment to their sandbox and your production Environment to their production system.

An Environment can also have more than one egress address. A highly available network runs one NAT gateway per availability zone, each with its own address, and traffic can leave through any of them. Give the partner every address for the Environment, not just one, or some calls fail at random.

Get your egress addresses

SVIEW does not show egress addresses. Raise a request in your dedicated Slack channel containing:

• Environments — which Environments the partner needs to allowlist, for example production and staging
• What it is for — the partner or API, in one line

CTO2B replies with the addresses for each Environment, in CIDR notation where the partner asks for it (203.0.113.25/32 for a single address).

When the addresses can change

Egress addresses are stable for the life of the Environment's network. They do not change when you deploy, restart or scale an application, or when the cluster adds or replaces nodes.

They can change when the network itself changes, for example:

• The Environment is rebuilt or moved to another region or cloud account
• NAT gateways are added, such as when an Environment moves to a highly available, multi-zone network, which adds addresses
• A migration to a new cluster or network

Before a planned change like this, raise a request for the new addresses and get them onto partner allowlists before the switch. If a partner integration suddenly starts refusing your calls, with connection timeouts or 403 Forbidden responses from the partner, check whether your egress addresses match what the partner has on file.

Verify the address

If you have namespace access with the exec role, you can confirm the address a pod calls out from by asking a public "what is my IP" service:

kubectl exec -it <pod-name> -n <namespace> -- curl -s https://checkip.amazonaws.com

The response is the egress address that pod used. The image must include curl; many minimal images do not. Run it more than once on a multi-zone Environment, since different pods can leave through different addresses.

Related articles

• IP Allowlisting for Applications and Databases — the reverse direction: restricting who can reach your applications
• Network Policies — outbound traffic rules inside the platform
• Site-to-Site VPN and On-Premises Connectivity — private connections to a partner instead of an internet allowlist
• Namespace Access — kubectl access to run the check above