Elastic Load Balancers
Last updated
Was this helpful?
Last updated
Was this helpful?
There are 4 ELB types:
Application Load Balancers (Layer 7)
Network Load Balancers (Layer 4)
Gateway Load Balancers (Layer 3)
Classic Load Balaners (Layer4/7)
ALB are Layer 7 aware and support only two linsteners: HTTP adn HTTPS.
An Application Load Balancer funtions at the Application Layer - the seventh layer of the Open System Interconnection (OSI) model. After the load balancer receive a request, it evaluates the listener rules in priority order to determinate which rule to apply, and then select a target from the target group for the rule action.
A listener checks for connection requests from clients, using the configured protocol and port.
Rules determine how the load balancer routes requests to the registered targets. When a conditions for a rule are met then its actions are performed. At least a default rule for each listener must be defined.
Target group routes requests to one or more registered targets, such as EC2 instances, using the protocol and port number you specify.
Health check. if you're using an Application Load Balancer (ALB), which is a Layer 7 load balancer, and one of the EC2 instances in the target group fails its health check, the traffic will indeed be routed to the other healthy instance. Here's a more detailed explanation:
Health Check Process:
The ALB performs regular health checks on all registered targets (EC2 instances) in the target group.
These health checks are customizable and can be based on protocols like HTTP, HTTPS, or TCP.
Instance Failure Detection:
If an instance fails its health check, the ALB marks it as unhealthy.
The ALB requires a certain number of consecutive failed checks before marking an instance as unhealthy (this is configurable).
Traffic Routing:
Once an instance is marked as unhealthy, the ALB stops routing new requests to that instance.
All new incoming traffic is automatically routed to the remaining healthy instance(s) in the target group.
Dynamic Adjustment:
This process is dynamic and automatic. No manual intervention is required.
If the unhealthy instance recovers and passes its health checks, the ALB will start routing traffic to it again.
Load Balancing Algorithm:
The ALB uses advanced request routing algorithms to distribute traffic among healthy instances.
Even with one instance down, it continues to balance traffic effectively across remaining healthy instances.
Metrics and Monitoring:
AWS provides metrics and logs to monitor the health status of your instances and the traffic distribution.
Auto Scaling Integration:
If you're using Auto Scaling, it can be configured to replace unhealthy instances automatically.
This behavior ensures high availability and fault tolerance for your application. Even if one instance fails, your service remains available through the other healthy instance(s).
It's important to note that for optimal reliability, it's generally recommended to have more than two instances across multiple Availability Zones when possible. This provides better resilience against both instance failures and potential AZ outages.
Traffic can be routed based on the resource uri path to different AZs.
NLB provides extreme performances (allows tens of thousands concurrent connections).
NLB is a Layer 4 Load balancing (works at Transport layer). After a connection request, the NLB select a target from the target group for the default rule.
It attempts to open a TCP connection to the selected target on the port specified in the listener configuration.
The listener on a NLB then forwards the request to the target group. There are no rules, unlike with ALB.
Protocols supported: TCP, UDP, TLS, TCP_UDP
Ports supported: 1-65535
You can use a TLS listener to offload the work of encryption and decryption to your load balancer so your applications can focus on their business logic.
If the protocol is TLS you must deploy exactly one SSL server certificate on the listener.
Key Features of NLBs at Layer 4:
NLBs can handle TCP, UDP, and TLS traffic.
They're capable of handling millions of requests per second with low latency.
NLBs provide static IP addresses for each Availability Zone, as well as one static IP for the load balancer.
They support zonal isolation, where each load balancer node in the Availability Zone uses an independent IP address.
The correction mainly concerns the IP address allocation. Let me elaborate:
Static IP per Availability Zone: Each NLB node in an Availability Zone gets a static IP address. This means if you have the NLB in three AZs, you'll get three static IP addresses, one for each AZ.
Elastic IP (Optional): You can optionally assign one Elastic IP address per Availability Zone to the NLB, allowing you to keep the same IP address even if you need to recreate the NLB.
Single DNS Name: The NLB is accessed via a single DNS name, which resolves to the node IPs in the enabled Availability Zones.
CLB is the same of ALB (Layer 7 load balancer) but can also use X-Forward-ror and Sticky sessions. Application that relay on TCP protocol and also use Layer 4 load balancing.
X-Forwarded-For request header contains the original IP address of the client.
504 error is Gateway timeout: if your application stops responding, the classing load balancer responds with a 504. This normally means that the application is having an issue at web server layer or database layer.
Deregistration Delay (formerly known as Connection Draining in Classic Load Balancers) is a feature that helps gracefully remove instances from service while completing in-flight requests. This feature ensures a smooth transition when instances are being removed from the load balancer, preventing disruption to end users.
When an instance is being deregistered or becomes unhealthy:
The load balancer stops sending new requests to the instance
Existing in-flight requests are allowed to complete
The instance remains registered until either:
All in-flight requests are completed
The maximum deregistration delay timeout is reached
Classic Load Balancer (CLB): Called "Connection Draining"
Application Load Balancer (ALB): Called "Deregistration Delay"
Network Load Balancer (NLB): Called "Deregistration Delay"
Default timeout: 300 seconds (5 minutes)
Configurable range: 1-3600 seconds (1 second to 1 hour)
Setting to 0 seconds disables the feature
Instance Maintenance
Performing updates or patches
Replacing instances
Scaling down operations
Blue-Green Deployments
Ensures zero downtime during deployments
Allows old instances to complete requests before termination
Auto Scaling Events
Graceful handling of scale-in events
Proper request completion during instance termination
Set Appropriate Timeout Values
Consider your application's average request processing time
Add buffer time for long-running requests
Avoid setting unnecessarily long timeouts
Monitoring
Monitor connection draining status through CloudWatch metrics
Track the number of requests in flight during deregistration
Set up alerts for instances stuck in draining state
Testing
Test deregistration delay during non-peak hours
Verify behavior during deployment processes
Ensure proper timeout configuration
