转载

实用VPC虚拟私有云设计原则

在云计算的基础架构领域，没有比从一开始就正确地布局VPC（虚拟私有云）IP地址更重要的事情了。VPC的设计对于系统的伸缩性，容错性以及安全性都有深刻的影响。它也直接影响到基础架构的灵活性：如果你走进了一个死胡同，将来就可能要花费大量的时间做跨子网实例（instance）迁移来释放地址空间。

幸运的是，如果记住了几个原则，正确地布局VPC就容易了。

子网

正确的子网布局是VPC运行良好的关键。子网决定路由、可用区（AZ）的分布和网络访问控制列表（NACLs）。

我观察到围绕VPC子网划分最常见的错误，是像对待数据中心网络那样对待VPC。VPC不是数据中心，不是交换机，更不是路由器，虽然它执行了全部这三项工作。VPC是一种软件定义网络，对大量数据包迁入、迁出和跨AWS区域（region）迁移进行了优化。在发起端捡起数据包，然后在其目的地丢下数据包，就这么简单。

就是由于这个简单性，许多数据中心和网络设备存在的问题在一开始就被解决掉了。

历史回顾：

90年代时，建造数据中心时使用的是10 Mb / 秒的以太网交换机。以太网用地址解析协议（ARP）进行广播，确定交换结构中数据的相应位置。因此，网络分段与广播域中主机的数量大致成正比。因此，超过几百台主机的网络段，性能就会降低。再加上IPv4子网公式的反直观性，导致了在实践中不同的网段都使用24位的子网。三个字节的地址，在全部约束条件下似乎是最佳选择。

这种思维不适用于云环境。VPC既不支持广播，也不支持多播。就像ARP之于OS，广播和多播可以非常优雅的使用SDN实现。考虑到这一点，就没有任何理由将一个VPC劈成一些24位的子网。事实上，不这样做的重要的原因在于：浪费。因为254（或128或64或32或16）个地址的“中间层”子网，只能有四个中间层主机，其它工作负载都用不到其余的地址。

相反，如果你有一个多用途的子网，可容纳4094个地址的话，那么你可以根据每个末位IP进行自动分组等等工作，这样一来尽可能的扩大子网就变得十分必要，这样做可以让你在庞大的地址池中得以自由地进行动态分配。。

一般来说，创建一个子网主要出于三个原因：

1.不同的主机需要用不同的的路由方式（例如，内网主机与公网主机）

2. 出于容错的目的，需要在多个AZ之间分配负载。这项工作应该持续不断地进行。

3. 特定的地址空间由于安全的原因需要授权NACL（例如，驻留客户个人身份信息数据库的网段）

让我们依次分析一下这些因素。

路由

VPC中的所有主机都可以通过路由与同一个VPC内的其他主机连接。唯一真正的问题在于：允许什么样的数据包可以在VPC中进出。

事实上，可以轻松地建立一个禁止任何数据包进入或离开的VPC。只要建立的VPC不存在互联网网关或虚拟专用网关，就可以有效地将其隔离为孤岛了。

VPC不产生任何网络流量那还有什么价值。假设，你有一个使用互联网的应用，在添加了互联网网关，并为主机指定了一些弹性的IP地址以后，是否就能公开访问了？不，并非如此。你还需要创建一个路由表，其中默认路由要是互联网网关。然后对一个或多个子网应用该表。之后，这些子网中的所有主机都将继承路由表。你需要创建一个路由表，将Internet网关作为默认路由，然后你需要将该表格应用于一个或多个子网中，之后所有子网内的host都会继承该路由表属性。任何指向VPC外被block的IP地址的都需要经过Internet网关，这样一来你的host就会被赋予回应外部通信的能力；即便如此几乎没有应用希望其所有的host都能被公开访问。

事实上，完善的安全性决定了最小特权原则。因此任何不是绝对需要外部世界直接访问的主机，都应不能直接从入口传送流量。这些主机需要有更高一层不同的路由表。

一个子网只能有一个路由表（尽管路由表可以应用于多个子网）。如果希望一组主机与另一组主机用不同的路由，就需要创建新的子网，并对其应用新的路由表。

容错

AWS以可用区（Availability Zones（AZ））的形式提供了开箱即用的geographic distribution，每个region至少有两个AZ。

子网不能跨越多个AZs。因此，要实现容错，需要在AZ中平均分配地址空间，并在每一个里面分别创建子网。AZ越多越好：假如你有三个可用AZ，就将地址空间分成四份，并把第四分段作为备用。

平均划分地址空间更加明显的原因，是让每个AZ的内部布局都是相同的。当创建诸如自动伸缩组等资源时，它们最好是均匀分布的。如果创建的地址块是不连续的，必然给今后的维护留下了后悔不已的噩梦。

安全性

在VPC中，防御措施的第一层已经得到解决：严格控制packet的出入。在路由层之上有两个补充性质的控件：安全组和NACLs（网络访问控制表）。安全组是动态的，有横跨整个VPC的状态和能力；NACLs是无状态的（也就是说你需要定义出入端口），静态的和子网特有的。

一般来说，如果要在多组管理员之间分配变更控制的权限，就需要上述两个控件。例如，可能让系统管理员团队控制安全组，而网络团队控制NACL。这样一来，任何一方都不可能独自突破网络的限制。

在实践中，NACLs应该谨慎使用，并且一旦被创建，就少去改动。因为他们是子网特定的，并与IP地址对应的，在此层管理流量的复杂度，将随着附加规则个数的增加，成几何级数地增加。

安全组是完成大部分工作的地方。除了前述的特定场合以外，应尽可能保持安全规则简单明了，这样能提供更好的服务。这样的安全组才是最好的。

一个例子

以上只是一组抽象的准则。我想提供一个具体的例子来说明如何将它们结合在一起。

布局一个VPC最简单的方法有下列几个步骤：

1. 在尽可能多的AZ中平均分配你的地址空间。

2. 确定你所需要的不同种类的路由，以及每种路由相关的host数量。

3. 在各个AZ中按照每个路由的需求来创建大小相同的子网，赋予其相同的路由表。

4. 为了预防任何遗漏，留下一点未分配的空间。(相信我一次。）

因此在我们的例子中，将创建一个具有外部访问网络主机的，标准的n层架构应用。使用的地址空间是10.0.0.0/16。

最简单地布局一个VPC地址空间时要忘掉IP范围，而只从子网掩码方面考虑。

以上述10.0.0.0/16地址空间为例。假设希望在美国-西部-2（us-west–2）地点运行全部三个AZ，以使Mongo cluster可以达到一个可靠的值。通过地址范围实现这个需求是很讨人厌的。相反，你可以简单地说：“我需要四个分块，三个AZ各对应一块，另一块备用。”因为子网掩码是二进制的，屏蔽码中每增加一个比特就将空间除以二。所以四个分块，就要增加两个比特，16比特将变成四个18比特。

10.0.0.0/16: <br>    10.0.0.0/18 — AZ A<br>    10.0.64.0/18 — AZ B<br>    10.0.128.0/18 — AZ C<br>    10.0.192.0/18 — Spare

现在你要决定在每个AZ内部的公共子网，私有子网和备用容量。能够公开访问的主机数量应该远远少于只能内部访问的数量，于是决定将私有子网一半大小的空间分配给公共子网。想要创建一个独立的地址空间，只需继续增加bit。即：

10.0.0.0/18 — AZ A     10.0.0.0/19 — Private     10.0.32.0/19             10.0.32.0/20 — Public             10.0.48.0/20 — Spare

随后，如果你想要在NACL中增加一个“受保护的”子网，只要再次从备用空间中划分出一块即可：

10.0.0.0/18 — AZ A       10.0.0.0/19 — Private       10.0.32.0/19               10.0.32.0/20 — Public               10.0.48.0/20                   10.0.48.0/21 — Protected                   10.0.56.0/21 — Spare

需要确保你在一个AZ中做过任何事情，都在所有其他AZ中重复一遍：

10.0.0.0/16: 10.0.0.0/18 — AZ A  10.0.0.0/19 — Private  10.0.32.0/19      10.0.32.0/20 — Public      10.0.48.0/20       10.0.48.0/21 — Protected       10.0.56.0/21 — Spare 10.0.64.0/18 — AZ B  10.0.64.0/19 — Private  10.0.96.0/19    10.0.96.0/20 — Public    10.0.112.0/20     10.0.112.0/21 — Protected     10.0.120.0/21 — Spare 10.0.128.0/18 — AZ C  10.0.128.0/19 — Private  10.0.160.0/19    10.0.160.0/20 — Public    10.0.176.0/20     10.0.176.0/21 — Protected     10.0.184.0/21 — Spare 10.0.192.0/18 — Spare

路由表是这样的：

“Public”     10.0.0.0/16 — Local     0.0.0.0/0  —  Internet Gateway “Internal-only” (ie, Protected and Private)     10.0.0.0/16 — Local

创建这两个路由表，把它们应用到每个AZ中正确的子网，然后就大功告成了！

如果团队中有人担心空间不足，就给他看这个表：

   16-bit: 65534 addresses    18-bit: 16382 addresses     19-bit: 8190 addresses     20-bit: 4094 addresses

很显然， Web 服务器不需要用4000个IP地址。这还不是问题的关键，关键是此VPC只有那些路由需求。没有理由在同一个AZ内部，没有子网有不同的路由需要时，再创建新的子网。

结论

适当地应用本文建议的规划方法，就可以确保不会由于起始的决定，在实施时捆住了手脚。这里谈到的一切 - 安全组，自动伸缩，弹性负载均衡，亚马逊关系数据库服务，AWS直接连接，甚至更多——这些都可以套用在该模式中。（文 / Nathan McCourtney：任职于亚马逊网络服务公司AWS，曾担任高级咨询师，现为软件开发工程师。

原文链接 ：https://medium.com/aws-activate-startup-blog/practical-vpc-design-8412e1a18dcc

如您需要了解AWS最新资讯或是技术文档可访问 AWS中文技术社区 ；如您有更多的疑问请在 AWS技术论坛 提出，稍后会有专家进行答疑。

订阅“AWS中文技术社区”微信公众号，实时掌握AWS技术及产品消息！

AWS中文技术社区为广大开发者提供了一个Amazon Web Service技术交流平台 ，推送AWS最新资讯、技术视频、技术文档、精彩技术博文等相关精彩内容，更有AWS社区专家与您直接沟通交流！快加入AWS中文技术社区，更快更好的了解AWS云计算技术。

（翻译/彭根禄责编/王玉平）

正文到此结束