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 inte***ce，也就是相當於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。
一點一點進步
requestparam,是獲取前端傳遞給後端的引數，可以使get方式，也可以是post方式。若前端傳遞的引數和後端接收的引數名稱不一致，則必須要標註。pathvariable,是獲取get方式，url後面引數，進行引數繫結。1.裝箱就是講基本資料型別轉換為包裝類，拆箱就是自動將包裝類轉換為基本資料...
他們寫的，一點思考，一點敬意
技術的正宗與野路子 我們的大腦好比記憶體。既然是記憶體，就裝不下所有的知識。但應該能裝下對於知識的索引，否則我們便沒法工作了。啊，我的程式為啥卡住啦 本文簡答介紹在linux環境下如何利用gdb來分析卡住的程式，本文使用的python為cpython2.7。2019，能否解開時間的困局？通常在年初的...
this的一點見解
執行環境 execution context,有時也成為上下文，有時也稱為 環境 執行環境定義了變數和函式有權訪問那些資料，決定各自的行為。全域性執行環境是最外圍的執行環境。全域性執行環境一直都存在。宿主環境不同執行環境也不同。每乙個環境都有乙個執行環境。當執行流進入乙個函式時，函式的環境就會被推入...