將具有相同 CIDR 塊的多個 VPC 連接到共享 VPC
在我公司的 AWS 雲中，我們有 4 個 VPC，一個用於我們的主要 API 環境（開發、測試、階段、產品）。為了使這些環境彼此盡可能相似，它們都將其 CIDR 塊設置為 10.0.0.0/16。
現在，我們需要創建在這些環境之間共享的內部服務。為了爭論，假設這個新服務儲存來自所有這些環境的日誌數據。該服務存在於其自己的 VPC 中，其 CIDR 塊為 10.1.1.0/24。
起初我以為我可以簡單地將來自所有環境 VPC 的對等連接添加到日誌 VPC 中。不過，當我開始設置路由表時，我遇到了障礙。我從 Dev -> Logging 中創建了一個路由表，該路由表將所有流量路由到目的地 10.1.1.0/24。但是我仍然無法從 dev 中連接到我的日誌伺服器。看來我需要為 Logging -> Dev 添加一個路由表，它將所有流量路由到目標 10.0.0.0/16。這允許我從開發伺服器連接到日誌記錄伺服器，但現在我無法將我的任何其他環境連接到日誌記錄 VPC。
日誌伺服器永遠不必啟動與我的 API 伺服器的連接，它只需要接收和響應連接。所以我的下一個想法是我可以在每個環境 VPC 上使用 NAT 網關，然後將它們路由到日誌 VPC。不幸的是，NAT 網關似乎直接連接到網際網路，我不希望我的日誌記錄 VPC 連接到網際網路。
我覺得必須有一種方法可以使這項工作發揮作用，但我想不出一個。目前我覺得我唯一的選擇是創建 4 個日誌記錄 VPC 並在每個 VPC 中執行單獨的日誌記錄伺服器，但從成本的角度來看，這對我並沒有真正的吸引力。
首先，我必須提到：您在 VPC 中複製子網犯了一個非常嚴重的錯誤。即使您需要在它們之間路由流量的可能性幾乎為零，RFC1918 地址空間也足夠大，您可以為每個 VPC 提供一個唯一的子網。我就 AWS 主題諮詢了許多公司，並維護了一個“主子網列表”電子表格來記錄我為客戶分配 VPC 時使用的子網，以確保我沒有重疊的子網。
您的問題的明顯答案是重新編號重疊的 VPC。這會很痛苦，但它是這個問題的正確答案，並且會一勞永逸地為你解決這個問題。
如果這不是一個選項，我可以考慮其他幾個選項：
- 為您的日誌使用 SQS - 將來自您的應用程序 VPC 的日誌發送到一個 SQS 隊列，並為您的每個應用程序 VPC 使用源 ID 進行註釋，然後從您的日誌記錄 VPC 中使用 SQS 之外的日誌。除了解決您所說的問題之外，這還在您的日誌生產者和日誌消費者之間放置了一個非常高可用性的緩衝區。如果您的基礎架構出現故障，或者您需要將其關閉以進行維護，這可以防止您失去日誌。
- 通過公共 IP（ELB、EIP 等）公開您的日誌記錄端點，將其設置為防火牆，以便只有您的應用伺服器的公共 IP 可以訪問它並讓它們以這種方式發送日誌。流量將保留在 AWS 的網路上，只要經過加密和身份驗證，就不是什麼安全問題。不過，您將為頻寬支付更多費用。