CLB (aka ELB) - Classic (Elastic) Load Balancer

CLB (aka ELB) - Elastic (Classic) Load Balancer
-         https://docs.aws.amazon.com/elasticloadbalancing/-         Elastic Load Balancing distributes incoming application or network traffic across multiple targets, such as Amazon EC2 instances, containers, and IP addresses, in multiple Availability Zones. Elastic Load Balancing scales your load balancer as traffic to your application changes over time. It can automatically scale to the vast majority of workloads.

-         If you have the same content available via multiple channels, ELB can ensure each channel receives the same share of the load
-         ELB is REGIONAL. Need to select at least one subnet in AZ for the ELB to be enabled in that AZ
-         Name – 32 chars, can't start with "–"
-         ELB Service vs ELB Node
-         Classical Load Balancer supports:

          §  HTTPS, HTTP, TCP, SSL (not HTTP/2) 

          §  Ports: 1->65535

          §  IPv4, IPv6, Dual Stack (process IPv4 and IPv6 data traffic simultaneously)
-         Not all EC2-bound traffic needs to go via ELB - can intra-EC2 ping, for example. Or if an EC2 public IP is configured with Security Group and NACLs – can access it from the outside
-         ELB has only to do with inbound traffic destined for the registered EC2 instances and respective return traffic
-         ELB Listener – process that checks for connection requests. Can configure Protocol/port on which to listen. Front End listeners and Back End listeners – can configure different ports/protocols for Front vs Back.
-         Charged hourly. Can delete ELB to avoid charges. Repoint Route53 (or another DNS) elsewhere.
-         When deleting ELB – make sure you change DNS side ahead of time, it takes up to 24 hrs for the new (non-ELB) IPs to be propagated all over the internet. s
-         Sends traffic to eth0. If there are multiple private IP’s on eth0, it will target the primary IP address
-         Supports IPv4 only in VPC

IMPORTANT: To ensure ELB can scale and launch new nodes in each AZ, need to ensure that subnet defined for ELB is at least /27 and has at least 8 available IPs for ELB to scale:

          §   /27 means 2^5=2*2*2*2*2=32 IPs available for devices. 0->31.

          §   0,1,2,3,31 are reserved by AWS. Left with total of 32-5=28: 8 for ELB, rest for devices
-         Need to define a SUBNET in AZ for ELB
 
Health Checks
-         Responsiveness. Console: HTTP requests to port 80; AWS API – TCP Ping to port 80. Health indicator values: 'In Service"; "Out-of-Service" - stop sending traffic to EC2 instance
-         expect response at HTTP "200 OK" within timeout period of 5 sec
-         Health check interval – how often to ping - Default 30 sec (range 5-300 sec). Toggle depending on how much CPU can afford
-         Response Timeout – how long to wait for a response prior to giving up
-         Unhealthy Threshold – how many failures allowed - default 2 consecutive failures. Range 2-10.
-         Healthy Threshold – how many successes required - default 10. Range 2-10.
-         Math: 30 sec interval, 10 times = 300 sec = 5 min to declare instance healthy again
-         Registering new EC2 under ELB. It takes 10 healthy responses to declare new EC2 In-Service. Default interval 30 sec -> 30*10=5min to declare In-Service under default settings. To speed up – decrease default timeout of 5 sec and health check interval of 30 sec.
 
Cross Zone Load Balancing
-         By default – distribute load evenly across AZ's regardless of the number of EC2’s in each zone
-         Cross Zone Load Balancing disabled by default
-         Enable – factor in the EC2 distribution
 
Internet facing ELB
-         Nodes need to have public IPs
-         Routes to private addresses of registered EC2. If these EC2's need to access internet, can give them public IPs too - or NAT
-         Need one "public" subnet – defined in ELB configuration
-         DNS: name-1234567890.elb.amazonaws.com.
-         If ELB scales horizontally and adds nodes – what determines which node should be receiving traffic? ALL ELB Node IP's will map to a single DNS name. ELB service will update authoritative DNS (Route53) with a new ELB node IP once one is added. DNS will load balance across ELB’s by responding to requests with a different ELB IP each time (round robin) and record TTL of 60 sec (to make sure it expires and gets re-requested)
 
Internal ELB
-         Nodes send traffic to eth0 Primary Private IP of registered EC2's
-         DNS: internal-name-123456789.elb.amazonaws.com.
 
ELB Security Group

-         can specify one for ELB. Default choice – the Security Group of VPC.

-         SC should allow:

          §  Incoming traffic from the front end

          §  Health check protocol/port towards the back end

          §  Back end listener protocol/port

ELB /EC2 NACL
-         subnet’s NACL should allow traffic to and from ELB
-         Ex: on-default NACL; internet facing EB

-         Inbound into ELB subnet:

          §  In to VNC NACL, Source: internet; Port: listeners (data flow to Internet)

          §  In to VPC NACL, Source: VPC CIDR Port: 1024-65535 (EC2 return traffic)

-         Outbound from ELB subnet: 

          §  Out to VPC CIDR, Port: listeners (data flow to EC2)

          §  Out to VPC CIDR, Port: health checks (EC2 health)

          §  Out to Internet, Dest: internet, Port: 1024-65535 (data flow back to internet)
 -          Inbound into EC2 subnet:

          §  Into EC2 NACL, Source: VPC CIDR Port: health check (health) 

          §   Into EC2 NACL, Source: VPC CIDR Port: listener (internet data flow from ELB)

-         Outbound from EC2 subnet:

          §  Out to VPC CIDR, Dest: VPC CIDR; Port: 1024-65535 (all data back to ELB)

-         Source: https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html