在《Lambda如何接入私有网络》篇中，我稍微介绍了一点Lambda创建的过程。
简单来说，当你有个任务需要Lambda去运行的时候，AWS在它自己的平台上，分出来一个Container给你，来运行你的程序。
你可以用这个Container跑一个任务，也可以跑多个任务。记得有一些限制，比如内存128M-10240M（10G内存支持于2020年12月1日），CPU不受你控制，但会跟内存分配的增加而增加。1000个软concurrency限制，/tmp目录512MB，以及一个任务最多运行15分钟。
但是这个Container从无到有，是需要一些时间的。这个“从无到有”时间，就是所谓的“冷启动”（Cold-start）。例子如图：
其实做了不少事情，但基本上就是完成的那个“创建一个Container然后分配给你”的过程。
如果你的Lambda已经执行过一次了，也就是AWS已经创建了一个Contiainer给你使用，那么你的下一次请求（若是对Lambda同样的配置），则会复用这个Contianer，那么这回就是我们所谓的“暖启动”（warm-start)，例子如图：
对比后发现了吗？Placement那个操作没有了。
Placement大约要花费100ms。
也就是说，你每次用warm-start，都可以省下100ms。然后积少成多。
于是我们的下一个问题可能是：如何保证我尽可能地用暖启动，而不是冷启动呢？
一个，你的程序用Lambda可以足够频繁，让这个Container一直在使用着。一个Container会在不被使用15分钟后，变为inactive。因此若你可以保证你的Lambda任务可以在每15分钟有一次操作的话，那就没问题。
但是我发现有些人，他的程序本身，或者说，在某些时间段内，是不满足每15分钟运行一次的。比如在non-peak时间段，比如大晚上等。但他为了保证lambda container一直活跃，写了脚本或者程序，每15分钟“激活”一下。
这样做没有什么问题，如果那100ms确实对你很重要的话。但是你要知道，Lambda的收费是按照运行时间+内存分配+请求数量计价的。
另一个方法，是AWS新加的功能（2019年12月，所以也不新了……），叫Provisioned Concurrency。
其实很简单，就是AWS保证给你一些Lambda一直处在“热乎”的状态，相当于它给一定量的Lambda创建好Container一直待命。
哇，听着不错。但你得交钱。如果你用了Provisioned Concurrency Lambda，那么你的收费标准就变成运行时间+内存分配+请求数量+Provisioned Concurrency。
所以啊，一样的。
