AWS Elastic Load Balancing (ELB)

Home » AWS Cheat Sheets » AWS Networking & Content Delivery » AWS Elastic Load Balancing (ELB)

AWS Elastic Load Balancing (ELB)

Last updated on February 2, 2024

AWS Elastic Load Balancing Cheat Sheet

  • Distributes incoming application or network traffic across multiple targets, such as EC2 instances, containers (ECS), Lambda functions, and IP addresses, in multiple Availability Zones.
  • When you create a load balancer, you must specify one public subnet from at least two Availability Zones. You can specify only one public subnet per Availability Zone.

General Features

  • Accepts incoming traffic from clients and routes requests to its registered targets.
  • Monitors the health of its registered targets and routes traffic only to healthy targets.
  • Enable deletion protection to prevent your load balancer from being deleted accidentally. Disabled by default.
  • Deleting ELB won’t delete the instances registered to it.
  • Cross Zone Load Balancing – when enabled, each load balancer node distributes traffic across the registered targets in all enabled AZs.
  • Supports SSL Offloading which is a feature that allows the ELB to bypass the SSL termination by removing the SSL-based encryption from the incoming traffic.

Types of Load Balancers

  • Application Load Balancer ( ALB )

Tutorials dojo strip
    • Functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model.
    • Allows HTTP and HTTPS.
    • At least 2 subnets must be specified when creating this type of load balancer.
    • Components:
      • A load balancer serves as the single point of contact for clients.
      • A listener checks for connection requests from clients. You must define a default rule for each listener that specifies a target group, condition, and priority.
      • Target group routes requests to one or more registered targets. You can register a target with multiple target groups, and configure health checks on a per target group basis.

AWS Training AWS Elastic Load Balancing 2

    • Benefits
      • Support for path-based and host-based routing.
      • Support for routing requests to multiple applications on a single EC2 instance.
      • Support for registering targets by IP address, including targets outside the VPC for the load balancer.
      • Support for containerized applications.
      • Support for monitoring the health of each service independently.
      • Support for redirecting requests from one URL to another.
      • Support for returning a custom HTTP response.
      • Support for the load balancer to authenticate users of your applications before routing requests using OIDC-compliant identity providers and/or Amazon Cognito user pools.
      • Support for registering Lambda functions as targets.
      • Supports load balancer-generated cookies for sticky sessions.
      • Supports Application-based cookie stickiness. This ensures that clients connect to the same load balancer target for the duration of their session using application cookies.
      • Supports dual-stack mode. This enables you to create IPv6 target groups and link IPv4 and IPv6 clients to targets in IPv6 or dual-stack subnets.
    • Cross-zone load balancing is always enabled.
    • If you specify targets using an instance ID, traffic is routed to instances using the primary private IP address specified in the primary network interface for the instance. If you specify targets using IP addresses, you can route traffic to an instance using any private IP address from one or more network interfaces.
    • You can also specify Lambda functions are targets to serve HTTP(S) requests.
    • HTTP/2 Support
    • WebSockets Support
    • Monitoring:
      • CloudWatch metrics – retrieve statistics about data points for your load balancers and targets as an ordered set of time-series data, known as metrics.
      • Access logs – capture detailed information about the requests made to your load balancer and store them as log files in S3.
      • Request tracing – track HTTP requests.
      • CloudTrail logs – capture detailed information about the calls made to the Elastic Load Balancing API and store them as log files in S3.
  • Network Load Balancer ( NLB )

    • Functions at the fourth layer of the Open Systems Interconnection (OSI) model. Uses TCP and UDP connections.
    • At least 1 subnet must be specified when creating this type of load balancer, but the recommended number is 2.
    • Components:
      • A load balancer serves as the single point of contact for clients.
      • A listener checks for connection requests from clients.
      • A target group routes requests to one or more registered targets. You can register a target with multiple target groups. You can configure health checks on a per target group basis.
    • Benefits
      • Ability to handle volatile workloads and scale to millions of requests per second.
      • Support for static IP addresses for the load balancer, or assign one Elastic IP address per subnet enabled for the load balancer.
      • Support for registering targets by IP address.
      • Support for routing requests to multiple applications on a single EC2 instance (register each instance or IP address with the same target group using multiple ports).
      • Support for containerized applications.
      • Support for monitoring the health of each service independently.
      • Supports forwarding traffic directly from NLB to ALB.
      • Supports load balancing for both IPv4 and IPv6 clients.
    • Cross-zone load balancing is disabled by default.
    • If you specify targets using an instance ID, the source IP addresses of the clients are preserved and provided to your applications. If you specify targets by IP address, the source IP addresses are the private IP addresses of the load balancer nodes.
    • Network Load Balancers support connections from clients over inter-region VPC peering, AWS managed VPN, and third-party VPN solutions.
    • You can deploy services that rely on the UDP protocol, such as Authentication and Authorization, Logging, DNS, and IoT, behind a Network Load Balancer
    • Offers multi-protocol listeners, allowing you to run applications such as DNS that rely on both TCP and UDP protocols on the same port behind a Network Load Balancer.
    •  
    • You CANNOT enable or disable Availability Zones for a Network Load Balancer after you create it.
    • Network Load Balancers use Proxy Protocol version 2 to send additional connection information such as the source and destination.
    • Preserves the client-side source IP allowing the back-end to see the IP address of the client. This can then be used by applications for further processing.
    • Automatically provides a static IP per Availability Zone (subnet) that can be used by applications as the front-end IP of the load balancer.
    • Zonal Isolation
    • In the event that your Network load balancer is unresponsive, integration with Route 53 will remove the unavailable load balancer IP address from service and direct traffic to an alternate Network Load Balancer in another region.
    • Supports TLS termination on Network Load Balancers. Additionally, Network Load Balancers preserve the source IP of the clients to the back-end applications, while terminating TLS on the load balancer.
    • Monitoring:
      • CloudWatch metrics – retrieve statistics about data points for your load balancers and targets as an ordered set of time-series data, known as metrics.
      • VPC Flow Logs – capture detailed information about the traffic going to and from your Network Load Balancer.
      • Access Logs – capture detailed information about the requests made to your load balancer and store them as log files in S3.
      • CloudTrail logs – capture detailed information about the calls made to the Elastic Load Balancing API and store them as log files in Amazon S3.
  • Gateway Load Balancer ( GWLB )

    • Primarily used for deploying, scaling, and running third-party virtual appliances.
    • The virtual appliances can be your custom firewalls, deep packet inspection systems, or intrusion detection and prevention systems in AWS 
    • Uses the Internet Protocol (IP) to pass the OSI Layer 3 traffic to its registered targets.
    • GWLB Target groups support the Generic Networking Virtualization Encapsulation (GENEVE) on port: 6081
    • Runs within one Availability Zone (AZ)
    • You cannot specify publicly routable IP addresses as your target
    • You can provision a Gateway Load Balancer Endpoint that creates a secured, low-latency, connections to and from the virtual appliance  
    • Does not support SSL Offloading, Server Name Indication (SNI), Back-end Server Encryption, User Authentication, Custom Security Policy or Application-Layer Protocol Negotiation (ALPN)
    • Monitoring:
      • CloudWatch metrics –  retrieve statistics about data points for your Gateway Load Balancers and virtual appliances (targets).
      • VPC Flow Logs – capture the information about the incoming and outgoing traffic to and from your Gateway Load Balancers (GWLB).
      • CloudTrail logs –  determine which GWLB API calls were made, the source IP address where the call came from, who made the call and when the call was made.
  • Classic Load Balancer ( CLB )

    • Distributes incoming application traffic across multiple EC2 instances in multiple Availability Zones.
    • For use with EC2 classic only. Register instances with the load balancer. AWS recommends using Application or Network load balancers instead.

AWS Training AWS Elastic Load Balancing 3

    • To ensure that your registered instances are able to handle the request load in each AZ, keep approximately the same number of instances in each AZ registered with the load balancer.
    • Benefits
      • Support for EC2-Classic
      • Support for TCP and SSL listeners
      • Support for sticky sessions using application-generated cookies
    • An Internet-facing load balancer has a publicly resolvable DNS name, so it can route requests from clients over the Internet to the EC2 instances that are registered with the load balancer. Classic load balancers are always Internet-facing.
    • Monitoring:
      • CloudWatch metrics – retrieve statistics about ELB-published data points as an ordered set of time-series data, known as metrics.
      • Access logs – capture detailed information for requests made to your load balancer and stores them as log files in the S3 bucket that you specify.
      • CloudTrail logs – keep track of the calls made to the Elastic Load Balancing API by or on behalf of your AWS account
  • HTTP Headers

    • Application Load Balancers and Classic Load Balancers support X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port headers.

  • Choose whether to make an internal load balancer or an Internet-facing load balancer. Classic Load Balancer in EC2-Classic must be an Internet-facing load balancer.
    • The nodes of an Internet-facing load balancer have public IP addresses.
    • The nodes of an internal load balancer have only private IP addresses.
  • Public DNS name format for your load balancers
    • EC2-VPC : name-1234567890.region.elb.amazonaws.com (supports IPv4 addresses only)
    • EC2-Classic: (support both IPv4 and IPv6 addresses)
      • name-123456789.region.elb.amazonaws.com
      • ipv6.name-123456789.region.elb.amazonaws.com    
      • dualstack.name-123456789.region.elb.amazonaws.com
  • Load Balancer States

    • Provisioning – The load balancer is being set up.
    • Active – The load balancer is fully set up and ready to route traffic.
    • Failed – The load balancer could not be set up.
  • By default, ELB idle timeout value to 60 seconds. If a target doesn’t send data at least every 60 seconds while the request is in flight, the load balancer can close the front-end connection. For back-end connections, enable the HTTP keep-alive option for your EC2 instances.
  • You can register each EC2 instance or IP address with the same target group multiple times using different ports, which enables the load balancer to route requests to microservices.
  • Listeners define the port and protocol to listen on.
  • Listener rules determine how the load balancer routes requests to the targets in one or more target groups. You can add rules that specify different target groups based on the content of the request. If no rules are found, the default rule will be followed. Parts are:
    • Rule priority
    • Rule action
    • Rule conditions
  • Slow Start Mode gives targets time to warm up before the load balancer sends them a full share of requests.
  • Sticky sessions route requests to the same target in a target group. You enable sticky sessions at the target group level. You can also set the duration for the stickiness of the load balancer-generated cookie, in seconds. Useful if you have stateful applications.
  • Health checks verify the status of your targets. The statuses for a registered target are:

Value

Description

initial

The load balancer is in the process of registering the target or performing the initial health checks on the target.

healthy

The target is healthy.

unhealthy

The target did not respond to a health check or failed the health check.

unused

The target is not registered with a target group, the target group is not used in a listener rule for the load balancer, or the target is in an Availability Zone that is not enabled for the load balancer.

draining

The target is deregistering and connection draining is in process.

Security, Authentication and Access Control

  • Use IAM Policies to grant permissions
  • Resource-level permissions
  • Security groups that control the traffic allowed to and from your load balancer.
    Recommended rules for internet-facing load balancer:

Inbound

Source

Port Range

0.0.0.0/0

listener

Outbound

Destination

Port Range

instance security group

instance listener

instance security group

health check

For internal load balancer:

Inbound

Source

Port Range

VPC CIDR

listener

Outbound

Destination

Port Range

instance security group

instance listener

instance security group

health check

Summary of Features 

Feature Application Load Balancer Network Load Balancer Gateway Load Balancer
Protocols HTTP, HTTPS, gRPC TCP, UDP, TLS IP
Platforms VPC VPC VPC
Health checks HTTP, HTTPS, gRPC TCP, HTTP, HTTPS TCP, HTTP, HTTPS
Cloudwatch Metrics Yes Yes Yes
Logging Yes Yes Yes
Zonal Failover Yes Yes Yes
Connection Draining (deregistration delay) Yes Yes Yes
Load Balancing to multiple ports on the same instance Yes Yes Yes
IP addresses as targets Yes Yes (TCP, TLS) Yes
Load Balancer deletion protection Yes Yes Yes
Configuration idle connection timeout Yes    
Cross-zone load balancing Yes Yes Yes
Sticky sessions Yes Yes Yes
Static IP   Yes  
Elastic IP address   Yes  
Preserve Source IP address Yes Yes Yes

Resource-based IAM permissions/ Tag-based IAM permissions

Yes Yes Yes
Slow start Yes    
Web sockets Yes Yes Yes
PravateLink Support   Yes (TCP, TLS) Yes (GWLBE)
Source IP address CIDR-based routing Yes    

Layer 7

Path-based routing Yes    
Host-based routing Yes    
Native HTTP/2 Yes    
Redirects Yes    
Fixed Response Yes    
Lambda Functions as targets Yes    
HTTP header-based routing Yes    
HTTP method-based routing Yes    
Query parameter-based routing Yes    

Security

SSL offloading Yes Yes  
Server Name Indication (SNI) Yes Yes  
Back-end server encryption Yes Yes  
User authentication Yes    
Session resumption  Yes Yes  
Terminates flow/proxy behavior Yes Yes Yes

 

AWS Elastic Load Balancing  Pricing

  • You are charged for each hour or partial hour that an Application Load Balancer is running and the number of Load Balancer Capacity Units (LCU) used per hour.
  • You are charged for each hour or partial hour that a Network Load Balancer is running and the number of Load Balancer Capacity Units (LCU) used by Network Load Balancer per hour.
  • You are charged for each hour or partial hour that a Gateway Load Balancer is running and the number of Gateway Load Balancer Capacity Units (GLCU) used by Gateway Load Balancer per hour.
  • You are charged per VPC endpoint, AZ, and GB of data processed for the Gateway Load Balancer Endpoint.
  • You are charged for each hour or partial hour that a Classic Load Balancer is running and for each GB of data transferred through your load balancer.

Best Practices on Elastic Load Balancing:

AWS Elastic Load Balancing-related Cheat Sheets:

Note: If you are studying for the AWS Certified Advanced Networking Specialty exam, we highly recommend that you take our AWS Certified Advanced Networking – Specialty Practice Exams and read our Advanced Networking Specialty exam study guide.

AWS Certified Advanced Networking Specialty Practice Exams

Validate Your Knowledge

Question 1

What is the primary reason why you should be using an elastic load balancer for a website with high activity?

  1. ELBs help you scale servers easily without manual intervention
  2. ELBs can distribute traffic equally to your backend targets to handle the incoming traffic load
  3. ELBs help tighten security through the use of security groups
  4. ELBs boost your website’s overall performance

Correct Answer: 2

Elastic Load Balancing automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, IP addresses, and Lambda functions. It can handle the varying load of your application traffic in a single Availability Zone or across multiple Availability Zones.

Elastic Load Balancing offers three types of load balancers that all feature the high availability, automatic scaling, and robust security necessary to make your applications fault-tolerant. They are Application Load Balancer, Network Load Balancer, and Gateway Load Balancer.

Hence, the correct answer is: ELBs can distribute traffic equally to your backend targets to handle the incoming traffic load.

The option that says: ELBs help you scale easily without manual intervention is incorrect. For automatic scaling of your compute capacity, you need another service called AWS Auto Scaling to go with your load balancers. Auto-scaling handles the scaling of capacity for you so that your instances are not being overwhelmed.

The option that says: ELBs help tighten security through the use of security groups is incorrect. Although ELBs do add security for your instances, it is not solely because of security groups. Security groups can be used directly with EC2 instances, so this statement is not the best answer for the scenario.

The option that says: ELBs boost your website’s overall performance is incorrect because ELBs do not boost website performance. This is usually done by another AWS service known as Amazon CloudFront. ELBs redirect traffic to healthy instances in a controlled manner, providing you the elasticity and fault tolerance that your applications need.

References:

https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html
https://aws.amazon.com/elasticloadbalancing/features/

Check out this AWS Elastic Load Balancing Cheat Sheet:
https://tutorialsdojo.com/aws-elastic-load-balancing-elb/

AWS Exam Readiness Courses

Application Load Balancer vs Network Load Balancer vs Classic Load Balancer vs Gateway Load Balancer:
https://tutorialsdojo.com/application-load-balancer-vs-network-load-balancer-vs-classic-load-balancer/

AWS Elastic Load Balancing Overview:

 

Note: This question was extracted from our AWS Certified Cloud Practitioner Practice Exams.

Question 2

After a year of development, the company’s 100-node high-performance computing (HPC) application is now ready to be deployed to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster with Horizontal Pod Autoscaler (HPA). The application must be capable of receiving millions of UDP traffic per second from the public Internet while maintaining low latency.

Which of the following is the most operationally efficient solution that should be implemented to meet the above requirements?

  1. Launch a Gateway Load Balancer and integrate an Elastic Fabric Adapter (EFA) to each Kubernetes pod deployed in the Amazon EKS cluster
  2. Integrate the AWS Load Balancer Controller add-on to the EKS cluster. Launch a Network Load Balancer to load balance network traffic to individual Kubernetes pods.
  3. Install the AWS Load Balancer Controller add-on to the EKS cluster and launch an Application Load Balancer to distribute the incoming traffic to the Kubernetes pods.
  4. Set up the kube-proxy Amazon EKS add-on to the cluster and configure the Source Network Address Translation (SNAT) of the Kubernetes pods by setting the AWS_VPC_K8S_CNI_EXTERNALSNAT configuration to true.

Correct Answer: 2

Network Load Balancer operates at the connection level (Layer 4), routing connections to targets – Amazon EC2 instances, microservices, and containers – within Amazon Virtual Private Cloud (Amazon VPC) based on IP protocol data. Ideal for load balancing of both TCP and UDP traffic, Network Load Balancer is capable of handling millions of requests per second while maintaining ultra-low latencies. Network Load Balancer is optimized to handle sudden and volatile traffic patterns while using a single static IP address per Availability Zone. It is integrated with other popular AWS services such as Auto Scaling, Amazon EC2 Container Service (ECS), Amazon CloudFormation, and AWS Certificate Manager (ACM).

Network Load Balancer preserves the client-side source IP address, allowing the back-end EC2 instances to see the IP address of the client. This can then be used by applications for further processing. 

Network traffic is load balanced at L4 of the OSI model. To load balance application traffic at L7, you deploy a Kubernetes ingress, which provisions an AWS Application Load Balancer. An AWS Network Load Balancer can load balance network traffic to pods deployed to Amazon EC2 IP and instance targets or to AWS Fargate IP targets.

The AWS Load Balancer Controller manages AWS Elastic Load Balancers for a Kubernetes cluster. The controller provisions the following resources:

– An AWS Application Load Balancer (ALB) when you create a Kubernetes Ingress.

– An AWS Network Load Balancer (NLB) when you create a Kubernetes service of type LoadBalancer.

In the past, the Kubernetes network load balancer was used for instance targets, but the AWS Load balancer Controller was used for IP targets. With the AWS Load Balancer Controller version 2.3.0 or later, you can create NLBs using either target type. The AWS Load Balancer Controller controller was formerly named the AWS ALB Ingress Controller. It’s an open-source project managed on GitHub.

Hence, the correct answer is Integrate the AWS Load Balancer Controller add-on to the EKS cluster. Launch a Network Load Balancer to load balance network traffic to individual Kubernetes pods.

The option that says: Install the AWS Load Balancer Controller add-on to the EKS cluster and launch an Application Load Balancer to distribute the incoming traffic to the Kubernetes pods is incorrect because an ALB is not capable of handling millions of requests per second while maintaining ultra-low latencies, unlike a Network Load Balancer. Moreover, this type of load balancer doesn’t preserve the client-side source IP address.

The option that says: Launch a Gateway Load Balancer and integrate an Elastic Fabric Adapter (EFA) to each Kubernetes pod deployed in the Amazon EKS cluster is incorrect because a Gateway Load Balancer simply helps you easily deploy, scale, and manage your third-party virtual appliances. This type of load balancer is not capable of receiving millions of requests per second while maintaining low latency.

The option that says: Set up the kube-proxy Amazon EKS add-on to the cluster and configure the Source Network Address Translation (SNAT) of the Kubernetes pods by setting the AWS_VPC_K8S_CNI_EXTERNALSNAT configuration to true is incorrect because kube-proxy just maintains network rules on each Amazon EC2 node of the EKS cluster. In addition, changing the default SNAT configuration is also unwarranted since the scenario didn’t mention any connection between your EKS cluster VPC to another VPC peering, a transit VPC, or a Direct Connect connection. SNAT must only be changed if these aforementioned resources need to initiate communication with your pods using an IPv4 address.

References:

https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html
https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html
https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html

Note: This question was extracted from our AWS Certified Advanced Networking Specialty Practice Exams.

For more AWS practice exam questions with detailed explanations, visit the Tutorials Dojo Portal:

Tutorials Dojo AWS Practice Tests

Additional Training Materials: AWS Elastic Load Balancing Video Courses on Udemy

  1. Amazon EC2 Master Class (with Auto Scaling & Load Balancer) 
  2. AWS: Get Started with Load Balancing and Auto-Scaling Groups

AWS ELB Cheat Sheet References:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html
https://aws.amazon.com/elasticloadbalancing/features/
https://aws.amazon.com/elasticloadbalancing/pricing/?nc=sn&loc=3

Tutorials Dojo portal

Be Inspired and Mentored with Cloud Career Journeys!

Tutorials Dojo portal

Enroll Now – Our Azure Certification Exam Reviewers

azure reviewers tutorials dojo

Enroll Now – Our Google Cloud Certification Exam Reviewers

Tutorials Dojo Exam Study Guide eBooks

tutorials dojo study guide eBook

FREE AWS Exam Readiness Digital Courses

Subscribe to our YouTube Channel

Tutorials Dojo YouTube Channel

FREE Intro to Cloud Computing for Beginners

FREE AWS, Azure, GCP Practice Test Samplers

Recent Posts

Written by: Jon Bonso

Jon Bonso is the co-founder of Tutorials Dojo, an EdTech startup and an AWS Digital Training Partner that provides high-quality educational materials in the cloud computing space. He graduated from Mapúa Institute of Technology in 2007 with a bachelor's degree in Information Technology. Jon holds 10 AWS Certifications and is also an active AWS Community Builder since 2020.

AWS, Azure, and GCP Certifications are consistently among the top-paying IT certifications in the world, considering that most companies have now shifted to the cloud. Earn over $150,000 per year with an AWS, Azure, or GCP certification!

Follow us on LinkedIn, YouTube, Facebook, or join our Slack study group. More importantly, answer as many practice exams as you can to help increase your chances of passing your certification exams on your first try!

View Our AWS, Azure, and GCP Exam Reviewers Check out our FREE courses

Our Community

~98%
passing rate
Around 95-98% of our students pass the AWS Certification exams after training with our courses.
200k+
students
Over 200k enrollees choose Tutorials Dojo in preparing for their AWS Certification exams.
~4.8
ratings
Our courses are highly rated by our enrollees from all over the world.

What our students say about us?