Elastic Load Balancing automatically distributes your incoming application traffic across multiple targets, such as EC2 instances. It monitors the health of registered targets and routes traffic only to the healthy targets. Elastic Load Balancing supports three types of load balancers:

  • Application Load Balancers
  • Network Load Balancers
  • Classic Load Balancers.

Basics - Classic Load Balancer

  • A load balancer distributes incoming application traffic across multiple EC2 instances in same or multiple Availability Zones. This increases fault tolerence of applications.
  • Detects unhealthy instances and forwards traffic only to healthy instances. i.e. ELB performs health checks on instances every 30 secs. If ELB gets to know that a specific instance is unhealthy, it will stop sending traffic to that specific node and re-routes the traffic to healthy nodes.
  • Load Balancer is a single point of contact for clients. This increases availability of the application.
  • Anytime add / remove instances from load balancer without disrupting the LB.
  • By default, the LB distributes traffic evenly across all the AZ that you enable for your load balancer. To distribute traffic evenly across all registered instances in all enabled Availability Zones, enable _cross-zone load balancing _on your load balancer.. AWS recommends to keep approximately same number of instances in each AZ registered with LB. E.g. if you have ten instances in Availability Zone us-west-2a and two instances in us-west-2b, the requests are distributed evenly between the two Availability Zones. As a result, the two instances in us-west-2b serve the same amount of traffic as the ten instances in us-west-2a. Instead, you should have six instances in each Availability Zone.

Listener

It checks for connection requests from clients using the protocol and port that you configure, and forwards requests to one or more registered instances using the protocol and port number. There can be one or more listener for a load balancer.

A listener is configured with a protocol and a port for front-end (client to load balancer) connections and a protocol and a port for back-end (load balancer to instance) connections.

Benefits of Classic Load Balancer

Using a Classic Load Balancer instead of an Application Load Balancer has the following benefits:

  • Support for EC2-Classic

  • Support for TCP and SSL listeners

  • Support for sticky sessions using application-generated cookies

Steps in Creating a Classic Load Balancer

  1. Specify the VPC inside which the LB is created. The VPC inside which your EC2 instances are residing should be selected here.
  2. Confirm if the LB should be internet facing or internal only LB.
    1. For an Internet-facing load balancer, we create it in a public subnet. Load balancers in EC2-Classic are always Internet-facing load balancers. It receives a DNS name and a public IP, and the DNS name always resolves to its public IP.
    2. For an internal load balancer, it still receives a DNS name, but the IP is private IP and the DNS name always resolves to its private IP. Each load balancer node is connected to the private IP addresses of the back-end instances using elastic network interfaces. If cross-zone load balancing is enabled, each node is connected to each back-end instance, regardless of Availability Zone. Otherwise, each node is connected only to the instances that are in its Availability Zone.
  3. Select at-least 2 subnets within the selected VPC to ensure high availability of LB.
  4. Create and assign security group (firewall) for LB to allow HTTP traffic at 80 and HTTPS traffic at 443.
  5. Create the listener configuration for front end traffic and back end traffic. If HTTPS is added as listener, we also need to upload SSL certificate to LB.

  6. Create a security group for LB and assign it.

  7. If the LB is listening for HTTPS, we need to upload the SSL certificate. We can obtain a SSL certificate from ACM (Amazon Certificate Manager)

  8. Configure the health check. Define:

    1. Ping Protocol

    2. Ping Port

    3. Ping Path

  9. Configure configurations for health check. Define:

    1. Response Timeout (LB expects for HTTP 200 from EC2 instances within this time, else the ping will be deemed as failure and Unhealthy threshold will be incremented.)

    2. Interval

    3. Unhealthy Threshold (After how many consecutive health fails, an instance should be deemed unhealthy)

    4. Healthy Threshold (For failed instances only - After how many consecutive health success, that instance should be treated as healthy)

  10. The load balancer performs health checks on all registered instances, whether the instance is in a healthy state or an unhealthy state.

  11. Select the target EC2 instances within the selected VPCs.

  12. Select "Enable Cross Zone LB". This will ensure that traffic is evenly distributed to all the AZs. We cannot change this defailt behavior of classic LB.

  13. Connection Draining - This makes sure that the in-flight requests are being taken care of. Whenever the instance is unhealthy from a LBs perspective, it will always ensure that the future traffic doesn't go to it, and the in-flight requests already headed towards the unhealthy instance will be taken care of _within _the seconds configured here.

results matching ""

    No results matching ""