经验分享: 成功经过AWS Advanced Networking Specialty认证考试

薛国锋  xueguofeng2011@gmail.com

 

本文主要分享了AWS高级网络专项认证考试（Advanced Networking Specialty - ANS）的备战及考试经验，同时对AWS网络相关服务进行REVIEW，分析其主要特色和一些应用限制；最后对AWS战略作简要分析，讨论一下对运营商及企业网络的影响。

 

2个月前正好有一些时间，决定树立个目标、优化一下本身的知识结构。在网上转了半天，初步选定AWS高级网络专项认证考试。

先简单介绍一下本人的专业背景：从事数据通讯领域多年，开发过路由器平台软件和协议模块，干过解决方案销售，参与过不少运营商IP网络建设，对主流数通协议及网络方案是比较了解的。3年前开始接触IT和云计算，2015年把WEB技术体系囫囵吞枣地过了一遍，包括前端HTML/JavaScript、AJAX以及后端的JSP/Servlet、Tomcat、Spring/Struts、Hibernate、MySQL、JAX-RS 等，固然这些都是利用业余时间学着玩的，只了解一些基本概念、编过一些小程序。后来朋友推荐玩一玩AWS，通过半年多的胡乱摸索（第一次经过SSH登录EC2主机都有很强的挫败感），2017年初经过了AWS解决方案架构师（助理级）和AWS开发者（助理级）的认证考试。2017年下半年把比较流行的开源软件框架都安装过一遍，包括OpenDaylight、QEMU/KVM、OVS、OpenStack/Python、Docker、Kubernetes及Hadoop等。总的来讲，从云计算的技术体系到业务应用，已经创建了初步概念和感性印象。

AWS 高级网络专项认证，是亚马逊2017年新推出的认证项目，重点考察面向企业混合云场景下的链接、路由、可靠性、容错、安全、加密、域名解析、CDN、目录服务、各类云服务对网络的需求（VDI、容器、RDS、大数据、数据库迁移等）、自动化部署与运维、效率与成本、风险及合规等与网络相关的知识，涉及面比较广、有必定深度。考试内容以场景为主，注重考察运用知识解决实际问题、而非知识点自己，170分钟时间共65道选择题（单选及多选），每道题介绍一个业务场景，你须要在2分半的时间内理解问题、创建模型、作出选择。咱们经过2道模拟题，看一下试题风格：

关键知识点：VPC Peering不支持Transitive Routing；Client-to-Site V_P_N为Client分配IP地址、作NAT；通常来讲NAT只支持单向链接。正确答案为B。

关键知识点：Mumbai和Singapore距离美国东岸距离较远、时延较大，应该在亚太创建Transit Hub VPC；VPC Peering不支持Transitive Routing，须要V_P_N over VPC Peering，链接2个Transit Hub VPC；跨Region的VPC Peering，AWS自动提供加密，无需采用IPSEC V_P_N，采用GRE隧道效率更高（我第一次作这道题，把Mumbai当成了Miami，整个题都理解错了）。正确答案为B。

网上不少人都反馈AWS ANS认证考试比较难，多是AWS 的9个证书中最难考的一个；美国有一位老兄手里拿了6个AWS证书（3个助理级 – SA、Developer、SysOps，3个专业级 – SA、DevOps、Big Data），挑战了3次才经过AWS ANS认证考试。如今回头分析这个事，我以为主要缘由以下：

1）ANS是2017年新推出的认证项目，经过的人很少，相对其它AWS认证项目，网上各类ANS模拟题库的质量不高。我在备战ANS认证考试过程当中一共作了800多道模拟题（主要来自Official Study Guide和WhizLabs，不少题目都是拷贝的），而在实际考试中基本一道题也没有遇到过，所以这个考试就是在考察你的真实水平。

2）网络就是要复杂一些，链接了各类云服务和On-premises，涉及到端到端网络和各类组件，正常状况下你感受不到它的存在、出了事儿可能全是它的问题；若是对网络一些核心概念理解不透彻的话，场景稍微调整一下，在遇到压力的状况，脑壳可能就乱了。

3）如今企业中从事云计算应用的人员多数来自IT和软件，从IP转过来的很少，不一样背景的人对AWS ANS认证考试难度的感知天然会有差别。我我的的体会是，IT和软件涉及面很广，而IP是比较复杂的。

在网上作了调研以后，当时心理仍是有必定压力的，我行不行啊、这个要投入多少时间？但客观分析一下，这个认证考试就是为我这种从IP转入IT和云计算的人设计的，若是我都不敢去挑战，还期望谁呢？我到底算不算专家啊，会考试的人不必定是专家，但真专家应该是不会害怕这种实战性强的考试。最终下定决心，上！

目标定下来后，就是坚决不移地执行，接下来的8个星期过得是比较辛苦的，几乎把全部能利用上的时间都利用上了，“理论学习 – Lab – 模拟题练习 – 总结”，俄罗斯世界杯期间一场足球比赛也没看。有一天忽然收到公司HR的电话 – “薛老师，你上个月加班150个小时、没事吧”，我说“没事儿，宿舍没空调、办公室凉快、本身看看书啥的”。

我总共看了几千页的材料，记了200多页的笔记，但仍感受信心不足、预约参加考试的时间也一拖再拖，不只仅是由于300多美圆报名费的问题，主要担忧若是考不过会影响自信心，毕竟咱是公司的专家。准备到后来都有些厌倦了，材料开始看不进去了、而且找不到大块的新知识点，时间不能再拖了，因而就报名了8/7的考试。

尽管事先作好了充分的思想准备，考试过程仍是很是紧张和刺激，时间飞速流逝，有些题就是看不懂、急得直跺脚，总盼着下一道题能简单点儿、赢回来一些时间，头脑中曾出现放弃的念头（随机选答案就交卷了），最终hold住了，只要还有一分钟时间、就要尽心尽力去读题作题。ANS ANS认证考试不只仅是考察你的专业知识，还包括你的心理素质和意志力，在有限时间和环境压力下可否稳定发挥。

我用了140分钟答完了65道题，对其中18道作了标记、属于拿不许的，而后就用剩下的30分钟对这18道题进行REVIEW，修改了部分题目的答案。在交卷前的一刻，其实人已经比较放松了，过去2个月不管是准备阶段仍是考试现场，我都作了详细的策划、尽了本身最大的努力，也系统地提高了本身在云计算和网络结合方面的专业水平，不管结果如何，都没有遗憾；若是过不了，那就是本身水平不行，或者实践不到位。点击鼠标后等待片刻，屏幕显示：

“Congratulations，you have successfully completed AWS Advanced Networking – Specialty exam…”

我当时心理有些犯嘀咕，complete考试有啥好祝贺的，难道还有人不能complete，我到底有没有pass啊？离开考场后打开手机，收到了AWS的邮件：

经过了，成绩为84%（及格线一般为65%~70%），结果仍是很不错的，这说明以前本身背负了过多的思想负担、备战工做有些overly prepared了。实际上认证考试只要能经过就OK了，工做与考试仍是有不少区别，考试成绩每提高1%都要付出额外的努力和时间，利用这些时间学些新东西或者享受一下生活不是更好吗！

云计算并不是个人本职工做，过去3年我投入了大量的业余时间学习云计算的相关技术，同时在工做中创造各类条件去实践，我对本身当前取得的进展是满意的。从当初对云计算一无所知、人云亦云，到逐渐可以造成一些本身的观点并经过AWS ANS这种专业级的云计算认证考试，我切切实实感觉到了本身的进步与成长；而且这种进步是源于本身为应对将来的挑战所做出的积极改变，收获的不只仅是信心，而是将来广阔的空间。

接下来我经过3个维度分享一下本次参加AWS ANS认证考试的经验与心得体会：

1）AWS ANS认证考试的备战与考试经验；

2）AWS网络相关服务REVIEW，主要特色与一些应用限制；

3）AWS战略的简要分析。

 

1、AWS ANS认证考试的备战与考试经验

主要采用的学习材料：

阅读材料	AWS Certified Advanced Networking Official Study Guide，31.99$，Amazon上有卖； AWS官网上各类云服务使用指南、FAQs、白皮书和博客； 平时用Google查阅一些知识点；
培训视频	A Cloud Guru上的ANS培训视频（主用），订阅费29$/月、前7天免费： https://acloud.guru/learn/aws-certified-advanced-networking-specialty Linux Academy上的ANS培训视频，订阅费49$/月、前7天免费： https://linuxacademy.com/amazon-web-services/training/course/name/aws-certified-networking-specialty AWS re:Invent 2017的网络相关视频（主用）： https://www.youtube.com/playlist?list=PLhr1KZpdzukewxjrgeVIGw49tiIbkqt0Z 网友整理的AWS ANS相关视频：https://www.youtube.com/watch?v=SMvom9QjkPk&list=PLlkukGgpsXyvUbJ85RVD7qNJ1mcGKO4_w&index=1
模拟题	Official Study 提供的ANS Practice Test，200多道练习题，随书赠送： https://testbanks.wiley.com/WPDACE/Dashboard Whizlabs提供8套ANS   Practice Test，600多道练习题，29$： https://www.whizlabs.com/aws-advanced-networking-speciality/
Lab	主要用AWS Management Console； 写了一些简单的Python Web程序，运行在EC2实例上，作测试用； 采用PuTTY登录EC2实例，须要配置穿越公司的代理服务器。

 

结合我的状况制定的学习计划：

Week  1,2,3,4	1）看培训视频； 2）阅读Official Study Guide（2遍），完成了主要的课后实验； 3）温习、学习了一些背景专业知识，包括：  - 对称加密与非对称加密、数字签名、CA证书、SSH、SSL/TLS、HTTPS、IPSEC/IKE；  - 正向代理/反向代理/HTTP代理/Socks代理，DHCP、DNS、CDN；  - LDAP与Active Directory、SAML/OIDC、SSO；  - KVM及XEN虚拟化，SR-IOV/DPDK，Dockers及Kubernetes的网络技术；  - JavaScript和AJAX、Tomcat与Servlet、Cookies与Session，等等。
Week  5,6,7	完成了800多道模拟题的训练，进行总结，加深理解。
Week  8	阅读Official Study Guide（第3遍），复习200多页的学习笔记； 重点补作了一些实验、看了一些视频。
	1）备战期间要坚持锻炼身体，调整好竞技状态； 2）AWS ANS认证考试的信息量比较大，平时要作好笔记，按期复习； 3）考试期间没有太多时间思考，对于一些主流的业务场景，如VPC路由选择、Hybrid DNS主要场景及方案、Transit Hub VPC方案的主要变种、EC2实例V_P_N网关的水平及垂直扩展方案等，要作好概括总结、可以触类旁通。

 

考试预定与参加考试的注意事项：

考试预定	参加ANS认证考试前，应先经过一门AWS助理级认证（SA、Developer或SysOps）； 到AWS网站上进行考试预定，支付318美圆： https://www.aws.training/certification 建议选择英文考试，AWS中文资料翻译的很差、常常会有歧义； 我选择的考点是：深圳市罗湖区深房广场1903室，下午1:30考试。
参加考试：	携带2个带照片的我的ID，考点提供安全柜，能够存放我的物品； 进入考场后不能携带任何物品，能够管考试中心的工做人员要一些纸和笔； 计算机考试，电子监控，周边一圈摄像头； 考试过程当中用脑强度会比较大，事先要确保充足的睡眠和能量，调整好心情； 考试期间容许上厕所，能够准备1瓶水放在去厕所的路上。

 

2、AWS网络相关服务REVIEW

AWS的英文文档作的很是好，为各个服务提供了很详细的使用指南及FAQs，但涉及到关键技术实现时每每一笔带过，这是我在准备AWS ANS认证考试过程当中遇到的主要障碍。在不清楚其具体实现原理的状况下，不少知识点就要靠人为记忆了，这是一件很不爽的事情。针对一些关键服务的实现，我参照了开源软件的实现方案以及网上的讨论，同时结合过去的研发经验，争取可以画出模型、加深理解、简化记忆。下面讨论AWS网络相关服务的部分重要及难点问题，来自我备战期间整理的学习笔记。

 

VPC转发逻辑与Transitive Routing

VPC应该是经过SDN及Overlay方案实现的，不支持Multicast和Broadcast，Subnet内部转发、Subnet之间转发、EC2实例到各种服务网关（IGW、VGW、NAT、DNS等等）的转发，都是一跳完成的。

VPC对报文转发逻辑作了重要的限定：若是一个报文的源地址不是对应本VPC内部的一个接口，则该报文的目的地址必定是对应本VPC内部的一个接口；报文的源地址或者目的地址至少有一个是对应本VPC内部的接口，不然报文就要被丢弃。

这个转发逻辑的制定 – VPC不支持Transitive Routing，应该主要是考虑到AWS云端网络的安全性及可靠性，好比说避免租户设计的VPC网络出现环路问题、避免源地址欺骗。VPC不支持Transitive Routing，会影响到AWS云端网络设计的方方面面，提高了总体方案的复杂度，这也是与传统On-premises网络区别最大的地方。如下表格是我根据AWS的官方文档和Lab整理出来的：

VPC内部各种服务网关	EC2 实例	IGW与  EIGW	VGW	VPC Peering	Gateway VPC Endpoint	Interface VPC Endpoint	VPC DNS	EFS	NAT网关与实例
在本VPC内部访问	V	V	V	V	V	V	V	V	V
经过VPC Peering接入后访问	V	X	X	X	X	\X 仅支持来自同一Region 其它VPC的部分实例的访问	X	X	X
经过Direct Connect接入后访问	V	X	V CloudHub	X	X	V	X	V	X
经过V_P_N Connection接入后访问	V	X	V CloudHub	X	X	X	X	X	X

IGW/EIGW、VGW、VPC Peering和Gateway VPC Endpoint在VPC内部都不存在ENI接口，只能在VPC内部访问。

VPC DNS虽然能够经过“VPC CIDR+2”的地址进行访问，但在VPC内部并不存在ENI接口（应该是VPC路由器直接截获DNS报文、转发给AWS-Managed DNS服务），因此只能在VPC内部访问。

对于Interface VPC Endpoint及EFS，它们在VPC内部都有ENI接口及IP地址，正常状况下与在外部访问EC2实例没有区别，AWS应该是基于商业考虑和技术约束作了一些访问限制。

对于NAT GW和NAT实例，它们在VPC内部都有ENI接口及IP地址，但它们处理的报文都是要访问Internet的（并不是访问NAT设备自己），因为VPC不支持Transitive Routing，只能在VPC内部访问。

在AWS平台上实现Transitive Routing须要采用Overlay的方案，将从VPC外部对VPC内部各种服务网关的访问/穿透，转换为在VPC内部发起请求；针对每一类服务网关，都要采用与之对应的解决方案。

针对VPC DNS的Transitive Routing问题，可采用AWS-Managed SimpleAD、Active Directory或本身部署Unbound，实施Conditional Forwarding。

针对IGW及NAT的Transitive Routing问题，须要采用EC2实例终结V_P_N隧道、作NAT转换（将报文源地址转换为VPC CIDR的地址），才有可能访问VPC的IGW及NAT。

针对VPC Endpoint的Transitive Routing问题，须要在HTTP应用层实现，具体能够采用2种方案：

1）反向代理（代理服务）：在VPC内部部署ELB及Proxy Farm，经过修改DNS，将VPC外部对服务网关的访问转换为先访问ELB，在由ELB及Proxy Farm访问服务网关。

2）正向代理（代理客户），在VPC内部部署ELB及Proxy Farm，在客户端配置ELB做为代理服务器，客户端先链接ELB，在由ELB及Proxy Farm访问服务网关。

VPC 的本地路由

VPC Local Route主要用于VPC内部的转发、确保全部资源之间的通讯，不能被修改，不能用more specific route进行覆盖。若是你想配置软件防火墙用于过滤Subnet之间的转发流量，你没法改动VPC Local Route，但能够经过改动EC2实例OS的路由配置间接实现。

能够在VPC路由表中增长比VPC CIDR范围更大的Destination。 

ENI接口

EC2实例的主接口，没法从实例分离。ENI能够在某Subnet中动态建立，表明虚拟网卡，能够与EC2实例动态绑定（EC2实例所在Subnet与ENI所在Subnet必须在同一AZ内），也能够从一个实例分离并从新绑定到另外一个实例。ENI接口能够用于网管网、主备倒换以及虚拟防火墙等。

EC2实例支持ENI接口数量有限，不支持NIC Teaming。 

跨帐户网络接口：

A帐户某VPC及Subnet的EC2实例，动态绑定B帐户某VPC及Subnet中的ENI，EC2实例与ENI须要在1个AZ内；主要用于AWS管理的服务与租户VPC之间的访问，包括RDS（AWS管理数据库、租户使用数据库）、Lambda（AWS提供计算资源、访问租户VPC）及Workspaces等。该方案的扩展性及可靠性通常。

受控使用，租户要使用这个功能，须要白名单控制。 

ENI接口的Source/Destination Check

与VPC转发逻辑不支持Transitive Routing的缘由相似，EC2实例的ENI接口发送/接收报文时，要作Source/Destination Check：发送报文时，报文的源地址必须是本身的IP地址；接收报文时，报文的目的地址必须是本身的IP地址；不然报文就要被丢弃。当EC2实例提供NAT、V_P_N、Firewall等功能时，接收和发送的报文一般都不是本身的，所以要禁止Source/Destination Check。 

安全组

安全组做用于ENI接口。安全组的Inbound规则，端口是本身的、源IP地址是远端的；安全组的Outbound规则，端口是远端的、源IP地址是远端的。安全组，只须要配置Allow。

默认安全组，经过配置自引用规则，实现能够接收来自配置了同一安全组的实例的报文、容许发送全部报文。新建的安全组，开始时禁止接收报文、但能够发送全部报文。

安全组是有状态的，只要容许报文进入、就容许报文离开，不管Outbound规则是如何配置的；反之亦然。若是针对某些端口，容许进出全部的流量，安全组就不须要维持状态了。

因为AWS内部的技术实现，对于已经存在的链接，删除对应的安全组后，通讯不会中断、仍会持续若干天，所以必需要配置网络ACL。 

网络ACL

网络ACL做用于Subnet。网络ACL的Inbound规则，端口是本身的、源IP地址是远端的；网络ACL的Outbound规则，端口是远端的、源IP地址是远端的。网络ACL须要显示配置Allow及Deny规则，按照规则顺序进行匹配。

默认ACL，经过在Inbound和Outbound方向配置100号规则，能够发送和接收全部报文。新建的NACL，开始时禁止接收和发送全部报文。

网络ACL是无状态的。 

IGW、NAT网关/实例和EIGW

NAT网关/实例，只是将报文的源地址转换为自身ENI接口的地址（私有地址），用源端口号来区别不一样的用户流；IGW最终将报文的源地址（私有地址）转换为公有IP地址或弹性IP地址，是1:1转换。

NAT网关，是AWS Managed的服务，你不能作任何改动，不能配置其ENI接口的安全组，不能配置Predefined端口、容许外部访问内部。NAT网关要部署到Subnet级别，性能能够自动伸缩、到45Gps。

NAT实例，能够采用第三方软件、须要禁止Source/Destination Check。NAT实例的安全组能够配置，Inbound规则实际上意义不大，由于收到的报文都不是要访问NAT实例自己的。

EIGW，是为IPV6业务提供相似IPV4 NAT的体验，VPC内部能够访问Internet、Internet不能访问VPC内部，但不作地址转换；EIGW部署在VPC级别、非Subnet。 

VPC路由优先级

VPC的静态路由配置是不能出现冲突的，既前往同一个Destination不能有2个Target，可是静态路由与动态路由之间是能够冲突的，这就涉及路由优先级的问题。AWS网络有2个位置，须要作出路由选择，分别是VPC和VGW。

VPC有多个路由来源，包括本地CIDR、静态配置、VGW动态注入。VPC的路由选择优先级为：本地CIDR路由，最长匹配路由（不管来自哪里），静态路由（前往某Destination，Target分别为IGW、VPC Peering、VGW、NAT、ENI等），经过Direct Connect注入的BGP路由（Target为VGW），V_P_N静态路由（Target为VGW），经过V_P_N Connection注入的BGP路由（Target为VGW）。

VGW也有多个路由来源，包括绑定VPC的CIDR、在V_P_N Connection上配置的静态路由、经过BGP协议及多个Direct Connect及V_P_N Connection对等体动态学习的路由。VGW的路由选择优先级为：本地CIDR路由、最长匹配路由、经过Direct Connect学到的BGP路由、V_P_N静态路由、经过V_P_N Connection学到的BGP路由。

VGW内部多个Direct Connect或多个V_P_N Connection存在多条BGP路由冲突时，BGP的路由选择优先级为：Weight（Highest Wins），Local_Pref（Highest Wins），聚合路由，AS_Path（Shortest Wins），Origin（IGP-EGP-Incomplete）、MED（Lowest Wins）等。

VGW经过BGP over Direct Connect 或 BGP over V_P_N Connection学到路由后，能够动态注入到VPC路由表，也能够在VPC路由表中配置静态路由、Target指向VGW。 

VPC Endpoint

主要是出于安全及合规考虑，访问AWS公有服务时，不走Internet。主要分为2类：

Gateway VPC Endpoint，早期的技术实现，主要针对S3和DynamoDB，将这些AWS服务的公网路由注入VPC及Subnet的路由表中（用PL-xxxxxxxx标识、做为Destination），VPC Endpoint做为Target（用vpce-xxxxxxxx标识，应该是提供NAT功能）。能够在VPC Endpoint配置IAM策略，可以访问哪些S3 Bucket；也能够在S3 Bucket配置IAM策略，可以被哪些VPC或VPC Endpoint访问，不能采用基于源IP地址的策略。此外在安全组也能够引用PL-xxxxxxxx、配置策略，网络ACL中不能引用PL-xxxxxxxx。

Interface VPC Endpoint，最新的技术实现，基于AWS PrivateLink技术，针对EC二、ELB、Kinesis等，为这些AWS服务在Consumer VPC增长了一个或多个ENI接口及IP地址，同时为这些ENI接口提供Region及Zone的DNS域名（公网可解析、返回私网IP地址），也能够在Consumer VPC内部将标准AWS服务域名（如：ec2.us-east-2.amazonaws.com）解析为这些ENI接口的私有IP地址。

经过PrivateLink技术，咱们本身也能够对外发布Endpoint Service：在Provider VPC建立Network ELB及Back-end服务器、基于ELB建立Endpoint Service；在Consumer VPC建立Interface VPC Endpoint、引用Provider VPC的Endpoint Service。

由于Network ELB只支持TCP，因此AWS PrivateLink只支持TCP。 

VPC Peering与AWS PrivateLink

VPC Peering适合于2个VPC之间的多个EC2实例之间的双向通讯，最多支持125个Peering；PrivateLink适合于单向通讯，能够支持数千个Consumer VPC。

同一Region的VPC Peering，能够引用对端的安全组，而且可配置将对端的公有DNS域名解析为VPC内部的私有IP地址（非弹性IP地址或公有IP地址）。采用VPC Peering后，并不能自动访问对端VPC关联的Route 53私有托管区，仍须要显示关联。跨Region的VPC Peering，AWS自动提供加密。 

V_P_N

Site-to-Site V_P_N，采用VGW，也能够本身在EC2实例上运行V_P_N软件、须要禁止Source/Distination Check。

CGW主要向VGW创建链接；CGW若是部署在NAT设备后面，须要支持NAT-T功能（这是IPSec的特性，将IPSEC ESP报文封装成UDP报文、端口为4500）。

1个V_P_N Connection、2个IPSec Tunnel，经过路由策略实施Active/Active或Active/Passive：

VGW –> CGW流量，CGW向VGW发布路由时采用BGP的 最长匹配路由、AS_Prepend或MED等策略；

CGW -> VGW流量，CGW向on-premises内部网络发布路由时采用BGP的Weight或Local_Pref等策略。

EC2实例V_P_N网关的HA方案：运行2个EC2实例做为IPSEC网关、创建隧道，其中EC2-1个做为on-premises路由的Target；运行自动化脚本，发现问题，修改VPC路由表、实现切换，选择EC2-2做为on-premises路由的Target。

EC2实例V_P_N网关的垂直扩展方案：EC2 Instance1（作ELB） 与3个EC2 Instance（处理IPSec）之间运行BGP。

EC2实例V_P_N网关的水平扩展方案：按照不一样的Prefix来分离IPSec网关，192.168.0.0./17走EC2 Instance 1，192.168.128.0/17走EC2 Instance 2。

Client-to-Site V_P_N，只能本身在EC2实例上运行V_P_N软件，一般还要为Client提供认证、IP地址分配及NAT等功能。 

Direct Connect

AWS与全球上百家区域运营商合做，将PoP点下移，采用DX Router就近进入客户。2种接入方案：

1）光纤直连，DX Router – Dark Fiber – CGW，支持1Gbps和10Gbps；

2）借助于运营商网络，DX Router – MPLS PE ………MPLE PE – CGW，支持50~500Mbps。

专用链接，Dedicated Connection，可配置多个VLAN（多个VIF），客户负责LOA-CFA；客户须要支付端口小时费。托管链接，Hosted Connection，只对应1个VLAN（1个VIF）、由运营商指定，运营商负责LOA-CFA，客户也须要支付端口小时费。

CGW经过DX Router及Private VIF，链接到VGW，运行BGP，在VPC及On-premises之间交换路由；VPC只会向CGW宣告其CIDR路由，非其它静态配置或动态注入的路由；CGW最多向VGW发布100条路由。

CGW经过DX Router及Public VIF，链接到AWS Internet，运行BGP，经过Community属性控制On-premises路由的传播范围（本Region、本Continent、全球），以及CGW学习AWS Internet路由的范围（本Region、本Continent、全球）。CGW最多向AWS Internet发布1000条路由，AWS Internet不会为On-premises的公网路由提供Transit服务；若是CGW采用私有ASN，AS-Prepend不会起做用。

托管VIF，Hosted VIF，能够是Public VIF，也能够是Private VIF（接收者绑定VPC）。Hosted VIF的流量相关费用，由接收者承担；端口小时费，由Owner承担。

VGW能够做为CloudHub，为V_P_N Connection及Direct Connect等接入方提供路由及转发。

CGW经过DX Router及Private VIF链接到Direct Connect Gateway后，能够链接到跨Region的多个VGW。Direct Connect Gateway的控制平面，提供相似BGP路由反射器的功能；其转发平面，完成CGW与多个VGW之间的流量交换（非VGW之间、非CGW之间）。

CGW经过DX Router及Public VIF接入AWS Internet后，能够再与VGW之间创建V_P_N Connection。

CGW经过DX Router及Private VIF接入VPC后，能够再与VPC内部的EC2实例之间创建V_P_N Connection。这时一般须要CGW支持Tunnel VRF功能：建立VRF，在VRF内部经过DX Router及Private VIF接入VGW和VPC，学到EC2实例V_P_N网关的路由；而后在CGW的主路由表中，建立隧道（隧道的Source及Destination为VRF的地址空间），链接EC2实例V_P_N网关，再经过BGP交换业务路由。

VPC DNS与Route 53

在VPC发布EC2实例后，自动提供公有DNS域名及私有DNS域名（enableDnsSupport为TRUE、enableDnsHostnames为TRUE），公有DNS域名在VPC内部解析为私有IP地址。

VPC DNS服务，经过“CIDR+2”的地址访问，自动为Internet公有域名、VPC资源以及Route 53私有托管区（与VPC绑定）提供查询服务。VPC DNS服务，不能被VPC外部访问（经过VPC Peering、V_P_N、Direct Connect等），不可更改配置。

Hybrid DNS存在多种解决方案：

1）Simple AD是AWS提供的AD管理服务，自动向VPC DNS转发请求，不可更改配置、不能向On-premises转发请求。经过配置DHCP Option Set，VPC EC2实例可使用Simple AD的DNS服务；若是VPC也要解析On-premises的域名，有需求的EC2实例能够安装Unbound、指向On-premises DNS服务器及VPC Simple AD。On-premises DNS服务器能够设置转发、指向Simple AD，从而实现On-premises解析VPC资源的域名。

2）Microsoft AD是AWS提供的AD管理服务，能够进行配置，能够向VPC DNS及On-premises DNS转发请求。经过配置DHCP Option Set，VPC EC2实例可使用Microsoft AD的DNS服务，同时解析VPC及On-premises的域名。On-premises DNS服务器能够设置转发、指向Microsoft AD，从而实现On-premises解析VPC资源的域名。

3）在VPC部署Unbound做为DNS服务器、实施Conditional Forwarding，能够向VPC DNS及On-premises DNS转发请求。经过配置DHCP Option Set，VPC EC2实例可使用Unbound的DNS服务，同时解析VPC及On-premises的域名。On-premises DNS服务器能够设置转发、指向Unbound，从而实现On-premises解析VPC资源的域名。

4）建立Route 53私有托管区、与VPC关联，利用CloudWatch的按期事件以及Lambda函数，按期在Route 53私有托管区镜像On-premises的DNS数据库，至关于为On-premises在VPC建立了Secondary DNS，实现VPC解析On-premises的域名。

Route 53提供域名注册、DNS服务以及Health Check功能；Route 53公共托管区，是外部可见的；Route 53私有托管区与Route 53公共托管区共享全球的DNS基础设施，但Route 53只响应关联VPC对Route 53私有托管区的查询，外部没法访问，主要用于Split-Horizon DNS场景（相同的域名在VPC内部及VPC外部可解析出不一样的IP地址）。

Route 53支持Alias记录，至关于指针，对DNS Resolver提供等效于查询A记录的体验；而采用CNAME，DNS Resolver要作2次查询。不能为Zone Apex增长CNAME记录（DNS协议的要求），但Alias记录能够。能够建立Alias的Alias – 指向指针的指针。在Route 53私有托管区建立Alias记录时，不能指向Route 53公共托管区的资源。

用户可能会选择很是远的DNS Resolver完成解析，会致使Route 53的各类路由策略失效。edns-client-subnet，是DNS扩展协议，容许DNS Resolver把用户IP地址传递给DNS Server；DNS Resolver支持这个协议，Route 53才会处理用户IP地址。

Route 53 的Health Check能够对特定资源、CloudWatch的Alarm/Metric以及其它的Health Check进行监控；在建立DNS记录时，能够指定Health Check（并不须要直接相关），从而实现利用Health Check的结果进行DNS查询、躲开出现问题的资源。 

ELB

ELB的大体原理：ELB是AWS-Managed VPC，在Consumer VPC的每一个Subnet（须要显示指定）都会建立1个或多个ENI、进行绑定

对于Internet-facing ELB，将ELB的公有域名解析为弹性IP或公有IP地址（报文在IGW被转换为ENI的私有地址），在VPC内部解析也是这样的，要求部署在Public Subnet。

对于Internal ELB，ELB的域名仍然是公有域名、但解析为这些ENI的私有IP地址，能够部署在Public Subnet或Private Subnet。

因为ELB在动态伸缩期间会增长/减小ENI及私有IP地址、以及对应的弹性或公有IP地址，所以要求使用ELB的域名、不直接使用IP地址。NLB的ENI及IP地址是固定，能够直接访问其IP地址。 

CLB是第一代ELB服务，面临EOX；CLB同时支持HTTPS/HTTP与TCP/SSL监听器；SSL监听器主要用于SSL Offloading，若是不处理SSL终结和CA证书，就采用TCP 443做为监听器；CLB的HTTPS/HTTP监听器，在应用层HTTP的处理能力很是有限，只支持基本的Sticky Session、SSL Offloading等功能；不支持SNI。

SSL协商配置（安全策略），在客户端与ELB之间进行SSL链接的协商，包括SSL协议、SSL密码、顺序首选项组合等。能够采用预约义安全策略，也能够自定义安全策略。

ALB是针对HTTP/HTTPS优化的服务，支持基于URL及HTTP HOST等进行负载均衡；支持SNI，单个IP地址承载多个SSL证书；若是采用目的IP，支持在VPC及ON-premises资源之间进行负载均衡。

NLB是针对TCP优化的服务，直接进行HASH、高性能；若是要求Back-end服务器处理SSL终结及CA证书，一般要使用NLB；若是采用目的IP，支持在VPC及ON-premises资源之间进行负载均衡。

ELB会修改IP报文的源地址，有2种方法，ELB可向Back-end服务器传递用户IP地址：

1）Proxy Protocol，为TCP添加了一个头、传递用户原始信息， CLB采用Proxy Protocol V1（文本格式），NLB采用Proxy Protocol V2（二进制格式）；

2）HTTP X-Forwarded_For，在HTTP头里面增长一个字段、传递用户原始信息（Client IP、Proxy IP1…、Proxy IP2…），CLB和ALB采用。

NLB，能够保留用户IP，这个功能多是经过NLB与VPC Router及IGW深度融合实现的。

CLB和ALB支持配置安全组，实际上就是配置Consumer VPC中ENI接口的安全组，做为Internet-facing ELB和Internal ELB时配置安全组的逻辑是不一样的；NLB不支持配置安全组，可经过配置Back-end服务器的安全组间接实现。

CLB和ALB在动态伸缩过程当中IP地址会发生变化，所以在配置Back-end服务器安全组策略时，应基于CLB和ALB采用的安全组（非IP地址）指定规则。

CLB和ALB支持Logs，NLB不支持Logs。

Connection Draining，在Auto Scaling期间，ELB中止向即将中止运行的EC2实例发送新的请求，但容许其处理完正在进行的会话，缺省为300秒。 

S3

S3 Static Web Hosting服务，只支持HTTP，返回HTML ，URL通常为：http://xgf-bucket-1.s3-website.us-east-2.amazonaws.com/。

S3 API Endpoint服务，支持HTTP和HTTPS，返回XML，URL通常为：https://s3.us-east-2.amazonaws.com/xgf-bucket-1。

CORS，跨域资源共享，S3 Bucket做为Static Web Hosting时须要支持CORS，容许客户访问Bucket时，可以实现跨域访问（网页中经过XMLHttpRequest引入一些其它网站的内容）。须要配置策略，容许在访问本网站/网页时，能够引入其它哪些网站的哪些操做GET/POST等。

 

S3 Transfer Acceleration，利用CloudFront的全球分发网络，采用优化路径下载/上载对象。首先在Bucket启用Transfer Acceleration；采用新的WBB域名（非API域名）- “bucketname.s3-accelerate.amazonaws.com”，定位到最近的Edge节点，原理与CDN相似。

 

S3 Bucket和Object的IAM策略是分开配置的，用于Web Hosting时，要容许公开访问。

 

S3 API Endpoint支持Signed-URL能力，大体原理以下：

 

1）外部经过HTTP访问AWS时（特定URL），须要能识别出发送它们的客户，包括验证请求者身份、防止请求被改动、请求期限等。

2）将请求（URL表明某资源 – 图片、网页等），采用HASH作一个Digest，而后用“签名密钥”对Digest作一个“数字签名”，而后放在HTTP Authorization头中，或者以查询字符串的方式放入URL中。

3）将Signed URL发放给客户，客户使用Signed URL进行访问；AWS收到后，根据“签名密钥”进行解密获得了“原始Digest“，同时作一个“Digest”，若是一致就OK了（知道请求是否被改、以及是谁作的）。

Signed URL与Token的应用场景不一样（在不拥有密码的状况下）：Signed URL，让“外面的人”在一段时间内访问某“资源、服务”，用URL标识；Token，让“外面的人”拿到临时权限，在一段时间内访问一组资源。

采用S3 Static Web Hosting服务时，若是使用别名，该DNS名称必须和Bucket名称相同，这是由于S3 Static Web Hosting要为多个帐户的多个Bucket提供Static Web Hosting服务，它须要根据HTTP 报文头中的HOST字段找到正确的Bucket。 

CloudFront

CloudFront，属于反向代理（代理服务器），利用了Route 53基于地理的路由策略，返回给请求者最近的资源。

CloudFront支持Web分发和RTMP分发。

CloudFront分发的域名与Origin的域名，是不一样的。

一般作法，Origin处理动态请求，对网页中的静态资源交给CloudFront处理；也能够将动态请求、静态请求所有交给CloudFront。

CloudFront，能够与S三、ELB、EC2及第三方服务器集成；与S3集成时，能够采用OAI实现CloudFront到Origin的访问控制；与其它资源集成时，能够采用Custom HTTP header实现CloudFront到Origin的访问控制；作到Origin不别其它CloudFront Distribution及非CloudFront资源所访问。

提供私有内容时，能够采用Signed URL（针对单个文件）或Signed Cookies（针对一组文件），“签名密钥”通常是根据Private Key生成，而非Private Key自己。

使用CloudFront，会给你一个DNS域名，能够直接使用，也能够建立一个友好的CNAME记录或Alias记录（若是采用了Route 53），但必需要告诉CloudFront这个DNS域名，由于Cloud Front要根据HTTP HOST字段信息（友好域名）判断出请求报文属于哪个Distribution。

CloudFront与Viewer之间，能够采用HTTP、HTTPS或Redirect HTTP to HTTPS；CloudFront与Origin之间，能够采用Match Viewer、HTTP或HTTPS。须要在US East注入Certificate，自动扩散到全球全部区域。

Lambda@Edge，处理时机为viewer request，origin request，origin response，viewer response；使用场景为检查cookie、重写URL、动态修改Custom HTTP Header或进行A/B测试（新兴的网页优化方法，一部分客户访问A，一部分客户访问B，经过两种方案的优劣）。

使用CloudFront的Geoblocking功能：使用GeoIP数据库，肯定用户位置，准确率99.8%；在Web Distribution的Restrictions中，配置Geo Restriction中的Whitelist和Blacklist；若是不符合，CloudFront返回403（禁止）。

使用第三方地理定位服务（须要Origin服务器支持）：将内容上传S3 Bucket，使用OAI，经过CloudFront提供私有内容；编写Web应用程序，根据用户IP，调用地理定位服务；若是容许，为CloudFront分发的内容提供Signed URL（用户请求抵达CloudFront后，判断Signed URL）；若是不容许，返回403。

ACM – AWS Certificate Manager

AWS管理TLS证书的服务，支持CloudFront、ELS、Elastic Beanstalk和API Gateway等；能够建立CA证书，或导入你的证书到ACM中；ACM提供的CA证书，13个月有效，自动RENEW。ACM是Regional级别的，在各Region单独处理；对于CloudFront的证书，须要在US East（NV）集中处理。

AWS WAF

WEB应用防火墙，与CloudFront和Application ELB集成，监控HTTP/HTTPS的请求，采用一些定制化的规则和模式，实施保护。采用WEB ACL进行控制（定义一些Conditions），根据IP地址、URI、HTTP报头及正文（某些JSP脚本）、地理位置、特定字符串等进行过滤，而后执行一些规则（rule）。

AWS Shield

标准服务，针对常见的Attack，SYN/UDP泛洪，L3/4层，没有费用，永远在线，动态应对变化。

高级服务，针对Route 53托管区、CloudFront的分发、ELB等，L7层，实施提供Attack信息。企业上云后，水平扩展的应用，能够消化DOS；可是经过帐单，能够看到谁被Attack了（EDOS、经济上遭受DOS）；DOS不会影响你的网络，但会影响你的费用。Shield高级服务，针对DOS Attack，提供成本保护，但只针对Route 53托管区、CloudFront的分发、ELB等服务。遭受Attack后，你能够实施AWS WAF（采用Shield高级服务，这个免费）；也能够与DRT（DOS处理团队）联系，识别Attack模式；DRT团队协助你部署AWS WAF，你须要提供Cross-account的IAM角色。

GuardDuty

智能威胁检测服务，监控和保护你的AWS的Account及Wordload。分析大量数据（利用CloudTrail、VPC Flow Logs、DNS Logs等），不须要探针、不会对负载的可用性及性能形成影响。总体分析，包括帐户。

Inspector

分析VPC环境、识别安全问题智能威胁检测服务。EC2实例要安装Inspector Agent，监控操做系统和应用程序的行为。针对VPC及EC2。

Macie

使用机器学习ML，发现、分类和保护敏感数据，主要针对S3存储的数据。

Xen虚拟化与Enhanced Networking

Xen负责CPU及内存，Dom0负责虚拟机管理和I/O虚拟化；Xen，运行的Bare-metal上的，Dom0就至关于主机OS、特权虚拟机，同时支持PV和HVM；支持HVM（硬件虚拟化、须要VT-x/d）和PV（半虚拟化，改动Guest OS内核、将敏感指令改成功能调用）。Xen的几种运行模式：

1）PV模式（半虚拟化、全软件模拟）：不须要CPU支持虚拟化，修改Guest OS内核，完成CPU及内存虚拟化；I/O请求发给Dom0的真实设备驱动；

2）PV on HVM模式（全虚拟化、硬件模拟，但IO采用软件模拟）：芯片完成对CPU及内存虚拟化的支持，I/O请求发给Dom0的真实设备驱动（修改Guest OS的IO驱动程序、缺省支持一些标准的vNIC及驱动程序），绕过了KVM的全虚拟化I/O阶段，对应virto方案。

3）SR-IOV PCI passthrough直通模式（前提是HVM），利用Intel VT-d，将PF/VF直接分配给Guest OS。

PV AMI和HVM AMI启动方式不一样：HVM AMI，直接利用MBR启动，可继续安装PV网络驱动（主要针对加强联网SR-IOV），提高I/O性能。PV AMI，利用PV-GRUB、要加载menu.list到OS内核。

加强联网：就是使用了SR-IOV的实例类型，须要主机的硬件支持，只有支持HVM的实例类型才支持加强联网。VPC及Internet支持单流5Gbps（在Place Group内可达到10Gbps），多流最多10Gbps或25Gbps（取决于硬件网卡Intel 52999或ENA）。

启用加强联网须要AMI支持（AMI不启用、不安装驱动，全部VM只能使用PF）。对于采用Intel 52999的实例类型：AMI安装使用Inter ixgbevf驱动程序、并设置sriovNetSupport属性（最新的AMI都已经设置完成）；对于采用ENA的实例类型：AMI安装使用ena驱动程序、并设置enaSupport属性属性（最新的AMI都已经设置完成）。

Cloud Formation

用软件程序描述基础设施，用AWS CodeCommit或GitHub管理版本，用CloudFormation进行部署，采用CodePipeline进行端到端协同。

validation错误，拼写及格式问题、预处理就可发现问题，不涉及rollback。

semantic错误，只有在资源实际建立时才能发现，须要rollback。

引用DependsOn，会影响建立的顺序。

Retaining Resource：在Template定义资源时将DeletionPolicy设置为Retain，在Stack被删除时保留。

采用新的Template进行Update，可能会Delete、Replace一些资源。在建立Stack时提供JSON文件，定义这些策略（Disable Update:Delete或Update:Replace），防止资源被新Template删除。

Change Sets：针对当前的Stack，建立Change Set，看差异，而后执行；帮助管理Stack的升级，防止Update具有破坏性。具体提供1个新配置文件，在部署以前，与运行的Stack进行对比，提供Change、可视化，最后是excute。

配置Non-AWS资源：CloudFormation能够建立Custom Resource。在CloudFormation执行Template、建立Custom Resource的时候，能够经过SNS发送消息（提醒人、进行手工操做），或者Invoke Lambda函数（经过Python和SSH配置客户侧的CGW）；而后CloudFormation提供一个Signed URL，你能够来用反馈资源建立结果（ID、Status）。经过这种方式，CloudFormation把非Non-AWS资源也管理起来。

应该为CloudFormation建立一个Service Role，去建立/更改/删除Stack；或者采用Caller的IAM权限。

CodeCommit – CI，托管的源代码控制服务（私有Git存储库），仍可使用Git的CLI，实施版本管理。新特性采用分支版本，避免冲突；证明无误后，合入主线。

CodePipeline – CD，快速地部署Update，Build – Test – Deploy，SaaS类产品，彻底兼容Jenkins的能力和使用习惯，就是将Jenkins上云、以SaaS形式对外提供服务。CodePipeline能够响应来自CodeCommit的触发器，按期检查。

Shared Services VPC与Transit VPC

Shared Services VPC的应用场景：大量资源在AWS上，经过PROXY很容易访问on-premises，采用proxy控制AWS与on-premises之间的访问。Shared Services VPC提供的服务包括：一些共享服务（AD、DNS、Database Replicas等）；提供访问远端的代理（Spoke VPC与On-premises之间相互访问），HTTPS或SOCK代理，须要在ASW上管理一些资源。

Transit VPC的应用场景：大量的Spoke VPC要访问On-premises，很难将On-premises的资源搬到AWS上，实施复杂路由。采用EC2实例 V_P_N网关，链接Spoke VPC的VGW和On-premises的CGW。V_P_N链接不能断：Hub VPC与Spoke VPC之间有VPC Peering，仍要创建V_P_N链接；On-premises与Hub VPC之间有Direct Connect，仍要创建V_P_N链接。

Transit VPC的4种细分场景和实现方案

方案1：两个信任的VPC之间经过VPC Peering直接互联，而且静态路由的优先级高于V_P_N及BGP，绕过Transit VPC Hub。  

方案2： 相互信任，On-premises经过Private VIF及Direct Connect Gateway直接链接VGW及Spoke VPC，AS_Path短，路由优先级高，绕过Transit VPC Hub。

方案3：Transit Hub VPC与远端VPC经过VPC Peering互联（提供高带宽），Transit Hub VPC的EC2实例仍要与远端VPC中的EC2实例创建IPSEC。

方案4：CGW 的VRF经过Private VIF/DX链接到VGW及VPC，而后与VPC中的EC2实例创建IPSEC隧道（得到DX的高带宽），须要CGW支持Tunnel VRF。

Billing与Data Transfer

网络相关的3种费用：服务/端口小时费，数据处理费用，数据传送费。

V_P_N Connections：按Connection-Hour收费，还有数据传输费用（离开AWS方向）。

Direct Connect：按Port-Hour收费，还有数据传输费用（离开AWS方向）；对于Hosted Connection ，只要Accept，就开始Port-Hour收费；对于Hosted VIF，接收者支付Data Transfer相关费用，Port-Hour仍是由Owner支付。

Data Transfer - Internet，在AWS Internet与Internet之间的（假设你经过Internet访问AWS）；流入AWS Internet不收费，流出AWS Internet为$0.09/GB（由被访问资源的拥有者支付费用），这涉及AWS Internet与其它Internet之间的网间结算问题。

Data Transfer - Region to Region，在AWS Internet与AWS Internet之间的，入方向不收费，流出方向$0.02/GB。

CloudFront：从Edge到User正常收费；Origin在AWS网络，从Origin到CloudFront的流量，不收费；上载数据，须要收费，$0.02/GB。

Data Transfer - Same Region，与同一区域AWS公有服务之间的流量，没有Data Transfer费用（可是AWS公有服务自己收费）；访问不一样区域AWS公有服务，包括AWS服务费及数据传输费。

Data Transfer - Inter-AZ（不是Subnet），双向收费，每一个方向$0.01/GB。

Data Transfer - VPC Peering：相同Region的VPC Peering，EC2实例之间的通讯，双向收费，每一个方向$0.01/GB。

Data Transfer - Intra-AZ，没有费用；若是采用Public IP地址通讯，双向收费，每一个方向$0.01/GB。

对于采用Direct Connect访问AWS Internet及VPC，Public VIF及Pirvate VIF自己不涉及流量费用；访问别人的资源、由对方支付$0.09/GB（离开AWS方向）；访问本身的资源，采用下降的费率，$0.02/GB（离开AWS方向）。

 

相关白皮书及博客的链接： 

https://aws.amazon.com/cn/blogs/apn/amazon-vpc-for-on-premises-network-engineers-part-one/

https://aws.amazon.com/cn/blogs/apn/amazon-vpc-for-on-premises-network-engineers-part-two/

https://d0.awsstatic.com/whitepapers/aws-amazon-vpc-connectivity-options.pdf

https://d1.awsstatic.com/aws-answers/AWS_Multiple_Region_Multi_VPC_Connectivity.pdf

https://aws.amazon.com/cn/answers/networking/aws-multiple-data-center-ha-network-connectivity/

https://aws.amazon.com/cn/answers/networking/aws-multiple-vpc-***-connection-sharing/

https://d0.awsstatic.com/whitepapers/Networking/integrating-aws-with-multiprotocol-label-switching.pdf

https://d1.awsstatic.com/whitepapers/hybrid-cloud-dns-options-for-vpc.pdf

https://aws.amazon.com/cn/blogs/compute/powering-secondary-dns-in-a-vpc-using-aws-lambda-and-amazon-route-53-private-hosted-zones/

https://aws.amazon.com/cn/blogs/security/how-to-set-up-dns-resolution-between-on-premises-networks-and-aws-using-aws-directory-service-and-amazon-route-53/

https://aws.amazon.com/cn/blogs/security/how-to-set-up-dns-resolution-between-on-premises-networks-and-aws-using-aws-directory-service-and-microsoft-active-directory/

https://aws.amazon.com/cn/blogs/security/how-to-set-up-dns-resolution-between-on-premises-networks-and-aws-by-using-unbound/

3、AWS战略的简要分析

AWS已经建设了一张覆盖全球的IP骨干网，链接了全部的Region（中国和美国政务云除外），便于企业快速在全球对外提供业务，同时实现企业内部业务的互联。

AWS与全球上百家区域运营商合做，将PoP点下移，经过Direct Connect服务就近接入企业客户，实现企业客户高质量、低成本上云，构建混合云、访问AWS公共服务、对外提供服务。

经过全球IP骨干网以及Direct Connect，结合提供的各类云服务，AWS基本就构建了一个端到端的闭环系统，企业只要接入AWS、流量就能够在AWS内部消化掉。固然企业对外提供业务，仍要借助于AWS Internet与其它Internet的互联互通。

最近有传言说，AWS要开发一些企业侧的盒子，这应该是很正常的。目前AWS提供Direct Connect及V_P_N服务，要对接On-premises的十几个供应商的数十款软硬件产品，这些产品的能力、配置参数等都不一样；与其在云端不断地去适配这些产品，换个思路就是提供本身的盒子、对技术作归一化；同时在On-premises有本身的盒子做为抓手，能够推出一些更有竞争力的混合云服务，包括路由能力、安全加密能力、可靠性、DNS解析、存储方案等能力提高。

 

随着传统企业上云步法加快，云计算对整个通讯行业会产生深远的影响。

对运营商市场的影响：企业上云后，其内部互联天然会从传统MPLS V_P_N转向云专线，云专线的开通速度和业务集成要远优于MPLS V_P_N；能够预见长途专线市场将从运营商向云服务商转移，云服务商仍依赖运营商提供的本地专线、接入客户；将来在我的或消费互联网领域运营商仍占据领先地位，但具有全球覆盖能力的云服务商将主导高价值的企业互联网。

对企业市场的影响：企业上云后，必将逐步减小对传统IT及网络设备的投资以及长途线路租用，转而消费云服务；因为规模经济和高效率，每在云端消费1$，将减小4$的On-premises投资，传统设备制造商和软件供应商的市场空间会逐步被蚕食；多数企业网络最终会演进成为家庭接入模型。

同时云计算也会对通讯行业带来一些新的机会。相比传统的On-premises，云端出于安全性及可靠性的考虑作出不少的功能限制；对于企业客户一些定制化的需求，须要引入各种VNF组件、搭建Overlay网络，包括负载均衡、路由器、V_P_N网关、V_P_N接入服务器、防火墙、WEB防火墙、NAT等等；已有众多的传统设备制造商及新型厂家投入到这一领域，推出了相应的软件化产品，并与主流的云服务平台进行了集成。

下图为将来的一个跨国公司的企业数字化基础设施平台，除了本地接入资源外，企业的IT、软件及网络等资源将所有构建于公有云平台之上。