Amazon Elastic Load Balancing

1. Welcome to Ducat India Language | Industrial Training | Digital Marketing | Web Technology | Testing+ | Database | Networking | Mobile Application | ERP | Graphic | Big Data | Cloud Computing Apply Now Training, Certification & Placement Call us: 70-70-90-50-90 www.ducatindia.com * See slide notes for page directions

2. Amazon Elastic Load Balancing Elastic Load Balancing is a hugely available service that distributes traffic across Amazon Elastic Compute Cloud (Amazon EC2) instances. It includes options that provide flexibility and control of incoming requests to Amazon EC2 instances. Types of Load Balancers Elastic Load Balancing provides various types of load balancers for handling different types of connections, including Internet-facing, internal, and load balancers that support encrypted connections. Internet-Facing Load Balancers An Internet-facing load balancer is, as the name implies, a load balancer that takes requests from clients over the Internet and distributes them to Amazon EC2 instances that are registered with the load balancer. When we configure a load balancer, it receives a public DNS name that clients can use to send requests to our application. The DNS servers resolve the DNS name to our load balancer’s public IP address, which can be visible to client applications. Internal Load Balancers In a multi-tier application, it is beneficial to load balance between the tiers of the application. For example, an Internet-facing load balancer can receive and balance external traffic to the demonstration or web tier whose Amazon EC2 instances then send its requests to a load balancer sitting in front of the application tier. We can use internal load balancers to route traffic to your Amazon EC2 instances in VPCs with private subnets.

3. HTTPS Load Balancers We can create a load balancer that uses the SSL/Transport Layer Security (TLS) protocol for encrypted connections (also known as SSL offload). This feature enables traffic encryption between our load balancer and the clients that initiate HTTPS sessions, and for connections between our load balancer and our back-end instances. Elastic Load Balancing supports security policies that have predefined SSL negotiation configurations to use to negotiate relations between users and the load balancer. To use SSL, we must install an SSL certificate on the load balancer that it uses to terminate the connection and then decrypt requests from clients before sending requests to the back-end Amazon EC2 instances. We can optionally choose to enable authentication on our back-end instances. Features of ELB There are main features of ELB are as follows:

4. Sticky sessions The sticky session is a way to consistently route traffic requests from a particular user to the same target instance based on an HTTP session, IP address, or a cookie. Classic load balancer supports application cookies, or if an application does not have a cookie, we can create a session cookie by specifying stickiness duration in ELB configuration. It creates a cookie named AWSELB for mapping the session to an instance. Idle connection timeout Every time a user requests an ELB, it maintains two connections. One connection is created with the client, and another link is created with the target EC2 instance. For each of these connections, ELB maintains an idle timeout period. If there is no activity during the specified idle time between the client and the target EC2 instance, ELB closes this connection. Connection draining An ELB stops sending requests to instances that are either unhealthy or are deregistering from the ELB. This can lead to the abrupt closure of an ongoing session initiated by a user. Such abrupt closed sessions give an unpleasant experience to an application user. To take care of such user experience issues, AWS supports connection draining in an ELB. When connection draining is enabled, and an instance becomes unhealthy or deregistering, an ELB stops sending new requests to such instances; however, it completes any in-flight request made to such instances. Cross-zone load balancing When a Classic Load Balancing is created with instances spread across multiple AZs, it distributes the traffic evenly between the associated AZs. If we have an ELB with ten instances in US-East-1a and two instances in US-East-1b, the traffic is distributed evenly between two AZs. This means two instances in US-East-1b serve the same amount of traffic as ten instances in US-East-1a. This is the default behavior of Classic Load Balancing. If we enable cross-zone load balancing, an ELB distributes traffic evenly between all the EC2 instances across multiple AZs.

5. CloudWatch Metrics AWS sends data points to CloudWatch for load balancers and all the instances associated with it. CloudWatch aggregates those data points and creates statistics in an ordered set of time-series data. This time-series data is called CloudWatch metrics for ELB. With CloudWatch metrics, we can verify the number of healthy EC2 instances in a load balancer during a specific period. It helps to confirm whether the system is consistently performing as expected or not. With CloudWatch, we can create an event trigger in case the metric is outside of the acceptable range. Such event triggers can send a mail to stakeholders or take any specific action based on its association with either Lambda function or Auto Scaling group. Proxy protocol When an end-user request hits ELB, ELB changes source IP and other request header and forwards it to one of the EC2 instances where the application is hosted. This is the default behavior of ELB, which bars an application from obtaining original client connection information. In some enterprise applications, it is required to have source connection details to perform traffic analysis. It helps the application to understand more about end user’s behavior with such information. Read More: https://tutorials.ducatindia.com/aws/amazon-elastic-load-balancing/

6. Thank You!! Call us: 70-70-90-50-90 www.ducatindia.com * See slide notes for page directions