Skip to content

Pasted image 20221101114927.png

Elastic Load Balancer

TLDR

AWS family of load balancers. Is used to spread and control traffic to a vertically scaled infrastructre.

Features

  • Server which forwands traffic to other servides (e.g. EC2)
  • spread load
  • expose single dns access to whole clustered application
  • seamlessly handle failures
  • health checks
  • provides https to instances
  • enforce stickyness with cookies
  • high availabliy across zones
  • separate public traffic from private traffic
  • can be setup as internal or external

General

  • managed by aws

Compatible services

Health checks

  • port and route

Classic Load Balancer

  • htt, https (layer 7), tcp (layer 4), ssl
  • deprecated
  • health checks tcp or http based
  • fixed hostname

Application Load Balancer

  • http, https , websocket (layer 7)
  • need target groups
  • can use to target diffrent containers on same mashine
  • good for ECS and docker
  • port mapping feature
  • fixed hostname
  • app servers dont see the clients ip directly
  • cannot attach elastic ip
  • cross AZ load balancing enabled by default

Target groups

  • EC2 Instances
  • ECS Tasks
  • Lambda functions
  • Private IP Adresses

Routing

  • based on path
  • based on hostname
  • based on query

Network Load Balancer

  • TCP, TLS, UDP (Layer 4)
  • high performance, millions of requests per second
  • less latency
  • one static ip per AZ
  • support elastic IP
  • health checks with tcp, http or https
  • cross AZ load balancing is disabled by default

Target Groups

  • EC2 Instances
  • Private Ip Adresses
  • Application Load Balancer (ELB)

Gateway Load Balacher

  • IP Protocol (layer 3, networkt)
  • Deploy scale and manage a fleed of 3rd party netwurk viurual aplicaneces
  • Examples, Firewals, Instrusion Detection, Deep Packet Inspection, payload manipulations
  • GENEVE Protocol on port 6081

Functions

  • Transparent Network Gateway, single entry exit for all trafic
  • Load Balancer distributes to your check mashienes

Target Groups

  • EC2 Instances
  • Private Ips

Security

Sticky Session

  • by default requests are spread
  • can be enabled for ELB CLB and ALB
  • controlled via cookie set by the ELB
  • might bring imbalance to the nodes
  • generated by the target
  • can include any custom attributes
  • cookie name is set in target group
  • dont use AWSALB, AWSSALBAPP or AWSSALBTG, there are reserved for use by ELB
  • generated by ELB
  • Cookie name is AWSALBAPP

Duration Based Cookies

  • generated by ELB
  • name AWSALB or AWSELB for CLB

Cross AZ Load Balancing

  • distributes evenly across all az instances
  • if not enabled distributes evenly across all az but not instances
  • ALB always enabled no extra cost
  • NLB disabled by default cost extra
  • CLB disabled by default can be enabled no extra cost

SSL/ TLS

  • ELB uses x.509 cert
  • can use AWS Certificate Manager (utils/ACM)
  • can upload own certificales
  • required for https listener
  • can add multiple to support multiple domains
  • can modify securitty policy to support older versions of SSL

SNI (Server Name Indication)

  • clients can use this to specify the hostname they reach
  • how do you load multiple certs on on server to serve multiple https website on one server
  • client indicateds hostname of the target server in inital handshake
  • only for ALB or NLB or Cloudfront

CLB

  • only one ssl cert
  • must use multiple clb if multiple domains via https

ALB

  • multiple listeners with multi ssl certs
  • SNI

NLB

  • multiple listeners multi certs
  • SNI
  • used for routing tcp traffic (e.g. ssh)

Connection Draining/ Deregistration Delay

  • Time to complete in flight request while instance is going to be no longer targetet by ELB
  • between 0 to 3600 seconds, default is 300
  • low value if requests are short

Launch Template

  • AMI
  • Instance Type
  • EC2 User Data
  • SecurityGroup
  • SSH Key Pair
  • IAM Roles for the EC2
  • Network and Subnets information
  • ELB Information
  • min max size
  • scaling policies

CloudWatch Alarms

  • monitor metic and scale out or in

Scaling Policies

Cooldown period

  • Afer scaling no other scaling can be done for a period
  • default 300 seconds
  • allows metrics to stabilized
  • use AMIs to launch instances faster and use less cooldown period

Good Metrics To Check

  • CPU Utilization
  • Request Count per Target
  • Average Network io
  • Any custom metric via CloudWatch

Dynamic Scaling

Target Tracking
  • i want cpu to stay around 50%
  • no cooldown period
Simple Step Scaling
  • when cpu > 70 add 2 && when cpu < 10% remove 2
Scheduled Actions
  • based on time

Preditive Scaling

  • Analyse historical load
  • ML
  • hands of approach