Note_Tech

All technological notes.

---

Project maintained by simonangel-fong Hosted on GitHub Pages — Theme by mattgraham

AWS Compute - Elatic Load Balancer

Back

• AWS Compute - Elatic Load Balancer
  • Elastic Load Balancer
    • Load Balancer Security Groups
    • Types of load balancer on AWS
      • Classic Load Balancers (v1) 已过时, 不用考
      • Application Load Balancer (v2)
        • Target Groups: http
      • Hands-On: ALB
      • Network Load Balancer (v2)
      • Hands-On: NLB
      • Gateway Load Balancer
    • Sticky Sessions/Session Affinity(Session Data)
      • Cookie Types and Names
      • Hands-On: Stickness Cookie
    • Cross-Zone Load Balancing
    • SSL/TLS
      • SSL Certificates
      • Server Name Indication (SNI): Certificate
      • Hands-on: SSL
    • Connection Draining

---

Elastic Load Balancer

• Load Balancers are servers that forward traffic to multiple servers (e.g., EC2 instances) downstream

• Purpose

  • Spread load across multiple downstream instances
  • Expose a single point of access (DNS) to your application
  • Seamlessly handle failures of downstream instances
  • Do regular health checks to your instances
    • When you enable ELB Health Checks, your ELB won’t send traffic to unhealthy (crashed) EC2 instances.
  • Provide SSL termination (HTTPS) for your websites
  • Enforce stickiness with cookies
  • High availability across zones
  • Separate public traffic from private traffic

---

• An Elastic Load Balancer is a managed load balancer

  • AWS guarantees that it will be working
  • AWS takes care of upgrades, maintenance, high availability
  • AWS provides only a few configuration knobs

• It costs less to setup your own load balancer but it will be a lot more effort on your end

• It is integrated with many AWS offerings / services

  • EC2, EC2 Auto Scaling Groups, Amazon ECS
  • AWS Certificate Manager (ACM), CloudWatch
  • Route 53, AWS WAF, AWS Global Accelerator

---

Load Balancer Security Groups

• Load balancer sg accept traffic from anywhere.

• EC2 sg accept traffic only from load balancer.

---

Types of load balancer on AWS

• AWS has 4 kinds of managed Load Balancers

  • Classic Load Balancer (v1 - old generation) – 2009 – CLB
    • HTTP, HTTPS, TCP, SSL (secure TCP)
  • Application Load Balancer (v2 - new generation) – 2016 – ALB
    • HTTP, HTTPS, WebSocket
  • Network Load Balancer (v2 - new generation) – 2017 – NLB
    • TCP, TLS (secure TCP), UDP
  • Gateway Load Balancer – 2020 – GWLB
    • Operates at layer 3 (Network layer) – IP Protocol
• Overall, it is recommended to use the newer generation load balancers as they provide more features
• Some load balancers can be setup as internal (private) or external (public) ELBs

---

Classic Load Balancers (v1) 已过时, 不用考

• Supports

  • TCP (Layer 4), HTTP & HTTPS (Layer 7)

• Health checks:

  • TCP or HTTP based

• Fixed hostname

  • XXX.region.elb.amazonaws.com

---

Application Load Balancer (v2)

• Application load balancers is Layer 7 (HTTP)

• Feature

  • Load balancing to multiple HTTP applications across machines(target groups)
  • Load balancing to multiple applications on the same machine(ex: containers)

• Expose:

  • Application Load Balancers and Classic Load Balancers have a static DNS name.

• Support

  • HTTP/2 and WebSocket
  • redirects (from HTTP to HTTPS for example)

• Routing tables to different target groups based on:

  • Url path:
    • example.com/users & example.com/posts
  • hostname:
    • one.example.com & other.example.com
  • Query String
    • example.com/users?id=123&order=false
  • HTTP Headers
• ALB are a great fit for micro services & container-based application (example: Docker & Amazon ECS)
• Has a port mapping feature to redirect to a dynamic port in ECS

• In comparison, we’d need multiple Classic Load Balancer per application

• HTTP Based Traffic diagram:

  

• Query Strings/Parameters Routing

  

• Good to Know

  • Fixed hostname (XXX.region.elb.amazonaws.com)
  • The application servers don’t see the IP of the client directly
  • Method to get:
    • IP of the client: X-Forwarded-For in the header
    • Port: X-Forwarded-Port in the header
    • Protocal: X-Forwarded-Proto in the header

  

---

Target Groups: http

• Target Group of ALB can be:

  • EC2 instances (can be managed by an Auto Scaling Group) – HTTP
  • ECS tasks (managed by ECS itself) – HTTP
  • Lambda functions – HTTP request is translated into a JSON event
  • IP Addresses – must be private IPs
• ALB can route to multiple target groups

• Health checks are at the target group level

• Health Checks

  • crucial for Load Balancers
  • They enable the load balancer to know if instances it forwards traffic to are available to reply to requests
  • The health check is done on a port and a route (/health is common)
  • If the response is not 200 (OK), then the instance is unhealthy
  • If the instance is unhealthy, ALB stop sending request to this instance.

  

---

Hands-On: ALB

• Create a new sg only allowing http

• Create a new target group

• Create ALB

• Verify: Uses the DNS name to visit in browser

---

• Limit EC2 only access from a ALB, not for public IP of instance.

• Add Rules: filter request by path and response a fixed message.

---

Network Load Balancer (v2)

• Network load balancers (Layer 4) allow to:

  • Forward TCP & UDP traffic to your instances
  • Handle millions of request per seconds
  • Less latency ~100 ms (vs 400 ms for ALB)
• NLB has one static IP per AZ, and supports assigning Elastic IP (helpful for whitelisting specific IP)
  • 考题: app limits access to a few ip
• NLB are used for extreme performance, TCP or UDP traffic

• Not included in the AWS free tier

• TCP (Layer 4) Based Traffic

• Target Group:

  • EC2 instances
  • IP Addresses – must be private IPs
  • Application Load Balancer
  • Health Checks:
    • TCP,
    • HTTP
    • HTTPS

  

  

  

---

Hands-On: NLB

• Create sg

• Create Target Group

• Create network load balancer

• Update sg of istances, allowing inboud of NLB

• Verify

---

Gateway Load Balancer

• Deploy, scale, and manage a fleet of 3rd party network virtual appliances in AWS
• Example: Firewalls, Intrusion Detection and Prevention Systems, Deep Packet Inspection Systems, payload manipulation, …

• Operates at Layer 3 (Network Layer) – IP Packets

• Combines the following functions:

  • Transparent Network Gateway:
    • single entry/exit for all traffic
  • Load Balancer
    • distributes traffic to your virtual appliances

• Uses the GENEVE protocol on port 6081

• Traffic will hit target group before reach the application.

• Target Group

  • EC2 instances
  • IP Addresses – must be private IPs

  

  

---

Sticky Sessions/Session Affinity(Session Data)

• It is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer
• This works for Classic Load Balancer, Application Load Balancer, and Network Load Balancer
• For both CLB & ALB, the “cookie” used for stickiness has an expiration date you control
• Use case:
  • make sure the user doesn’t lose his session data
• Enabling stickiness may bring imbalance to the load over the backend EC2 instances

---

Cookie Types and Names

• Application-based Cookies

  • Application cookie

    • Generated by the load balancer
    • Cookie name
      • AWSALBAPP

  • Custom cookie

    • Generated by the target (application itself)
    • 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)

• Duration-based Cookies

  • Cookie generated by the load balancer
  • Cookie name
    • AWSALB for ALB
    • AWSELB for CLB

---

Hands-On: Stickness Cookie

• Edit target group attributes:

• Visit app always using the same instance, ip address always the same.

---

Cross-Zone Load Balancing

• Without Cross Zone Load Balancing:
  • Requests are distributed in the instances of the node of the Elastic Load Balancer

• With Cross Zone Load Balancing:
  • each load balancer instance distributes evenly across all registered instances in all AZ

---

• Application Load Balancer
  • Enabled by default (can be disabled at the Target Group level)
  • No charges for inter AZ data

• By default, cross za is enable. But can be change in the target group.

---

• Network Load Balancer & Gateway Load Balancer
  • Disabled by default
    • You pay charges ($) for inter AZ data if enabled

---

• Classic Load Balancer
  • Disabled by default
  • No charges for inter AZ data if enabled

---

SSL/TLS

• An SSL Certificate allows traffic between your clients and your load balancer to be encrypted in transit (in-flight encryption)

  • SSL: Secure Sockets Layer, used to encrypt connections
  • TLS: Transport Layer Security, which is a newer version
  • Nowadays, TLS certificates are mainly used, but people still refer as SSL
• Public SSL certificates are issued by Certificate Authorities (CA)
  • Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt, etc…
• SSL certificates have an expiration date (you set) and must be renewed

---

SSL Certificates

• The load balancer uses an X.509 certificate (SSL/TLS server certificate)
• You can manage certificates using ACM (AWS Certificate Manager)

• You can create upload your own certificates alternatively

• 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
  • Ability to specify a security policy to support older versions of SSL / TLS (legacy clients)

• Classic Load Balancer (v1)

  • Support only one SSL certificate
  • Must use multiple CLB for multiple hostname with multiple SSL certificates

• Application Load Balancer (v2)

  • Supports multiple listeners with multiple SSL certificates
  • Uses Server Name Indication (SNI) to make it work

• Network Load Balancer (v2)

  • Supports multiple listeners with multiple SSL certificates
  • Uses Server Name Indication (SNI) to make it work

---

Server Name Indication (SNI): Certificate

• SNI solves the problem of loading multiple SSL certificates onto one web server (to serve multiple websites)
• Server Name Indication (SNI) allows you to expose multiple HTTPS applications each with its own SSL certificate on the same listener.
• 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
• Note:
  • Only works for ALB & NLB (newer generation), CloudFront
  • Does not work for CLB (older gen)

---

Hands-on: SSL

• ALB:

• Specify target group

• Specify policy and certificate
  • From ACM
  • From IAM
  • import to ACM

---

Connection Draining

• Feature naming 在不同的 balancer 中有不同的名称

  • Connection Draining – for CLB
  • Deregistration Delay – for ALB & NLB

• Connection Draining

  • Give time to complete “in-flight requests” while the instance is de-registering or unhealthy
  • Stops sending new requests to the EC2 instance which is de-registering

• Parameterize

  • Between 1 to 3600 seconds (default: 300 seconds)
  • Can be disabled (set value to 0)
  • Set to a low value if your requests are short

---

Top