2022-02-15 Chapter 11 - Elastic Load Balancing

service-elb-001; The AWS {{c1::Elastic Load Balancing}} service automatically distributes incoming application traffic across multiple targets, such as {{c1::EC2 instances}}. This can be done across multiple {{c1::AZs}}.

service-elb-002; Elastic Load Balancing offers {{c1::3}} different types of load balancers which are likely to be covered in the SAA-C02 exam.

service-elb-003; {{c1::Application Load Balancer}} is a type of load balancer offered within the Elastic Load Balancing service. It is best suited for load balancing of {{c1::HTTP}} and {{c1::HTTPS}} traffic. It operates at Layer 7 and is application-aware. It can be thought of as an {{c1::intelligent}} load balancer.

service-elb-004;{{c1::Network Load Balancer}} is a type of load balancer offered within the Elastic Load Balancing service. It operates at the connection level (Layer 4). It is capable of handling millions of requests per second while maintaining ultra-low latencies. It can be thought of as a {{c1::high-performance}} load balancer.

service-elb-005; {{c1::Classic Load Balancer}} is a legacy type of load balancer offered within the Elastic Load Balancing service. It can load balance HTTP/HTTPS applications and use Layer 7-specific features, such as X-Forwarded and sticky sessions. It can be thought of as a classic/{{c1::test/dev}} load balancer.

service-elb-006; All load balancers can be configured with health checks. These periodically send requests to instances that are behind the load balancers to test their status. The status of the instances that are healthy at the time of the health check is {{c1::InService}}. The status of instances that are unhealthy at the time of the health check is {{c1::OutOfService}}. Load balancers route requests only to the {{c1::healthy}} instances.

service-elb-007; After an Application Load Balancer receives a request, it evaluates the {{c1::listener rules}} in priority order to determine which {{c1::rule}} to apply, and then selects a {{c1::target}} from the {{c1::target}} group for the rule {{c1::action}}.

service-elb-008; In an Application Load Balancer, a {{c1::listener}} checks for connection requests from clients, using the {{c1::protocol}} and {{c1::port}} you configure.

service-elb-009; In an Application Load Balancer, each rule consists of a {{c1::priority}}, one or more {{c1::actions}} and one or more {{c1::conditions}}.

service-elb-010; In an Application Load Balancer, you must define a {{c1::default rule}} for each listener, and you can optionally define additional {{c1::rules}}.

service-elb-011; Application Load Balancers can use {{c1::path-based routing}} to direct requests based on pattern matching against the URL path.

service-elb-012; An Application Load Balancer only supports {{c1::HTTP}} and {{c1::HTTPS}} protocols.

service-elb-013; To use an HTTPS listener in an Application Load Balancer, you must deploy at least one {{c1::SSL/TLS server certificate}} on your load balancer. The load balancer uses a {{c1::server certificate}} to terminate the frontend connection then decrypt the request from clients before sending them to the targets.

service-elb-014; After a Network Load Balancer receives a connection request, it selects a target from the target group for the default rule. It attempts to open a {{c1::TCP}} connection to the selected target on the port specific in the listener configuration.

service-elb-015; Unlike Application Load Balancers, Network Load Balancers do not support {{c1::additional rules}}.

service-elb-016; A Network Load Balancer supports T{{c1::CP}}, T{{c1::LS}}, U{{c1::DP}} and T{{c1::CP_UDP}} protocols on any port.

service-elb-017; Network Load Balancers can handle {{c1::encryption}} and {{c1::decryption}} using TLS listeners. If the listener protocol is TLS then you must deploy exactly one {{c1::SSL server certificate}} on the listener.

service-elb-018; A Classic Load Balancer supports the {{c1::X-Forwarded-For}} request header in order that the target server can see the client's original IP address.

service-elb-019; A Classic Load Balancer will respond with a {{c1::504 error}} if the underlying application is having issues. These could be either at the web server layer or the database layer.

service-elb-020; {{c1::Sticky sessions}} allow you to bind a user's session to a specific EC2 instance when using a Classic Load Balancer. You can also enable {{c1::sticky sessions}} in an Application Load Balancer, which binds traffic to a {{c1::target group}} rather than a specific instance.

service-elb-021; If a user receives an error because they are directed to a terminated instance because of sticky sessions in a Classic Load Balancer, you can solve the issue by {{c1::disabling}} sticky sessions.

service-elb-022; {{c1::Deregistration Delay}} (or {{c1::Connection Draining}}) is a feature that allows load balancers to keep existing connections open for a given time interval if the EC2 instances are de-registered or become unhealthy.

service-elb-023; If no hosts are healthy, a NLB load balancer will {{c1::send traffic to all the instances, hoping one is online}}.