我有幾個實例在同一個安全群組（例如：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） 。
如果我使用彈性IP，它將不起作用。如果我使用自己的 FQDN 指向彈性 IP，它將無法運作。
如果我將入站規則中的來源從 sg-XXXXX（A 群組）更改為 0.0.0.0，它可以與我自己的 FQDN 和彈性 IP 配合使用。但出於安全考慮，我們不會使用它。如果我刪除入站規則，即使使用內部 IP，也不起作用。
那如果我想使用自己的 FQDN 該怎麼辦？ (worker-1.company.com -> Elastic IP)，更具可讀性且更易於管理。
答案1
您所描述的行為是正常的，因為當透過彈性 IP 在實例之間進行通訊時，安全性群組內電腦的身份（出於依賴 sg-xxxxxxxx 來源的安全性群組配置的目的）無法真正建立完整的信心，因為轉換地址（大概）透過中間硬體發送流量，流量不再被視為源自直接地從實例。
解決方案是使用指向公共 DNS 記錄的 CNAME 記錄（而不是指向特定 IP 位址的 A 記錄）在 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，但網路實際上將使用私有通訊（無論如何，這更安全）。
如果您有一組較小且相對固定的實例，那麼這是一個合理的選擇。如果可能的話，您可能應該自動化此流程。
您也可以使用 Route 53（Amazon 的 DNS 即服務）。將您的 FQDN 對應到執行個體的公共 DNS 名稱。在 EC2 內，這將會對應到私人 IP。您仍然需要使用 Route 53 API 來自動執行此操作。