我在同一个安全组（例如：Group-A）中运行多个实例，它们需要相互通信，特别是端口 4369。
每个实例都有不同的弹性 IP。
安全组配置为允许通过 TCP:4369 Soruce:sg-XXXXX (Group-A) 入站流量
但是，实例只能通过内部 IP（10.xxx.xxx.xx）或 Amazon 公共 DNS：ec2-ELASTIC-IP.compute-1.amazonaws.com（显然 Amazon 会将其转换为内部 IP）相互通信。
如果我使用 Elastic IP，它就不起作用。如果我使用指向 Elastic IP 的自己的 FQDN，它就不起作用。
如果我将入站规则中的源从 sg-XXXXX（Group-A）更改为 0.0.0.0，它将与我自己的 FQDN 和弹性 IP 配合使用。但出于安全考虑，我们不会使用它。如果我删除入站规则，则什么都不起作用，即使使用内部 IP 也是如此。
那么如果我想使用自己的 FQDN 该怎么办？（worker-1.company.com -> 弹性 IP），这更具可读性且更易于管理。
答案1
您描述的行为是正常的，因为当通过弹性 IP 在实例之间进行通信时，安全组内的机器的身份（出于依赖 sg-xxxxxxxx 源的安全组配置的目的）实际上无法完全确定，因为转换地址会将流量（大概）发送到中间硬件，并且流量不再被视为起源直接地从实例中。
解决方案是在 DNS 中使用指向公共 DNS 记录的 CNAME 记录来命名您的主机，而不是指向特定 IP 地址的 A 记录。
在 company.com DNS 区域中：
worker-1 IN CNAME xx-xx-xx-xx.compute-1.amazonaws.com.
现在，如果从内部查询，worker-1.company.com 将解析为私有 IP，如果从外部查询，则解析为公共 IP。
答案2
虽然并不完美，但您可以在每个实例的 hosts 文件中添加从 FQDN 到私有 IP 的显式映射。因此，您的代码将使用 FQDN，但网络实际上将使用私有通信（无论如何这更安全）。
如果您有一组相对固定的小型实例，这是一个合理的选择。如果可能的话，您应该自动执行此过程。
您还可以使用 Route 53，Amazon 的 DNS 即服务。将您的 FQDN 映射到实例的公共 DNS 名称。在 EC2 内部，这将映射到私有 IP。您仍需要使用 Route 53 API 自动执行此操作。