Elastic Load Balancers – AWS

A Load Balancer is just a server that will distribute the request load to a set of downstream servers. We can add more downstream servers & make applications scale horizontally. We use Elastic Load Balancer(ELB) in AWS. AWS will take care of upgrades, maintenance & high availability.

ELB automatically distributes incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones. It monitors the health of its registered targets and routes traffic only to the healthy targets. ELB can be integrated with many AWS services like EC2, ASG, ECS, Route53, and CloudWatch. There are 4 types of ELB,

  • Classic Load Balancer
  • Application Load Balancer
  • Network Load Balancer
  • Gateway Load Balancer

Classic Load Balancer (CLB)

It supports TCP(Layer 4), HTTP & HTTPS(Layer 7). Health Checks are TCP or HTTP based. It is a legacy option & deprecated.

Application Load Balancer (ALB)

It makes routing decisions at the application layer(Layer 7)(HTTP/HTTPS). It distributes incoming application traffic across multiple targets. We can register a target with multiple target groups. Health checks are at the group level.

It supports HTTP/2 and WebSocket and redirects. This will route requests based on URL path, hostname, QueryString &/or headers. Client IP will be inserted in the header X-Forward-For. We can get Port & Protocol from X-Forwarded-Port & X-Forwarded-Proto respectively

Network Load Balancer(NLB)

It allows forwarding TCP & UDP traffic to our instances. Handles millions of requests per second. Less latency(~100ms) compared to ALB(400ms).NLB has one static IP per AZ and supports assigning Elastic IP(helpful for whitelisting specific IP)

Gateway Load Balancer(GWLB)

Gateway Load Balancers enable you to deploy, scale, and manage virtual appliances, such as firewalls, intrusion detection and prevention systems, and deep packet inspection systems.

It combines a transparent network gateway (that is, a single entry and exit point for all traffic) and distributes traffic while scaling your virtual appliances with the demand.

The Gateway Load Balancer and its registered virtual appliance instances exchange application traffic using the GENEVE protocol on port 6081. It supports a maximum transmission unit (MTU) size of 8500 bytes.

Common Load Balancer Errors: Error 504 Gateway Timeout – The target(downstream or web or application server) failed to respond.

If you want to understand the difference between these load balancer types, please visit this page from AWS documentation.

Stick Sessions for ALB

We can use the sticky session feature (also known as session affinity) to enable the load balancer to bind a user’s session to a specific target.

This feature is useful for servers that maintain state information in order to provide a continuous experience to clients. To use sticky sessions, the client must support cookies. Enabling stickiness may bring imbalance to the load over the backend EC2 instance.

ALB supports both,

  • Application-based cookies
  • Duration-based cookies
  • Application-based cookies
    • Custom cookie – Generated by the target
      • Can include any custom attributes required by the application
      • Cookie name must be specified individually for each target group
      • Don’t use AWSALB, AWSALBAPP, or AWSALBTG (reserved for use by the ELB)
    • Application cookie – Generated by the load balancer
      • The cookie name is AWSALBAPP
  • Duration based Cookies
    • The cookie generated by the load balancer
    • Cookie name is AWSALB for ALB, AWSELB for CLB

Cross zone load balancing

  • Cross zone load balancing enabled: Distributes evenly across all registered instances in all AZ
  • Cross zone load balancing not enabled: Distributed in the instances of the node of the elastic load balancer.

It’s enabled in ALB by default. No Charges for inter AZ data transfers. But it’s disabled in NLB & CLB. We have to pay charges for inter AZ data transfer if we want to enable it in NLB. No charges for CLB.

SSL certificates

The load balancer uses an X.509 certificate (SSL/TLS server certificate). We can manage certificates using ACM (AWS Certificate Manager). We can also create and upload our own certificates. When we set HTTPS listener, we must specify a default certificate. Then we can add an optional list of certs to support multiple domains. Clients can use SNI (Server Name Indication) to specify the hostname they reach.

SNI – Server Name Indication

SNI solves the problem of loading multiple SSL certificates onto one web server(to serve multiple websites). It’s a newer protocol and requires the client to indicate the hostname of the target server in the initial SSL handshake. The server will then find the correct certificate or return the default one. It only works for ALB & NLB & CloudFront. Doesn’t work for CLB

Connection Draining

To ensure that a Classic Load Balancer stops sending requests to instances that are de-registering or unhealthy, while keeping the existing connections open, use connection draining. It’s also called Deregistration Delay in ALB & NLB.

This enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy.

The maximum timeout value can be set between 1 and 3,600 seconds (the default is 300 seconds). If we set this as ), this will be disabled.

Security Group

We can configure the Security Group for both application & load balancer. We can allow the requests from any IP address in the load balancer security group. In the application security group, we can allow requests only from the load balancer by linking the load balancer security group to the source. If you want to know more about security groups, please visit this blog.

Access logs for Application Load Balancer

Elastic Load Balancing provides access logs that capture detailed information about requests sent to our load balancer. Each log contains information such as

  • The time the request was received
  • The client’s IP address
  • Latencies
  • Request paths
  • Server responses.

We can use these access logs to analyze traffic patterns and troubleshoot issues.

Access logging is an optional feature of Elastic Load Balancer. It is disabled by default. After we enable it, Elastic Load Balancing captures the logs and stores them in the Amazon S3 bucket that we specify as compressed files. We can disable access logging at any time.