故事的開始是這樣的，遇到有人說他們想要去了解AWS的VPC的技術細節，然后說要在AWS的公有云上創建幾個實例，希望通過抓包來分析AWS的VPC的實現細節。當時我就忍不住跳出來說，如果AWS的VPC可以提供這么的功能的話，他們的實現細節豈不早被人學會了。畢竟，VPC是基于overlay的網絡，在三層的物理網絡上實現一個大二層的專用網絡，如果能看到物理三層的東西的話，豈不是太不安全了。

但是，后來的發展的確說明我可能想的太多，因為AWS的確從2015年開始就提供了VPC Flow Log[1]這樣的服務。當然，大家也不要想太多，這個功能的目的主要是提供給大規模上云的用戶來做自家的VPC內的網絡故障排除的。如果AWS真的說可以讓你抓到ENA上的網絡包，建議你三思。

VPC的故事和其他人一樣都是從OVS+VXLAN開始的，如下圖。

AWS的服務提供如下的幾種類型：

Accepted and rejected Traffic

No data and skipped records

Security group and network ACL rules

IPv6 traffic

TCP flag sequence

Traffic through a NAT gateway

Traffic through a transit gateway

需要注意的事，AWS說提供的是VPC Flow的信息，也就可以認為這個信息只能是一跳的內容，和傳統的wireshark的TCP session還是不同的。

關于AWS的VPC log的格式以及使用場景，AWS一如既往地提供了詳細文檔，就不贅述了。其中有意思的點如下：

當創建一個客戶可定制的flow log時候的選項包含：

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${instance-id} ${subnet-id} ${vpc-id} ${pkt-srcaddr} ${pkt-dstaddr} ${tcp-flags} ${type}

其中，version 2和3 的區別：2是AWS default設置，并保存在S3上。3是客戶定制的。

其中的兩項需要多說一下：

pkt-srcaddr 和pkt-dstaddr. 當ena有多個IP地址，或者和NAT網關連接的時候，使用缺省的log的格式，其中的IP信息其實是不正確的，這個使用這個字段來提供正確的信息。

看了老大的服務，老二Azure肯定也要了解一下。[2] Azure畢竟是software公司出身，相對AWS的簡單的CSV格式，提供了基于JSON的輸出，而且比較合理地做了進一步的整合，提供了flowtuples的方式可以把一個TCPsession多個flow 保留在一起。因為包含了兩個方向的，因此package_send有了兩個方向的內容。

正因為做了聚合，因此不需要AWS那個相對比較別扭的pkt_srcaddr和pkt_destaddr. 和AWS相比，沒有包含帳號信息，感覺是對于一個具體的VPC的subnetwork的flow信息。AWS 的格式則是包含了一個帳號內的一個VPC網絡的子網內的一個EC2實例上的一個ENA網卡的包信息。

對于另一個巨頭Google來講，簡直把這個log玩出了花[3]。因為google號稱可以實現跨數據中心的遷移，因為在Flow log中包含了太多的信息。特別貼心的是有個五元組的結構，估計查詢上肯定極為舒適。

不僅包含了實例的信息，源和目的的都有：

InstanceDetails 字段格式

同時還包含了地理信息，對，你沒看錯：

GeographicDetails 字段格式

當然Google的內部的cluster和pod的信息也不隱藏了。

只能說Google把一個VPC日志能夠包含的，VPC可能涉及的，可以透露的信息都提供了。

而且，大家都知道Google喜歡RTT，他同樣提供一個

這個，可以算是很多網管都感興趣的信息吧。

回到國內的公有云，目前能夠拿到詳細信息的有aliyun[4]和華為云。

濃濃的AWS風格，這個也沒錯，畢竟云業務要做到簡單，可靠，耐操。畢竟云用戶中不懂JSON和遞歸結構的才是優質客戶。

華為云：

沒有使用AWS和aliyun那種直接，扁平的方式，而是和Google一樣加了一個project的概念來提供VPC中的subnetwork的信息。

最后，看到公有云上面玩的這么花，其實硬件廠家是拒絕的。network switch肯定也可以做，但是如果能做到Google這樣的per cluster和pod，估計在現有架構上就難了。因此就有了INT

這下子，一個協議橫跨軟硬件，功能估計是復雜了很多，但是接受程度如何呢？

原文標題：AWS、Azure、Google，VPC哪家強？

文章出處：【微信公眾號：ssdfans】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq