I. Introduction

  1. Distributes incoming application or network traffic across multiple "targets" including EC2, Lambdas, ECS etc.
  2. When you create an ELB, you must specify one public subnet from at least two AZs (one public subnet per AZ).
  3. Enable deletion protection to prevent your load balancer from being deleted accidentally.
  4. Deleting ELB won't delete the instances registered to it.
  5. You can perform load balancing on ports 1-65535
  6. Inherent ability to detect unhealthy instances

II. HA

  1. High Availability (HA) means running your application in at least two data centers (== AZ). The goal of HA is to survive a data center loss.

  2. Load balancers (LB) are servers that forward internet traffic to multiple servers (EC2 instances) downstream.

  3. Uses of LB

    1. Spread load across multiple downstream instances
    2. Expose a single point of access (DNS) to your application
    3. Seamlessly handle failures of downstream instances
    4. Do regular health checks to your instance
    5. Provide TLS to your apps
    6. Enforce stickiness with cookies
    7. HA across zones
    8. Separate public and private traffic

  4. The health check is done through port and route (/health is a common one)

    1. The instance will be pinged every 5s (can be configured)
    2. If the response is not 200, that instance would be deemed unhealthy

III. Types of ELB

  1. Classic LB (v1, 2009)

    1. Old generation, supports TCP (layer 4) and HTTP/HTTPS (layer 7)
    2. For use with EC2 classic only
    3. Health checks are TCP or HTTP based
    4. Fixed hostname XXX.region.elb.amazonaws.com
    5. Can be used for internet-facing as well as internal apps
    6. Supports IPv6
    7. Does not support SNI
    8. Does not support path-based or HTTP header-based routing

  2. Application LB (v2, 2016)

    1. Supports layer 7 - HTTP, HTTPS

    2. The default routing algorithm is round robin

    3. Supports path based routing (wildcard supported)

      1. myapp.com goes to instance A
      2. api.myapp.com goes to instance B
      3. mobile.myapp.com goes to instance C

    4. Fixed hostname (XXX.region.elb.amazonaws.com)

    5. The application servers don't see IP of client directly — use X-Forwarded-For header

    6. Load balancing to multiple apps on the same machine (containers)

    7. Supports HTTP/2 , websockets and redirects

    8. Routing based on different paths e.g. /user and /posts

    9. Routing based on hostname in URL and query strings

    10. Routing based on HTTP headers and methods

    11. Cross-zone load balancing is ALWAYS enabled

    12. The targets can be lambdas as well

    13. Need detailed HTTP logs → Enable access logs

    14. You are charged for each hour (full or partial) that an ALB is running and the number of Load Balancer Capacity Units (LCU) used per hour.

    15. You are not charged for cross-region data transfer while load balancing

    16. Great for microservices and containers (targets in general)

    17. (Setup video = #78)

    https://prod-files-secure.s3.us-west-2.amazonaws.com/4b1ebf36-c889-4d85-858e-cb2146e77ba5/5cefef5a-1260-43e4-b2a6-41c3f8479f58/Screen_Shot_2020-08-29_at_8.58.42_PM.png

  3. Network LB (new v2, 2017)

    1. Supports layer 4 - TCP, UDP, TLS
    2. Faster than ALB because it operates on layer 4, not 7
    3. Can handle millions of requests per second
    4. Best suited for low-latency and high throughput workloads
    5. Less latency ~100ms (vs 400ms for ALB)
    6. Has one static IP per AZ and supports elastic IP
    7. At least one subnet must be specified, preferably two
    8. Cross-zone load balancing is DISABLED by default
    9. Supports connections from clients over inter-region VPC peering, AWS-managed VPN and third party VPN solutions
    10. You cannot enable/disable AZ after creating the NLB
    11. Preserves client IP so it can be seen by the backend
    12. Automatically provides a static IP per AZ that can be used by the applications as their frontend. Also enables one Elastic IP.

  4. It's recommended to use newer versions.

  5. Any user can talk to ELB but only ELB can talk to EC2. The EC2 instance's security group should be configured such that it can only talk to the ELB.

  6. ELBs can scale but not instantaneously, contact AWS for a warmup

  7. ELB access logs will log all requests (CloudWatch)