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 字段格式

字段	类型	说明
project_id	字符串	包含虚拟机的项目的 ID
vm_name	字符串	虚拟机的实例名称
region	字符串	虚拟机所在的地区
zone	字符串	虚拟机所在的区域

同时还包含了地理信息，对，你没看错：

GeographicDetails 字段格式

字段	类型	说明
continent	字符串	外部端点所在的大洲
country	字符串	外部端点所在的国家/地区，采用 ISO 3166-1 Alpha-3 国家/地区代码的形式表示。
region	字符串	外部端点所在的地区
city	字符串	外部端点所在的城市
ASN	int32	此端点所属外部网络的自治系统编号 (ASN)。