当我在安全组中打开临时端口（1024-65535）以允许ALB和EC2 Container服务之间的通信时，我在运行AWS Trusted Advisor时获得“操作建议”（红色！）。我应该担心或不信任AWS Trusted Advisor吗？
答案 0 :(得分：2)
原始答案
安全组是有状态的，这意味着从实例发起到另一个源的流量将具有与该出站请求相关的所有返回流量（即短暂端口）。它实际上是VPC中的NACL，你必须实际允许短暂的流量，因为它不是有状态的，并且不像安全组那样理解返回流量。
对于ALB说 - ＆gt;您赢得的实例流量不需要在sec组中打开这些端口，因为sec group将允许从ALB（到实例）内发起的流量以及返回到ALB的相关短暂端口流量。
您的实例将只需要检查的任何端口（端口80/8080 /等），因为它来自外部的流量。但是，它不需要任何东西来允许流量出站到ALB临时端口，因为它们是从实例内部启动的，并且连接到允许流量的传入端口。
修改
经过大量的EC2实例尝试解释之后，我在原始解释中发现了一些错误。我会在这里留下原来的解释，因为我认为知道错误很重要。
无论如何，让我们在这里更深入地回答。
NACL（网络访问控制列表）
这些是无状态防火墙。基本上它不知道传出的短暂端口流量与传入的HTTP流量有关。它也是一种优先类型系统。基本上，您按照您希望评估的顺序对规则进行编号，从最低到最高。它命中的规则与它应用的流量匹配的那一刻。您还可以明确拒绝流量。
这里的主要缺点是NACL每个方向只允许20个规则（总共40个规则），而安全组允许每个方向50个规则（总共100个规则）。也就是说，如果您出于任何原因开始耗尽安全组规则，它始终可以采用通用流量规则并将其应用于NACL。在高度合规的环境中，NACL也是需要考虑的因素，绝对必须阻止某些流量，因为明确的DENY规则是可能的，而安全组是唯一允许的规则。
安全组
与NACL不同，安全组只能拥有宽松的效果规则。 DENY只是缺乏宽容的角色。但是，在下面说明的某些情况下，安全组会跟踪流量并自动添加允许其他方向流量的规则。
默认情况下，安全组具有允许所有出站流量的规则。这里的想法是，如果它是从您的实例启动的，那么绝大多数用例都可以。现在，如果黑客理论上通过服务漏洞访问系统，那么他们现在可以在任何他们想要的地方拥有出站流量。
您可以在此处执行的操作是删除安全组中的出站流量规则。在这种情况下，您将拥有以下内容：
安全组还会跟踪连接（这就是它们被称为有状态的原因），以允许来自其他方向的流量自动相关。 然而它只会跟踪此情况，否则会拒绝流量。
例如，如果您没有删除允许所有访问的出站规则，则安全组不需要是有状态的，因为不需要添加规则。但是，当不允许流量时，它确实需要有状态。我没有找到关于它如何实现的真实可靠的文档，但我认为它是围绕三次TCP握手。当SYN进入或进入允许的端口时，它必须开始允许另一个方向的流量。然后它完全跟踪握手的其余部分（SYN + ACK - > ACK）是否完成。当连接关闭相关的数据包到来时，它可能会删除跟踪。
考虑到这一点，在处理高容量前端服务时，如果可能的话，你可以更加宽松地使用传出流量，因为我可以想象跟踪开始将速度降低到明显的速度。
<强>推荐