[AWS] 扫盲，AWS的网络组件介绍

小提示：您能找到这篇{[AWS] 扫盲，AWS的网络组件介绍}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的[AWS] 扫盲，AWS的网络组件介绍内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

前言

< ">用了产品免费发布网站一段时间的AWS，决定总结一下我已经用到过的AWS中的网络组件，算是个扫盲文，适用于网络技术背景的同学。对于网络小白，我只有一个建议——好好阅读用户手册，反正你本来也不懂，你用的云说啥，就是啥好了。

< ">公正的讲，对于非网络专业方向的IT管理员来说，AWS所抽象过的网络组件，确实更容易理解，它隐藏了很多现实中网络的细节，但反过来，当一个深受Cisco荼毒的工程师开始用这些东西，就会觉得怎么用怎么不顺手。

< ">顺带一提，福厂的网络组件，简直是对AWS网络组件的1:1映射，不愧是福厂，善于学习列强的先进经验(笑

< ">< font-size: 18px;">AWS的网络组件都有哪些东西？

< ">VPC

< ">Route Table

< ">Subnet

< ">IGW/VGW/TGW

< ">SG&Network ACL

< ">Avaibility Zone

< ">VPN/Direct connect

< ">Endpoint

< ">3rd Party Device(Virtual)

< ">我知道的，大概就是上面这些东西，由于成本压力和客观上的超远距离(从中国到美东的us-east-1)，我们没有使用Direct connect，而选择了AWS VPN，结果深受其害，在持续数周的"一小时"抖动后，我终于发现，原来AWS也是和我们这些网工一个路数，做个产品以“能用”就为标准(通了就走！)

< ">AWS:什么？Cisco的IOS-XE都已经更新到了16.10了？关我什么事，我提供的配置参考仍然是12.4的版本，并且只有IKEv1的参考……

< ">关于这个悲伤的故事，放到后面再说，下面逐一来介绍一下AWS的这些网络组件。

< ">< font-size: 18px;">VPC

< ">Virtual Private Cloud，为每个用户提供一个隔离的网络环境，你很容易就能想到现实中的网络概念——VRF。

< ">VRF是在单台设备上进行路由资源隔离，如果要在整个网络中为用户提供隔离的网络环境，就势必要用上各种各样的封装技术，也就是VPN们——MPLS/VPN，VXLAN/EVPN，甚至使用VRF&GRE隧道也可以。

< ">我们无从得知AWS到底用了什么，当然，这也不重要。在笔者看来，这些技术虽然各有优劣，但仅就提供隔离网络环境这一效果来说，没什么太大差别——因为最终，网络资源的隔离仍然是在单台设备上完成的，所有这些技术，只是为了将分散在单台设备上的，隔离的网络资源，在公共的网络上打通，封装的本质，只是为了让远端的设备能够识别，数据包到底属于哪个VRF而已。这些技术/方案的逻辑，你甚至可以用远古时期的Frame-Relay来解释。

< ">p.s.当年在培训机构学习MPLS/VPN的时候，Frame-Relay就天天被拉出来鞭尸。

< ">< font-size: 18px;">Route Table，路由表

< ">这是我个人最讨厌的一个组件，它割裂了我对于“路由表”的理解，产生了极大的不适感。我用一张图来说明AWS的Route Table是个什么东西，这张图是我在部署CSR1000v时画的。

AWS Route Table Example

< ">< background-color: rgb(242, 242, 242);">Private Subnet A和< color: rgb(165, 165, 165);">Private Subnet B被关联在一个< color: rgb(165, 165, 165);">Route Table上，姑且就叫< background-color: rgb(242, 242, 242);">Private Route Table好了。

< ">< background-color: rgb(242, 242, 242);">Public Subnet A关联在另一个< background-color: rgb(242, 242, 242);">Route Table上，就叫< background-color: rgb(242, 242, 242);">Public Route Table好了。

< ">CSR1是笔者部署的一台EC2，当然，是一台启动后就是CSR1000v虚拟路由器的EC2。它有两个网卡，分别关联到了< background-color: rgb(242, 242, 242);">Private Subnet A以及< background-color: rgb(242, 242, 242);">Public Subnet A上。

< ">换言之，从这两个网络接口发出的流量，进入了不同的路由表，也就是< background-color: rgb(242, 242, 242);">Private Route Table和< background-color: rgb(242, 242, 242);">Public Route Table

< ">那么请问，CSR1，关联到Public Subnet那侧的端口，是否能访问到Private Subnet B中的主机呢？通常来说，应该是不可以。看图说话你会觉得路由域是隔离的。

< ">但是请记住，AWS只会给你提供一个隔离网络，一个VPC即为一个隔离网络，在一个VPC内部，你只能依赖安全组进行进一步的隔离。

< ">所以，CSR1关联到< background-color: rgb(242, 242, 242);">Public Subnet A上的端口，也是可以访问到内部网络去的，你必须依赖安全组进行访问控制。

< ">Route Table在VPC内部不具备隔离网络资源的作用，它最主要的作用是，分割访问至VPC外部的路由

< ">典型的访问至VPC外部的路由，就是访问Internet所需要的默认路由。

< ">在上图中，< background-color: rgb(242, 242, 242);">Public Route Table的默认路由指向了AWS的< background-color: rgb(242, 242, 242);">Internet Gateway(缩写为< background-color: rgb(242, 242, 242);">IGW，即AWS设定的VPC中的Internet出口)，而< background-color: rgb(242, 242, 242);">Private Route Table的路由则指向了CSR1的网卡

< ">换言之，关联在Private Route Table中的Subnet，命中默认路由去往CSR1，经过CSR1进行NAT转换后访问互联网。

< ">当然，如果你有访问其它外部资源的情况，比如VPN，比如TGW，也是一样的。同一个VPC内不同的路由表的主要区别在于去往VPC外部时的路由，A路由表和B路由表对于同一条路由，指向的下一跳可以不同，仅此而已。

< ">P.S.TGW，用于将不同的VPC连起来的一个组件。在多VPC环境中，TGW还可以简化VPN拓扑的复杂度。Transit Gateway，其实就是个提供网络连通性的网络服务节点。

< ">那，它如何实现的？我们不妨大胆猜测一下——

< ">实际上，如果你观察AWS路由表这一事物，会发现里面从来就没有关联至特定子网的明细路由，只有一条VPC大段路由。VPC内所有的路由表都是如此。

< ">乍一看上去，“将子网关联至路由表”这一行为非常像是我们在路由器的某个SVI接口下敲一条vrf forwarding XXX的命令，但若真是这样，就无法解释为什么关联在不同路由表中的子网内的主机可以互相通信了。所以，一个基本的事实是，VPC内的所有子网一定是在一个路由域内的，而路由表这一概念，其实是别的东西，从它的作用来看，或许称呼为外联路由表更合适。所以，我们也可以推断出，子网的网关，并不在路由表上，所有子网的网关都在一个路由域内，路由表，其实是这个路由域外部的一个东西。

< ">于是我就画了这样一张图——

< ">可以肯定的一件事是，没人会去吃饱了撑的天天重复造轮子，AWS实现的网络组件的背后，一定也是我们熟悉的种种网络技术，而最贴近的，应该就是PBR了。

< ">上面这张图可以实现AWS的逻辑，即某个特定子网的流量被固定扔到一个路由表中去，当然这个路由表有一条回到VPC网络的大段路由。到这里，其实它就是一个可以执行三层转发的路由实例，只不过AWS起了个名字叫路由表，它到底是个什么我们不得而知，也不重要。

< ">当然啊，以上只是猜测，是从它的行为逻辑反推出来的结论。

< ">< font-size: 18px;">Subnet

< ">每个VPC在创建的时候会要求分配一个根网段，Subnet则是从根网段下派生出来的子网。VPC创建的时候会有一个主路由表，如果你不做显式关联，那么每个Subnet默认关联到主路由表。

< ">将Subnet关联到特定的路由表即可影响该Subnet下所有主机访问外部的路径。在AWS中，典型的一个应用场景是——

< ">负载均衡器所在的Subnet，关联到< background-color: rgb(242, 242, 242);">Public Route Table，其默认路由指向< background-color: rgb(242, 242, 242);">IGW，因为负载均衡器通常都需要固定的公网IP地址;

< ">而对于后端服务器，可以关联到< background-color: rgb(242, 242, 242);">Private Route Table，由于不需要对外暴露端口，< background-color: rgb(242, 242, 242);">Private Route Table可以将默认路由指向一个NAT网关，通过NAT网关访问互联网。

< ">AWS提供了一款NAT网关，你也可以自己部署第三方虚拟机，比如大C记或者Fortinet的虚拟路由器/防火墙之类的……

< ">< font-size: 18px;">IGW/VGW/TGW

< ">AWS所抽象出来的三种网关类型。

< ">IGW，Internet Gateway，访问Internet的必经之地。当你为EC2分配公网IP地址的时候，这个地址总是存在于IGW上的，IGW做了EC2私网地址到公网地址的1对1转换。

< ">VGW，当VPC需要通过VPN/Direct connect连接到本地数据中心/站点时，就需要VGW。VGW存在的合理性很容易分析，如果是我设计机房，接入区肯定被单独安排在某个或者某几个物理位置，所以从用户所在的位置到达接入区一定是存在物理链路/物理网络的，那么对应的，在虚拟网络里就需要一个VGW这样的角色，用于完成底层的流量转发。

< ">TGW，当你有多个VPC，且多个VPC需要互访，切多个VPC还需要和本地互访的时候，TGW就派上用场了。Transit Gateway，顾名思义，中转用的网络节点，在这种情况下，VPN可以直接安排在TGW上。不过笔者曾经碰到过TGW上无法排障的流量黑洞问题，很企业网站是头痛。AWS的网络组件多半都存在这个问题，抽象后易于使用，但缺少排障和运维工具，一旦点子背，就只能怪自己运气不好。

< ">< font-size: 18px;">SG&Network ACL

< ">这两个都是访问控制，差别在于，SG有会话特性，也就是支持自反，对于一个被放行的会话，不会去阻挡反向连接;Network ACL看上去就是工作在普通三层设备上的ACL，没有自反。没有自反的ACL基本等于废物，所以在我们的实践中，Network ACL的入站和出站都是允许0.0.0.0/0，安全控制完全依赖SG进行。

< ">SG，即Security Group，安全组。

< ">有一种说法是SG实际上是iptables，但是看起来，AWS并没有控制用户虚拟机的权限，所以如果SG是iptables，那应该也是宿主机上的iptables。

< ">在网络防火墙的部署中，我们很少会基于特定主机去部署防火墙，即便是逻辑上的虚拟墙(例如ASA的Security Context或者Fortinet的VDOM)，也是对应逻辑上的子网，将一个或者一些子网放到一个逻辑上的区域中，以区域为单位配置访问策略。

< ">不基于主机来做的原因也很简单——没必要。当整个网络都是由特定几个管理员来管理时，用户根本就不需要关心ACL做在哪里，用户只需要在意通或者不通，能不能通这样的问题就好了。

< ">AWS将IP抽象掉了，一些普通用户搞不好连自己的EC2的私有IP是啥都不知道。某个主机需要通公网就直接给个公网IP。并且如果没有专业的网络工程师来规划网络，很多用户搞不好就是一个Subnet用到死，甭管啥应用都在这一个子网里，于是对于AWS而言，在照顾网络小白用户的前提下，SG就必须能基于特定主机来实现。

< ">这基本上就毙掉了所有的网络防火墙方案。宿主机上的iptables看起来最合适。但是宿主机的iptables过于分散，AWS还需要将它们抽象在一起，这些工作都被AWS隐藏掉了，用户看到的，只是SG，以及将SG关联到具体的虚拟机上去。

< ">这也就解释了，为什么SG总是舆情预案监测入站控源，出站控目标……因为SG在整个网络的末端，而网络防火墙，工作在网络的转发路径上。

< ">< font-size: 18px;">Avaibility Zone

< ">可用区这个概念，实际上是真实物理网络在虚拟世界的一个映射。虚拟的东西最终还是要落到哪些物理的服务器，交换机上去的，没有哪个技术可以支撑一个虚拟化跑遍全世界的网络，于是就会有Region，会有可用区。每个可用区的设计规模，可能只有AWS自己清楚，用户不知道，但用户可以选。

< ">把不同的Subnet放到不同的可用区，一定是可以提高可靠性的，我个人在规划CSR1000v的部署的时候，CSR1和CSR2所关联的Subnet就在两个不同的可用区……这一定程度上加剧了部署时的复杂性。

< ">< font-size: 18px;">VPN/Direct connect

< ">Direct connect……名字叫的贼好听，不就专线么。VPN，就是隧道模式的IPSec VPN，AWS贴心的为你提供了很多厂家的配置参考，虽然都比较老。

< ">笔者公司面临的需求是跨国的混合云，Direct connect用脚趾想都知道会贵到难以承受，所以选择了VPN的方案。

< ">我习惯性的配置了IKEv2的VPN，也确实UP了，也能转发流量，但是总有几条隧道每隔一个小时就断一次，断的莫名其妙。一个小时太过规律，所以怀疑是生存时间到期，但通常来说，IPSec会在生存时间到期前就去re-key，不应该出现规律性的中断问题。

< ">在本地数据中心的路由器上开Debug查了很久，看到一些疑似症状，譬如re-key timeout之类的日志，但无论是改配置的方式，甚至两条隧道Down掉一条，都不能解决问题。搞笑的是，当我尝试把隧道按照AWS的配置参考改成IKEv1的配置时，故障就消失了……

< ">着重说一下AWS的VPN，拓扑结构是下面这样的——

< ">简单来说，AWS的一个VPN实例包含两个隧道，AWS一端，两条隧道源自不同的Router，实现了可靠性，至于客户端，对不起，我们只接受一个Customer Gateway，你可靠不可靠关我屁事……

< ">如果你一定要实现客户端，也就是你本地数据中心/站点的可靠性，你的拓扑就得长这样……

< ">换言之，要维护四条IPSec隧道。还行，不算多，VPC多了以后可能就上天了。(我已经上天了……)

< ">当然，VPC多了以后，可以引入TGW来避免重复造VPN，拓扑大概这样子——

< ">对于每个VPN实例，AWS会运行BGP来保证可靠性，两个VPN隧道完全对等，路由选择是取决于哪边的路由先收到……在你本地的BGP中，如果隧道1的路由先收到，则隧道1的路由优选，如果隧道1挂了，隧道2的路由优选，隧道1恢复后变为备份。

< ">如果你有两个VPN实例，你就要控选路了，而且只能在本端控。我实测AWS的BGP至少还是认识AS-PATH这个属性的，可以通过设置AS-PATH来控制路由。AWS一端的BGP没有给你留操作界面。

< ">对于跨国场景，底层的Internet质量总是不稳定，延时丢包率都比较感人，所以AWS的部分Region支持加速，加速的逻辑其实也很粗暴——当你开启加速的时候，AWS在其网络边缘的节点给你开了个NAT或者反向代理之类的东西，反正能让你的IPSec流量顺利通过该节点转发至真正的VPN点。所以即便是AWS，也无法解决真实的距离问题，也只能通过就近接入，然后把包袱扔给自家骨干网来优化访问……

< ">< font-size: 18px;">Endpoint

< ">AWS上有一些SaaS服务，比如S3，它不是工作在用户的VPC中的。当用户需要通过VPC去访问这些SaaS服务的时候，AWS给用户开了一个Endpoint，在VPC中，将访问这些服务的路由指向Endpoint，这些路由多半都是公网路由。

< ">不同用户的VPC的IP地址一定存在重叠，所以可以很容易的想到，Endpoint还会执行SNAT。所以，就是一个通往SaaS服务的路由+NAT点。

< ">< font-size: 18px;">3rd Party Device

< ">AWS生态非常牛逼的地方就在这，它支持丰富的第三方扩展。但实际上，3rd Device的集成，是个很美好的大饼，而真正部署起来的时候，并没有那么好用。究其根源是，AWS对3rd Device的处理一视同仁——EC2，所以，无论你是买了ASA还是CSR1000v还是Fortigate，本质上都是买了个EC2，你需要遵循EC2中的种种规则和限制。

< ">举几个例子，比如，AWS的路由表中的下一跳并不是填写ip地址的，由于3rd Device实际上是EC2，所以当你要通过路由引流至这些设备时，你就必须写路由指向这些设备的网卡。

< ">那如果要高可用呢？Cisco的思路是，让CSR1000v去调用AWS的API，修改路由表中路由的下一跳，以便指向另外一台设备的网卡。啥？HSRP？不好意思不支持。

< ">再比如，两个CSR1000v之间起了个IBGP，结果发现流量在两个路由器之间的转发是有黑洞的……原因也很容易想到，因为这俩路由器压根就不是直连，它们中间还过了一个"路由表"，这个"路由表"可不会跟着你的CSR1000v去收敛路由，解决方案也很傻X——我在两个CSR1000v的内部接口之间起了个GRE隧道……(捂脸

< ">至于各家稀奇古怪的高可用技术就更不谈了，现实世界中，网络设备商的高可用几乎做到了用户无感知，做不到的都不好意思拿出来卖，但到了云上，你需要仔细研究，小心规划，做好文档，不然说不定哪天就不通了……这背后的原因还是因为3rd Device本质是EC2。

< ">我见过的高可用骚操作包括——修改网卡关联的(飘网卡!)，修改路由表的，如果支持HAVIP这样的功能就使用HAVIP的，真的很佩服设备商们的想象力。

< ">但，最根本的问题是，设备商在云上的虚拟机真的赚钱吗？

< ">还是以CSR1000v为例，部署复杂，暗坑较多不说，AWS直接购买的价格也很惊人，虽然有一年购买的50%OFF，但是，不能选性能也是个讨厌的事情。譬如笔者可能只需要50Mbps的性能，但随便一个EC2都能达到更高的性能，而直接购买的License又只有Max Performance一种，于是总的成本就会很高。

< ">另一种购买方式是BYOL，即自带license，AWS上只有一个虚拟机，成本低非常多，但是又多了一步线下采购License的流程。

< ">无论是从购买还是使用上，设备商和AWS的割裂都很严重，并没有人真的很重视这块市场，甚至恐怕真的在AWS上应用CSR1000v的人也很少。不赚钱的生意就是无源之水，卖虚拟机不是做慈善，既然是无源之水，设备商为AWS上的虚拟机所能提供的支持，软件稳定性，可靠性，兼容性，都是要打上一个大大的问号的。

< ">笔者就曾碰到过< background-color: rgb(242, 242, 242);">t2.medium级别的虚拟机尽管配置看上去能满足我的需求，但实际上，却出现了IPSec不解包导致DMVPN永远卡在NHRP上的问题(本地DC的NHRP包发出去了，但CSR不解IPSec，致使NHRP协商不成功)

< ">< font-size: 18px;">关于云的一些思考

< ">在和云上的这些妖魔鬼怪打交道的日子里，我也在思考，云到底带来了什么。在我看来，云似乎仍然只是一个服务中小型IT需求的东西，对于大型的IT需求，对于已有完整的内部分工和流程的公司而言，云的诸多限制，反而会增加很多隐性成本，而这些成本，是很难被量化和计算的。

< ">有一些问题可以靠云解决，比如在一个距离较远的地方建立一个虚拟的数据中心，VPC的开通总是比租机房快的多。

< ">但也有很多问题不是靠云可以解决的，譬如物理距离所带来的延时和丢包，网络的不稳定……光就能跑那么快，海底光缆就那么几根，如果你的应用从没有考虑过弱网对抗，那么在这种条件下，势必就会很难受。

< ">说起来，很多Global Design的PPT，总是每个大洲画个Region，却从来不提Region之间要怎么建，似乎总是默认Region之间有个骨干网。真是的，拿空气给你造骨干网么。

< ">还是那句话，云不是万能药，上云要谨慎，做混合云要谨慎。小公司可以完全依赖云，TOP大公司可以自己造个云，最难受的永远是中间这一层的大部分公司，他们的IT基础设施，永远在预算和需求之间来回摇摆，嗯，这么说起来，中产阶级的生活状态，差不多也是这样(笑