同じセキュリティ グループ (グループ A とします) で複数のインスタンスが実行されており、特にポート 4369 で相互に通信する必要があります。
各インスタンスには異なる Elastic IP があります。
セキュリティグループは、TCP:4369 ソース:sg-XXXXX (グループ 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 と Elastic IP で動作します。ただし、セキュリティ上の懸念から、これは使用しません。受信ルールを削除すると、内部 IP を使用しても何も動作しません。
では、独自の FQDN (worker-1.company.com -> Elastic IP) を使用する場合はどうすればよいでしょうか。これは、はるかに読みやすく、管理も簡単です。
答え1
あなたが説明した動作は正常です。インスタンス間でエラスティックIPを介して通信する場合、セキュリティグループ内のマシンのID（sg-xxxxxxxxソースに依存するセキュリティグループ構成の目的）は、アドレスを変換するとトラフィックが（おそらく）中間ハードウェアを介して送信され、トラフィックが送信元として認識されなくなるため、完全に確実に確立することはできません。直接インスタンスから。
解決策は、特定の IP アドレスを指す A レコードではなく、パブリック DNS レコードを指す CNAME レコードを使用して DNS でホストに名前を付けることです。
company.com DNS ゾーンの場合:
worker-1 IN CNAME xx-xx-xx-xx.compute-1.amazonaws.com.
これで、worker-1.company.com は、内部からクエリされた場合はプライベート IP に解決され、外部からはパブリック IP に解決されるようになります。
答え2
完璧ではありませんが、各インスタンスのホスト ファイルで FQDN からプライベート IP への明示的なマッピングを追加できます。そのため、コードでは FQDN が使用されますが、ネットワークでは実際にはプライベート通信が使用されます (いずれにしても、より安全です)。
インスタンスのセットが小さく、比較的固定されている場合、これは適切なオプションです。可能であれば、このプロセスを自動化する必要があります。
また、Amazon の DNS サービスである Route 53 を使用することもできます。FQDN をインスタンスのパブリック DNS 名にマッピングします。EC2 内では、これはプライベート IP にマッピングされます。ただし、Route 53 API を使用してこれを自動化する必要があります。