NLB – Network Application Load Balancer

NLB – Network Load Balancer
-         Choose a Network Load Balancer when you need ultra-high performance, TLS offloading at scale, centralized certificate deployment, support for UDP, and static IP addresses for your application. Operating at the connection level, Network Load Balancers are capable of handling millions of requests per second securely while maintaining ultra-low latencies

-         https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
-         https://medium.com/awesome-cloud/aws-difference-between-application-load-balancer-and-network-load-balancer-cb8b6cd296a4

-         Layer 4; supports TCP and TLS for client requests
-         Fast – can process 1M’s of request/sec; lower latency
-         NLB creates a network interface (eni) for each Availability Zone you enable. Anything coming in over this eni gets balanced across all instances in the VPC
-         Can reference target by IP or EC2 ID. IPs are used for resources outside of AWS. Can’t have the mix of the two in same VPC (IP or EC2)
-         Unique to NL: can gave the load balancing service identifiable by a unique static IP in each availability zone. If NLB is internet facing – this can be an elastic IP. Good if need to hard code IPs on the app instance. Can white list it on the VPC.
-         NLB supports TCP and UDP
-         If multiple apps are running on a single EC2 in VPC – can have the apps exposed to NLB using multiple ports
-         Can balance across ECS containers
-         Health checks are performed on target group level
-         Can use Auto Scaling with NLB – need to register instance by instance ID, not by IP
-         Support incoming request over:
          §  VPC Peering
          §  AWS VPN
          §  3^rd party VPN
-         Access Logs, Cross-Zone Load balancing, Delete Protection – Disabled by default; can enable
-         TLS Listener – SSL offloading; allows for decrypting the encrypted Client->LB on the balancer and then passing on un-encrypted from LB to the target. Need x.509 on the listener
-         Can use WebSockets

Target types
-         The following are the possible target types:
          §  instance - The targets are specified by instance ID
                  §  NLB will preserve the originator (client) IP on all messages sent to target instances. The target response will flow back to the client not via the NLB but via NIC – might have to set up NAT, Security Groups, etc.
          §  ip - The targets are specified by IP address
                  §  The source IP on the messages to the target will be the NLB private IP
                  §  Need to enable Proxy Protocol (not x-forwarded-for!) if the client IP needs to be exposed to the target
-         When the target type is ip, you can specify IP addresses from one of the following CIDR blocks:
          §  The subnets of the VPC for the target group
          §  10.0.0.0/8 (RFC 1918)
          §  172.16.0.0/12 (RFC 1918)
          §  192.168.0.0/16 (RFC 1918)
          §  100.64.0.0/10 (RFC 6598)
-         Important - You can't specify publicly routable IP addresses
-         Lambda is not supported as a target

Health checks
-         Active – NLB periodically sends a request to each target to check the status of the health indicators
-         Passive – NLB monitors the health of the connection to the target; the aim is to identify a potential problem before the health checks report the target as unhealthy. Passive checks are built in and cannot be changed
-         If no target is healthy – requests are sent to all targets in hope that at least one would process
-         Metrics are posted to CloudWatch every 1 min
-         FlowLogs capture traffic going through the each NLB NIC. One NIC per subnet exists. NACL and Security Group rejects get logged.
-         Access Logs – LB specific feature, logs detailed info about requests made to LB. Each log contains information such as the time the request was received, the client's IP address, latencies, request paths, and server responses. You can use these access logs to analyze traffic patterns and to troubleshoot issues. Stored on S3 (charges for storage only apply). Available only for TLS listeners. Disabled by default. A log file for every LB is published every 5 min – eventual consistency (https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/access-log-collection.html)
-         CloudTrail captures all API calls for Elastic Load Balancing as events. The calls captured include calls from the AWS Management Console and code calls to the Elastic Load Balancing API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Elastic Load Balancing

Potential issues
-         NLB does not use connection multiplexing – unlike CLB and ALB. Can have performance effect – the more TCP connections to targets are established – the greater the overhead (handshake, keepalive, etc.)
-         Hairpinning / loopback – of a target tries to access a fellow target via the NLB in the middle, the connection will time out unless the NLB is internet facing (non-internal) and targets registered by IP address
-         NLB does not support Security Groups

-         Security Group on targets needs to allow traffic on the listener port and on the health check port