在我公司的 AWS 云中，我们有 4 个 VPC，每个 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。这允许我从 dev 服务器连接到日志服务器，但现在我无法将我的任何其他环境连接到日志 VPC。
日志服务器永远不需要发起与我的 API 服务器的连接，它只需要接收和响应连接。所以我的下一个想法是，我可以在每个环境 VPC 上使用 NAT 网关，然后将它们路由到日志 VPC。不幸的是，NAT 网关似乎直接连接到互联网，而我不希望我的日志 VPC 连接到互联网。
我觉得一定有办法实现这一点，但我想不出。目前我觉得我唯一的选择是创建 4 个日志 VPC 并在每个 VPC 中运行单独的日志服务器，但从成本角度来看，这对我没有什么吸引力。
答案1
首先，我必须指出：您在 VPC 中复制子网犯了一个非常严重的错误。即使您需要在它们之间路由流量的可能性几乎为零，RFC1918 地址空间也足够大，您可以为每个 VPC 分配一个唯一的子网。我为多家公司提供 AWS 主题咨询，并在为客户分配 VPC 时维护一个“主子网列表”电子表格来记录正在使用的子网，以确保没有重叠的子网。
对你的问题，显然的答案是重新编号重叠的 VPC。这会很痛苦，但这是解决这个问题的正确方法，并将一劳永逸地为你解决这个问题。
如果那不是一个选择，我还可以想到其他几个选择：
- 利用 SQS 处理日志 - 将日志从应用程序 VPC 发送到 SQS 队列，为每个应用程序 VPC 标注源 ID，然后从日志 VPC 中使用 SQS 中的日志。除了解决您所述的问题之外，这还带来了非常日志生产者和日志消费者之间的高可用性缓冲区。如果您的基础设施出现故障，或者您需要关闭基础设施进行维护，这可以防止您丢失日志。
- 通过公共 IP（ELB、EIP 等）公开您的日志记录端点，并对其进行防火墙保护，以便只有您的应用服务器的公共 IP 可以访问它，并让它们以这种方式发送日志。流量将保留在 AWS 的网络上，只要它经过加密和身份验证，就不会造成太大的安全问题。不过，您需要为带宽支付更多费用。