AWS nat 实例和 elb 瓶颈

AWS nat instance and elb bottle neck

有一个可能完全愚蠢的快速问题,但现在是在清晨。所以我有一个标准的 AWS VPC,带有一个 ELB、NAT 实例和 2x EC2 实例用于应用程序代码。从下图可以看出,互联网网关将流量传递给 ELB 和 NAT 实例。我的问题是为什么 NAT 实例不在 ELB 前面或后面?看起来这个 VPC 中的单一瓶颈可能是 NAT 实例,如果所有流量都经过那里的话。

NAT(网络地址转换)服务器用于为私有子网中的 Amazon EC2 实例提供出站 Internet 连接。

传入流量 将通过负载均衡器进入,对此流量的任何响应也将通过负载均衡器退出。 Elastic Load Balancing 服务根据流量自动扩展(传输流量也会收费)。

如果私有子网中的 EC2 实例希望启动到 Internet 的连接(例如下载更新或与 Amazon S3 通信),它无法发送负载均衡器的流量 "out"。相反,子网将配置为 将流量路由到 NAT 服务器 ,NAT 服务器充当从 Internet 请求数据的代理。

NAT 服务器有可能成为瓶颈。如果是这样,请修改实例以使用更大的实例类型——这不仅会增加 CPU 和 RAM,还会增加网络带宽。

在某些情况下,人们可能还会将 NAT 服务器用于 传入流量 -- 或者作为 jump-box 用于管理目的(登录到私有子网中的实例)或将特定端口转发到私有服务器(通过端口转发)。但是,出于安全和管理目的,最佳做法是将这些功能分离到不同的实例。

附加信息:自从写下这个答案后,AWS 推出了一个可以自动扩展的Managed NAT Gateway。它是在单个 AZ 中创建的,因此您可能希望 运行 它在两个 AZ 中以实现高可用性。

我不确定它是如何工作的,如果 loadbalacer 在 APP Tier 上终止,那么在这些子网中启动的实例将使用 IGW 配置路由-table 而不是 NAT 实例,which raises a question how to make outbound traffic on the public network which is configured over a loadbalalncer