Please enable JavaScript.
Coggle requires JavaScript to display documents.
ELB - Coggle Diagram
ELB
-
Network Load Balancer
Target Group
- Routes requests to one or more registered targets, such as EC2, using protocol and port you specify
- If no instances are healthy in the Target Group the NLB allows traffic to all targets in all enabled Availability Zones, regardless of their health status (ELB opens fail)
Ports and Protocol
- Protocols: TCP, TLS, UDP, TCP_UDP
- Ports: 1- 65535
- Basically any Protocols and Ports
- TCP_UDP means the listener support both protocols, so the Target Group must support TCP_UDP as well
Listener
- Checks for connection requests from clients, using the protocol and port you configure
- Forwards the request to the Target Group. There are no Rules, unlike the ALB
Encryption
- Use a TLS Listener to offload to your NLB the encryption / decryption
- When you create a TLS listener, you must specify at least one certificate (default certificate). If you specify additional certificates in a certificate list to host multiple secure applications through a single load balancer
- Support SNI (Server Name Indication)
- If you need to pass encrypted traffic to targets without the load balancer decrypting it, create a TCP listener on port 443
Request Received
- After a NLB receives a connection request, it selects a target from the Target Group
- It attempts to open a TCP/UDP connection to the selected target on the port specified in the listener
- NLB are best for load balancing of TCP traffic where extreme performance is required
- Operating at Layer 4 NLB can handle millions of requests per seconds, while maintaining ultra-low latency
- Use NLB for protocols not supported by ALB
- By default has one static IP address per AZ for the NLB, or assign one Elastic IP address per subnet enabled for the NLB
- Support for routing requests to multiple applications on a single EC2 instance (register each instance or IP address with the same target group using multiple ports)
- CANNOT enable or disable AZ for a NLB after you create it
- Preserves the client-side source IP
- Access logs and store it to S3
-
Health Check
Supported protocols are HTTP, HTTPS, and TCP. The default is the TCP protocol
For HTTP or HTTPS health check requests, the host header contains the IP address of the load balancer node and the listener port, not the IP address of the target and the health check port
DNS Name
- Regional NLB DNS name returns the IP addresses for all NLB nodes in all enabled AZs
- my-nlb-1234567890abcdef.elb.us-east-1.amazon.aws.com
- Zonal DNS Name NLB has DNS names for each node
- us-east-1a.my-nlb-1234567890abcdef.elb.us-east-1.amazon.aws.com
Sticky Sessions
- Enables your user session to stick to the same EC2 instance
- Can be useful if you are storing information locally to that instance
- If you are using CLB and remove an EC2 instance from a pool the CLB continues to direct traffic to that EC2 instance
- To solve a scenario like this, disable sticky session
- You can enable Sticky Sessions for ALB
- If you are using ALB with Sticky Sessions you are not affected by CLB's issue, as traffic is sent at the target group level
To use sticky sessions, the client must support cookies
-
Sticky Sessions vs Target Group Stickiness
- Sticky Sessions makes sure that the requests from a client are always sticking to a particular target within a target group
- Target group stickiness only ensures the requests are sent to a particular target group
- Sticky sessions can be used in conjunction with the target group level stickiness (Use Case: Blue/green deployments)
When scaling up, if the number of targets increases considerably, there is potential for unequal distribution of load due to stickiness. To rebalance:
- Set an expiry on the cookie generated by the application that is prior to the current date and time - This will prevent clients from sending the cookie to the ALB, which will restart the process of establishing stickiness
- Set a very short duration on the load balancer’s application-based stickiness configuration, for example, 1 second. This forces the ALB to reestablish stickiness even if the cookie set by the target has not expired
Basics
Distributes incoming application traffic across targets, such as EC2 instances. This can be done across multiple AZs
Types of ELB
Network Load Balancer >> "performance"
- Operates at layer 4 (connection level)
- Handles millions of requests per second, while maintaining ultra-low latencies
Classic Load Balancer >> "test/dev"
- Legacy solution
- Balances TCP, TLS and HTTP/HTTPs application using layer 7 specific features such as X-Forwarded-For and sticky sessions
Application Load Balancer >> "intelligent"
- Best suited for load balancing of HTTP, HTTPs, Websocket and gRPC traffic
- Operates at layer 7 and are application-aware
Gateway Load Balancer
- Layer 3 Load Balancer
- Use it to deploy and manage third party virtual appliances that support GENEVE (a network virtualisation standard)
Health Check
-
-
-
- The ELB performs health checks on all registered instances regardless the status of the instances
- The ELB routes request only to the healthy instances
- When ELB determines an instance is unhealthy, it stops routing requests to that instance but it keeps testing the health status
- ELB resumes routing requests to the instance when it has been restored to a healthy state
- If a target group contains only unhealthy targets, the ELB routes requests to all targets, regardless of their health status (ELB fails-open)
When you create an "external" load balancer, you must specify one public subnet from at least two AZ. You can specify only one public subnet per Availability Zone
Cross Zone Load Balancing – when enabled, each load balancer node distributes traffic across the registered targets in all enabled AZs
Classic Load Balancer
X-Forwarded-For
When traffic is sent from a LB, the server access log contains the IP Address of the LB/proxy
To see the original client IP Address the X-Forward-For request header is used
Gateway Timeouts
If your application stops responding, the CLB returns a 504 Error this means the gateway has timed out
This means the application is having an issue. This could be either the web/app server layer or the database layer
- Legacy Load Balancer, use it for dev/test
- Balance HTTP/HTTPs applications
- Use Layer 7 specific features such as X-Forward-For and Sticky Sessions
- Use strict Layer 4 balancing for app that rely purely on TCP
- Support for HTTP, HTTPS, TCP and TLS
- Only internet-facing load balancer
SSL Certificates
- I can only have a single SSL certificate
- Can have multiple SAN (Subject Alternate Name)
- BUT every time you need add / edit / remove SAN the certificate MUST be changed
- THUS it is recommended to use ALB with SNI
- Use multiple CLBs if you want to have distinct SSL certificates
- Only way to use 2-way SSL authentication is TCP to TCP
Deregistration Delay
- ALB >> Deregistration Delay
- CLB >> Connection Drain
- Allows LB to keep existing connections open if the EC2 instances are de-registered or become unhealthy
- This enables the LB to complete in-flight requests made to instances that are de-registered or unhealthy
You can disable deregistration delay if you want your load balancer to immediately close connections to the instances that are de-registered or have become unhealthy
Gateway Load Balancer
Allows to load balance workloads for 3-rd party virtual appliances running in AWS
- Virtual Appliances from the AWS Marketplace
- Virtual Firewalls from Fortinet, Palo Alto, Juniper, Cisco
- IDS/IPS systems from CheckPoint, TrendMicro, etc.
-
