You can select the appropriate load balancer based on your application needs. If you need flexible application management, we recommend that you use an Application Load Balancer. If extreme performance and static IP is needed for your application, we recommend that you use a Network Load Balancer. If you have an existing application that was built within the EC2-Classic network, then you should use a Classic Load Balancer.
|Feature||Application Load Balancer||Network Load Balancer||Gateway Load Balancer||Classic Load Balancer|
|Load Balancer type||Layer 7||Layer 4||Layer 3 Gateway + Layer 4 Load Balancing||Layer 4/7|
|Target type||IP, Instance, Lambda||IP, Instance||IP, Instance|
|Terminates flow/proxy behavior||Yes||Yes||No||Yes|
|Protocol listeners||HTTP, HTTPS, gRPC||TCP, UDP, TLS||IP||TCP, SSL/TLS, HTTP, HTTPS|
|Reachable via||VIP||VIP||Route table entry|
|Desync Mitigation Mode||✔|
|HTTP header based routing||✔|
|Common configurations and characteristics|
|IP address - Static, Elastic||✔|
|Connection draining (deregistration delay)||✔||✔|
|Configurable idle connection timeout||✔||✔|
|PrivateLink Support||✔ (TCP, TLS)||✔ (GWLBE)|
|Long-lived TCP connection||✔||✔|
|Load Balancing to multiple ports on the same instance||✔||✔||✔|
|Load Balancer deletion protection||✔||✔||✔|
|Preserve Source IP address||✔||✔||✔|
|Supported network/Platforms||VPC||VPC||VPC||EC2-Classic, VPC|
|Cross-zone Load Balancing||✔||✔||✔||✔|
|IAM Permissions(Resource, Tag based)||✔||✔||✔||✔ (Only resource based)|
Flow Stickiness (All packets of a flow are sent to one target, and return traffic comes from same target)
Target Failure behavior
|Fail close on targets, unless all targets are unhealthy(fail open)||Fail close on targets, unless all targets are unhealthy(fail open)||Existing flows continue to go to existing target appliances, new flows are rerouted to healthy target appliances.|
|Health Checks||HTTP, HTTPS, gRPC||TCP, HTTP, HTTPS||TCP, HTTP, HTTPS||TCP, SSL/TLS, HTTP, HTTPS|
|Server Name Indication (SNI)||✔||✔|
|Back-end Server Encryption||✔||✔||✔|
|Custom Security Policy||✔|
|Kubernetes Ingress Controller|
|IP Address targeting||✔ (Fargate pods)|
|Load Balance to multiple namespaces||✔|
|Support for fully private EKS clusters||✔||✔|
|Logging and monitoring|
When using Amazon Virtual Private Cloud (VPC), you can create and manage security groups associated with Elastic Load Balancing to provide additional networking and security options for Application Load Balancer and Classic Load Balancer. You can configure any of the Load Balancers to be Internet facing or create a load balancer without public IP addresses to serve as an internal (non-internet-facing) load balancer.
An Elastic Load Balancer is highly available. You can distribute incoming traffic across your Amazon EC2 instances in a single Availability Zone or multiple Availability Zones. An Elastic Load Balancer automatically scales its request handling capacity in response to incoming application traffic. To ensure that your targets are available and healthy, Elastic Load Balancer runs health checks on targets on a configurable cadence.
Elastic Load Balancer is designed to handle traffic as it grows and can load balance millions of requests/sec. It can also handle sudden volatile traffic patterns.
An Elastic Load Balancer only routes traffic to healthy targets such as EC2 instances, containers, IP addresses, microservices, Lambda functions, and Appliances. With Elastic Load Balancing, you get improved insight into the health of your applications in two ways: (1) health check improvements that allow you to configure detailed error codes. The health checks allow you to monitor the health of each of your services behind the the load balancer; and (2) new metrics that give insight into traffic for each of the services running on an EC2 instance.
Sticky sessions are a mechanism to route requests from the same client to the same target. Elastic Load Balancers support sticky sessions. Stickiness is defined at a target group level.
Operational monitoring & logging
Amazon CloudWatch reports Application and Classic Load Balancer metrics such as request counts, error counts, error types, request latency, and more. Amazon CloudWatch also tracks Network and Gateway Load Balancer metrics such as Active Flow count, New Flow Count, Processed bytes, and more. Elastic Load Balancers are also integrated with AWS CloudTrail which tracks API calls to the ELB.
You can enable deletion protection on an Elastic Load Balancer to prevent it from being accidentally deleted.