These notes were written while preparing for my AWS solution architect exam and are collected from different sources and AWS documentation. Primarily, they’re notes for me, but you might find them useful too.
Since the AWS is changing quickly, it’s possible that some of these notes may be out of date, so please take that into consideration if you are reading them.
Please let me know in the comments if you have any updates which you’d like me to add.
Elastic Load Balancing
- ELB service allows you to distribute incoming layer 4 or layer 7 traffic across a group of targets such as EC2 instances, containers, and IP addresses in one or more AZs. This enables you to achieve high availability.
- The elasticity of the ELB allows application load balancing scale up/down automatically. (Cost efficient)
- Before a client sends a request to your ELB, it resolves its domain name using a DNS.
- When you are creating your ELB, you need to specify whether you want an Internet-facing load balancer or an internal load balancer.
- Nodes of internal load balancer have only private IP addresses.
- Nodes of Internet-facing load balancer have public IP addresses and the DNS name is publicly available.
- Target instances do not need public IP addresses behind a load balancer. This is because load balancer uses private IP addresses of the targets.
- ELB seamlessly integrates with the Auto Scaling service to auto scale EC2 instances behind the load balancer.
- Application Load balancing can load balance HTTP/HTTPS plus usage of HTTP headers to do the load balancing.
- Application ELB Can terminate the HTTPS connection between the load balancer and the clients.
- Application ELB supports SSL certification management through IAM.
- Application ELB supports Lambda functions and IP addresses as target.
- You need at least two AZ in a VPC with a minimum of one public subnet in each AZ. These public subnets will be used to configure the application load balancer.
- You need a web server like Apache or IIS on an EC2 instance in each public subnet with a security group which allows HTTP/HTTPs for application load balancers.
- Every load balancer must have one or more listeners configured.
- A listener is a process that constantly checks for a connection request.
- A listener configured by a protocol and a port for its front-end connection, and a protocol and port for the back-end (targets) connection.
Idle Connection Time
- For each request that a client makes through an ELB, there are two connections. One from client to ELB, and one from ELB to the target. Idle connection time can be configured by the user to inform ELB a connection termination when the Idle connection time period has elapsed without any transfer of data.
- The default idle timeout is 60 seconds.
- Keep alive can be set either in a web server or the kernel setting of the EC2 instance to allow the ELB to reuse the connections to your back-end target which reduces CPU utilization.
Cross-Zone Load Balancing
- If cross zone disabled, ELB distributes the load across the registered targets in its AZ only.
- If cross zone enabled, ELB distributes the load across the registered targets in all AZs.
- When traffic comes toward AWS, it hits the Route 53 first for the DNS resolution. Next, the DNS provides the load balancer public IP to client and client hit the load balancer. At this point, if you have multiple load balancers, the request will be divided equally between the load balancers. If Cross-Zone enabled, one subnet can get let say 80% of the load because it has 80% of the targets in its subnet, whereas the other subnet will get only 20% of the load because it has only 20% of the targets in it. (if there are two subnets with two load balancers instead of 50-50)
- Cross-Zone load balancing reduces the need to maintain equivalent numbers of back-end targets.
- Use connection draining to ensure ELB stops sending requests to instances that are de-registering or unhealthy while keeping the existing connection open.
- Connection Draining helps to complete in-flight requests made to instances that are de-registering or unhealthy.
- By default ELB routes the traffic to the registered target with the lowest load, however, the sticky session can be enabled to inform ELB to bind a user’s session to a specific instance.
- If the application has its own session cookie then ELB can follow the duration set in the cookie. If not, then ELB can be configured to create a session cookie by specifying stickiness duration.
- ELB will create a cookie named AWSELB.
- ELB support health check to determine the health of the targets. A health check is a ping, a connection attempt, or a web page check.
- You can set the interval between each health check, and the amount that ELB can wait before getting the response.
- You also can set the number of consecutive failure before setting an instance OutOfService and vice versa (number of consecutive success before setting the InService)