用戶的云計算提供商和云實例的活動通常受到IP地址范圍和可用性的限制，因此用戶的工作負載在公共云中使用的地址通常與其在場景中使用的地址(通常是動態的)不同。
例如，當用戶將內部服務(如Web服務器)遷移到公共云(如Amazon Web Services)時，最好希望其內部服務的IP地址隨遷移和公共云移動實例采用該地址。但這根本不會發生。
相反，公共云提供商擁有的內部和外部IP地址池比較有限，例如適用于工作負載的服務和實例的虛擬IP地址。用戶不能簡單地強制本地IP地址正確路由到云計算提供商。
添加到IP地址問題是提供者通常動態分配它們的事實。一旦實例停止運行，云端IP地址可以在工作負載重新啟動時更改。當其他工作負載需要訪問新移動的工作負載時，所有這些都更加麻煩。例如，如果新移動的工作負載是其他工作負載需要的數據庫或其他后端系統時，則這些其他服務現在不再可用，因為它們不能再將移動的服務定位在其新的IP地址。
然而，有幾種策略可以幫助緩解這種轉變，并避免主要的IP地址問題。
首先，公共云用戶通常對分配給其實例的IP地址具有一定程度的控制。例如，一些面向客戶的服務(如Web服務器)需要靜態IP地址，而云計算提供商通常會為靜態IP分配提供一個配置，以確保該地址不會隨著實例重新啟動而改變。即使生成的地址不太可能與原始的內部部署IP地址相匹配，用戶至少可以選擇一個IP地址，并且知道在實例的整個生命周期內不會更改它。
其次，為新移動的工作負載選擇新的云計算IP地址之后，將公共域名系統(DNS)更新到新地址。更新請求中的短暫的實時指定可確保更新能夠快速跨全球互聯網傳輸。更新公共DNS條目后，對服務的后續引用指向公共云提供商。
京公網安備 11010502049343號