AWS改用Lambda网络为VPC客户减少了冷启动时间

AWS宣布改变Lambda函数连接虚拟私有云（Virtual Private Cloud，简称VPC）资源的方式。这个改变，即使用预先创建的网络接口而不是为每个函数执行环境创建的网络接口，为无服务器功能消除了“冷启动”的一个主要因素。

这个改变是不是IOpipe的Austin Huminski所称的“大量使用VPC的企业采用无服务器的转折点”？可以肯定的是，自2016年以来，AWS Lambda用户已经能够连接到运行于VPC中的服务器和服务了。由于AWS Lambda的所有计算基础设施都运行于AWS拥有的VPC中，因此，与客户VPC的连接传统上是通过弹性网络接口实现的。在客户VPC中，为每个执行环境创建了这些弹性网络接口。在这些网络接口被创建和附加之前，无法执行Lambda函数代码。随着功能的扩展，更多执行环境需要甚至更多的网络接口，如来自AWS的下图所示。

借助刚发布的AWS Lambda更新，正如AWS的一篇博文所解释的那样，连接架构得到了简化。

从今天开始，我们改变了功能连接到VPC的方式。用于网络负载平衡器和NAT网关的网络函数虚拟化平台AWS Hyperplane，支持AWS PrivateLink等产品的VPC之间的连接，并且，我们现在利用Hypenplane提供从Lambda VPC到客户VPC的NAT功能。

如下图所示，从AWS到客户VPC子网的网络接口现在在整个AWS Lambda执行环境中共享。

AWS表示，这个共享网络接口的一次性设置只需要90秒就可以完成。但是，由于网络接口是在Lambda函数首次创建或VPC设置更新时创建的，与连接相关的延迟在冷启动时接近于零。函数扩展也一样，不再需要为每个新执行环境提供新的网络接口。Amazon的Chris Munns最近发了一则推文，他展示了一张图，显示在部署了这个VPC网络更改后，延迟有显著的降低。

顺便提一下，“冷启动”问题经常出现，原因是无服务器功能不适合很多工作负载。在调用函数和代码实际运行之间，是什么因素造成了延迟？Amazon的Tim Bray指出，有很多因素导致了冷启动延迟。

启动一个函数需要的时间取决于最近启动该函数的时间。因为，如果我们已经在最近合理地运行了该函数，那么，我们可能已经把它加载到主机上，准备运行了，只需要把事件路由到正确的地方就可以。如果不是这样，那么，我们必须找到一个空主机，在存储器中找到函数，拉取出来，在我们使用它之前安装一下即可。

接着，Bray提到，一旦函数被“启动”，那么，就会有特定语言的初始化，可能需要编译代码或启动一个VM。接着，函数要做的事是加载状态并连接到依赖的服务。不管怎样，AWS在大力调整Lambda，以减少冷启动时间，正如在这个最近的编程语言冷启动时间上的比较所示。

当然，客户可以并确实能够使用AWS Lambda而无需运行VPC。默认情况下，Lambda函数可以访问任何在公共互联网上可用的东西，包括很多AWS服务。尽管，在最近几年，AWS已经把客户引导到VPC上去用经典的工作负载。默认情况下，Amazon EC2虚拟机运行于VPC内部。Amazon RDS、数据仓库Redshift，以及类似Paas的环境弹性Beanstalk的关系数据库产品也是如此。IOpipe的Huminski说，采用云的企业熟悉VPC模式，而现在更适合于AWS Lambda这样的现代运行时。

对于从私有数据中心迁移过来，或仍在运行混合基础设施的公司或组织来说，VPC似乎是个无需动脑的选择。它怎么看都像孤立的传统服务环境，有着IT习惯的藩篱。 … 尽管新的更改有利于开发人员把Lambda函数连接到VPC，但是，基础架构不会因我们的VPC而变化。

这个功能正在全球范围逐步推广，预计于几周内完成。AWS为这次更改更新了其文档，并共享了这个升级功能，没有相关的成本。根据AWS的说法，VPC连接的很多方面保持不变，包括对IAM权限配置的要求和所需的NAT网关，以连接VPC外部端点。

原文链接：

Change to AWS Lambda Networking Reduces Cold Start Time for VPC Customers