Customize cluster egress with outbound types in Azure Kubernetes Service (AKS)

By default, AKS uses a Standard Load Balancer for egress. You can customize this configuration for scenarios that prohibit public IP addresses or require extra egress hops.

This article describes the outbound connectivity types available for AKS clusters.

Limitations

• Setting outboundType requires AKS clusters with a vm-set-type of VirtualMachineScaleSets and load-balancer-sku of Standard.

Outbound types in AKS

You can configure an AKS cluster using the following outbound types: load balancer, NAT gateway, user-defined routes, none, or block. The outbound type affects only the egress traffic of your cluster. For more information, see ingress networking concepts.

Outbound type: Load Balancer

The load balancer is used for egress through an AKS-assigned public IP. An outbound type of loadBalancer supports Kubernetes services of type loadBalancer, which expect egress out of the load balancer created by the AKS resource provider.

If loadBalancer is set, AKS automatically completes the following configuration:

• A public IP address is created for cluster egress.
• The public IP address is assigned to the load balancer resource.
• Backend pools for the load balancer are set up for agent nodes in the cluster.

For more information, see using a standard load balancer in AKS.

Outbound type: NAT Gateway

When you select managedNATGateway or userAssignedNATGateway for outboundType, AKS uses Azure NAT Gateway for cluster egress.

• Select managedNATGateway for AKS-managed virtual networks. Starting with API version 2026-06-01, AKS defaults to StandardV2 in regions where it's available and otherwise uses Standard.
• Select userAssignedNATGateway for bring-your-own virtual networks. Create a NAT gateway before you create the cluster. Both the Standard and StandardV2 NAT Gateway SKUs are supported.

StandardV2 NAT Gateway is recommended because it's zone-redundant by default and offers higher bandwidth and throughput. For more information, see StandardV2 NAT Gateway.

For more information, see using NAT gateway with AKS.

Outbound type: User-Defined Routes

If you set userDefinedRouting, AKS doesn't automatically configure egress paths. You configure the egress path.

You must deploy the AKS cluster into an existing virtual network with a subnet that you configure. Since you're not using a Standard Load Balancer architecture, you must establish explicit egress. Configure a route table with a 0.0.0.0/0 route that points to a gateway or network virtual appliance, and associate the route table with the cluster subnet.

For more information, see configuring cluster egress via user-defined routing.

Outbound type: none

If you set none, AKS doesn't automatically configure egress paths. This option is similar to userDefinedRouting but doesn't require a default route as part of validation.

The none outbound type supports both bring-your-own (BYO) and AKS-managed virtual networks. For a BYO virtual network, deploy the cluster into an existing virtual network with a configured subnet. AKS doesn't create a Standard Load Balancer or other egress infrastructure, so configure any required egress path through a firewall, proxy, gateway, or other custom network component.

Outbound type: block (Preview)

If you set block, AKS configures network rules to block egress traffic from the cluster. This option is useful for highly secure environments where outbound connectivity must be restricted.

When using block:

• AKS ensures that no public internet traffic can leave the cluster through network security group (NSG) rules. VNet traffic isn't affected.
• You must explicitly allow any required egress traffic through extra network configurations.

The block option provides network isolation but requires careful planning to avoid disrupting workloads or dependencies.

Update outboundType after cluster creation

Changing the outbound type after cluster creation deploys or removes resources as required to put the cluster into the new egress configuration.

The following tables show the supported migration paths between outbound types for managed and BYO virtual networks. Each row shows whether the outbound type can be migrated to the types listed across the top. "Supported" means migration is possible, while "Not Supported" or "N/A" means it isn't.

Supported migration paths for managed VNet

The following table lists supported outbound type migration paths for AKS clusters that use AKS-managed virtual networks.

Managed NAT gateway SKU behavior

The following table describes how the managed NAT gateway SKU behaves with API version 2026-06-01 and later.

Supported migration paths for BYO VNet

The following table lists supported outbound type migration paths for AKS clusters that use BYO virtual networks.

Update cluster outbound type with Azure CLI

Update the outbound configuration of your cluster using the az aks update command.

Update cluster from loadBalancer to managedNATGateway with StandardV2

When you use API version 2026-06-01 or later and work in a region with StandardV2 NAT gateway availability, the SKU defaults to StandardV2 for outbound type managedNATGateway.

{
  "properties": {
    "networkProfile": {
      "outboundType": "managedNATGateway"
      }
    }
  }
}

Update cluster from loadBalancer to userAssignedNATGateway in BYO VNet scenario

Before running the update command, associate an existing NAT gateway with the cluster subnet. For full configuration steps, see Create a managed or user-assigned NAT gateway.

az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type userAssignedNATGateway

Related content

• Configure standard load balancing in an AKS cluster
• Configure NAT gateway in an AKS cluster
• Configure user-defined routing in an AKS cluster
• Azure networking UDR overview
• Manage route tables