本文主要分享了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战略的简要分析。
一、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瓶水放在去厕所的路上。 |
二、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技术，针对EC2、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，可以与S3、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/
三、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、软件及网络等资源将全部构建于公有云平台之上。
