AWS Load Balancers - The Frontline Defence

Load balancers sit in front of your ec2 servers to distribute traffic to healthy ec2 servers & not to expose any server IP directly.

They are like those frontbench students who are always ahead of our backbenchers (ec2-servers), but we all know end of the day our backbenchers are the real heroes who serve all the incoming traffic.

Flow

Listeners -> Target Groups -> EC2-servers

Explanation

As the name suggests load balancer, distributes the incoming requests. Since It's the first point of contact, it does much more than distributing traffic, like routing based on Path/domain name, and protecting servers from incoming attacks.

  1. Listeners -> Port & Protocol.

    Load-balancer will have many rules, so to categorize it based on ports, the first thing is listeners. On LB, we can have many listeners.

  2. Target Groups -> Grouping of Targets

    Our targets are our EC2 servers.

    • We can add ec2-servers to a target group by its name or an IP. IP is used if my ec2 is not present within the same vpc, & vpc peering is there.

    • We can add health checks, & configure if I get consecutive 2 unsuccessful hits on my health check path, ec2-server is unhealthy, & do not send traffic to it until it becomes healthy.

  3. EC2-servers

    The application is running over here on a particular port.

OSI Model

Before looking at the Application load balancer (Layer 7) and Network load balancer (Layer 4) we need to look at the OSI Model which is a reference model on how communication happens between 2 machines.

  • Layer 7 - Application layer -> Browsers work on this layer. HTTP requests are made from here. (By default browsers, make HTTP requests)

  • Layer 6 - Presentation layer -> Encryption and decryption of requests happens over here. (Sender side - Encryption, Receiver side - Decryption)

  • Layer 5 - Session layer -> Creates communication channel, called session between sender & receiver.

  • Layer 4 - Transport layer -> On the sender side data is divided into small packets called segments, to transport data safely, and on the receiver side data is reassembled. TCP & UDP protocols work here.

  • Layer 3 - Network layer -> Source & Destination is added to Packets. Best Path is discovered to send this data through Routers.

  • Layer 2 - Data Link layer -> Switches work over here. Switch connects devices in a network with each other, allowing them to exchange packets.

  • Layer 1 - Physical Layer - Physical cables connected to the server work at this layer. (Router -> Switch -> Cable)

Application Load Balancer

If we want to distribute incoming traffic at Layer 7 when the user initiates a request, depending on the Path or Domain, then ALB is used.

  • Incoming Requests are distributed by various algorithms like the Round-Robin algorithm. Round-Robin algorithm distributes traffic equally - Eg. if 100 requests come, & 2 servers are there, then 50 requests would go to one server & remaining 50 to another server.

  • Auto-scaling integration to add/remove instances automatically based on request traffic.

  • SSL offloading - Removes SSL-based encryption from incoming requests, so that the server is relieved of the processing burden, this processing is done on the LB

    level.

Network Load Balancer

Works on Layer 4 - Transport Layer. Used when we want to use TCP / UDP protocol. This is mainly used for streaming platforms. Ensures there's low latency & data is transmitted at high speed.

One Difference between HTTP/HTTPS & TCP/UDP requests?

  • In HTTP/HTTPS Request is made -> Response is sent and Communication ends.

  • In TCP/UDP Request is made and the Response is sent continuously till the client/server ends the communication.

    Eg. -> Sports Matches Broadcasting

Target Group Monitoring

Here we'll monitor the Target Group response time, and incoming request count per target (instance). For that, we need to create cloud watch alarms for both these metrics, & then using cloudwatch CLI commands we can get metrics.

First, we will get the current time in UTC for our start-time & end-time filters.

start_time=$(date -ud "-1 min" "+%Y-%m-%dT%H:%M:00Z")
end_time=$(date -u "+%Y-%m-%dT%H:%M:00Z")

-u - For getting UTC time.

-d - For getting a specific date & time, like here got -1 current time.

For Target group Response time -

aws cloudwatch get-metric-statistics \ 
--metric-name TargetResponseTime \
--start-time $start_time --end-time $end_time --period 60 \
--namespace AWS/ApplicationELB --statistics Average \
--dimensions Name=LoadBalancer,Value=<LB-arn> \
--query 'Datapoints[].Average' --output text

For Request per Instance on Target Group -

aws cloudwatch get-metric-statistics \
--metric-name RequestCountPerTarget \
--start-time $start_time --end-time $end_time --period 60 \
--namespace AWS/ApplicationELB --statistics Sum \
--dimensions Name=TargetGroup,Value=<tg-arn> \
--query 'Datapoints[].Sum' --output text

You can get all these keys & values on your Cloudwatch alarm dashboard.

Note:- If you've installed aws, & you get aws command not found, then check where aws is installed by using locate aws command.

Eg. /usr/local/bin/aws <command> if its present over there.