Networking & Content Delivery
Exploring new subnet management capabilities of Network Load Balancer
Introduction
Today Amazon Web Services (AWS) is enhancing subnet management capabilities of Network Load Balancer (NLB). NLBs were previously restricted to only adding subnets in new Availability Zones (AZs), and they now support full subnet management, including removal of subnets, matching the capabilities of Application Load Balancer (ALB). This enhancement offers organizations greater control over their network architecture and brings consistency to AWS load balancing services. In this post, we explore the best practices and implementation guidelines for these new subnet management features.
NLB subnet management flexibility
Prior to this change, during NLB creation, it necessitated specifying at least one subnet in an AZ, which creates an Elastic Network Interface (ENI). Although adding subnets in other AZs was possible, the inability to remove them post-deployment presented some challenges. For example, organizations facing business changes, such as mergers or data sovereignty requirements, found themselves constrained by this limitation. This often resulted in maintaining unused AZs or completely replacing NLBs to modify subnet configurations.
The introduction of the ability to remove subnets using the SetSubnets API changes subnet management for NLBs. This new capability enables you to modify subnet configurations after deployment, allowing you to relocate your load balancer to any desired subnet within your Amazon Virtual Private Cloud (Amazon VPC). This enhanced flexibility provides better control over your network architecture, eliminates the need for complete rebuilds, and supports more efficient resource usage.
Considerations when using delete subnet capability
Although this new capability expands flexibility for NLB configuration, we recommend careful consideration to avoid any service disruptions. You should evaluate the potential impact on existing connections and traffic flow.
Before making any subnet changes, make sure that you’ve evaluated the potential impact on existing connections and traffic flow. It’s also crucial to plan the migration timing to minimize any effect on your production workloads. Here are some critical factors to consider:
- Removing a subnet deletes the associated ENI, which terminates all active connections in that zone.
- Targets within the AZ being removed from the NLB are marked as “unused”.
- This terminates all active connections to these targets, including connections originating from other AZs when cross-zone load balancing is enabled.
- The NLB’s DNS record has a 60-second DNS TTL (Time-To-Live). When removing an AZ containing targets, clients may experience network timeouts until DNS cache expires by exceeding the TTL and resolves for an updated record, after which traffic redistributes to the remaining AZs.
- Plan for sufficient capacity in the remaining zones to handle the load increase.
- If you are re-adding a previously removed subnet, then a new network interface is created with a different ID. This doesn’t recover previously existing connections.
- Subnet removal isn’t possible if VPC endpoints are associated with that AZ. All zonal VPC endpoint associations must be removed first.
- Subnet changes within the same AZ need separate operations. First you remove the existing subnet, then you add the new one.
- Wait for complete subnet removal before adding new ones. Any premature additions trigger an error indicating the previous subnet is still being removed.
To verify how your clients behave, we recommend testing subnet changes in non-production environments and scheduling modifications during maintenance windows to minimize service impact.
Best practices to remove a subnet
By following these steps, you should be able to complete the subnet removal with minimal service disruption:
1. Identify active IPs in your load balancer’s DNS record.
This is an example using the dig command:
To verify which IP addresses are removed, you can optionally map the IPs to their corresponding subnets. This validation step helps you confirm the correct subnet identification before proceeding with removal. Cross-referencing IP addresses with their subnet locations allows you to make sure you’re targeting the intended subnet for removal. This helps prevent unintended changes to your network configuration:

Figure 1: NLB ENIs
In the example above, we identified that the IP address 10.0.147.176 is located in subnet eu-north-1c, which is the subnet we want to remove from the NLB configuration.
2. Adjust load balancer settings
While this operation is being done, we recommend considering disabling cross-zone load balancing from the load balancer or all target groups that are associated with it. This helps during target deregistration and DNS failover for a smoother transition.

Figure 2: Cross-zone load balancer settings
Furthermore, check the cross-zone settings for each target group associated with the NLB:

Figure 3: Cross-zone target group setting
In the preceding example, the target-group inherits settings from the NLB. When we turn off the cross-zone from NLB, it also takes effect in the Target Group.
3. Make sure your target groups are configured with “Terminate connections on deregistration”. This setting makes sure of a clean connection termination during the removal process.

Figure 4: Target group – Target deregistration management settings
4. Preparing the AZ to be removed:
Consider using use Amazon Application Recovery Controller (ARC) zonal shift to shift away from the AZ being removed. Using ARC provides a smoother transition by shifting traffic before target deregistration.
Verify IP address removal from the DNS record using the following:
After that step, you can proceed to the following:
- Deregister all targets in the AZ to be removed.
- Wait for the deregistration delay interval to allow traffic to drain completely.
Without ARC, DNS changes occur when the target group no longer has targets in the AZ, which occurs during target deregistration. This may cause some client timeouts while they attempt to connect to the IP being removed from the NLB DNS record. The IP address for the AZ being removed should no longer appear in the DNS record before proceeding to the removal step.
5. Now you can remove the subnet using the elbv2 set-subnet command:
Or you can use the Console, find the “Networking mapping” tab and click on “Edit subnets” button. This an example before removing the subnet:

Figure 5: Network Mappings for NLB before the change
Select the subnet to be removed:

Figure 6: Network Mappings for NLB when changing subnets
Click on the “Save changes” button.
6. You can now verify your NLB configuration:

Figure 7: NLB mappings
The NLB is now only present in two subnets, one in eu-north-1a and in eu-north-1b.
After these steps were complete, you can turn cross-zone load balancing back on, if had it turned off on the step 1.
Using specific IP addresses on the new subnet being added to the NLB
When configuring new subnets using the SetSubnet request, you can include SubnetMappings to customize IP address assignments:
- For internet-facing load balancers, designate a specific Elastic IP address for each new subnet, and in dual-stack NLBs, you also have the option to assign an IPv6 address per subnet.
- For internal load balancers, allocate one specific private IP address per subnet, provided that it’s available within the subnet’s IPv4 address range.
Conclusion
This new subnet removal capability support for NLBs provides greater control in managing your AWS infrastructure, allowing you to delete subnets and reconfigure NLB subnets without having to recreate the NLB. Although this feature offers significant benefits for network architecture modifications, successful implementation necessitates careful planning and execution.
Following the best practices outlined here and considering all operational impacts allows you to safely modify your load balancer subnet configurations while minimizing service disruptions. Remember that subnet removal is a potentially disruptive operation that affects active connections, DNS resolution, and target availability. Always test these changes in non-production environments first, and schedule production changes during maintenance windows when possible. Maintaining sufficient capacity across remaining AZs and monitoring system health throughout the process helps make sure of a smooth transition.
These enhancements bring NLB subnet management parity to ALB capabilities, providing a more consistent experience across AWS load balancing. For more information, refer to ELBv2 set-subnet CLI documentation and SetSubnet API.
About the authors