本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
示例汽车公司用例
白皮书的这一部分展示了如何使用注意事项、需求定义问题和决策树来帮助您决定最佳混合网络设计。识别和获取需求非常重要，因为它们被用作决策树的输入。预先获取需求可以避免进一步的设计迭代。如果必须重新审查设计，项目就会完全停止，宝贵的资源就会被搁置，而如果能事先了解需求，就能最大限度地减少这种情况的发生，最理想的情况是避免这种情况的发生。
这一部分将以示例汽车公司作为客户示例。他们希望在 AWS 上初步部署第一个分析项目。分析项目侧重于分析来自公司制造的汽车的数据以及公司数据中心中已有的其他数据集。最初，公司的架构小组认为他们需要一个 AWS 账户、一个 Amazon VPC 和几个子网来托管生产和开发环境。项目团队渴望开始工作，他们要求尽快获得访问开发环境的权限。他们的目标是在三个月后投入生产。
示例汽车公司还计划将其 AWS 用于其他几个项目，例如，在未来 6 个月内将其 ERP 系统、虚拟桌面基础设施 (VDI) 和另外 20 个应用程序从本地迁移到 AWS。其他项目的一些要求仍在确定中，但很明显，它们的 AWS Cloud 使用量会增加。
架构团队决定采用本白皮书中概述的方法。他们使用每项考虑事项下概述的需求定义问题来获取输入信息，从而做出设计决策。
它们从与连接类型相关的要求开始，下表对此进行了总结。
表 4——示例汽车公司可靠性输入
| 连接类型选择注意事项 | 需求定义问题 | 回答 |
|---|---|---|
| 部署时间 | 部署所需的时间轴是什么？ 几小时、几天、几周还是几个月？ |
|
| 安全性 | 您的安全要求和政策是否允许通过互联网使用加密连接来连接 AWS，还是强制使用专用网络连接？ |
|
| 利用专用网络连接时，网络层是否必须提供传输中加密？ | 否，将使用应用层加密。 | |
| SLA | 是否需要包含服务积分的混合连接 SLA？ |
|
| 正常运行时间目标是什么？ |
|
|
| 整个混合网络是否遵守正常运行时间目标？ |
|
|
| 性能 | 所需的吞吐量是多少？ |
|
| AWS与本地网络之间可接受的最大延迟时间是多少？ |
|
|
| 可接受的最大网络抖动是多少？ |
|
|
| 成本 | 您每月要向 AWS 发送多少数据？ |
|
| 您每月要从 AWS 发送多少数据？ |
|
|
| 这种连接是永久性的吗？ | 是 |
根据收到的需求，架构团队遵循了图 9 中的连接类型决策树。这使架构团队能够决定开发、测试和生产环境的连接类型。对于生产环境，他们考虑了当前和未来的需求。对于开发和测试，示例汽车公司将通过互联网建立 Site-to-site VPN。在生产方面，他们将与服务提供商合作，将其公司网络与 AWS Direct Connect 连接起来。示例汽车公司最初考虑使用 Direct Connect 托管连接，但由于需要AWS 提供 SLA
确定连接类型后，下一步就是获取影响连接设计选择的需求。这与逻辑设计有关，例如如何配置连接以及使用哪些 AWS 服务来支持业务和技术需求。
为获取可扩展性和通信模型需求，架构团队使用了本白皮书相关部分中的需求定义问题。下表概述了与这两个注意事项相关的需求。
表 5——需求定义问题
| 连接设计选择注意事项 | 需求定义问题 | 回答 |
|---|---|---|
| 可扩展性 | 当前或预计需要连接到一个或多个本地站点的 VPC 数量是多少？ | 最初 2 个，6 个月后增至 30 个 |
| 这些 VPC 是部署在单个 AWS 区域 还是多个区域？ | 单个区域 | |
| 需要将多少个本地站点连接到 AWS？ | 2 个数据中心 | |
| 每个站点有多少客户网关设备需要连接到 AWS？ | 每个数据中心 2 台路由器 | |
| 预计将向 AWS VPC 通告多少条路由，以及预计从 AWS 端收到多少条路由？ |
|
|
| 是否有计划考虑在不久的将来增加与 AWS 连接的带宽？ |
|
|
| 连接设计模型 | 是否需要启用 VPC 间通信（区域内和/或跨区域）？ | 是，在 AWS 区域 内 |
| 是否需要直接从本地访问 AWS 公共端点服务？ | 是 | |
| 是否需要从本地使用 VPC 端点访问 AWS 服务？ | 否 |
根据输入，架构团队遵循了连接设计部分的决策树。由于预计未来 6 个月内 VPC 数量将从 2 个增加到 30 个，架构团队决定使用 AWS Transit Gateway 作为连接的终端网关和 VPC 之间的路由。独立 AWS Transit Gateway 将终止用于开发和测试的 VPN 连接，以及与 AWS Direct Connect 的生产连接。使用分离的 AWS Transit Gateway 可以简化变更管理，明确划分开发/测试环境和生产环境。由于 AWS Transit Gateway，生产需要 AWS Direct Connect 网关。公有 VIF 将用于访问 AWS 公共端点服务。图 14 说明了根据收集到的需求在决策树上采取的路径。
图 14——示例汽车公司连接设计决策树
在确定满足可扩展性和通信模型需求的解决方案后，下一步就是获取与可靠性相关的要求。这与所需的可用性和弹性水平有关。
为获取可靠性需求，架构团队使用了本白皮书相关部分中的需求定义问题。下表总结了需求。
表 6——可靠性需求问题
| 连接设计选择注意事项 | 需求定义问题 | 回答 |
|---|---|---|
| 可靠性 | 如果 AWS 出现连接故障，对业务的影响有多大？ |
|
| 从业务角度来看，AWS 出现连接故障后的成本是否高于为 AWS 部署高可靠性连接模式的成本？ |
|
根据所收到的意见，架构团队遵循了本白皮书前面所介绍的可靠性注意事项部分中的决策树。考虑到生产连接的正常运行时间目标为 99.99%，以及服务中断对业务的严重影响，架构团队决定使用 2 个 Direct Connect 位置，并从每个本地数据中心到每个 Direct Connect 位置设置 2 个链接（共 4 个链接）。用于开发和测试的 VPN 连接还将使用两个 VPN 连接来增加冗余。使用可靠性部分中讨论的路由工程技术，将按以下方式配置连接：
-
在开发和测试过程中，将使用 ECMP 通过 2 条隧道对通往主数据中心的流量进行负载平衡。这样可以提高吞吐量。如果主隧道发生故障，将使用通往备用数据中心的隧道。
-
在生产方面，本地与 AWS 之间通过任一 Direct Connect 位置的延迟非常相似。在这种情况下，对于部署在主数据中心的本地系统，决定通过两个连接到主数据中心的 AWS 和本地之间的流量进行负载平衡。同样，对于在备用数据中心运行的本地系统，流量将在备用数据中心的两个连接之间的流量进行负载平衡。如果连接失败，BGP 将自动进行失效转移。
图 15 说明了根据收集到的需求在决策树上采取的路径。
图 15——示例汽车公司可靠性决策树
