# Network Load Balancers A Network Load Balancer serves as the single point of contact for clients. Clients send requests to the Network Load Balancer, and the Network Load Balancer sends them to targets, such as EC2 instances, in one or more Availability Zones. To configure your Network Load Balancer, you create [target groups](load-balancer-target-groups.md), and then register targets with your target groups. Your Network Load Balancer is most effective if you ensure that each enabled Availability Zone has at least one registered target. You also create [listeners](load-balancer-listeners.md) to check for connection requests from clients and route requests from clients to the targets in your target groups. Network Load Balancers support connections from clients over VPC peering, AWS managed VPN, Direct Connect, and third-party VPN solutions. **Topics** + [Load balancer state](#load-balancer-state) + [IP address type](#ip-address-type) + [Connection idle timeout](#connection-idle-timeout) + [Load balancer attributes](#load-balancer-attributes) + [Cross-zone load balancing](#cross-zone-load-balancing) + [DNS name](#dns-name) + [Load balancer zonal health](#load-balancer-zonal-health) + [Create a load balancer](create-network-load-balancer.md) + [Update Availability Zones](availability-zones.md) + [Update the IP address type](load-balancer-ip-address-type.md) + [Edit load balancer attributes](edit-load-balancer-attributes.md) + [Update the security groups](load-balancer-security-groups.md) + [Tag a load balancer](load-balancer-tags.md) + [Delete a load balancer](load-balancer-delete.md) + [View the resource map](view-resource-map.md) + [CloudWatch logs](load-balancer-cloudwatch-logs.md) + [Zonal shift](zonal-shift.md) + [LCU reservations](capacity-unit-reservation.md) ## Load balancer state A Network Load Balancer can be in one of the following states: `provisioning` The Network Load Balancer is being set up. `active` The Network Load Balancer is fully set up and ready to route traffic. `failed` The Network Load Balancer couldn't be set up. ## IP address type You can set the types of IP addresses that clients can use with your Network Load Balancer. Network Load Balancers support the following IP address types: **`ipv4`** Clients must connect using IPv4 addresses (for example, 192.0.2.1). **`dualstack`** Clients can connect to the Network Load Balancer using both IPv4 addresses (for example, 192.0.2.1) and IPv6 addresses (for example, 2001:0db8:85a3:0:0:8a2e:0370:7334). **Considerations** + The Network Load Balancer communicates with targets based on the IP address type of the target group. + To support source IP preservation for UDP IPv6 listeners, ensure that **Enable prefix for IPv6 source NAT** is turned on. + When you enable dualstack mode for the Network Load Balancer, Elastic Load Balancing provides an AAAA DNS record for the Network Load Balancer. Clients that communicate with the Network Load Balancer using IPv4 addresses resolve the A DNS record. Clients that communicate with the Network Load Balancer using IPv6 addresses resolve the AAAA DNS record. + Access to your internal dualstack Network Load Balancer through the internet gateway is blocked to prevent unintended internet access. However, this does not prevent other internet access (for example, through peering, Transit Gateway, AWS Direct Connect, or Site-to-Site VPN). For more information, see [Update the IP address types for your Network Load Balancer](load-balancer-ip-address-type.md). ## Connection idle timeout For each TCP request that a client makes through a Network Load Balancer, the state of that connection is tracked. If no data is sent through the connection by either the client or target for longer than the idle timeout, the connection is no longer tracked. If a client or target sends data after the idle timeout period elapses, the client receives a TCP RST packet to indicate that the connection is no longer valid. The default idle timeout value for TCP flows is 350 seconds, but can be updated to any value between 60-6000 seconds. Clients or targets can use TCP keepalive packets to restart the idle timeout. Keepalive packets sent to maintain TLS connections can't contain data or payload. The connection idle timeout for TLS listeners is 350 seconds and can't be modified. When a TLS listener receives a TCP keepalive packet from either a client or a target, the load balancer generates TCP keepalive packets and sends them to both the front-end and back-end connections every 20 seconds. You can't modify this behavior. While UDP is connectionless, the load balancer maintains UDP flow state based on the source and destination IP addresses and ports. This ensures that packets that belong to the same flow are consistently sent to the same target. After the idle timeout period elapses, the load balancer considers the incoming UDP packet as a new flow and routes it to a new target. Elastic Load Balancing sets the idle timeout value for UDP flows to 120 seconds. This cannot be changed. EC2 instances must respond to a new request within 30 seconds in order to establish a return path. For more information, see [Update idle timeout](update-idle-timeout.md). ## Load balancer attributes You can configure your Network Load Balancer by editing its attributes. For more information, see [Edit load balancer attributes](edit-load-balancer-attributes.md). The following are the load balancer attributes for Network Load Balancers: `access_logs.s3.enabled` Indicates whether access logs stored in Amazon S3 are enabled. The default is `false`. `access_logs.s3.bucket` The name of the Amazon S3 bucket for the access logs. This attribute is required if access logs are enabled. For more information, see [Bucket requirements](enable-access-logs.md#access-logging-bucket-requirements). `access_logs.s3.prefix` The prefix for the location in the Amazon S3 bucket. `deletion_protection.enabled` Indicates whether [deletion protection](edit-load-balancer-attributes.md#deletion-protection) is enabled. The default is `false`. `ipv6.deny_all_igw_traffic` Blocks internet gateway (IGW) access to the Network Load Balancer, preventing unintended access to your internal Network Load Balancer through an internet gateway. It is set to `false` for internet-facing Network Load Balancers and `true` for internal Network Load Balancers. This attribute does not prevent non-IGW internet access (for example, through peering, Transit Gateway, AWS Direct Connect, or Site-to-Site VPN). `load_balancing.cross_zone.enabled` Indicates whether [cross-zone load balancing](#cross-zone-load-balancing) is enabled. The default is `false`. `dns_record.client_routing_policy` Indicates how traffic is distributed among the Network Load Balancers Availability Zones. The possible values are `availability_zone_affinity` with 100 percent zonal affinity, `partial_availability_zone_affinity` with 85 percent zonal affinity, and `any_availability_zone` with 0 percent zonal affinity. `secondary_ips.auto_assigned.per_subnet` The number of [secondary IP addresses](edit-load-balancer-attributes.md#secondary-ip-addresses) to configure. Use to resolve port allocation errors if you can't add targets. The valid range is 0 to 7. The default is 0. After you set this value, you can't decrease it. `zonal_shift.config.enabled` Indicates whether [zonal shift](zonal-shift.md) is enabled. The default is `false`. ## Cross-zone load balancing By default, each Network Load Balancer node distributes traffic across the registered targets in its Availability Zone only. If you turn on cross-zone load balancing, each Network Load Balancer node distributes traffic across the registered targets in all enabled Availability Zones. You can also turn on cross-zone load balancing at the target group level. For more information, see [Cross-zone load balancing for target groups](edit-target-group-attributes.md#target-group-cross-zone) and [Cross-zone load balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing) in the *Elastic Load Balancing User Guide*. ## DNS name Each Network Load Balancer receives a default Domain Name System (DNS) name with the following syntax: *name*-*id*.elb.*region*.amazonaws.com. For example, my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com. If you'd prefer to use a DNS name that is easier to remember, you can create a custom domain name and associate it with the DNS name for your Network Load Balancer. When a client makes a request using this custom domain name, the DNS server resolves it to the DNS name for your Network Load Balancer. First, register a domain name with an accredited domain name registrar. Next, use your DNS service, such as your domain registrar, to create a DNS record to route requests to your Network Load Balancer. For more information, see the documentation for your DNS service. For example, if you use Amazon Route 53 as your DNS service, you create an alias record that points to your Network Load Balancer. For more information, see [Routing traffic to an ELB load balancer](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html) in the *Amazon Route 53 Developer Guide*. The Network Load Balancer has one IP address per enabled Availability Zone. These are the IP addresses of the Network Load Balancer nodes. The DNS name of the Network Load Balancer resolves to these addresses. For example, suppose that the custom domain name for your Network Load Balancer is `example.networkloadbalancer.com`. Use the following **dig** or **nslookup** command to determine the IP addresses of the Network Load Balancer nodes. **Linux or Mac** ``` $ dig +short example.networkloadbalancer.com ``` **Windows** ``` C:\> nslookup example.networkloadbalancer.com ``` The Network Load Balancer has DNS records for its nodes. You can use DNS names with the following syntax to determine the IP addresses of the Network Load Balancer nodes: *az*.*name*-*id*.elb.*region*.amazonaws.com. **Linux or Mac** ``` $ dig +short us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com ``` **Windows** ``` C:\> nslookup us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com ``` ## Load balancer zonal health Network Load Balancers have zonal DNS records and IP addresses in Route 53 for each enabled availability zone. When a Network Load Balancer fails a zonal health check for a particular availability zone, its DNS record is removed from Route 53. Load balancer zonal health is monitored using the Amazon CloudWatch metric `ZonalHealthStatus`, giving you more insight into events that cause a fail-away to implement preventative measure to ensure optimal application availability. For more information see, [Network Load Balancer metrics](load-balancer-cloudwatch-metrics.md#load-balancer-metrics-nlb). Network Load Balancers can fail zonal health checks for multiple reasons, causing them to become unhealthy. See below for common causes of unhealthy Network Load Balancers caused by failed zonal health checks. **Check for the following possible causes:** + There are no healthy targets for the load balancer + The number of healthy targets is less than the configured minimum + There is a zonal shift or zonal auto-shift in progress + Traffic is being automatically shifted to healthy zones due to detected issues # Create a Network Load Balancer A Network Load Balancer takes requests from clients and distributes them across targets in a target group, such as EC2 instances. For more information, see the [Network Load Balancer overview](introduction.md#network-load-balancer-overview). **Topics** + [Prerequisites](#load-balancer-prereqs) + [Create the load balancer](#create-load-balancer) + [Test the load balancer](#test-load-balancer) + [Next steps](#create-load-balancer-next-steps) ## Prerequisites + Decide which Availability Zones and IP address types your application will support. Configure your load balancer VPC with subnets in each of these Availability Zones. If the application will support both IPv4 and IPv6 traffic, ensure that the subnets have both IPv4 and IPv6 CIDRs. Deploy at least one target in each Availability Zone. + Ensure that the security groups for target instances allow traffic on the listener port from client IP addresses (if targets are specified by instance ID) or load balancer nodes (if targets are specified by IP address). For more information, see [Target security groups](target-group-register-targets.md#target-security-groups). + Ensure that the security groups for target instances allow traffic from the load balancer on the health check port using the health check protocol. + If you plan to provide your load balancer with static IP addresses, ensure that each Elastic IP address is from Amazon's pool of IPv4 addresses and that it has the same network border group as the load balancer. + If you plan to utilize QUIC or TCP\$1QUIC listeners ensure that the Network Load Balancer uses the `ipv4` address type and has no security groups associated with it. ## Create the load balancer As part of creating a Network Load Balancer, you'll create the load balancer, at least one listener, and at least one target group. Your load balancer is ready to handle client requests when there is at least one healthy registered target in each of its enabled Availability Zones. ------ #### [ Console ] **To create a Network Load Balancer** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Load Balancers**. 1. Choose **Create load balancer**. 1. Under **Network Load Balancer**, choose **Create**. 1. **Basic configuration** 1. For **Load balancer name**, enter a name for your Network Load Balancer. The name must be unique within your set of load balancers in the Region. It can have a maximum of 32 characters, and contain only alphanumeric characters and hyphens. It must not begin or end with a hyphen, or with `internal-`. 1. For **Scheme**, choose **Internet-facing** or **Internal**. An internet-facing Network Load Balancer routes requests from clients to targets over the internet. An internal Network Load Balancer routes requests to targets using private IP addresses. 1. For **Load balancer IP address type**, choose **IPv4** if your clients use IPv4 addresses to communicate with the Network Load Balancer or **Dualstack** if your clients use both IPv4 and IPv6 addresses to communicate with the Network Load Balancer. 1. **Network mapping** 1. For **VPC**, select the VPC that you prepared for your load balancer. With an internet-facing load balancer, only VPCs with an internet gateway are available for selection. 1. With a dualstack load balancer, you can't add a UDP listener unless **Enable prefix for IPv6 source NAT** is **On (source NAT prefixes per subnet)**. 1. For **Availability Zones and subnets**, select at least one Availability Zone, and select one subnet per zone. Note that subnets that were shared with you are available for selection. If you select multiple Availability Zones and ensure that you have registered targets in each selected zone, this increases the fault tolerance of your application. 1. With an internet-facing load balancer, you can select an Elastic IP address for each Availability Zone. This provides your load balancer with static IP addresses. With an internal load balancer, you can enter a private IPv4 address from the address range of each subnet or let AWS select one for you. With a dualstack load balancer, you can enter an IPv6 address from the address range of each subnet or let AWS select one for you. For a load balancer with source NAT enabled, you can enter a custom IPv6 prefix or let AWS select one for you. 1. **Security groups** We preselect the default security group for the load balancer VPC. You can select additional security groups as needed. If you don't have a security group that meets your needs, choose **create a new security group** to create one now. For more information, see [Create a security group](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html) in the *Amazon VPC User Guide*. **Warning** If you don't associate any security groups with your Network Load Balancer now, you can't associate them later on. **Warning** To utilize QUIC or TCP\$1QUIC listeners, your Network Load Balancer must have no security groups. 1. **Listeners and routing** 1. The default is a listener that accepts TCP traffic on port 80. You can keep the default listener settings, or modify **Protocol** and **Port** as needed. 1. For **Default action**, select a target group to forward traffic to. To add another target group choose **Add target group** and update the weights as needed. If you don't have a target group that meets your needs, choose **Create target group** to create one now. For more information, see [Create a target group](create-target-group.md). 1. (Optional) Choose **Add listener tag** and enter a tag key and a tag value. 1. (Optional) Choose **Add listener** to add another listener (for example, a TLS listener). 1. **Secure listener settings** This section appears only if you add a TLS listener. 1. For **Security policy**, choose a security policy that meets your requirements. For more information, see [Security policies](describe-ssl-policies.md). 1. For **Default SSL/TLS server certificate**, choose **From ACM** as the certificate source. Select a certificate that you provisioned or imported using AWS Certificate Manager. If you don't have an available certificate in ACM but do have a certificate for use with your load balancer, select **Import certificate** and provide the required information. Otherwise, choose **Request new ACM certificate**. For more information, see [AWS Certificate Manager certificates](https://docs.aws.amazon.com/acm/latest/userguide/gs.html) in the *AWS Certificate Manager User Guide*. 1. (Optional) For **ALPN policy**, choose a policy to enable ALPN. For more information, see [ALPN policies](load-balancer-listeners.md#alpn-policies). 1. **Load balancer tags** (Optional) Expand **Load balancer tags**. Choose **Add new tag** and enter a tag key and a tag value. For more information, see [Tags](load-balancer-tags.md). 1. **Summary** Review your configuration, and choose **Create load balancer**. A few default attributes are applied to your Network Load Balancer during creation. You can view and edit them after creating the Network Load Balancer. For more information, see [Load balancer attributes](network-load-balancers.md#load-balancer-attributes). ------ #### [ AWS CLI ] **To create a Network Load Balancer** Use the [create-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-load-balancer.html) command. The following example creates an internet-facing load balancer with two enabled Availability Zones and a security group. ``` aws elbv2 create-load-balancer \ --name my-load-balancer \ --type network \ --subnets subnet-1234567890abcdef0 subnet-0abcdef1234567890 \ --security-groups sg-1111222233334444 ``` **To create an internal Network Load Balancer** Include the `--scheme` option as shown in the following example. ``` aws elbv2 create-load-balancer \ --name my-load-balancer \ --type network \ --scheme internal \ --subnets subnet-1234567890abcdef0 subnet-0abcdef1234567890 \ --security-groups sg-1111222233334444 ``` **To create a dualstack Network Load Balancer** Include the `--ip-address-type` option as shown in the following example. ``` aws elbv2 create-load-balancer \ --name my-load-balancer \ --type network \ --ip-address-type dualstack \ --subnets subnet-1234567890abcdef0 subnet-0abcdef1234567890 \ --security-groups sg-1111222233334444 ``` **To add a listener** Use the [create-listener](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-listener.html) command. For examples, see [Create a listener](create-listener.md). ------ #### [ CloudFormation ] **To create a Network Load Balancer** Define a resource of type [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html). ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal IpAddressType: dualstack Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup Tags: - Key: 'department' Value: '123' ``` **To add a listener** Define a resource of type [AWS::ElasticLoadBalancingV2::Listener](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-listener.html). For examples, see [Create a listener](create-listener.md). ------ ## Test the load balancer After creating your Network Load Balancer, you can verify that your EC2 instances have passed the initial health check, and then test that the Network Load Balancer is sending traffic to your EC2 instances. To delete the Network Load Balancer, see [Delete a Network Load Balancer](load-balancer-delete.md). **To test the Network Load Balancer** 1. After the Network Load Balancer is created, choose **Close**. 1. In the left navigation pane, choose **Target Groups**. 1. Select the new target group. 1. Choose **Targets** and verify that your instances are ready. If the status of an instance is `initial`, it's probably because the instance is still in the process of being registered or it has not passed the minimum number of health checks to be considered healthy. After the status of at least one instance is healthy, you can test your Network Load Balancer. For more information, see [Target health status](target-group-health-checks.md#target-health-states). 1. In the navigation pane, choose **Load Balancers**. 1. Select the new Network Load Balancer. 1. Copy the DNS name of the Network Load Balancer (for example, my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com). Paste the DNS name into the address field of an internet-connected web browser. If everything is working, the browser displays the default page of your server. ## Next steps After you create your load balancer, you might want to do the following: + Configure [load balancer attributes](edit-load-balancer-attributes.md). + Configure [target group attributes](edit-target-group-attributes.md). + [TLS listeners] Add certificates to the [optional certificate list](listener-update-certificates.md#add-certificates). + Configure [monitoring features](load-balancer-monitoring.md). # Update the Availability Zones for your Network Load Balancer You can enable or disable the Availability Zones for your Network Load Balancer at any time. When you enable an Availability Zone, you must specify one subnet from that Availability Zone. After you enable an Availability Zone, the load balancer starts routing requests to the registered targets in that Availability Zone. Your load balancer is most effective if you ensure that each enabled Availability Zone has at least one registered target. Enabling multiple Availability Zones helps improve the fault tolerance of your applications. Elastic Load Balancing creates a Network Load Balancer node in the Availability Zone you choose, and a network interface for the selected subnet in that Availability Zone. Each Network Load Balancer node in the Availability Zone uses the network interface to get an IPv4 address. You can view these network interfaces, but they can't be modified. **Considerations** + For internet-facing Network Load Balancers, the subnets that you specify must have at least 8 available IP addresses. For internal Network Load Balancers, this is only required if you let AWS select a private IPv4 address from the subnet. + You can't specify a subnet in a constrained Availability Zone. However, you can specify a subnet in a non-constrained Availability Zone and use cross-zone load balancing to distribute traffic to targets in the constrained Availability Zone. + You can't specify a subnet in a Local Zone. + You can't remove a subnet if the Network Load Balancer has active Amazon VPC endpoint associations. + When adding back a previously removed subnet, a new network interface is created with a different ID. + Subnet changes within the same Availability Zone must be independent actions. You first complete removing the existing subnet, then you can add the new subnet. + Subnet removal can take up to 3 minutes to complete. When creating an internet-facing Network Load Balancer, you can choose to specify an Elastic IP address for each Availability Zone. Elastic IP addresses provide your Network Load Balancer with static IP addresses. If you choose not to specify an Elastic IP address, AWS will assign one Elastic IP address for each Availability Zone. When creating an internal Network Load Balancer, you can choose to specify a private IP address from each subnet. Private IP addresses provide your Network Load Balancer with static IP addresses. If you choose not to specify a private IP address, AWS assigns one for you. Before updating the Availability Zones for your Network Load Balancer, we recommend you evaluate for any potential impact on existing connections, traffic flows, or production workloads. **Updating an Availability Zone can be disruptive** When a subnet is removed, its associated Elastic Network Interface (ENI) is deleted. This causes all active connections in the Availability Zone to be terminated. After a subnet is removed, all targets within the Availability Zone it was associated with are marked as `unused`. This results in those targets being removed from the available target pool, and all active connections to those targets being terminated. This includes any connections originating from other Availability Zones when utilizing cross-zone load balancing. Network Load Balancers have a 60 second Time To Live (TTL) for their Fully Qualified Domain Name (FQDN). When an Availability Zone that contains active targets is removed any existing client connections may experience timeouts until DNS resolution occurs again, and traffic is shifted to any remaining Availability Zones. ------ #### [ Console ] **To modify the Availability Zones** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Network mapping** tab, choose **Edit subnets**. 1. To enable an Availability Zone, select its check box and select one subnet. If there is only one available subnet, it is selected for you. 1. To change the subnet for an enabled Availability Zone, choose one of the other subnets from the list. 1. To disable an Availability Zone, clear its check box. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To modify the Availability Zones** Use the [set-subnets](https://docs.aws.amazon.com/cli/latest/reference/elbv2/set-subnets.html) command. ``` aws elbv2 set-subnets \ --load-balancer-arn load-balancer-arn \ --subnets subnet-1234567890abcdef0 subnet-0abcdef1234567890 ``` ------ #### [ CloudFormation ] **To modify the Availability Zones** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref new-subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup ``` ------ # Update the IP address types for your Network Load Balancer You can configure your Network Load Balancer so that clients can communicate with the Network Load Balancer using IPv4 addresses only, or using both IPv4 and IPv6 addresses (dualstack). The Network Load Balancer communicates with targets based on the IP address type of the target group. For more information, see [IP address type](network-load-balancers.md#ip-address-type). **Dualstack requirements** + You can set the IP address type when you create the Network Load Balancer and update it at any time. + The virtual private cloud (VPC) and subnets that you specify for the Network Load Balancer must have associated IPv6 CIDR blocks. For more information, see [IPv6 addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) in the *Amazon EC2 User Guide*. + The route tables for the Network Load Balancer subnets must route IPv6 traffic. + The network ACLs for the Network Load Balancer subnets must allow IPv6 traffic. + There are no QUIC or TCP\$1QUIC listeners attached to the Network Load Balancer. ------ #### [ Console ] **To update the IP address type** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Load Balancers**. 1. Select the check box for the Network Load Balancer. 1. Choose **Actions**, **Edit IP address type**. 1. For **IP address type**, choose **IPv4** to support IPv4 addresses only or **Dualstack** to support both IPv4 and IPv6 addresses. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the IP address type** Use the [set-ip-address-type](https://docs.aws.amazon.com/cli/latest/reference/elbv2/set-ip-address-type.html) command. ``` aws elbv2 set-ip-address-type \ --load-balancer-arn load-balancer-arn \ --ip-address-type dualstack ``` ------ #### [ CloudFormation ] **To update the IP address type** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal IpAddressType: dualstack Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup ``` ------ # Edit attributes for your Network Load Balancer After you create a Network Load Balancer, you can edit its attributes. **Topics** + [Deletion protection](#deletion-protection) + [Cross-zone load balancing](#load-balancer-cross-zone) + [Availability Zone DNS affinity](#zonal-dns-affinity) + [Secondary IP addresses](#secondary-ip-addresses) ## Deletion protection To prevent your Network Load Balancer from being deleted accidentally, you can enable deletion protection. By default, deletion protection is disabled for your Network Load Balancer. If you enable deletion protection for your Network Load Balancer, you must disable it before you can delete the Network Load Balancer. ------ #### [ Console ] **To enable or disable deletion protection** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Load Balancers**. 1. Select the name of the Network Load Balancer to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Protection**, enable or disable **Deletion protection**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable or disable deletion protection** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `deletion_protection.enabled` attribute. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=deletion_protection.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable or disable deletion protection** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `deletion_protection.enabled` attribute. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: - Key: "deletion_protection.enabled" Value: "true" ``` ------ ## Cross-zone load balancing With Network Load Balancers, cross-zone load balancing is off by default at the load balancer level, but you can turn it on at any time. For target groups, the default is to use the load balancer setting, but you can override the default by explicitly turning cross-zone load balancing on or off at the target group level. For more information, see [Cross-zone load balancing for target groups](edit-target-group-attributes.md#target-group-cross-zone). ------ #### [ Console ] **To enable or disable cross-zone load balancing for a load balancer** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select the name of the load balancer to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. On the **Edit load balancer attributes** page, turn **Cross-zone load balancing** on or off. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable or disable cross-zone load balancing for a load balancer** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `load_balancing.cross_zone.enabled` attribute. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=load_balancing.cross_zone.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable or disable cross-zone load balancing for a load balancer** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer ](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `load_balancing.cross_zone.enabled` attribute. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: - Key: "load_balancing.cross_zone.enabled" Value: "true" ``` ------ ## Availability Zone DNS affinity When using the default client routing policy, requests sent to your Network Load Balancers DNS name will receive any healthy Network Load Balancer IP addresses. This leads to the distribution of client connections across the Network Load Balancer's Availability Zones. With the Availability Zone affinity routing policies, client DNS queries favor Network Load Balancer IP addresses in their own Availability Zone. This helps improve both latency and resiliency, as clients do not need to cross Availability Zone boundaries when connecting to targets. Availability Zone affinity routing policies only apply to clients resolving the Network Load Balancers DNS name using Route 53 Resolver. For more information, see [ What is Amazon Route 53 Resolver?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html) in the *Amazon Route 53 Developer Guide* **Client routing policies available to Network Load Balancers using Route 53 resolver:** + **Availability Zone affinity** – *100 percent zonal affinity* Client DNS queries will favor Network Load Balancer IP address in their own Availability Zone. Queries may resolve to other zones if there are no healthy Network Load Balancer IP addresses in their own zone. + **Partial Availability Zone affinity** – *85 percent zonal affinity* 85 percent of client DNS queries will favor Network Load Balancer IP addresses in their own Availability Zone, while the remaining queries resolve to any healthy zone. Queries may resolve to other healthy zones if there are no healthy IP addresses in their zone. When there are no healthy IP addresses in any zone, queries resolve to any zone. + **Any Availability Zone** (default) – *0 percent zonal affinity* Client DNS queries are resolved among healthy Network Load Balancer IP addresses across all Network Load Balancer Availability Zones. Availability Zone affinity helps route requests from the client to the Network Load Balancer, while cross-zone load balancing is used to help route requests from the Network Load Balancer to the targets. When using Availability Zone affinity, cross-zone load balancing should be turned off, this ensures the Network Load Balancer traffic from clients to targets remains within the same Availability Zone. With this configuration, client traffic is sent to the same Network Load Balancer Availability Zone, so it's recommended to configure your application to scale independently in each Availability Zone. This is an important consideration when the number of clients per Availability zone, or the traffic per Availability Zone are not the same. For more information, see [Cross-zone load balancing for target groups](edit-target-group-attributes.md#target-group-cross-zone). When an Availability Zone is considered unhealthy, or when a zonal shift is started, the zonal IP address will be considered unhealthy and not returned to clients unless fail open is in effect. Availability Zone affinity is maintained when the DNS record fails open. This helps keep Availability Zones independent and prevent potential cross zone failures. When using Availability Zone affinity, times of imbalance between Availability Zones are expected. It's recommended ensuring your targets are scaling at the zonal level, to support each Availability Zones workload. In cases where these imbalances are significant, it's recommended turning off Availability Zone affinity. This allows even distribution of client connections between all the Network Load Balancer's Availability Zones within 60 seconds, or the DNS TTL. **Before using Availability Zone affinity, consider the following:** + Availability Zone affinity causes changes on all of the Network Load Balancers clients who are using Route 53 Resolver. + Clients aren't able to decide between zonal-local and multi-zone DNS resolutions. Availability Zone affinity decides for them. + Clients aren't provided with a reliable method to determine when they're being impacted by Availability Zone affinity, or how to know which IP address is in which Availability Zone. + When using Availability Zone affinity with Network Load Balancers and Route 53 Resolver, we recommend clients use the Route 53 Resolver inbound endpoint in their own Availability Zone. + Clients will remain assigned to their zone-local IP address until it is deemed fully unhealthy according to DNS health checks, and is removed from DNS. + Using Availability Zone affinity with cross-zone load balancing on can lead to unbalanced distribution of client connections between Availability Zones. It's recommended to configure your application stack to scale independently in each Availability Zone, ensuring it can support zonal clients traffic. + If cross-zone load balancing is on, the Network Load Balancer is subject to cross zone impact. + The load on each of the Network Load Balancers Availability Zones will be proportional to the zonal locations of clients requests. If you don't configure how many clients are running in which Availability Zone, you will have to independently scale each Availability Zone reactively. ### Monitoring It is recommended to track the distribution of connections between Availability Zones, using the zonal Network Load Balancer metrics. You can use metrics to view the number of new and active connections per zone. We recommend tracking the following: + **`ActiveFlowCount`** – The total number of concurrent flows (or connections) from clients to targets. + **`NewFlowCount`** – The total number of new flows (or connections) established from clients to targets in the time period. + **`HealthyHostCount`** – The number of targets that are considered healthy. + **`UnHealthyHostCount`** – The number of targets that are considered unhealthy. For more information, see [CloudWatch metrics for your Network Load Balancer](load-balancer-cloudwatch-metrics.md) ### Enable Availability Zone affinity ------ #### [ Console ] **To enable Availability Zone affinity** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Load Balancers**. 1. Select the name of the Network Load Balancer to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Availability Zone routing configuration**, **Client routing policy (DNS record)**, select **Availability Zone affinity** or **Partial Availability Zone affinity**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable Availability Zone affinity** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `dns_record.client_routing_policy` attribute. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=dns_record.client_routing_policy,Value=partial_availability_zone_affinity" ``` ------ #### [ CloudFormation ] **To enable Availability Zone affinity** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `dns_record.client_routing_policy` attribute. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: - Key: "dns_record.client_routing_policy" Value: "partial_availability_zone_affinity" ``` ------ ## Secondary IP addresses If you experience [port allocation errors](load-balancer-troubleshooting.md#port-allocation-errors-privatelink) and you can't add targets to the target group to resolve them, you can add secondary IP addresses to the load balancer network interfaces. For each zone where the load balancer is enabled, we select IPv4 addresses from the load balancer subnet and assign them to the corresponding network interface. These secondary IP addresses are used to establish connections with targets. They are also used for health check traffic. We recommend that you add one secondary IP address to start with, monitor the `PortAllocationErrors` metric, and add another secondary IP address only if the port allocation errors are not resolved. **Warning** After you add secondary IP addresses, you can't remove them. The only way to release the secondary IP addresses is to delete the load balancer. Before you add secondary IP addresses, verify that there are enough available IPv4 addresses in the load balancer subnets. ------ #### [ Console ] **To add a secondary IP address** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Load Balancers**. 1. Select the name of the Network Load Balancer to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. Expand **Special case attributes**, unlock the **Secondary IP addresses auto assigned per subnet** attribute, and choose the number of secondary IP addresses. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To add a secondary IP address** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `secondary_ips.auto_assigned.per_subnet` attribute. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=secondary_ips.auto_assigned.per_subnet,Value=1" ``` You can use the [describe-network-interfaces](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-network-interfaces.html) command to get the IPv4 addresses for the load balancer network interfaces. The `--filters` parameter scopes the results to the network interfaces for Network Load Balancers and the `--query` parameter further scopes the results to the load balancer with the specified name and displays only the specified fields. You can include additional fields as needed. ``` aws elbv2 describe-network-interfaces \ --filters "Name=interface-type,Values=network_load_balancer" \ --query "NetworkInterfaces[?contains(Description,'my-nlb')].{ID:NetworkInterfaceId,AZ:AvailabilityZone,Addresses:PrivateIpAddresses[*]}" ``` ------ #### [ CloudFormation ] **To add a secondary IP address** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `secondary_ips.auto_assigned.per_subnet` attribute. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: - Key: "secondary_ips.auto_assigned.per_subnet" Value: "1" ``` ------ # Update the security groups for your Network Load Balancer You can associate a security group with your Network Load Balancer to control the traffic that is allowed to reach and leave the Network Load Balancer. You specify the ports, protocols, and sources to allow for inbound traffic and the ports, protocols, and destinations to allow for outbound traffic. If you don't assign a security group to your Network Load Balancer, all client traffic can reach the Network Load Balancer listeners and all traffic can leave the Network Load Balancer. You can add a rule to the security groups associated with your targets that references the security group associated with your Network Load Balancer. This allows clients to send traffic to your targets through your Network Load Balancer, but prevents them from sending traffic directly to your targets. Referencing the security group associated with your Network Load Balancer in the security groups associated with your targets ensures that your targets accept traffic from your Network Load Balancer even if you enable [client IP preservation](edit-target-group-attributes.md#client-ip-preservation) for your Network Load Balancer. You are not charged for traffic that is blocked by inbound security group rules. **Topics** + [Considerations](#security-group-considerations) + [Example: Filter client traffic](#filter-client-traffic-recommended-rules) + [Example: Accept traffic only from the Network Load Balancer](#load-balancer-traffic-only-recommended-rules) + [Update the associated security groups](#update-security-group) + [Update the security settings](#update-security-settings) + [Monitor Network Load Balancer security groups](#monitor-load-balancer-security-groups) ## Considerations + You can associate security groups with a Network Load Balancer when you create it. If you create a Network Load Balancer without associating any security groups, you can't associate them with the Network Load Balancer later on. We recommend that you associate a security group with your Network Load Balancer when you create it. + After you create a Network Load Balancer with associated security groups, you can change the security groups associated with the Network Load Balancer at any time. + Health checks are subject to outbound rules, but not inbound rules. You must ensure that outbound rules don't block health check traffic. Otherwise, the Network Load Balancer considers the targets unhealthy. + You can control whether PrivateLink traffic is subject to inbound rules. If you enable inbound rules on PrivateLink traffic, the source of the traffic is the private IP address of the client, not the endpoint interface. ## Example: Filter client traffic The following inbound rules in the security group associated with your Network Load Balancer allow only traffic that comes from the specified address range. If this is an internal Network Load Balancer, you can specify a VPC CIDR range as the source to allow only traffic from a specific VPC. If this is an internet-facing Network Load Balancer that must accept traffic from anywhere on the internet, you can specify 0.0.0.0/0 as the source. **Inbound** | Protocol | Source | Port range | Comment | | --- | --- | --- | --- | | protocol | client IP address range | listener port | Allows inbound traffic from the source CIDR on the listener port | | ICMP | 0.0.0.0/0 | All | Allows inbound ICMP traffic to support MTU or Path MTU Discovery † | † For more information, see [Path MTU Discovery](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#path_mtu_discovery) in the *Amazon EC2 User Guide*. **Outbound** | Protocol | Destination | Port range | Comment | | --- | --- | --- | --- | | All | Anywhere | All | Allows all outbound traffic | ## Example: Accept traffic only from the Network Load Balancer Suppose that your Network Load Balancer has a security group sg-111112222233333. Use the following rules in the security groups associated with your target instances to ensure that they accept traffic only from the Network Load Balancer. You must ensure that the targets accept traffic from the Network Load Balancer on both the target port and the health check port. For more information, see [Target security groups](target-group-register-targets.md#target-security-groups). **Inbound** | Protocol | Source | Port range | Comment | | --- | --- | --- | --- | | protocol | sg-111112222233333 | target port | Allows inbound traffic from the Network Load Balancer on the target port | | protocol | sg-111112222233333 | health check | Allows inbound traffic from the Network Load Balancer on the health check port | **Outbound** | Protocol | Destination | Port range | Comment | | --- | --- | --- | --- | | All | Anywhere | Any | Allows all outbound traffic | ## Update the associated security groups If you associated at least one security group with a Network Load Balancer when you created it, you can update the security groups for that Network Load Balancer at any time. ------ #### [ Console ] **To update the security groups** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select the Network Load Balancer. 1. On the **Security** tab, choose **Edit**. 1. To associate a security group with your Network Load Balancer, select it. To remove a security group from your Network Load Balancer, clear it. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the security groups** Use the [set-security-groups](https://docs.aws.amazon.com/cli/latest/reference/elbv2/set-security-groups.html) command. ``` aws elbv2 set-security-groups \ --load-balancer-arn load-balancer-arn \ --security-groups sg-1234567890abcdef0 sg-0abcdef0123456789 ``` ------ #### [ CloudFormation ] **To update the security groups** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup - !Ref myNewSecurityGroup ``` ------ ## Update the security settings By default, we apply the inbound security group rules to all traffic sent to the Network Load Balancer. However, you might not want to apply these rules to traffic sent to the Network Load Balancer through AWS PrivateLink, which can originate from overlapping IP addresses. In this case, you can configure the Network Load Balancer so that we do not apply the inbound rules for traffic sent to the Network Load Balancer through AWS PrivateLink. ------ #### [ Console ] **To update the security settings** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select the Network Load Balancer. 1. On the **Security** tab, choose **Edit**. 1. Under **Security setting**, clear **Enforce inbound rules on PrivateLink traffic**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the security settings** Use the [set-security-groups](https://docs.aws.amazon.com/cli/latest/reference/elbv2/set-security-groups.html) command. ``` aws elbv2 set-security-groups \ --load-balancer-arn load-balancer-arn \ --enforce-security-group-inbound-rules-on-private-link-traffic off ``` ------ #### [ CloudFormation ] **To update the security settings** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal EnforceSecurityGroupInboundRulesOnPrivateLinkTraffic: off Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup ``` ------ ## Monitor Network Load Balancer security groups Use the `SecurityGroupBlockedFlowCount_Inbound` and `SecurityGroupBlockedFlowCount_Outbound` CloudWatch metrics to monitor the count of flows that are blocked by the Network Load Balancer security groups. Blocked traffic is not reflected in other metrics. For more information, see [CloudWatch metrics for your Network Load Balancer](load-balancer-cloudwatch-metrics.md). Use VPC flow logs to monitor traffic that is accepted or rejected by the Network Load Balancer security groups. For more information, see [VPC flow logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) in the *Amazon VPC User Guide*. # Tag a Network Load Balancer Tags help you to categorize your Network Load Balancers in different ways. For example, you can tag a resource by purpose, owner, or environment. You can add multiple tags to each Network Load Balancer. If you add a tag with a key that is already associated with the Network Load Balancer, it updates the value of that tag. When you are finished with a tag, you can remove it from your Network Load Balancer. **Restrictions** + Maximum number of tags per resource—50 + Maximum key length—127 Unicode characters + Maximum value length—255 Unicode characters + Tag keys and values are case-sensitive. Allowed characters are letters, spaces, and numbers representable in UTF-8, plus the following special characters: \$1 - = . \$1 : / @. Do not use leading or trailing spaces. + Do not use the `aws:` prefix in your tag names or values because it is reserved for AWS use. You can't edit or delete tag names or values with this prefix. Tags with this prefix do not count against your tags per resource limit. ------ #### [ Console ] **To update the tags for a load balancer** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Load Balancers**. 1. Select the check box for the Network Load Balancer. 1. On the **Tags** tab, choose **Manage tags**. 1. To add a tag, choose **Add tag** and enter the tag key and tag value. Allowed characters are letters, spaces, numbers (in UTF-8), and the following special characters: \$1 - = . \$1 : / @. Do not use leading or trailing spaces. Tag values are case-sensitive. 1. To update a tag, enter new values in **Key** or **Value**. 1. To delete a tag, choose **Remove** next to the tag. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To add tags** Use the [add-tags](https://docs.aws.amazon.com/cli/latest/reference/elbv2/add-tags.html) command. The following example adds two tags. ``` aws elbv2 add-tags \ --resource-arns load-balancer-arn \ --tags "Key=project,Value=lima" "Key=department,Value=digital-media" ``` **To remove tags** Use the [remove-tags](https://docs.aws.amazon.com/cli/latest/reference/elbv2/remove-tags.html) command. The following example removes the tags with the specified keys. ``` aws elbv2 remove-tags \ --resource-arns load-balancer-arn \ --tag-keys project department ``` ------ #### [ CloudFormation ] **To add tags** Define a resource of type [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `Tags` property. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup Tags: - Key: 'project' Value: 'lima' - Key: 'department' Value: 'digital-media' ``` ------ # Delete a Network Load Balancer As soon as your Network Load Balancer becomes available, you are billed for each hour or partial hour that you keep it running. When you no longer need the Network Load Balancer, you can delete it. As soon as the Network Load Balancer is deleted, you stop incurring charges for it. You can't delete a Network Load Balancer if deletion protection is enabled. For more information, see [Deletion protection](edit-load-balancer-attributes.md#deletion-protection). You can't delete a Network Load Balancer if it is in use by another service. For example, if the Network Load Balancer is associated with a VPC endpoint service, you must delete the endpoint service configuration before you can delete the associated Network Load Balancer. Deleting a Network Load Balancer also deletes its listeners. Deleting a Network Load Balancer does not affect its registered targets. For example, your EC2 instances continue to run and are still registered to their target groups. To delete your target groups, see [Delete a target group for your Network Load Balancer](delete-target-group.md). ------ #### [ Console ] **To delete a Network Load Balancer** 1. If you have a DNS record for your domain that points to your Network Load Balancer, point it to a new location and wait for the DNS change to take effect before deleting your Network Load Balancer. For example: + If the record is a CNAME record with a Time To Live (TTL) of 300 seconds, wait at least 300 seconds before continuing to the next step. + If the record is a Route 53 Alias(A) record, wait at least 60 seconds. + If using Route 53, the record change takes 60 seconds to propagate to all global Route 53 name servers. Add this time to the TTL value of the record that is being updated. 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Load Balancers**. 1. Select the check box for the Network Load Balancer. 1. Choose **Actions**, **Delete load balancer**. 1. When prompted for confirmation, enter **confirm** and choose **Delete**. ------ #### [ AWS CLI ] **To delete a Network Load Balancer** Use the [delete-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elbv2/delete-load-balancer.html) command. ``` aws elbv2 delete-load-balancer \ --load-balancer-arn load-balancer-arn ``` ------ # View the Network Load Balancer resource map The Network Load Balancer resource map provides an interactive display of your Network Load Balancers architecture, including its associated listeners, target groups, and targets. The resource map also highlights the relationships and routing paths between all resources, producing a visual representation of your Network Load Balancers configuration. **To view the resource map for your load balancer** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the Network Load Balancer. 1. Choose the **Resource map** tab. ## Resource map components **Map views** There are two views available in the Network Load Balancer resource map: **Overview**, and **Unhealthy Target Map**. **Overview** is selected by default and displays all of your Network Load Balancer's resources. Selecting the **Unhealthy Target Map** view will only display the unhealthy targets and the resources associated to them. The **Unhealthy Target Map** view can be used to troubleshoot targets that are failing health checks. For more information, see [Troubleshoot unhealthy targets using the resource map](load-balancer-troubleshooting.md#troubleshoot-with-resourcemap). **Resource columns** The Network Load Balancer resource map contains three resource columns, one for each resource type. The resource groups are **Listeners**, **Target groups**, and **Targets**. **Resource tiles** Each resource within a column has its own tile, which displays details about that specific resource. + Hovering over a resource tile highlights the relationships between it and other resources. + Selecting a resource tile highlights the relationships between it and other resources, and displays additional details about that resource. + **target group health summary:** The number of registered targets for each health status. + **target health status:** The target's current health status and description. **Note** You can turn off **Show resource details** to hide additional details within the resource map. + Each resource tile contains a link that, when selected, navigates to that resource's details page. + **Listeners** ‐ Select the listeners protocol:port. For example, `TCP:80` + **Target groups** ‐ Select the target group name. For example, `my-target-group` + **Targets** ‐ Select the targets ID. For example, `i-1234567890abcdef0` **Export the resource map** Selecting **Export** gives you the option of exporting the current view of your Network Load Balancer's resource map as a PDF. # CloudWatch logs for your Network Load Balancer Amazon CloudWatch Logs support Network Load Balancer access logs as vended logs, improving observability and simplifying debugging for network traffic patterns. You can analyze Network Load Balancer access logs directly in CloudWatch to gain insights into client connections, traffic distribution, and connection status, helping you identify and troubleshoot network issues faster. You can configure delivery of Network Load Balancer access logs to Amazon CloudWatch Logs, Amazon Data Firehose, and Amazon Simple Storage Service (Amazon S3) with support for Apache Parquet format. **Important** Access logs are created only if the load balancer has a TLS listener, and the logs contain information about TLS requests only. Access logs record requests on a best-effort basis. We recommend that you use access logs to understand the nature of the requests, not as a complete accounting of all requests. **Important** Traditional "legacy" access logs remain available for Network Load Balancer. To manage configurations for legacy access logs, visit your load balancer's **Attributes** tab. For more information on "legacy" Access logs, see [Access logs for your Network Load Balancer](load-balancer-access-logs.md). With this CloudWatch Logs integration, you can track detailed access patterns using CloudWatch Logs Insights queries, create metric filters for monitoring, and review traffic patterns in real time using Live Tail. You can enable CloudWatch Logs for Network Load Balancer access logs from the load balancer's **Integrations** tab in the console. To enable logging, you must be logged in as a user that has certain permissions. Additionally, you must grant permissions to AWS to enable the logs to be sent. For required permissions for each logging destination, see [Enable logging from AWS services. ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) For more information, see [What is Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). For pricing information, see [ Amazon CloudWatch Pricing.](https://aws.amazon.com/cloudwatch/pricing/) # Zonal shift for your Network Load Balancer Zonal shift is a capability in Amazon Application Recovery Controller (ARC). With zonal shift, you can shift a Network Load Balancer resource away from an impaired Availability Zone with a single action. This way, you can continue operating from other healthy Availability Zones in an AWS Region. When you start a zonal shift, your Network Load Balancer stops routing traffic to targets in the affected Availability Zone. Existing connections to targets in the affected Availability Zone are not terminated by zonal shift. It might take several minutes for these connections to complete gracefully. **Topics** + [Before you begin](#zonal-shift-before-you-begin) + [Administrative override](#admin-override) + [Enable zonal shift](enable-zonal-shift.md) + [Start a zonal shift](start-zonal-shift.md) + [Update a zonal shift](update-zonal-shift.md) + [Cancel a zonal shift](cancel-zonal-shift.md) ## Before you begin a zonal shift + Zonal shift is disabled by default and must be enabled on each Network Load Balancer. For more information, see [Enable zonal shift for your Network Load Balancer](enable-zonal-shift.md). + You can start a zonal shift for a specific Network Load Balancer only for a single Availability Zone. You can't start a zonal shift for multiple Availability Zones. + AWS proactively removes zonal Network Load Balancer IP addresses from DNS when multiple infrastructure issues impact services. Always check current Availability Zone capacity before you start a zonal shift. If you use a zonal shift on your Network Load Balancer, the Availability Zone affected by the zonal shift also loses target capacity. + During zonal shift on Network Load Balancers with cross-zone load balancing enabled, the zonal load balancer IP addresses are removed from DNS. Existing connections to targets in the impaired Availability Zone persist until they organically close, while new connections are no longer routed to targets in the impaired Availability Zone. For more information, see [Best practices for zonal shifts in ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. ## Zonal shift administrative override Targets that belong to a Network Load Balancer will include a new status `AdministrativeOverride`, which is independent from the `TargetHealth` state. When a zonal shift is started for a Network Load Balancer, all targets within the zone being shifted away from are considered administratively overridden. The Network Load Balancer stops routing new traffic to administratively overridden targets. Existing connections remain intact until they are organically closed. The possible `AdministrativeOverride` states are: **unknown** State cannot be propagated due to an internal error **no\$1override** No override is currently active on target **zonal\$1shift\$1active** Zonal shift is active in target Availability Zone **zonal\$1shift\$1delegated\$1to\$1dns** This target's zonal shift state is not available through `DescribeTargetHealth` but can be viewed directly through the AWS ARC - Zonal Shift API or console. # Enable zonal shift for your Network Load Balancer Zonal shift is disabled by default and must be enabled on each Network Load Balancer. This ensures that you can start a zonal shift using only the specific Network Load Balancers that you want. For more information, see [Zonal shift for your Network Load Balancer](zonal-shift.md). **Prerequisites** If you enable cross-zone load balancing for the load balancer, every target group attached to the load balancer must meet the following requirements before you can enable zonal shift. + The target group protocol must be `TCP` or `TLS`. + The target group type must not be `alb`. + [Connection termination for unhealthy targets](edit-target-group-attributes.md#unhealthy-target-connection-termination) must be disabled. + The `load_balancing.cross_zone.enabled` target group attribute must be `true` or `use_load_balancer_configuration` (the default). ------ #### [ Console ] **To enable zonal shift** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select the Network Load Balancer. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Availability Zone routing configuration**, for **ARC zonal shift integration**, choose **Enable**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable zonal shift** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `zonal_shift.config.enabled` attribute. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=zonal_shift.config.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable zonal shift** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `zonal_shift.config.enabled` attribute. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-nlb Type: network Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: -Key: "zonal_shift.config.enabled" Value: "true" ``` ------ # Start a zonal shift for your Network Load Balancer Zonal shift in ARC enables you to temporarily move traffic for supported resources away from an Availability Zone so that your application can continue to operate normally with other Availability Zones in an AWS Region. **Prerequisite** Before you begin, verify that you [enabled zonal shift](enable-zonal-shift.md#enable-zonal-shift.title) for the load balancer. ------ #### [ Console ] This procedure explains how to start a zonal shift using the Amazon EC2 console. For steps to start a zonal shift using the ARC console, see [Starting a zonal shift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. **To start a zonal shift** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select the Network Load Balancer. 1. On the **Integrations** tab, expand **Amazon Application Recovery Controller (ARC)** and choose **Start zonal shift**. 1. Select the Availability Zone that you want to move traffic away from. 1. Choose or enter an expiration for the zonal shift. A zonal shift can initially be set from 1 minute up to three days (72 hours). All zonal shifts are temporary. You must set an expiration, but you can update active shifts later to set a new expiration. 1. Enter a comment. You can update the zonal shift later to edit the comment. 1. Select the check box to acknowledge that starting a zonal shift reduces capacity for your application by shifting traffic away from the Availability Zone. 1. Choose **Confirm**. ------ #### [ AWS CLI ] **To start a zonal shift** Use the Amazon Application Recovery Controller (ARC) [start-zonal-shift](https://docs.aws.amazon.com/cli/latest/reference/arc-zonal-shift/start-zonal-shift.html) command. ``` aws arc-zonal-shift start-zonal-shift \ --resource-identifier load-balancer-arn \ --away-from use2-az2 \ --expires-in 2h \ --comment "zonal shift due to scheduled maintenance" ``` ------ # Update a zonal shift for your Network Load Balancer You can update a zonal shift to set a new expiration, or edit or replace the comment for the zonal shift. ------ #### [ Console ] This procedure explains how to update a zonal shift using the Amazon EC2 console. For steps to update a zonal shift using the Amazon Application Recovery Controller (ARC) console, see [Updating a zonal shift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. **To update a zonal shift** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select an Application Load Balancer with an active zonal shift. 1. On the **Integrations** tab, expand **Amazon Application Recovery Controller (ARC)** and choose **Update zonal shift**. This opens the ARC console to continue the update process. 1. (Optional) For **Set zonal shift expiration**, select or enter an expiration. 1. (Optional) For **Comment**, optionally edit the existing comment or enter a new comment. 1. Choose **Update**. ------ #### [ AWS CLI ] **To update a zonal shift** Use the Amazon Application Recovery Controller (ARC) [update-zonal-shift](https://docs.aws.amazon.com/cli/latest/reference/arc-zonal-shift/update-zonal-shift.html) command. ``` aws arc-zonal-shift update-zonal-shift \ --zonal-shift-id 9ac9ec1e-1df1-0755-3dc5-8cf57EXAMPLE \ --expires-in 1h \ --comment "extending zonal shift for scheduled maintenance" ``` ------ # Cancel a zonal shift for your Network Load Balancer You can cancel a zonal shift any time before it expires. You can cancel zonal shifts that you initiate, or zonal shifts that AWS starts for a resource for a practice run for zonal autoshift. ------ #### [ Console ] This procedure explains how to cancel a zonal shift using the Amazon EC2 console. For steps to cancel a zonal shift using the Amazon Application Recovery Controller (ARC) console, see [Canceling a zonal shift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. **To cancel a zonal shift** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select a Network Load Balancer with an active zonal shift. 1. On the **Integrations** tab, under **Amazon Application Recovery Controller (ARC)**, choose **Cancel zonal shift**. This opens the ARC console to continue the cancelation process. 1. Choose **Cancel zonal shift**. 1. When prompted for confirmation, choose **Confirm**. ------ #### [ AWS CLI ] **To cancel a zonal shift** Use the Amazon Application Recovery Controller (ARC) [cancel-zonal-shift](https://docs.aws.amazon.com/cli/latest/reference/arc-zonal-shift/cancel-zonal-shift.html) command. ``` aws arc-zonal-shift cancel-zonal-shift \ --zonal-shift-id 9ac9ec1e-1df1-0755-3dc5-8cf57EXAMPLE ``` ------ # Capacity reservations for your Network Load Balancer Load balancer Capacity Unit (LCU) reservations allow you to reserve a static minimum capacity for your load balancer. Network Load Balancers automatically scale to support detected workloads and meet capacity needs. When minimum capacity is configured, your load balancer continues scaling up or down based on the traffic received, but also prevents the capacity from going lower than the minimum capacity configured. Consider using LCU reservation in following situations: + You have an upcoming event that will have a sudden, unusual high traffic and want to ensure your load balancer can support the sudden traffic spike during the event. + You have unpredictable spiky traffic due to the nature of your workload for a short period. + You are setting up your load balancer to on-board or migrate your services at a specific start time and need start with a high capacity instead of waiting for auto-scaling to take effect. + You are migrating workloads between load balancers and want to configure the destination to match the scale of the source. **Estimate the capacity that you need** When determining the amount of capacity you should reserve for your load balancer, we recommend performing load testing or reviewing historical workload data that represents the upcoming traffic you expect. Using the Elastic Load Balancing console, you can estimate how much capacity you need to reserve based on the reviewed traffic. Alternatively, you can refer to CloudWatch metric **ProcessedBytes** to determine the right level of capacity. Capacity for your load balancer is reserved in LCUs, with each LCU being equal to 2.2Mbps. You can use the Max (**ProcessedBytes**) metric to see the maximum per-minute throughput traffic on the load balancer, then convert that throughput to LCUs using a conversion rate of 2.2Mbps equals 1 LCU. If you don't have historical workload data to reference and cannot perform load testing, you can estimate capacity needed using the LCU reservation calculator. The LCU reservation calculator uses data based on historical workloads AWS observe and may not represent your specific workload. For more information, see [Load Balancer Capacity Unit Reservation Calculator](https://exampleloadbalancer.com/ondemand_capacity_reservation_calculator.html). **Supported Regions** This feature is available only in the following Regions: + US East (N. Virginia) + US East (Ohio) + US West (Oregon) + Asia Pacific (Hong Kong) + Asia Pacific (Singapore) + Asia Pacific (Sydney) + Asia Pacific (Tokyo) + Europe (Frankfurt) + Europe (Ireland) + Europe (Stockholm) **Minimum and maximum values for an LCU reservation** The total reservation request must be at least 2,750 LCU per Availability Zone. The maximum value is determined by the quotas for your account. For more information, see [Load Balancer Capacity Units](load-balancer-limits.md#lcu-quotas). # Request Load balancer Capacity Unit reservation for your Network Load Balancer Before you use LCU reservation, review the following: + LCU reservation is not supported on Network Load Balancers using TLS listeners. + LCU reservation only supports reserving throughput capacity for Network Load Balancers. When requesting a LCU reservation, convert your capacity needs from Mbps to LCUs using the conversion rate of 1 LCU to 2.2 Mbps. + Capacity is reserved at the regional level and is evenly distributed across availability zones. Confirm you have enough evenly distributed targets in each availability zone before turning on LCU reservation. + LCU reservation requests are fulfilled on a first come first serve basis, and depends on available capacity for a zone at that time. Most requests are typically fulfilled within an hour, but can take up to a few hours. + To update an existing reservation, the previous request must be provisioned or failed. You can increase reserved capacity as many times as you need, however you can only decrease the reserved capacity two times per day. + You will continue to incur charges for any reserved or provisioned capacity until they are terminated or cancelled. ------ #### [ Console ] **To request an LCU reservation** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer name. 1. On the **Capacity** tab, choose **Edit LCU Reservation**. 1. Select **Historic reference based estimate**. 1. Select the reference period to view the recommended reserved LCU level. 1. If you do not have historic reference workload, you can choose **Manual estimate** and enter the number of LCUs to be reserved. 1. Choose **Save**. ------ #### [ AWS CLI ] **To request an LCU reservation** Use the [modify-capacity-reservation](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-capacity-reservation.html) command. ``` aws elbv2 modify-capacity-reservation \ --load-balancer-arn load-balancer-arn \ --minimum-load-balancer-capacity CapacityUnits=3000 ``` ------ #### [ CloudFormation ] **To request an LCU reservation** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup MinimumLoadBalancerCapacity: CapacityUnits: 3000 ``` ------ # Update or cancel Load Balancer Capacity Unit reservations for your Network Load Balancer If the traffic patterns for your load balancer change, you can update or cancel the LCU reservation for your load balancer. ------ #### [ Console ] **To update or cancel an LCU reservation** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer name. 1. On the **Capacity** tab, do one of the following: 1. To update the LCU reservation choose **Edit LCU Reservation**. 1. To cancel the LCU reservation, choose **Cancel Capacity**. ------ #### [ AWS CLI ] **To cancel an LCU reservation** Use the [modify-capacity-reservation](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-capacity-reservation.html) command. ``` aws elbv2 modify-capacity-reservation \ --load-balancer-arn load-balancer-arn \ --reset-capacity-reservation ``` ------ # Monitor Load balancer Capacity Unit reservation for your Network Load Balancer **Reservation status** The following are the possible status values for an LCU reservation: + `pending` ‐ Indicates the reservation it is in the process of provisioning. + `provisioned` ‐ Indicates the reserved capacity is ready and available to use. + `failed` ‐ Indicates the request cannot be completed at the time. + `rebalancing` ‐ Indicates an availability zone has been added or removed and the load balancer is rebalancing capacity. **LCU utilization** To determine reserved LCU utilization, you can compare the per-minute `ProcessedBytes` metric with the per-hour `Sum(ReservedLCUs)`. To convert bytes per minute to LCU per hour, use (bytes per min)\$18/60/ (10^6)/2.2. ------ #### [ Console ] **To view the status of an LCU reservation** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer name. 1. On the **Capacity** tab, you can view the **Reservation Status** and **Reserved LCU** value. ------ #### [ AWS CLI ] **To monitor the status of an LCU reservation** Use the [describe-capacity-reservation](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-capacity-reservation.html) command. ``` aws elbv2 describe-capacity-reservation \ --load-balancer-arn load-balancer-arn ``` ------