aws lambda vpc的一点感想

SirLZF 2017-06-10

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。

相关推荐