我正在设置 AWS 负载均衡器并查看两个可供选择的选项。似乎网络负载均衡器能够做应用程序负载均衡器能够做的任何事情，同时功能更全面并且每个 LCU 的定价成本更低，这让我想知道为什么应用程序负载均衡器是均匀的提供。我能看到的唯一可能的优势是稍微易于配置，但对我来说，我知道我已经拥有功能更齐全的负载均衡器，以防万一需要更复杂的平衡，我无法使用应用程序负载均衡器，似乎值得小幅增加的实施成本。
Application Load Balancer 有我所缺少的优势吗？
【问题讨论】：
标签： amazon-web-services amazon-ec2 amazon-elb
ALB 和 NLB 用于不同的目的。下面我将列出一些，在我的选择中，它们是关键的。
ALB 用于 HTTP/HTTPS 流量（第 7 层），因此它可以检查 HTTP 标头、基于路径的重定向、查询字符串和其他 HTTP 特定功能。在用于 TCP/UDP/TLS 流量（第 4 层）的 NLB 中，上述任何一项都不可能。因此，对于服务于网站或任何其他 HTTP/HTTPS 应用程序，ALB 提供了更多功能，并且专为这些类型的用例而设计。
ALB 的另一个重要优势是它支持安全组 (SG)。 NLB 不支持它们，因此您必须基本上将其完全开放以供互联网使用。使用 SG，您可以将 ALB 访问限制为仅特定 IP 范围或单个端口（例如 80 或 443）。在 NACL 中执行相同操作会影响子网中的所有其他内容，而不仅仅是 NLB。控制对 NLB 的访问的唯一方法是通过功能远少于 SG 的 NACL，例如您不能在另一个中引用一个 NACL，它们是无状态的。
说到安全性，ALB 支持WAF，而 NLB 不支持。这可以保护您的网站免受各种攻击，例如跨站点脚本或 SQL 注入。
与 NLB 不同，ALB 还支持 lambda 目标。因此，您也可以基于 lambda 函数构建负载平衡应用程序。这通常非常有用。
粘性会话基于 cookie 是 ALB 的另一个功能，NLB 中不存在该功能。如果您的应用程序需要保持用户会话处于活动状态，这将非常有用。
还有很多不同，NLB和ALB的对照表是here：
【讨论】：