If you’re not aware of Amazon Elastic Load Balancing Service, I’d suggest you to read What is Amazon ELB? before going through the FAQ.
- Elastic Load Balancing supports three types of load balancers.
- If you need flexible application management then we recommend you to use Application Load Balancer.
- If extreme performance and static IP is needed for your application then we recommend you to use Network Load Balancer.
- If your application is built within the EC2 Classic network then you should use Classic Load Balancer.
You can privately access Elastic Load Balancing APIs from your Amazon Virtual Private Cloud (VPC) by creating VPC endpoints. With VPC endpoints, the routing between the VPC and Elastic Load Balancing APIs is handled by the AWS network without the need for an Internet gateway, NAT gateway, or VPN connection.
Elastic Load Balancing guarantees a monthly availability of at least 99.99% for your load balancers.
HTTP/2 support is enabled natively on an Application Load Balancer. Clients that support HTTP/2 can connect to an Application Load Balancer over TLS.
Application Load Balancers are the foundation of our application layer load-balancing platform for the future.
Application Load Balancers require a new set of APIs. You cannot use existing APIs that I use with my Classic Load Balancer with an Application Load Balancer.
You cannot convert one load balancer type into another.
You can migrate to Application Load Balancer from Classic Load Balancer
If you need Layer-4 features, you should use Network Load Balancer.
You can terminate HTTPS connection on the Application Load Balancer. You must install an SSL certificate on your load balancer. The load balancer uses this certificate to terminate the connection and then decrypt requests from clients before sending them to targets.
An Application Load Balancer is integrated with AWS Certificate Management (ACM). Integration with ACM makes it very simple to bind a certificate to the load balancer thereby making the entire SSL offload process very easy.
You can associate multiple certificates for the same domain to a secure listener.
You can integrate your Application Load Balancer with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing you to configure rules based on IP addresses, HTTP headers, and custom URI strings. Using these rules, AWS WAF can block, allow, or monitor (count) web requests for your web application.
There are various ways to achieve hybrid load balancing. If an application runs on targets distributed between a VPC and an on-premises location, you can add them to the same target group using their IP addresses. To migrate to AWS without impacting your application, gradually add VPC targets to the target group and remove on-premises targets from the target group. If you have two different applications such that the targets for one application are in a VPC and the targets for other applications are in on-premises location, you can put the VPC targets in one target group and the on-premises targets in another target group and use content based routing to route traffic to each target group. You can also use separate load balancers for VPC and on-premises targets and use DNS weighting to achieve weighted load balancing between VPC and on-premises targets.
If you link these EC2-Classic instances to the load balancer’s VPC using ClassicLink and use the private IPs of these EC2-Classic instances as targets, then you can load balance to the EC2-Classic instances.
You should use authentication through Amazon Cognito if:
- You want to provide flexibility to your users to authenticate via social network identities (Google, Facebook, and Amazon) or enterprise identities (SAML) or via your own user directories provided by Amazon Cognito’s User Pool.
- You are managing multiple identity providers including OpenID Connect and want to create a single authentication rule in Application Load Balancer (ALB), that can use Amazon Cognito to federate your multiple identity providers.
- You have a need to actively manage user profiles with one or more social or OpenID Connect identity providers from one central place. For example, you can put users in groups and add custom attributes to represent user status and control access for paid users.
HTTP(S) requests received by a load balancer are processed by the content-based routing rules. If the request content matches the rule with an action to forward it to a target group with a Lambda function as a target then the corresponding Lambda function is invoked.
An LCU (Load Balancer Capacity Unit) is a new metric for determining how you pay for an Application Load Balancer. An LCU defines the maximum resource consumed in any one of the dimensions (new connections, active connections, bandwidth and rule evaluations) the Application Load Balancer processes your traffic.
Classic Load Balancers will continue to be billed for bandwidth and hourly usage.
Since cross-zone load balancing is always on with Application Load Balancer, you are not charged for this type of regional data transfer.
Applications Load Balancers emit two new CloudWatch metrics. LambdaTargetProcessedBytes metric indicates the bytes processed by Lambda targets and the StandardProcessedBytes metric indicates bytes processed by all other target types.
Network Load Balancers support only TCP (Layer 4) listeners and TLS listeners.
Network Load Balancer provides TCP (Layer 4) load balancing. It is architected to handle millions of requests/sec, sudden volatile traffic patterns and provides extremely low latencies. In addition Network Load Balancer also supports TLS termination, preserves the source IP of the clients, and provides stable IP support and Zonal isolation. It also supports long-running connections that are very useful for WebSocket type applications.
Network Load Balancer preserves the source IP of the client which in the Classic Load Balancer is not preserved. Customers can use proxy protocol with Classic Load Balancer to get the source IP. Network Load Balancer automatically provides a static IP per Availability Zone to the load balancer and also enables assigning an Elastic IP to the load balancer per Availability Zone. This is not supported with Classic Load Balancer.
You can create your Network Load Balancer in a single availability zone by providing a single subnet when you create the load balancer.
You can use Amazon Route 53 health checking and DNS failover features to enhance the availability of the applications running behind Network Load Balancers. Using Route 53 DNS failover, you can run applications in multiple AWS Availability zones and designate alternate load balancers for failover across regions. In the event that you have your Network Load Balancer configured for multi-AZ, if there are no healthy EC2 instances registered with the load balancer for that Availability Zone or if the load balancer nodes in a given zone are unhealthy, then R-53 will fail away to alternate load balancer nodes in other healthy availability zones.
A Network Load Balancer’s addresses must be completely controlled by you, or completely controlled by ELB. This is to ensure that when using Elastic IPs with a Network Load Balancer, all addresses known to your clients do not change.
For each associated subnet that a load balancer is in, the Network Load Balancer can only support a single private IP.
Each container on an instance can now have its own security group and does not need to share security rules with other containers. The ability to use the same port across containers allows containers on an instance to communicate with each other through well-known ports instead of random ports.
You can enable cross-zone loading balancing only after creating your Network Load Balancer. You achieve this by editing the load balancing attributes section and then by selecting the cross-zone load balancing support checkbox. Yes, you will be charged for regional data transfer between Availability Zones with Network Load Balancer when cross-zone load balancing is enabled.
Network Load Balancer currently supports 200 targets per Availability Zone. For example, if you are in 2 Availability-Zones, you can have up to 400 targets registered with Network Load Balancer. If cross-zone load balancing is on, then the maximum targets reduces from 200 per Availability Zone to 200 per load balancer. So, in the example above when cross-zone load balancing is on, even though your load balancer is in 2 Availability Zones, you are limited to 200 targets that can be registered to the load balancer.
The number of LCUs per hour will be determined based on maximum resource consumed amongst the three dimensions that constitutes a LCU.
The Classic Load Balancer supports Amazon EC2 instances with any operating system currently supported by the Amazon EC2 service. The Classic Load Balancer supports load balancing of applications using HTTP, HTTPS (Secure HTTP), SSL (Secure TCP) and TCP protocols.
IPv6 is not supported in VPC. You can use an Application Load Balancer for native IPv6 support in VPC.
Classic Load Balancers do not cap the number of connections that they can attempt to establish with your load balanced Amazon EC2 instances. You can expect this number to scale with the number of concurrent HTTP, HTTPS, or SSL requests or the number of concurrent TCP connections that the Classic load balancers receive.
Classic Load Balancers do not support instances launched using a paid AMI from Amazon DevPay site.
- You are not charged for regional data transfer between Availability Zones when you enable cross-zone load balancing for your Classic Load Balancer.
Reference: Amazon ELB FAQs