为什么 AWS 中的 NLB 不需要安全组？

Question

在 AWS 中，在配置 CLB 和 ALB 类型的负载均衡器时，必须关联一个安全组。此关联有助于限制到负载均衡器的流量类型。为什么 NLB 不需要安全组？难道不是安全隐患？我知道这里最好的猜测可能是——“AWS 是这样设计的”，但他们的文档似乎没有解释省略 NLB 安全组配置的推理/优势。

Answer 1

我猜想网络负载均衡器 (NLB) 不需要安全组，因为它通过保留关联目标实例的源 IP 来透明地运行。也就是说，您仍然可以指定安全组 - 但直接在目标级别而不是负载均衡器上指定。因此，从概念上讲，指定 SG 的情况并没有太大区别（当在 NLB 后面使用 EC2 实例时） 。尽管如此，有些人指出限制 NLB 运行状况检查的 IP 范围可能很棘手。[1] 此外，我认为在负载均衡器上（集中）指定一次安全组规则可能更方便，而不是将特定的安全组附加到作为 NLB 目标的每个 EC2 实例。与其他两种负载均衡器相比，这两个可以看作是 NLB 的缺点。

从技术上讲，与 ALB/CLB 相比，NLB 建立在全新的技术之上。AWS 员工在 Reddit 上指出了一些差异 [2]：

从较高层面来看，经典 (CLB) 和应用程序 (ALB) 负载均衡器是通过一组弹性网络接口 (ENI) 连接到您的 VPC 的负载均衡资源的集合。他们有监听器，接受来自客户端的请求并将它们路由到您的目标（ALB 和 NLB）/后端（CLB）。同样，网络负载均衡器 (NLB) 是连接到 VPC 的负载均衡资源的类似分组，但使用 AWS 超平面 ENI，而不是常规 ENI。超平面 ENI 是一种分布式结构，它与 EC2 的软件定义网络 (SDN)集成，通过单个 IP 地址透明地连接多个底层负载均衡资源。

之前没有听说过“超平面”这个词的大家，请随时查看相应的 re:Invent 会议。[3] Hyperplane 用于 NAT 网关、PrivateLink 和 Lambda 改进的 VPC 网络 [4]。

考虑到 Hyperplane 的功能以及它是基于 EC2 构建的这一事实，如果 AWS 愿意的话，我认为没有理由不能为 NLB 实现 SG。我同意@Marcin 的观点，这可能是设计使然。

[1] https://forums.aws.amazon.com/thread.jspa?threadID=263245
[2] https://www.reddit.com/r/aws/comments/cwbkw4/behind_the_scenes_what_is_an_aws_load_balancer/#t1_eyb2gji
[3] https://www.youtube.com/watch?v=8gc2DgBqo9U#t=33m40s
[4] https://aws.amazon.com/de/blogs/compute/announcing-improved-vpc-networking-for-aws- lambda 函数/

Answer 2

NLB 也不例外。NAT 网关也没有 SG。

ALB、CLB 和 NLB（以及 NAT）之间的主要区别在于它们的网络接口(ENI) 具有不同的Source/dest。检查设置。

对于 ALB 和 CLB，Source/dest. check是true. 对于 NLB 和 NAT 网关，选项为false. 虽然我不知道 CLB 和 NAT 没有 SG 的技术原因，但我认为部分原因可能是由于Source/dest. check设置：

指示是否执行源/目标检查，其中实例必须是它发送或接收的任何流量的源或目标。

因此，在我看来，原因是 NAT 和 NLB 的预期目的，而不是 AWS 在技术上无法在它们上提供 SG。他们的主要目的是充当代理。NLB 和 NAT 通常不会干扰流量，并且大多只是通过它。由目的地决定是否允许流量。因此 NAT 和 NLB 都不使用 SG。他们阻止传入流量的唯一方法是通过 NACL。

相比之下，ALB 和 CLB 在检查所有请求时积极参与流量传输。因此，他们也有能力决定是否允许流量。