Network Load Balancer 2nd part

Client Source IP address Preservation

If you use Instance ID as target type, NLB preserves the clients source IP addresses, and provide them to the targets.

On the other hand, If you use the IP address s the target, the source IP addresses are the private IP addresses of the load balancer nodes.

• In this case if your application require the clients source IP address, you can configure Proxy Protocol on the NLB.

If you use Instance ID as target type, NLB preserves the clients source IP addresses, and provides them to the targets.

This will also facilitate controlling client access to target based on Client source IP addresses using normal firewall rules, including VPC Security Groups.

Since the packets will arrive at the Instances with the Clients IP address as the source IP in the packets.

• This implies that EC2 instances MUST have a route to the internet (for Internet-facing NLBs), this can be via a NAT instance/Gateway, or by having the instance in a public subnet with an Internet Gateway.

If you have micro services on instances registered with a Network Load Balancer, you cannot use the load balancer to provide communication between them unless the load balancer is internet-facing or the instances are registered by IP address.

Two load balancers with a service layer sandwiched between them.

The services layer can have NGFWs, Proxies, or 3rd Party load balancers, or even a web tier.

This way you can scale this layer while using fewer Elastic IP addresses.

Proxy Protocol

NLB supports Proxy Protocol v2

• Is configured at the Target group level, and It is disabled by default.

This comes in handy in case targets are referred by IP address and the clients source IP address is required for the applications.

• The applications however, must be able to parse that header from the packets.

When enables, the NLB prepends a proxy protocol header to the TCP data.

• The NLB will not discard or overwrite any existing data, including any proxy protocol headers sent by the client or any other proxies, load balancers, or servers in the network path.
• As in CLB, caution has to be exercised to not receive more than one proxy protocol header.

If the traffic/requests are coming to the NLB from ELB service consumers through a VPC endpoint service.

• The source IP addresses provide to your applications is the NLB nodes private IP addresses.

Health Checks

Network Load Balancers use active and passive health checks to determine whether a target is available to handle requests.

With active health checks, the load balancer periodically sends a request to each registered target to check its status.

• Each load balancer node checks the health of each target, using the health check settings for the target group with which the target is registered.
• After each health check is completed, the load balancer node closes the connection that was established for the health check.

With Passive (Network) health checks, the load balancer observes how targets respond to connections.

• Passive health checks enable the load balancer to detect an unhealthy target before it is reported as unhealthy by the active health checks.
• You cannot disable, configure or monitor passive health checks.

If there are no enabled Availability Zones with a healthy target group, request are routed to targets in all enabled Availability Zones.

If you add a TLS listener to your NLB, AWS ELB performs a listener connectivity test.

• As TLS termination also terminates a TCP connection, a new TCP connection is established between your load balancer and your targets.
• This might be seen as TCP pings for this test from the NLB to the targets that are registered with that TLS listener.
• These TCP pings can be identified, since their source IP address is the NLB’s IP address. Also, the connection do not contain data packets.

Monitoring the NLB- VPC Flow Logs

VPC Flow Logs can be used to capture detailed information about the traffic going to and from your NLB.

Create a flow log for each interface for your load balancer.

• There is one network interface per load balancer subnet.
• The NLB ENIs can be identified as the NLB name exist in their description field.

If the target is registered by instance ID, the connection appears to the instance as a connection from the client.

• Flow logs would also show NACL and Security Group Accept/Reject messages for the different load balancer traffic.

Monitoring the NLB- Access Logs

Access logs can be used to capture detailed information about TLS requests made to the NLB.

• The log files are stored in Amazon S3 buckets.
• Access logs can be used to analyse traffic patterns and to troubleshoot issues with your targets.

Access logs are created only if the load balancer has a TLS listener and they contain information only about TLS requests.

Access logs are disabled by default. You can enable it/disable it at anytime.

There is no additional charge for access logs. Only storage charges apply.

ELB publishes a log file for each load balancer node every 5 minutes.

• Log delivery is eventually consistent.

Cloud Trail

AWS Cloud Trail can be used to capture detailed information about the calls made to the Elastic Load Balancing API and store them as log files in Amazon S3.

These Cloud Trail logs can be used to determine which calls were made, the source IP address where the call came from, who made the call, when the call was made and so on.

Thank you,

Bharathi.