Introduction

In Azure Kubernetes Service, the phrase "outbound IP" means the public address used when pods or nodes reach services outside the cluster. You usually need that address for firewall allowlists, partner API access, or audit work. The important detail is that AKS does not always use the same egress mechanism, so the correct command depends on the cluster's outboundType.

Start by Checking the Outbound Type

Do not assume every AKS cluster uses a load balancer for egress. Newer clusters can use a managed NAT gateway, a user-assigned NAT gateway, user-defined routing, or other egress patterns.

Check the current setting first:

1RESOURCE_GROUP=my-rg
2CLUSTER_NAME=my-aks
3
4az aks show \
5  --resource-group "$RESOURCE_GROUP" \
6  --name "$CLUSTER_NAME" \
7  --query "networkProfile.outboundType" \
8  -o tsv

Typical results include loadBalancer, managedNATGateway, userAssignedNATGateway, and userDefinedRouting.

That one value changes where you should look next. If you skip this step, it is easy to inspect the wrong Azure resource and allowlist an IP that your workloads never use.

Load Balancer Clusters

For clusters that use loadBalancer, AKS exposes the effective outbound public IP resources in the load balancer profile. First get the resource IDs, then resolve those IDs to actual IPv4 addresses.

1RESOURCE_GROUP=my-rg
2CLUSTER_NAME=my-aks
3
4az aks show \
5  --resource-group "$RESOURCE_GROUP" \
6  --name "$CLUSTER_NAME" \
7  --query "networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id" \
8  -o tsv

That returns one or more Azure resource IDs. Convert them to the concrete IP values:

1RESOURCE_GROUP=my-rg
2CLUSTER_NAME=my-aks
3
4az aks show \
5  --resource-group "$RESOURCE_GROUP" \
6  --name "$CLUSTER_NAME" \
7  --query "networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id" \
8  -o tsv |
9while read -r PUBLIC_IP_ID; do
10  az network public-ip show \
11    --ids "$PUBLIC_IP_ID" \
12    --query "ipAddress" \
13    -o tsv
14done

If you see multiple addresses, that is normal. AKS can distribute outbound connections across more than one public IP.

NAT Gateway Clusters

If the cluster uses managedNATGateway or userAssignedNATGateway, the outbound IPs come from the NAT gateway profile instead of the load balancer profile. The query path is different, but the pattern is the same.

1RESOURCE_GROUP=my-rg
2CLUSTER_NAME=my-aks
3
4az aks show \
5  --resource-group "$RESOURCE_GROUP" \
6  --name "$CLUSTER_NAME" \
7  --query "networkProfile.natGatewayProfile.effectiveOutboundIPs[].id" \
8  -o tsv |
9while read -r PUBLIC_IP_ID; do
10  az network public-ip show \
11    --ids "$PUBLIC_IP_ID" \
12    --query "ipAddress" \
13    -o tsv
14done

This is the most direct way to answer the operational question, which is not "what Azure resource exists" but "which public IPs does the cluster actually use for egress right now".

A compact version that branches on outboundType is often useful in runbooks:

1RESOURCE_GROUP=my-rg
2CLUSTER_NAME=my-aks
3
4OUTBOUND_TYPE=$(az aks show \
5  --resource-group "$RESOURCE_GROUP" \
6  --name "$CLUSTER_NAME" \
7  --query "networkProfile.outboundType" \
8  -o tsv)
9
10case "$OUTBOUND_TYPE" in
11  loadBalancer)
12    QUERY="networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id"
13    ;;
14  managedNATGateway|userAssignedNATGateway)
15    QUERY="networkProfile.natGatewayProfile.effectiveOutboundIPs[].id"
16    ;;
17  *)
18    echo "Inspect the external egress path for outbound type: $OUTBOUND_TYPE" >&2
19    exit 1
20    ;;
21esac
22
23az aks show \
24  --resource-group "$RESOURCE_GROUP" \
25  --name "$CLUSTER_NAME" \
26  --query "$QUERY" \
27  -o tsv |
28while read -r PUBLIC_IP_ID; do
29  az network public-ip show --ids "$PUBLIC_IP_ID" --query "ipAddress" -o tsv
30done

When AKS Is Not the Source of Truth

If outboundType is userDefinedRouting, AKS itself is not the final owner of the public egress IP. In that model, outbound traffic is usually sent to an Azure Firewall, network virtual appliance, or another custom path defined by the route table.

In that case, use AKS only to confirm the mode, then inspect the real egress device. For example, if a subnet is attached to a NAT gateway, find that gateway from the subnet and then inspect its public IPs:

1SUBNET_ID="/subscriptions/.../subnets/aks-subnet"
2
3NAT_GATEWAY_ID=$(az network vnet subnet show \
4  --ids "$SUBNET_ID" \
5  --query "natGateway.id" \
6  -o tsv)
7
8az network nat gateway show \
9  --ids "$NAT_GATEWAY_ID" \
10  --query "publicIpAddresses[].id" \
11  -o tsv |
12while read -r PUBLIC_IP_ID; do
13  az network public-ip show --ids "$PUBLIC_IP_ID" --query "ipAddress" -o tsv
14done

The operational rule is simple: the outbound IP belongs to the component that performs SNAT. Sometimes that is the AKS-managed load balancer. Sometimes it is a NAT gateway or firewall outside the managed cluster resource.

Common Pitfalls

• Looking only at the Kubernetes Service external IP and assuming it is also the outbound IP.
• Querying the load balancer profile even though the cluster uses a NAT gateway or user-defined routing.
• Allowlisting one public IP when the cluster actually uses several effective outbound IPs.
• Forgetting that changing outboundType changes egress addresses and can break firewall rules.
• Reading the Azure portal load balancer resource directly after a cluster change instead of querying AKS first.

Summary

• Start with az aks show --query "networkProfile.outboundType".
• For loadBalancer, read networkProfile.loadBalancerProfile.effectiveOutboundIPs.
• For NAT gateway based clusters, read networkProfile.natGatewayProfile.effectiveOutboundIPs.
• Convert resource IDs to actual addresses with az network public-ip show.
• For userDefinedRouting, inspect the real egress device because AKS is not the final source of truth.