Elastic Load Balancer (ELB)
Elastic Load Balancer (ELB)
Why Load Balancer ? -
- Spread load across multiple downstream instances
- Expose a single point of access to your application
- Seamlessly handle failure of downstream instances
- Do regular healthchecks to your instances
- High availability across zones
Elastic Load Balancer (ELB) -
- Load balancer is a service that uniformly distributes the network traffic and workloads across multiple servers or a cluster of servers
- Load balancer increase the availability and fault tolerance of an application
- ELB sclaes itself a necessary to handle load
- Incoming traffic distributed across EC2 instances in multiple availability zones
- Load balancer is the single point of contact for clients
Three Types of Elastic Load Balancers
Three Types of Elastic Load Balancers include:
- Classic Load Balancer ( Layer 4 and Layer 7)
- Application Load Balancer (Layer 7)
- Network Load Balancer (Layer 4)
Classic Load Balancer -
- Distributes the incoming traffic across ec2 instances in multiple Az and function at 7th and 4th layer of OSI model
- Routes the traffic to healthy instances only and it is evenly distributed
- Internet and internal facing load balancer
- Not recommended by AWS
Application Load Balancer -
- Most popular and frequently used ELB in AWS
- Functions at the 7th layer of OSI model
- identifies the incoming resource type and directs it to the appropriate server
- It will not give high performance and it will not handle enormouse traffic
- Support redirects (from HTTP to HTTPS)
- ALB are great fit for microservices and container based application
- ALB can route to multiple target group
- The slow start mode allows targets to “warm up” with a ramp-up period.
- The ALB supports content-based routing which allows the routing of requests to a service based on the content of the request. For example:
- Host-based routing routes client requests based on the Host field of the HTTP header allowing you to route to multiple domains from the same load balancer.
- Path-based routing routes a client request based on the URL path of the HTTP header (e.g. /images or /orders).
Network Load Balancer -
- Functions at the 4th layer of OSI model
- Handles millions of requests per second and maintain low latency
- Ideal for load balancing the TCP traffic and supports static/elastic IP per AZ
- If a host fails or goes offline, the load is automatically redistributed among the other available hosts within a few seconds to minimize downtime and prevent application failure
- You can load balance any application hosted in AWS or on-premises using IP addresses of the application back-ends as targets
Gateway Load Balancer -
- GLB automatically distributes incoming traffic across multiple targets in one or more AZ
- It monitors the health of its registered targets and routes the traffic only to those are in good condition
- Uses GENEVE protocol on port 6081
- Operates at layer 3 (network layer)
- Deploy third-party virtual appliances more quickly
- Scale virtual appliances while keeping cost in check
- Increase the availability of your third party virtual appliances and continuously monitor health and performance metrics
- Using GLB endpoints , ensure private connectivity across the AWS network
Target Groups -
- A target group tells a load balancer where to direct traffic to : EC2 instances, fixed IP addresses; or AWS Lambda functions, amongst others.
- When creating a load balancer, you create one or more listeners and configure listener rules to direct the traffic to one target group.
Weighted Routing -
- With weighted routing we can switch the traffic between the versions of our application. This configuration allows us to distribution of the traffic to our application
- For example - if we define a rule having two target groups with weights 8 and 2, the load balancer will route 80% of the traffic to the first targetgroup and 20% to the other
You can configure Listener Rules based on:
- Based on path - in28minutes.com/a to target group A and in28minutes.com/b to target group B
- Based on Host - a.in28minutes.com to target group A and b.in28minutes.com to target group B
- Based on HTTP headers (Authorization header) and methods (POST, GET, etc)
- Based on Query Strings (/microservice?target=a, /microservice?target=b)
- Based on IP Address - all requests from a range of IP address to target group A. Others to target group B

- You can have multiple listeners listening for a different protocol or port
- Sticky session also known as session persistence, refers to the process by which a load balancer establishes an affinity between a client and a specific network server for the duration of a session (i.e., the time a specific IP spends on a website). Sticky sessions can help to improve user experience while also optimizing network resource usage.
- A load balancer assigns an identifying attribute to a user with sticky sessions, typically by issuing a cookie or tracking their IP details. Then, based on the tracking ID, a load balancer can begin routing all of this user's requests to a specific server for the duration of the session.
- Advantages for using sticky sessions
- Reduced data exchange - When using sticky sessions, servers in your network do not need to exchange session data, which is an expensive process when done on a large scale.
- RAM cache utilization - Sticky sessions enable more efficient use of your application's RAM cache, resulting in improved responsiveness.
This is known as cookie-based persistence.
Instead of relying on the SSL/TLS session ID,
the load balancer would insert a cookie to
uniquely identify the session the first time a
client viewed the site, and then refer to that
cookie in subsequent requests to maintain the
connection to the proper server.
Duration based Session
Persistence -
Your load balancer sends out a cookie that specifies
the period for session stickiness. When the load
balancer gets a client request, it checks for the
presence of this cookie. The session is no longer
sticky once the stated time period has passed and
the cookie has expired.
Application Controlled
Session Persistence -
Application-based stickiness allows you to define
your own client-target stickiness criteria. When
application-based stickiness is enabled, the load
balancer directs the initial request to a target inside
the target group based on the algorithm selected. To
enable stickiness, the target is required to set a
custom application cookie that matches the cookie
setup on the load balancer.
Cross Zone Load Balancing -
- By default, CLB nodes distribute the traffic to instances in their availability zone only
- We enable cross-zone load balancing to route evenly across EC2 instances
- CLB routes each request to the instance with the smallest load
- In ALB cross zone balancing is enabled by default and does charge
- In NLB cross zonr balancing is disabled and chargable if enabled for inter AZ data
- In CLB cross zonr balancing is disabled but not chargable if enabled for inter AZ data
Connection Draining -
- By enabling this feature, you will be able to better manage the resources behind the Elastic Load Balancer, such as replacing backend instances without disrupting the user experience
- Taking an instance out of service and replacing it with a new EC2 instance with updated software, for example, while avoiding breaking open network connection
Load balancer SSL/TLS Certificates -
- Load balancer uses an X.509 certificate (SSL/TLS Certificates)
- You can manage certificates using ACM (AWS certificate manager)
- You can create upload your certificates alternatively
- HTTP Listners -
- You must specify the default certificate
- You can add optional list of certs to support multiple domains
- Clients can use SNI to specify the hostname they reach
- Ability to specify the security policy to support older versions SSL/TLS (legacy clients
- SNI solves the problem of loading multiple certs on to one web servers (to serve multiple websites)
- Its a newer protocol and requires client to indicate the hostname of the target server
- The server will then find the right cert or return to the default one
- Only works on ALB or NLB , CloudFront
- That's all for ELB guys please email if you have any corrections, additions, queries or to discuss something about the above points. EMAIL - mahajanrohit759@gmail.com
- Please share it with your friends
- In the next post, we will discuss about Auto scaling (ASG)
Comments
Post a Comment