AWS、Azure、Google，VPC哪家强？

故事的开始是这样的，遇到有人说他们想要去了解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

这下子，一个协议横跨软硬件，功能估计是复杂了很多，但是接受程度如何呢？

[1]https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html

[2]https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-overview

[3]https://cloud.google.com/vpc/docs/flow-logs

[4]https://www.alibabacloud.com/help/zh/doc-detail/127150.htm?spm=a2c63.p38356.b99.79.60101bbfTB4SXX

[5]https://support.huaweicloud.com/intl/en-us/usermanual-vpc/FlowLog_0002.html