[AWS] Load Balancing

Load balancing is a method used to distribute incoming connections across a group of servers or services.

• Elastic Load Balancing (ELB) automates distributing traffic evenly to all instances in multiple AZs within a region.
  • Cross Zone Load Balancing allows load balancers to cross multiple AZs.
• SSL can be directly applied to ELB – can help reduce the compute power on an EC2 instance.

---

Features

• ELB has its own DNS record, which allows access to outside.
  • ELBs can be paired with Auto Scaling Groups to enhance high availability and fault tolerance.
  • ELB uses the health check – direct requests to only healthy instances.
  • Cross-zone LB can be enabled.
• Load Balancing Target Type
  • EC2 Instances
  • Private IP Addresses
  • Lambda functions – ALB only
  • Application Load Balancers
• “X-Forwarded-For” header is used to identify the originating IP of an end-user through a load balancer.

• Load balancing algorithm – Target Groups
  • Round robin
  • Least outstanding requests
• Sticky Sessions with ELB: EC2 instances need to keep the session info.
  • Load Balancer generated cookie
  • Application generated cookie
  • Non-ELB Option (Recommended)
    • ElastiCache or DynamoDB to find the session

• Error Codes
  • 502 error (Bad Gateway)
    • The target host is unreachable.
  • 504 error (Gateway timed out) is reported when applications do not respond within the idle timeout period.
    • The ELB cannot establish a connection to the target (a web server, a database, or a lambda function).

---

Types of ELB

There are different types of load balancer: Application (ALB), Network (NLB), Classic (CLB), and Gateway (GWLB).

• No granular routing rules. All instances get routed evenly
• Good when all instances contain the same data.
• Operates at Layer 3 & 4 (TCP & SSL) + Some Layer 7 features (X-Forwarded-For header).
• 504 error (Gateway timed out) was reported when applications do not respond.
• DNA A Record is connected to the CLB – 1 SSL Certificate per CLB.
• Offload SSL connection – HTTPS to the load balancer and HTTP to instances

• Supports EC2, ECS, EKS, Lambda, HTTP, HTTPS, and Web Sockets

• Can be integrated with AWS Web Application Firewall (WAF)
• Listeners
  • By using rules (conditions and target groups), you can redirect requests to multiple target groups.
    • Host-based: based on the host field of the HTTP header
    • Path-based: based on the URL path of the HTTP header
• Target Groups -> Targets (Instances)
• ALB needs to be deployed into at least 2 subnets.

• Low latency, source IP address preservation (packets unchanged), best performance
• Capable of handling millions of requests per second – used for extreme performance but expensive
• Targets can be addressed using IP addresses (static IP address or Elastic IP).

• Gateway Load Balancer (GWLB) provides a gateway to distribute traffic across multiple third-party virtual appliances running in AWS.

---

ELB Dynamic Ports

• Classic Load Balancer must statically map port numbers on a container instance.
• The second-generation LBs (ALB and NLB) supports dynamic ports.
• A single EC2 instance can run multiple containers that use randomly assigned ports – these port numbers are not static and may change when the instance restarts.
  • Dynamic ports are controlled by target groups, which track the list of ports.
• Ideal for containerized services (docker, Elastic Container Services (ECS))

---

Monitoring & ELB Access Logs

By default, ELB sends some basic metrics to CloudWatch.

• HealthyHostCount
• UnHealthyHostCount
• RequestCount
• TargetResponseTime
  • The time elapsed, in seconds, after the request leaves the load balancer until a response from the target is received.

ELB Access Logs is an optional feature that captures detailed information about requests.

• Each log contains information such as the time the request was received, the client’s IP address, latencies, request paths, and server responses.
• Captures the logs are stored in the Amazon S3 bucket.
• Each access log file is automatically encrypted using SSE-S3 before it is stored in your S3 bucket and decrypted when you access it. No user action is required.

---

Authenticate Users with ALB

You can configure ALB to authenticate users.

• through OpenID Connect (OIDC) compliant Identity Provider (IdP)
• through the user pools supported by Amazon Cognito
  • use social IdpS, such as Google, Facebook, or Amazon
  • use corporate identities using SAML, Microsoft AD,or LDAP

ALB authentication with CloudFront

You need to set the following settings:

• Forward request headers: CloudFront does not cache responses for authenticated requests
• Query string forwarding and caching: the ALB has access to the query string parameters
• Cookie forwarding: CloudFront forwards all authentication cookies to the ALB