Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Note
After 31 March 2026, new AKS clusters that use the AKS-managed virtual network option will place cluster subnets into private subnets by default (defaultOutboundAccess = false).
This setting does not impact AKS-managed cluster traffic, which uses explicitly configured outbound paths. It may affect unsupported scenarios, such as deploying other resources (e.g., VMs) into the same subnet.
Clusters using BYO VNets are unaffected by this change. In supported configurations, no action is required.
You can customize egress for an AKS cluster to fit specific scenarios. By default, AKS creates a Standard Load Balancer to be set up and used for egress. However, the default setup may not meet the requirements of all scenarios if public IPs are disallowed or extra hops are required for egress.
This article covers the various types of outbound connectivity that are available in AKS clusters.
Note
You can now update the outboundType after cluster creation.
Important
In nonprivate clusters, API server cluster traffic is routed and processed through the clusters outbound type. To prevent API server traffic from being processed as public traffic, consider using a private cluster, or check out the API Server VNet Integration feature.
Limitations
- Setting
outboundTyperequires AKS clusters with avm-set-typeofVirtualMachineScaleSetsandload-balancer-skuofStandard.
Outbound types in AKS
You can configure an AKS cluster using the following outbound types: load balancer, NAT gateway, or user-defined routing. The outbound type impacts only the egress traffic of your cluster. For more information, see setting up ingress controllers.
Outbound type of loadBalancer
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 of managedNatGateway or userAssignedNatGateway
If managedNatGateway or userAssignedNatGateway are selected for outboundType, AKS relies on Azure Networking NAT gateway for cluster egress.
- Select
managedNatGatewaywhen using managed virtual networks. AKS provisions a NAT gateway and attach it to the cluster subnet. - Select
userAssignedNatGatewaywhen using bring-your-own virtual networking. This option requires that you have a NAT gateway created before cluster creation.
For more information, see using NAT gateway with AKS.
Outbound type of userDefinedRouting
Note
The userDefinedRouting outbound type is an advanced networking scenario and requires proper network configuration.
If userDefinedRouting is set, AKS doesn't automatically configure egress paths. The egress setup is completed by you.
You must deploy the AKS cluster into an existing virtual network with a subnet that is configured. Since you're not using a standard load balancer (SLB) architecture, you must establish explicit egress. This architecture requires explicitly sending egress traffic to an appliance like a firewall, gateway, proxy or to allow NAT to be done by a public IP assigned to the standard load balancer or appliance.
For more information, see configuring cluster egress via user-defined routing.
Outbound type of none
Important
The none outbound type is only available with Network Isolated Cluster and requires careful planning to ensure the cluster operates as expected without unintended dependencies on external services. For fully isolated clusters, see isolated cluster considerations.
If none is set, AKS won't automatically configure egress paths. This option is similar to userDefinedRouting but does not require a default route as part of validation.
The none outbound type is supported in both bring-your-own (BYO) virtual network scenarios and managed VNet scenarios. However, you must ensure that the AKS cluster is deployed into a network environment where explicit egress paths are defined if needed. For BYO VNet scenarios, the cluster must be deployed into an existing virtual network with a subnet that is already configured. Since AKS doesn't create a standard load balancer or any egress infrastructure, you must establish explicit egress paths if needed. Egress options can include routing traffic to a firewall, proxy, gateway, or other custom network configurations.
Outbound type of block (Preview)
Important
The block outbound type is only available with Network Isolated Cluster and requires careful planning to ensure no unintended network dependencies exist. For fully isolated clusters, see isolated cluster considerations.
If block is set, AKS configures network rules to actively block all 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 another level of network isolation but requires careful planning to avoid breaking workloads or dependencies.
Updating 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.
Supported Migration Paths for Managed VNet
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.
| From|To | loadBalancer |
managedNATGateway |
userAssignedNATGateway |
userDefinedRouting |
none |
block |
|---|---|---|---|---|---|---|
loadBalancer |
N/A | Supported | Not Supported | Not Supported | Supported | Supported |
managedNATGateway |
Supported | N/A | Not Supported | Not Supported | Supported | Supported |
userAssignedNATGateway |
Not Supported | Not Supported | N/A | Not Supported | Not Supported | Not Supported |
none |
Supported | Supported | Not Supported | Not Supported | N/A | Supported |
block |
Supported | Supported | Not Supported | Not Supported | Supported | N/A |
Supported Migration Paths for BYO VNet
| From|To | loadBalancer |
managedNATGateway |
userAssignedNATGateway |
userDefinedRouting |
none |
block |
|---|---|---|---|---|---|---|
loadBalancer |
N/A | Not Supported | Supported | Supported | Supported | Not Supported |
managedNATGateway |
Not Supported | N/A | Not Supported | Not Supported | Not Supported | Not Supported |
userAssignedNATGateway |
Supported | Not Supported | N/A | Supported | Supported | Not Supported |
userDefinedRouting |
Supported | Not Supported | Supported | N/A | Supported | Not Supported |
none |
Supported | Not Supported | Supported | Supported | N/A | Not Supported |
Migration is only supported between loadBalancer, managedNATGateway (if using a managed virtual network), userAssignedNATGateway and userDefinedRouting (if using a custom virtual network).
Warning
Migrating the outbound type to user managed types (userAssignedNATGateway or userDefinedRouting) will change the outbound public IP addresses of the cluster.
if Authorized IP ranges is enabled, ensure new outbound IP range is appended to authorized IP range.
Warning
Changing the outbound type on a cluster is disruptive to network connectivity and results in a change of the cluster's egress IP address. If any firewall rules are configured to restrict traffic from the cluster, you need to update them to match the new egress IP address.
Update cluster to use a new outbound type
Note
You must use a version >= 2.56 of Azure CLI to migrate outbound type. Use az upgrade to update to the latest version of Azure CLI.
- Update the outbound configuration of your cluster using the
az aks updatecommand.
Update cluster from loadbalancer to managedNATGateway
az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type managedNATGateway --nat-gateway-managed-outbound-ip-count <number of managed outbound ip>
Update cluster from managedNATGateway to loadbalancer
az aks update --resource-group <resourceGroup> --name <clusterName> \
--outbound-type loadBalancer \
<--load-balancer-managed-outbound-ip-count <number of managed outbound ip>| --load-balancer-outbound-ips <outbound ip ids> | --load-balancer-outbound-ip-prefixes <outbound ip prefix ids> >
Warning
Don't reuse an IP address that is already in use in prior outbound configurations.
Update cluster from managedNATGateway to userDefinedRouting
- Add route
0.0.0.0/0default route table. Please see Customize cluster egress with a user-defined routing table in Azure Kubernetes Service (AKS)
az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type userDefinedRouting
Update cluster from loadbalancer to userAssignedNATGateway in BYO vnet scenario
- Associate nat gateway with subnet where the workload is associated with. Refer to Create a managed or user-assigned NAT gateway
az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type userAssignedNATGateway
Next steps
Azure Kubernetes Service