大咖专栏 | 大家热聊的VPC，大咖给你讲清楚（篇一）
大咖专栏
大咖专栏主要刊登亚马逊AWS诸位大咖亲自撰写的Blog，内容涉猎广泛，话题讨论前沿，且与实战紧密相连。我们非常欢迎小伙伴们在评论区留言，与大咖互动交流！
今天为大家撰文的大咖，是AWS解决方案架构师——代闻老师。
代闻
AWS解决方案架构师
代闻负责基于AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内的应用和推广，在大规模后台架构、物联网应用、媒体行业转型、企业混合IT和自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前，他担任思科中国系统工程师，负责方案咨询和架构设计，在企业私有云和基础网络方面有丰富经验。他曾任IBM中国软件开发中心软件工程师，从事企业软件和移动平台的开发工作。
大
咖
有
话
说
最近有很多用户开始关注VPC (Virtual Private Cloud)，我也解答了不少关于AWS网络的问题。交流之余，我觉得有必要写几篇白话文章，谈一谈AWS网络。今天就先讲讲VPC吧，说说我自己经历的一些故事，希望文章读起来不会很教条，能帮助大家更好地理解。
时间回到2014年3月份，我还在思科工作，每天奔波在大大小小的数据中心项目中，并且开始研究Openstack，尤其是其中的网络模块Neutron。当时Neutron已经支持插件模式，可以支持软件Overlay或硬件网络统一接入，但是Overlay配置比较复杂，性能有限，复杂拓扑也难以支持。那时我觉得，Overlay在性能和功能上可能还得发展几年。
2014年4月份，在好友的鼓励和推荐下，我开始面试AWS的Solutions Architect职位。在准备期间，我仔细阅读了VPC的文档，内心被震撼到无法相信。AWS VPC实现了子网、网关、路由、访问控制列表、防火墙等网络功能，任何数据中心拓扑都可以在VPC里完全重现。当时的感觉是：为什么有人做到这么好的虚拟网络，还这么低调。
入职后，我了解到，超过90%的AWS服务是由客户需求驱动，VPC也不例外。很多企业都有自己的数据中心，他们希望云上能有一个隔离的网络环境作为数据中心私有网络的延伸，VPC便应运而生了。所以，VPC设计的初衷就是建造一个隔离的私有网络环境。
在实现上，VPC基于SDN，底层通过Overlay技术完成逻辑隔离。也正因为使用了Overlay技术，AWS才能支持海量的VPC。
2009年11月，AWS发布VPC的时候，业界还没有任何商业硬件或软件能够支持如此大规模的多租户（Multi-Tenant）环境。后来在2013年的re:Invent用户大会，AWS安全部门的同事分享过VPC实现的基本原理。下图是其中一页PPT的截图，Overlay网络一目了然。用户数据只能装在EC2虚拟机的IP报文里，底层网络对用户透明。同时，Mapping Service提供分布式查询服务，通过VPC和EC2虚拟机IP可以查询到对应的物理机。并且，通过查询Mapping Service，物理主机可以识别非法或错误访问，及时报警。
那么问题来了，AWS是怎么解决Overlay的性能问题的呢？为什么采用Overlay的方式居然可以支持万兆的EC2实例呢？
答案是，AWS“软硬兼施”的不断创新。由于Overlay处理是在物理服务器上完成，物理服务器对于网络的处理能力就成为首要一环。从2012年开始，AWS就开始将网络处理交给硬件，比如万兆网卡的处理器使用自定义软件、提供Intel SRIOV支持、提供基于Placement Group的万兆无阻塞部署策略等。在2016年，AWS实现了自己的ASIC——Amazon Annapurna ASIC。这是AWS完全控制硬件和软件的ASIC芯片，提供25Gbps吞吐。基于Amazon Annapurna ASIC，AWS实现了支持20GE吞吐的EC2实例，现在已经上线（如：m4.16xlarge、r4.16xlarge、i3.16xlarge等）。
如果你对AWS底层实现感兴趣，re:Invent 2016的第一场Keynote绝对值得一看，由AWS副总裁、杰出工程师James Hamilton 主讲。当时我在现场，感觉——血液都要烧起来了！
想看高清版的童鞋，请访问：
https://www.youtube.com/watch?v=AyOAjFNPAbA
在功能方面，正因为有实实在在的用户需求驱动，VPC的设计才能既重现真实网络，又适度抽象配置，同时功能还可以不断丰富。下图是我最常使用的一张讲解VPC架构的示意图。
图中，VPC是一个自定义的IPv4网段（10.0.0.0/16），并且拥有抽象后的互联网网关（IGW）和虚拟私有网关（VGW），分别用于访问Internet和物理机房。左边子网将默认路由指向IGW，成为“公有子网”，相当于传统网络的DMZ；右边子网没有IGW路由，成为“私有子网”，相当于传统网络的内网区，并且，右边“私有子网”将物理机房路由的下一跳设置为VGW，而从内向外访问Internet的路由指向公有子网的NAT实例（也可以使用托管的NAT Gateway服务）。子网级别访问控制有NACL，虚拟机级别的防火墙有安全组（Security Group），这些都是经典网络概念的重现。
所以，与传统数据中心的多层访问控制类似，VPC内的网络访问控制流程可以参考下图。从外到内的访问控制分别有：子网路由、网络访问控制列表（NACL）、安全组。
举个例子，如果你在一个没有公网路由的子网里，给一个EC2分配了固定的公网IP（EIP），并且NACL和安全组都允许这台EC2实例上公网，结果还是上不去——这个结果和物理网络环境是完全一样的——没有路由，服务器即使有公网IP也不能访问Internet。
那么问题又来了，数据中心基础架构是如何承载VPC的呢？
有几点值得注意：第一，VPC可以覆盖一个区域（Region）里的多个可用区（AZ），但不能覆盖多个区域（Region）；第二，一个子网只能在一个可用区（AZ）内，不能跨可用区（AZ）；第三，VPC与用户自己的物理机房互联时，地址段不能冲突。
由于VPC对用户网络环境的灵活性和安全性有极大改善，在VPC发布一段时间之后，AWS对于新开账户的用户，默认就只提供VPC环境了；对于新发布的区域（Region），也只有 VPC环境，比如北京区域（Region）。同时，AWS在老用户社区里发起了从经典网络迁移到VPC的运动，包括提供VPC培训、平滑迁移的技术方案、用户迁移经验分享等等。
刚接触AWS的用户常有这样的疑问：“我应该建立多少个VPC？”其实没有标准答案，因为这取决于用户公司内部的安全策略、应用和基础架构设计。下图是沃达丰（Vodafone）澳大利亚公司在AWS悉尼区域部署的VPC规划，基于生产测试和服务类别的隔离策略得到了充分保障。
在帐号默认设置中，每个用户可以有5个VPC——但这个限制只是一个软性配额，用户可以通过开工单（Customer Case）提升。
另外，细心的同学也许看到了，上图沃达丰自己的网络和VPC连接的地方有两个闪电符号，并写着“AWS Direct Connect”——这是AWS的专线服务。
在2015年的上半年，非常有幸，我参与了DirectConnect服务在AWS北京区域的落地工作。这也是在加入AWS之后，第一次又和网络硬件打交道。
Direct Connect是个设计非常巧妙的网络服务。技术方面，基于802.1Q协议，一条物理专线上可以运行多个VLAN，每个VLAN里是一对BGP邻居，然后再将VLAN通过Direct Connect虚拟接口的方式关联到VPC的虚拟私有网关，实现VLAN（也就是BGP连接）与VPC的一一对应。实施方面，AWS对专线接入商的选择是开放的，每个区域（Region）会有两个或两个以上的专线接入点（Direct Connect Location）供用户选择的SP进行专线接驳，多点接入也可以提高专线网络整体可用性。
此外，如果一个用户有多VPC需求，那么他通常会有比较严格的权限管理需求——常见于企业上云项目。这时，IAM (Identity Access Management)就是一个需要重点关注的服务了。通过编写Policy，可以限定某一个或一类用户的权限。下面的例子可以限定一个用户只能在指定的子网里启动EC2，并且只能使用指定的安全组。
另外，有些用户甚至单独建立一个运维帐号，再把多个服务对应到多个AWS帐号。也就是说，各个服务的VPC属于不同帐号。然后，在各个服务帐号下创建不同权限的IAM角色（Role），在需要操作AWS资源时，通过跨帐号授权把IAM角色关联给运维帐号的IAM用户，从而完成权限的动态管理。
说到企业级用户，网络安全监控是个常见需求。2015年6月，AWS发布了一个让所有网络管理员兴奋的功能——VPC Flow Log。这是一个能够实时监控VPC、子网、网卡等各个虚拟网络层级的服务，监控的内容包括网卡Interface ID、源地址、目的地址、源端口、目的端口、协议等。换句话说，以前需要Netflow、sFlow等网络监控功能的需求，现在可以通过VPC Flow Log实现。并且，与物理网络设备相比，VPC Flow Log捕获的是全部数据包的信息，并可以通过归档到S3达到容量无限制。如果用户需要对IT日志进行大数据分析，VPC Flow Log还可以和AWS的大数据服务无缝对接。同时，第三方分析工具也对VPC Flow Log提供给了支持，比如大名鼎鼎的Splunk、Sumologic等等。
其实，关于VPC的话题，还可以讲很多，比如IPv6支持、托管的NAT网关、为私有子网提供S3访问能力的VPC Endpoint等等。
今天先开个头，把基础部分说清楚，我们下回继续分解。
点击“阅读原文”
了解更多AWS官方Blog内容