While ELB and ALB are both load balancers, they function very differently. The main difference between the two services is that the ELB service works at the Layer 4 (transport) of the Open Systems Interconnection (OSI) model and the ALB is a Layer 7 (application) load balancer.

This means that the ELB service can only speak and understand up to the TCP/IP layer. When you configure an ELB, you configure the load balancer port on one side and the instances addresses and ports on the other.

Because the ALB service is a Layer 7 load balancer, in addition to what the ELB can do, it also understands application protocols such as HTTP. This allows for a more complex and granular configuration. A very common use case when using an ALB is to send requests to certain routes to a specific pool of hosts.

For example, you may decide to separate all API requests and put them in their own service while still keeping the access route to https://domain.com/api/. By implementing that logic in your ALB as shown in the following figure, your API requests will be able to directly hit your API service without having to go through the edge service:

Up to this point, we have seen a number of services that will help you with scaling while keeping the latency of your application low, but in some cases, latency doesn't matter as much. For those use cases, you can look into adding offline processing services.