Deep Dive in AWS Loadbalancers

All right, welcome back.

So as part of task statement 1.3, we first should know how load balancing works at layer 3, 4 and layer 7 of the OSI model.

So let's talk about that.

So it's not really just usual spread this traffic.

I mean, when we look or we hear the term load balancer we just think like there is a load traffic load and you are balancing it but it's not as simple as that we we really have some more granular concepts around load balancing so let's try to break them into multiple layers of osi model and if you don't know osi model then i think you should go back and read some network basics because to be honest i cannot cover a whole osi model here but there are seven layers of osi model layer three layer four and layer seven i think are the most important ones and because aws provide load balancer on these three major layers i think that's why they want us to cover first basics about these three layers so let's start with layer three layer three is network layer which simply means it's based on IP addresses.

What does that mean? That load balancing will also rely on IP addresses.

So if you are thinking it's sort of like routing level load balancing, I think we sort of covered it in Route 53 load balancing as well, where Route 53 provides basic routing policy-based failovers.

In a way, if you are only looking at layer three load balancing, which is a network layer, I think Route 53 can cover that use case as well.

But of course, we have something from AWS side.

So let's go back to layer three.

It's based on IP addresses.

We don't care about the application.

We don't care about the ports.

We only care about the source and destination IP addresses.

So it decides where the traffic should go if it's coming from a specific source IP, if it's based on source IP, or if it's based on destination, then it should decide which destination IP it should send the traffic to.

And now this type of load balancing is quite often done by routers or systems that are using routing protocol.

So like I mentioned, Route 53 does it.

And of course, routers in our legacy infrastructure, they also do it.

So for example, if traffic is destined to same virtual IP address, it might be distributed to multiple backend servers of like... uh something we used to have in our old days of firewalls or even virtual firewall appliances these these days also they sometimes use it where you have like multiple back-end IP addresses or virtual machines which have their own IP addresses, you have one virtual IP address sitting in front of them and traffic is distributed just based on that source and destination.

So that's what layer three load balancing looks like.

It's pretty fast, efficient because it's of course don't take care of a major, if you recall that each packet flowing from one source to a destination, that packet actually have a lot of content.

now this layer 3 load balancing doesn't inspect the packets deeply because of course it just need source and destination destination ip address but why don't we use just this one because it's fast and efficient of course there's a trade-off as well it's less intelligent you can't make decision based on application data urls user sessions so of course in in today's world when we are moving so fast into these new ai based developments kubernetes based deployments layer 3 load balancing isn't really the thing which we need it's way we need way more than just source and ip based traffic load balancing and that it come and it brings us to layer four the transport layer which relies on ports as well so now we are putting into mix ip addresses along with ports these ports can be tcp or udp ports or it can be ports like http on port 80 https 443 database anything can come in picture so when a client connects the load balancer chooses the backend server maybe based on round robin or lease connection it decide which server it should go based on the ports and based on ip address as well so once the connection is established in that session we'll go to the backend server which the traffic should intend to therefore balancing is also very fast compared to maybe it's still slower compared to layer 3 but it's still very fast because it's again not looking into application payload but it's more flexible because now you are putting into mix the ports and sessions now of course you will find layer 4 load balancer in i think many high high performance environments especially where speed matters more than deep packet inspection so i think maybe i don't know gaming applications where you all you care about is like speed you don't care about what's really going inside the services so i i think that's one might be one of the use case anyways uh let's move into layer seven which is the most application aware load balancer Now this load balancer actually understand the protocols.

So it understand HTTP or HTTPS, but it also looks into URLs, headers, cookies, or maybe requested content as well.

So you can literally like decide which particular backend server should be handling what particular type of request content.

So you can even decide that granular level of decisions from layer seven load balancing.

All right, welcome back.

So as part of task statement 1.3, we first should know how load balancing works at layer 3, 4 and layer 7 of the OSI model.

So let's talk about that.

So it's not really just usual spread this traffic.

I mean, when we look or we hear the term load balancer we just think like there is a load traffic load and you are balancing it but it's not as simple as that we we really have some more granular concepts around load balancing so let's try to break them into multiple layers of osi model and if you don't know osi model then i think you should go back and read some network basics because to be honest i cannot cover a whole osi model here but there are seven layers of osi model layer three layer four and layer seven i think are the most important ones and because aws provide load balancer on these three major layers i think that's why they want us to cover first basics about these three layers so let's start with layer three layer three is network layer which simply means it's based on IP addresses.

What does that mean? That load balancing will also rely on IP addresses.

So if you are thinking it's sort of like routing level load balancing, I think we sort of covered it in Route 53 load balancing as well, where Route 53 provides basic routing policy-based failovers.

In a way, if you are only looking at layer three load balancing, which is a network layer, I think Route 53 can cover that use case as well.

But of course, we have something from AWS side.

So let's go back to layer three.

It's based on IP addresses.

We don't care about the application.

We don't care about the ports.

We only care about the source and destination IP addresses.

So it decides where the traffic should go if it's coming from a specific source IP, if it's based on source IP, or if it's based on destination, then it should decide which destination IP it should send the traffic to.

And now this type of load balancing is quite often done by routers or systems that are using routing protocol.

So like I mentioned, Route 53 does it.

And of course, routers in our legacy infrastructure, they also do it.

So for example, if traffic is destined to same virtual IP address, it might be distributed to multiple backend servers of like... uh something we used to have in our old days of firewalls or even virtual firewall appliances these these days also they sometimes use it where you have like multiple back-end IP addresses or virtual machines which have their own IP addresses, you have one virtual IP address sitting in front of them and traffic is distributed just based on that source and destination.

So that's what layer three load balancing looks like.

It's pretty fast, efficient because it's of course don't take care of a major, if you recall that each packet flowing from one source to a destination, that packet actually have a lot of content.

now this layer 3 load balancing doesn't inspect the packets deeply because of course it just need source and destination destination ip address but why don't we use just this one because it's fast and efficient of course there's a trade-off as well it's less intelligent you can't make decision based on application data urls user sessions so of course in in today's world when we are moving so fast into these new ai based developments kubernetes based deployments layer 3 load balancing isn't really the thing which we need it's way we need way more than just source and ip based traffic load balancing and that it come and it brings us to layer four the transport layer which relies on ports as well so now we are putting into mix ip addresses along with ports these ports can be tcp or udp ports or it can be ports like http on port 80 https 443 database anything can come in picture so when a client connects the load balancer chooses the backend server maybe based on round robin or lease connection it decide which server it should go based on the ports and based on ip address as well so once the connection is established in that session we'll go to the backend server which the traffic should intend to therefore balancing is also very fast compared to maybe it's still slower compared to layer 3 but it's still very fast because it's again not looking into application payload but it's more flexible because now you are putting into mix the ports and sessions now of course you will find layer 4 load balancer in i think many high high performance environments especially where speed matters more than deep packet inspection so i think maybe i don't know gaming applications where you all you care about is like speed you don't care about what's really going inside the services so i i think that's one might be one of the use case anyways uh let's move into layer seven which is the most application aware load balancer Now this load balancer actually understand the protocols.

So it understand HTTP or HTTPS, but it also looks into URLs, headers, cookies, or maybe requested content as well.

So you can literally like decide which particular backend server should be handling what particular type of request content.

So you can even decide that granular level of decisions from layer seven load balancing.