AKS Egress Patterns: UDR Through Firewall vs Managed NAT vs ALB

AKS lets you choose the cluster's --outbound-type at create time. Most teams accept the default and discover later that the default doesn't fit. Here are the four options ranked by use case:

1. loadBalancer (default)

Egress via a Standard Load Balancer with a few PIPs. Fine for small clusters. SNAT ports ≈ 1,024 per backend pool member — exhausts quickly on chatty workloads. Use it for dev only.

2. managedNATGateway

AKS provisions and owns a NAT Gateway. ~64,512 ports per PIP × up to 16 PIPs. No firewall in the picture, but huge SNAT scale. Best fit when:

• You don't need L7 outbound inspection.
• You're comfortable with public egress IPs from the NAT GW.

3. userAssignedNATGateway

Same as managed, but you bring your own NAT Gateway in your spoke. Useful when egress IPs need to be allowlisted by partners and you want to manage the prefix yourself.

4. userDefinedRouting (the hub-spoke pattern)

You attach a route table to the AKS subnet that sends 0.0.0.0/0 through the hub firewall. The firewall handles SNAT and egress rules. NAT Gateway can be downstream of the firewall for SNAT scale.

This is the standard enterprise pattern. It costs more (Firewall is ~$300/month) but you get:

• L7 inspection of all outbound traffic.
• Centralized rule management across many spokes.
• Auditable, predictable egress IPs.

The decision tree

If "every cluster needs the same outbound rules and audit trail" → UDR. If "I just need lots of SNAT ports" → managed NAT Gateway. If "this is a dev sandbox" → leave the default and don't think about it.