Elastic Load Balancer
There are3 types of Load Balancers:
1. ALB: Application LB - Http, https, Web-Socket
2. NLB: Network LB:: TLS, TCP, UDP
3. GWLB: Gateway LB. Operate at layer:3, the network layer
In AWS when we need to load balance some ec2 instances, then the NSG of these ec2 will allow NSG of LB.
ALB layer 7 Application Load Balancer.
- Its layer 7 only that means HTTP and HTTPS only. SSL termination also unlike azure.
- Can do path & hostname based routing. Again this is unlike azure.
- Can also do header query based routing.. Like &client=pnc for pnc and similar for life.
What can be backend pool of ALB: EC2, ECS, Lambda functions, Private IPs
When we create ALB, we need to choose a fixed region, but we can deploy it to different availability zones.
Assume we have 2 ec2, and load balancer has its own NSG. Now you can delete rule in ec2’s NSG to allow http traffic
to them from any ip, instead choose NSG of LB:
If you wanna do path based routing or query based etc.. goto ALB > Listeners. Open the listener
Add a new rule, note: Lower the number on Priority of the Listener role, it is run earlier.
Then choose which condition to for that rule to be based on:
NLB Layer 4
- Network Load Balancer: Forwards TCP & UDP
TCP is used for web-browsing, email, text message..
UDP is very fast and is used when real-time data transmission is needed.
NLB has lower latency than ALB.
Advantage of NLBs:
- Both ALB and NLB can be one each in each availability zone.. But NLB can make each one in each
availability zone get their own Static IP address.
Note: we can route to IP addresses but they need to be private.. Cos u r clever and route to google 🙂
we can route from NLB to ALB.. not vice versa…
---------------------------------------------------------------------------------------------------------------------------------------------------------------
GWLB Layer 3
Gateway LB is newest. And it is only useful when we have 3rd party network appliance to route to. Example, we have
some cisco firewalls, 3 of them… we can route traffic to them using GWLB.
- It uses GENEVE protocol on port 6081: useless info but exam needs
What happens is that gwlb routes to firewall appliances.. That what gets approved is returned back to gwlb and gwlb
finally routes to EC2 or IPs…
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Cookies in Load Balancing
How do we make sure one client request is routed to one ec2 till that session is active?
Ans: Cookies
That client session is called as STICKY SESSION
Cookies should ideally be generated by your app and you can let LB know whats the cookie name..
But if now LB can create its own, and you need to tell it how long to keep a cookie active, 1-7 days…
Only possible for ALB & not possible in NLB: because NLB can have different IPs in each avail-zone.. Or whatever…
—------------------------------------------------------------------------------------------------------------------------------------------------------------
Cross-zone Load Balancing
Suppose we have 3 avail-zones, each one has an ALB deployed. By default each of these 3 ALB will route traffic evenly
to all ec2 instances even if they are not in their avail-zone…
This is called as cross-zone load balancing..
- cross-zone load balancing is active by default in ALB and free.
- cross-zone load balancing is not active in NLB & GWLB, and costs money to enable.
=========================================================================================
SSL/TLS termination
We can load ssl certs in LB. Best part is we can now load multiple certs in one LB: both ALB & NLB.
- CV & tatil certs in one ALB/NLB.
- When people from cv access, it uses cv certs, and same for tatil
How this works is, during initial handshake, clients are now supposed to send SNI: SERVER NAME INDICATOR
This sni tells LB which server they wanna access, cv or tatil.
Connection Draining
Say we need to shutdown one ec2 instance being load balanced by ALB/NLB… what we can do is use connection
draining which allows LB to not route new traffic to this ec2.. But allows existing connections to complete work..
- Also called: DeRegistration Delay
- Max limit is 1 hour, default is 5 min
—-------------------------------------------------------------------------------------------------------------------------------------------------
ASG = Auto Scaling Groups VM Scale sets
EC2 > Auto Scaling Groups > Create new ASG
Then create a launch template… kind of launch pad for our instances or launching like rockets.
- Choose machine image
- Instance type like m5.large
- Key-pair to login to our instances by ssh
- AVOID CHOOSING A SUBNET… because its a template
- Choose or create a new NSG
- Choose memory size
Now click save to create the launch template/pad
Launch pad/template has basic VM config..
Now to launch it:
1. choose this launch pad,
2. then choose a VPC (vnet).
3. Select availability zones where all to launch - should all be from same region as VPC
4. Choose either existing LB u have, or create new… You may choose not to have any LB
5. Optional to add a health check for instances
6. Choose min capacity, max and also desired capacity
7. Optional to choose scaling policy
If scaling happens, say from 1 instance, 1 more was launched.. Then for default 300 seconds or 5 min, AutoScaling will
stop or “COOL-DOWN” period. This is because it wants to wait 5 min to see if it needs to scale up/down still..
If an instance in asg is found unhealthy, its terminated and replaced by a new one.
Scaling policy can be based on: CPU usage, Request count per instance, memory usage, avg network in/out…
There are 2 types of Scaling Policies:
1. Predictive: based on ML. based on forecast.. But we need to choose metric to forecast on.. Say memory..
2. Dynamic: based on set metric.. Say cpu should be 40%.. If it goes over it adds… basically in this we set an
alarm at 40% cpu.. As soon as that alarm rings…………. These alarms can be seen in Cloudwatch.
Dynamic Scaling itself can be 4 types:
a. Simple scaling: say 70% cpu, scale up
b. Step scaling: say 70% cpu add 1 more.. If 80% add 2 more.. If 90% add 5 more
c. Target tracking: say requests count should be max 500 per instance… so it can add 1,2,.. Or as many to meet
the target
d. Scheduled: at fixed date/time add these many…
Elastic means ALB & NLB.
NLB can target ALB. not vice versa… rich can target poor, not the other way around.
only nlb gets static ip
Our own application’s cookie cant use ALB’s cookie names.
