aws lambda vpc的一点感想 博客分类： vpclambdaaws lambdavpcenisubnetweb service

aws vpc是在公有云内建立的一个私有云网络，目的是出于安全考虑。lambda缺省是在公有云上面运行，不过，现在也支持了在vpc内部运行，不过运行的效率会变低，会出现网络延迟，所以对于web service这样的程序的话，还是不要在vpc内部运行lambda，如果对于延迟和性能不敏感的场景，还是可以采用的。

那么，lambda在vpc内运行和不在vpc内运行有什么不同呢？一点个人理解，仅供参考。
1。lambda本身其实也在一个vpc内运行，只是这个vpc和aws用户的vpc不是同一个，而且我怀疑不是固定的vpc，这取决于内部的技术实现，对于云用户来说可以不用关注。因为lambda属于serverless的概念，所以只要你的程序能跑起来就ok了。
2。前面说的公有lambda，它有什么弊端呢
1》不在我们自己的vpc内运行，所以我们无法控制，包括安全性我们也无能为力，只能相信aws的技术实力
2》如果我们的lambda程序想要访问我们自己vpc 内部的服务，比如db，就比较麻烦了，因为我们的db部署在ec2内，而且不对公网开放ip的，这样从公网的lambda是无法连接我们vpc内部的db服务的。

那么，如果想从lambda程序访问我们vpc的内部服务的话，只能把lambda本身也拉进我们自己的vpc里面来，这样同一个网络内部访问就没有任何问题了。

也是基于以上这种应用场景，lambda也开始支持指定vpc了。其实不止是指定vpc，还包括subnet，security group，概括起来就是eni，elastic network interface，也就是相当于attach上一个虚拟网卡，这个eni属于aws用户的default vpc。也就是相当于把公有lambda从它自己的vpc里面detach，然后再attach到你的default vpc里面，然后指定个eni虚拟网卡，让lambda跟你的vpc 里面的别的ec2虚拟主机同属于一个私有网络，这样就可能互相连接访问了。

前面主要是从功能上来说明，貌似一切问题都解决了，但是只有一点，就是一开始提到的lambda 函数调用延迟的问题，这个跟aws lambda内部的技术实现有很大关系。
1》这个eni虚拟网卡的attach是动态的，不是绑定一次就一劳永逸了。类似于timeout的机制，如果过一定的时间没有调用lambda函数，eni会被detach，下次再调用还要再attach网卡。
2》lambda天生就是公共服务，你的lambda 函数每次调用的时候可能都不在同一个虚拟机上，包括vpc，IP地址都不是固定的，虽然你把lambda绑定到了你自己的vpc里面，但是每次lambda 函数调用的时候，都是动态选择虚拟机或者叫server来执行你的代码的，所以每次都可能存在动态现用现绑定vpc，eni的动作，这就是造成latency的原因。

综上所述，如果对于性能和响应时间要求较高的场景，必须用公有lambda，也就是不指定vpc。其它场景如果不需要访问vpc内部资源的话，也没有必要绑定vpc。除非需要访问内部资源，对响应时间又没有过高要求的场景下，可以考虑绑定vpc。