ELB

Introduction

• Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets.

Feature

• ELB can be internal (private) or external (public).

• Types:

  • Classic-LB (old generation) for HTTP / HTTPS / TCP / TLS

  • Application-LB for HTTP / HTTPS / WebSocket.

  • Network-LB for TCP / TLS / WebSocket /UDP

• CLB

  • Health check can be HTTP (layer 7), TCP (layer 4).

  • Support only one SSL Certificate

    • One SSL Certificate can have many SAN (Subject Alternate Name), but the SSL Certificate must be changed (re-authenticate and re-provision) for any SAN modification.

    • Better to use ALB with SNI (Server Name Indication - many CAs on one server, to return correct CA according to clients requests)

    • Can use multiple CLB if need distinct SSL Certificate

  • TCP passes all traffic to EC2 instance

    • Only way to use 2-way SSL authentication.

• ALB

  • Works at layer 7.

  • Load balancing to multiple HTTP applications across machines (Target Group).

  • Load balancing to multiple applications on the same machine (ex. containers)

  • Supports redirects (ex. from HTTP to HTTPS).

  • Routing to different Target Groups:

    • Based on path in URL

      • Ex. host/users --> Target Group to ECS. Then host/something --> invoking Lambda.

    • Based on hostname in URL

    • Based on query strings, HTTP Headers, CIDR blocks.

  • Has Port Mapping feature to redirect to a dynamic port in ECS.

  • In comparison, Multiple CLB are needed for many applications due to lacking of Port Mapping.

  • Good fit for Micro-services & container-based application.

  • Target Group:

    • EC2 instances (can be managed by an ASG)

    • ECS tasks (managed by ECS)

    • Lambda (HTTP request translated into JSON event)

    • IP Addresses (must be private IPs. Ex. instances in peered VPC, on-premise)

    • ALB can route to multiple Target Group

  • Health checks are at the Target Group level

  • SSL Certificate:

    • Supports multiple listeners

    • Supports SNI (Server Name Indication)

• NLB

  • Works at layer 4

  • can forward TCP / UDP traffic to instances

  • can handle millions of requests per seconds

  • Lesser latency ~ 100 ms (vs 400 ms for ALB)

  • has one static IP per AZ, and supports assigning Elastic IP. (helpful for whitelisting specific IP)

  • Supports SNI

  • Good fit for extreme performace, TCP, UDP traffic or with AWS PrivateLink to expose a service internally.

  • Target Groups:

    • EC2 instances (can be managed by an ASG)

    • ECS tasks (managed by ECS)

    • IP addresses (Private IP only, even outside your VPC.)

• Proxy Protocol Mode

  • Availabe in CLB / NLB, due to it's Layer 4.

  • Send additional connection information such as the source and destination

  • The load balancer prepends a proxy protocol header to the TCP data

  • Helpful when you have the "IP address" Target Group type

    • can retrieve the source IP of the originating client

• Cross-zone load balancing feature

  • When enabled, balancers in different AZs would try to send requests evenly to instances across AZs. Otherwise, Each balancer send requests evenly to instance in its AZ. (Enable if for balancing EC2 usage across AZs, disable it for cost saving when it comes to NLB.)

  • CLB:

    • By default disabled

    • No charges for inter AZ data if enabled

  • ALB:

    • Always on (can't be disabled)

    • No charges for inter AZ data

  • NLB

    • By default disabled

    • Pay for inter AZ data if enabled

• Stickiness

  • Can implement stickiness for clients to always get redirected to the same instance behind a load balancer

  • This works for CLB, ALB with cookie, and the expiration date to control it.

    • Creates a cookie, named AWSELB to map the session to the instance.

  • Enabling stickiness may bring the imbalance to the instances.

  • Alternative is to cache session data in ElastiCache, DynamoDB for example.

• Instance status monitored by ELB

  • InService

  • OutOfService