8.2. High Availability - Load Balancers (ELB, CLB, NLB and ALB).md

Load Balancers

• Requests and responses go through load balancer to EC2
• Benefits
  • Spread load
  • Single point of access (DNS) to your application
  • Fault tolerance: Seamlessly handle failure of downstream instances with health checks
  • Enforce stickiness (sessions) with cookies: same user -> same instance
    • You can control expiration date of the cookie.
    • 📝Load is not spread evenly then: e.g. causes one LB is having 80% CPU, other one 20%.
  • High availability across zones
  • Separate public traffic from private traffic

ELB: Elastic Load Balancer

• ELB is managed load balancer
  • Highly available & AWS guarantees that it'll be working
  • Cheaper to setup your own load balancer but more effort.
  • It is integrated with many AWS offerings / services

CLB: Classic Load Balancer

• Deprecated: (v1 - old generation) - 2009
• Requires one load balancer per application -> very expensive & inefficient
• Has an associated IPv4, IPv6, and dualstack (both IPv4 and IPv6) DNS name
• Cross-zone load balancing

ALB: Application Load Balancer

• Application Load Balancer (ALB) (v2 - new generation) - 2016
• Layer 7 of OSI: HTTP traffic
• Components
  • Target Groups
    • Multiple HTTP applications across multiple machines (target groups)
      • Target type can be an IP-address or an instance.
    • When you create each listener rule, you specify a target group and conditions.
      • When a rule condition is met, traffic is forwarded to the corresponding target group.
    • Chooses target group based on the load & health checks.
    • Stickiness is generated only by ALB and can be enabled at target group level.
  • Listeners (= rules)
    • E.g. if protocol = X, hostname = Y, port = 5, path = /test, query = q=Hello then redirect to target group A.
    • Supported condition types are: host-header, http-header, http-request-method, path-pattern, query-string and source-ip.
• Load balance based on
  1. path (e.g. example.com/users, example.com/payments)
     • called also path patterns or path based routing.
  2. hostname in URL (users.example.com & payments.example.com)
• Very good for micro services & container-based applications (e.g. docker & Amazon ECS)
• Has a port mapping feature to redirect to dynamic port
  • 📝Allows load balancing to multiple applications on the same machine (e.g. ECS containers)
• Supports HTTP/HTTPS & WebSockets
• 💡 Application servers don't see the IP of the client directly
  • By default e.g. EC2 instance sees the private IP of the load balancer, not the client.
    • True IP of the client is inserted in the header X-Forwarded-For, port in X-Forwarded-Port and proto in X-Forwarded-Proto headers.
• ❗📝 Uses DNS name you cannot attach a static IP
  • However you can deploy NLB in front of the ASG to get a static IP.
• Supports authentication
  • From OIDC compliant identity providers such as Google, Facebook and Amazon.
  • It is implemented through an authentication action on a listener rule that integrates with Amazon Cognito to create user pools.

NLB: Network Load Balancer

• v2 - new generation - 2017
• Layer 4 of OSI: TCP traffic
• Allows you to
  • Forward TCP traffic to your instances
  • Very high performance: handle millions of request per seconds with less latency
    • Less latency around 100 ms (vs 400 ms for ALB)
• Uses target groups just like ALB
• Types:
  • Public facing: must attach Elastic IP -> 📝can help whitelist by clients
  • Private facing: Random private IP at time of creation.
• Sees client IP directly
• Can terminate SSL/TLS
• Automatically provides a static IP per AZ to load balancer
  • Enables assigning an Elastic IP to the load balancer per AZ.

NLB vs ALB

Attribute	ALB	NLB
OSI Layer	7	4
Use case	App player, great for dockers	High network performance
Private facing	Private DNS only	Static IP per AZ
Public facing	Public DNS only	Must attach Elastic IP
Protocol	HTTP, HTTPS, WebSockets	All TCP
Latency	≈ 400 ms	≈ 100 ms
Target groups	✓	✓
Client IP visibility for app servers	Sent in headers	Directly
SSL / TLS certificates & termination	✓	✓
To multiple ports on target	✓	✓
To lambda functions	✓	✖
IP/port information	X-forwarded-for header	Proxy protocol

Common functionality

• Static host name (do not resolve and use underlying IP)
• Target can be IP address
  • They allow registering e.g. Instances in a peered VPC
• Pre-warming: Can scale but not instantaneously - contact AWS for a "warm-up"
  • Traffic increases more than 50% in less than 5 minutes -> Faster for ELB to scale up to meet it.
• Have error status codes:
  • 4XX: Client induced errors
  • 📝5XX: Application induced errors (503 -> at capacity or no registered target)
• Can be in multiple availability zones
• You can setup internal (private) or external (public, internet facing) ELBs.
  • ❗ For public facing ELBs: you need one public subnet in each AZ where the ELB is defined
  • Both types of ELB route traffic to the private IP addresses of EC2 instances
• 📝They must span to at least two public subnets.
• 📝Do not have pre-defined IPv4 addresses
  • NLB can have elastic IP but better to resolve to them using a DNS name
• Route traffic across AZ, but not region.
• Health Checks
  • Enable load balancer to know if instances it forwards traffic are available to reply to requests.
    • ELB won't send traffic to unhealthy (crashed) instances
  • The health check is done on a port and a route (/health is common)
  • By default, response is not 200 (OK), then the instance is unhealthy
    • You can customize health checks e.g. healthy threshold, unhealthy threshold, timeout, interval, success codes.
• Cross load balancing
  • If disabled:
    • Traffic is distributed evenly to multiple AZ's
    • E.g. for 2 AZ: 50% 50, 5 instances in first AZ share 50% of traffic (under-utilization), 1 instance in second gets 50% (over-utilization)
  • If enabled: Traffic is distributed evenly to instances as if they're on same AZ.
  • Always on in ALB, can be enabled in NLB/ALB.
• Connection Draining
  • Enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy.
    • Keeps existing connection open when instances are de-registering/unhealthy to get last response.
    • Stops sending new requests though.

Security

• Load Balancer Security Group
  • LBS must have security group attached to it.
    • 💡📝 If LB can't connect to your application, check your security group.
    • 💡📝 If you don't want your instance IP to be publicly available ->
    • Allow inbound traffic in instance security group only for load balancer security group
  • Usually:
    • In LB, allow inbound HTTP (TCP 80) & HTTPS (TCP 443) from anywhere
    • In instance, allow HTTP (TCP 80) from LB
• Monitoring
  • CloudWatch
    • Sent from ELB to CloudWatch every 1 to 5 minutes (1 when requests are active)
  • Access Logs is an optional feature that logs to S3.
    • Logs useful information for debugging and auditing.
    • E.g. protocol, timestamp, client and target (port & ip), request size, user agent, processing time.

SSL Termination

• SSL Termination: HTTPS is not needed internally as LB (network & application) can terminate SSL/TLS.
• You can manage certificates using ACM (AWS Certificate Manager) on Load Balancer
  • 📝Alternatively you can create & upload your own certificates.
• Supports Perfect Forward Secrecy (new SSL key per session).
• For HTTPS listener:
  • You must specify a default certificate
  • You 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 is an extension of the TLS protocol.
    • 📝 Allows clients to map many domain names & certificates in one IP.
    • Only available in Application Load Balancer and CloudFront.
    • You can have unique certificates for each domain (i.e. many certificates) while those domains share the same IP
    • Indicates requested hostname from the browser at the beginning of the 'handshake' process.
    • How it works in SSL/TLS?
      1. Browser require a digital certificate from the server, before it even knows what page the browser wishes to access.
         • Web server checks IP address to see target website of user.
         • Web server send the right certificate to the browser or client.
         • ❗ Problem: IP addresses are limited, can be problematic to require every website to have IP
           • 💡 SNI solves this: the browser communicates directly the hostname instead of just IP so that web server can respond with right certificate
      2. Browser then compares the name on the certificate from the server with the name of the page it is trying to make a connection with.
      3. If the names match, the connection will be made in an ordinary way.
         • The names do not match > A warning message that could indicate a man-in-the-middle attack.