st-*_*t-h 5 amazon-ec2 amazon-vpc amazon-nat-gateway
我正在为一家几乎不会有很多流量的初创公司建立基础设施,但应该能够在需要时进行扩展。
我们倾向于使用 LB 设置,将流量分配到专用私有子网(超过 3 个可用区)中的前端节点,然后向它们自己专用子网上的受支持节点发出请求,然后请求到mongodb 通过 atlas 和 vpc 对等互连进行管理。
为了让每个节点进行配置,它都需要访问 Internet。后端节点也会向第三方服务发出请求,因此在运行时也需要访问互联网。
我看到三个选项:
为每个可用区中的每个私有子网设置一个 nat 网关。根据位置,这相当于每个可用区每个子网约 30 美元。有 3 个可用区和 2 个子网,每月总计约 180 美元,这实际上比我们计划用于 ec2 实例的要多,而系统上没有太多流量和负载。我们可能可以将其减少到只在每个可用区中为所有私有子网使用 1 个 nat 网关,但仍然约为 90 美元。
将 ec2 实例设置为 nat 网关,这可能会便宜一些,但需要维护和设置。
只需使用一个私有子网,为每个节点分配公共 ip,并通过路由表条目使用 Internet 网关。我认为使用专用的私有子网没有多大意义,因为节点无论如何都应该能够通过网关相互连接。
最后一个选项很可能是最便宜的选项,因为一个弹性 ip 已经包含在 ec2 实例中,并且不需要专用网关。但是,我想知道这样做是否存在重大不利因素或风险?我们计划在需要时(比如有大量流量)重新考虑使用专用子网的想法,但我们真的希望在开始时尽可能降低成本。
Mic*_*bot 14
您似乎对 VPC 中的网络基础存在一些误解。
为每个可用区中的每个私有子网设置一个 nat 网关。
出于所有实际目的,这从来都不是您真正需要做的事情。
您在单个 VPC 中需要的 NAT 网关的最大数量为每个可用区 1 个。
NAT 网关永远不会放置在它们所服务的(任何)子网中。NAT 网关位于公共子网中,该子网具有指向 Internet 网关的默认路由。然后,它们向其他子网上的实例提供 NAT 服务,其中 NAT 网关被指定为这些子网的默认网关。
所以在 AZ 中私有子网的数量与 NAT 网关的数量没有关系。除非您需要每个可用区超过 45 Gbit/s 的 Internet 带宽,否则您不需要多个 NAT 网关。
接下来,从技术上讲,每个 VPC 只需要一个 NAT 网关。NAT 网关是一个逻辑实体,而不是物理实体,因此没有已知的机制可以“失败”(除非在初始创建时,可能无法定义)。反对跨区域共享 NAT 网关的建议如下:
接下来,使用 EC2 实例作为 NAT 设备几乎不需要设置。NAT 实例的库存 AMI 在实例级别是零配置。您也可以构建自己的。 EC2 Instance Recovery可以在底层硬件实际出现故障或虚拟机管理程序无响应(罕见但可能)时修复 NAT 实例。
我认为使用专用的私有子网没有多大意义,因为节点无论如何都应该能够通过网关相互连接。
无论哪种方式,这都无关紧要。专用子网或缺少它们对实例相互通信的方式没有真正的影响——只会影响它们认为自己正在通信的方式。VPC 中每个子网上的“默认路由器”是一个虚构的设备,其存在是为了与 IP over Ethernet 的工作方式兼容。当安全组和网络 ACL 允许 VPC 中的两个实例进行通信时,它们的实际流量从一个实例到另一个实例的方式是相同的,无论这两个实例是否在同一子网中。
跨子网,一个实例通过arping默认网关并将流量发送到它的动作,同时管理程序继续运行但有效地忽略了所有这些并将流量直接发送到另一个实例的管理程序。在一个子网内,实例为其对等体进行 arp,管理程序欺骗该响应(ARP“谁拥有”从未出现在目标实例上,但源实例看到目标从未生成的响应)和节点到节点的流量遵循与以前完全相同的路径。
多年来,我们一直使用 EC2 实例作为 NAT 实例都做得很好,因为这是唯一的选择——NAT 网关是一项相对较新的服务。如果你想节省成本,那就去吧。或者在除了一个可用区之外的所有可用区都使用它,并在那个可用区中使用一个 NAT 网关。
为支持它们的服务添加 VPC 端点,例如 S3 和 DynamoDB,因为这些端点允许您在没有 NAT 设备的情况下访问这些服务。
您可以将来自多个私有子网的出站流量路由到同一个 natgw 实例。
有时我会创建一个单独的公共“管理”子网,natgw(或类似资源)所在的位置,并提供所有私有子网,这些子网应该能够根据到该 natgw 的路由访问互联网。
这种布局更明显地表明该子网是用于特殊目的,并最终被其他几个独立的子网使用。通常我会为这样的子网分配一个很小的 CIDR。
归档时间: |
|
查看次数: |
7354 次 |
最近记录: |