我想知道亚马逊应用程序负载均衡（ALB）与经典负载均衡（CLB）之间的主要区别。我搜索过但是他们只给出了一些示例，例如经典负载均衡只包含相同的内容，但应用程序负载均衡可以包含不同的内容并与目标组分组。
ALB具有一些功能（例如，基于主机的路由，基于路径的路由），但我的问题是我们使用ALB而不是经典负载平衡的原因。请提供两者的用例。
答案 0 :(得分：0)
<强> ALB
应用程序负载均衡器（Elastic Load Balancer V2）允许您根据更复杂的条件/规则（特别是URL路径）将流量定向到EC2实例。您可以让用户尝试访问＆＃34; /注册＆＃34;转到一组实例和用户试图访问＆＃34; / homepage＆＃34;转到另一组实例。与传统ELB相比，ALB检查应用程序级别的流量（OSI第7层）。例如，在此级别上可以解析URL路径。
<强> ELB /经典
经典负载均衡器使用TCP级别的信息（OSI第4层传输）统一路由流量。它将向每个实例发送请求＆＃34; round-robin＆＃34;样式或利用粘性会话，并将每个用户/客户端发送到他们最初登陆的同一个实例。
为什么ALB超过ELB？
如果您决定以每个路径都有自己的实例集或自己的服务的方式构建系统，则可以使用ALB。所以 / signup，/ login，/ info等等都通过一个负载均衡器固定到您的域名https // mysite.com，但是不同的EC2实例正在为每个负载平衡器提供服务。 ALB仅支持HTTP / HTTPS。如果您的系统使用其他协议，则必须使用ELB / Classic负载均衡器。目前仅在ALB上支持Websockets HTTP / 2。
您可能选择ALB优于ELB的另一个原因是还有一些尚未添加到ELB或可能永远不会添加的其他新功能。正如迈克尔在下面指出的那样，AWS WAF在经典负载均衡器上不受支持，但在ALB上。我进一步扩展了其他功能。
为什么ELB超过ALB？
从架构上讲，将每个请求发送到同一组实例然后在应用程序内部委托对某些函数/类/方法等的某些路径的请求会更简单...这本质上是大多数应用程序启动的整体设计作为。对于大多数工作负载，将流量专用于某些实例组（ALB方法）将浪费EC2功率。你会有一些实例做很多工作而其他人几乎没用过。
与ALB类似，经典ELB的功能还没有到达ALB。我在下面进行扩展。
更新 - 有关功能差异的更多信息
从产品的角度来看，它们在其他方面存在差异，这些方式与它们的运作方式并不相关，而且还有一些尚未出现的功能。
HTTP到HTTPS重定向 - 例如，在ALB中，每个目标组（您指定特定路由的实例组）当前只能处理一个协议，因此如果您要实现HTTP到HTTPS重定向这需要最少两个实例。使用ELB，您可以在单个实例上处理HTTP到HTTPS重定向。我想ALB很快就会有这个功能。
https://forums.aws.amazon.com/thread.jspa?threadID=247546
一个负载均衡器上的多个SSL证书 - 使用ALB，您可以为不同的域分配多个SSL证书。虽然已请求功能，但在经典负载均衡器上无法实现此功能。对于经典的负载均衡器，您可以使用通配符证书，但这不是一回事。 ALB利用SNI服务器名称标识使其成为可能，因为它尚未添加到经典ELB功能集中。