亚马逊云科技基础网络架构从单账号到多账号体系的迁移实践

背景：

着陆区（Landing Zone）是亚马逊云科技通过以结果为导向的工作方法提出的一种解决方案，该解决方案基于亚马逊云科技的最佳实践、旨在为上云用户准备一套可配置、安全合规、易于扩展的云上基础环境，非常适合用户做为新系统开发和应用迁移的初始化环境。

着陆区提出了多账户治理概念及相应的多账户架构，在多账号架构下进行资源部署，可获得诸如有效缩小爆炸半径、避免争夺共享资源以及支持具体资源消费情况和详细账单等众多好处，正因如此，越来越多的用户正在或准备着手使用着陆区解决方案来构建他们在亚马逊云科技云上的业务平台，但是，其中也有部分客户，由于上云时间较早，存在其绝大部分业务都集中部署在单一账号内的情况，他们希望将部署在单账户中的业务平滑的迁移至着陆区解决方案中推荐的多账户架构下。为实现此类业务迁移需求，需要提前在多账户架构下为待迁移业务搭建好相关的基础网络架构，以实现对待迁移业务的承载并提供业务需求的联网能力。

根据着陆区解决方案多账户设计最佳实践，用户待迁移业务需根据（包含但不限于）：1）业务的安全合规需求、2）业务应用所处软件开发生命周期的具体阶段（例如生产/开发/测试）、3）业务系统提供的具体服务内容、4）业务系统面向的客户群体（内部或外部） 等不同因素综合考量后划分到不同的业务账号下；由单独的网络账户统筹规划网络架构及相关组件的部署、维护，以满足分布在不同业务账号下的业务间及与亚马逊云科技云外网络的通讯需求，以实现基于全局视角的网络资源部署、路由规划，实现网络架构相关组件的成本最优化、对业务流量实行精准、灵活控制的能力，同时也可以让业务账号管理者更聚焦于业务本身。

本文将以客户从单账号环境到多账号环境的业务迁移需求为背景，结合一个案例为大家介绍，如何在多账户环境下为业务迁移准备基础网络架构，以尽可能减少迁移对业务造成的影响；同时也会分享如何通过自动化手段加速多账户环境下基础网络架构的创建。

如何为业务迁移准备基础架构？

本文中所提及的为业务迁移提前准备的“基础网络架构”包括：

• 多账号体系下各业务账号下的VPC: 准备的过程是对当前单账户环境中待迁移业务的网络载体-VPC（含其内部组件，如：子网、路由表、互联网网关、NAT网关、安全组、NACL等）的配置进行梳理，基于梳理好配置在对应迁移到的业务账号下（Workload Account）下提前创建好对应的VPC，这些VPC未来将用于承载迁移后的业务。
• 多账号体系下网络账号下的组网能力：准备的过程是以待迁移的业务为核心，在当前的单账户环境下梳理与业务相关的网络间通信需求，基于梳理好的结果在网络账号（Network Account）下提前创建好可在多账号体系下提供相应联网能力的网络架构。

当基础网络架构准备好后，当前但账号环境下的各个业务将被迁移到对应业务账号下预先创建的VPC中；被迁移的业务间则通过网络账号下的网络设施实现彼此间的通信。

基础网络架构的准备可大致分为“基础架构规划设计”、“原架构信息采集”、“新基础架构创建”和“连通性测试”等4个阶段，下面将依次介绍各阶段涉及的主要工作内容：

1、基础架构规划设计：

基础架构规划设计阶段的核心任务是结合实际业务迁移需求分析、确认如下问题，并据此完成基础架构设计：

• 分析、确定现有单账号环境中哪些业务需要被迁移？它们目前被部署在哪个VPC中？ 以及这些应用未来准备将被迁移到多账号体系中的哪些业务账号下？相关分析结果和结论可以帮助确定需要申请的新的业务账号？需要提前在这些业务账号下创建哪些VPC用于承载迁移后的业务应用?
• 同时还需要梳理这些将迁移的业务应用的网络通讯需要，它们需要和什么网络保持通讯（包含亚马逊云科技云内VPC网络以及亚马逊云科技云云外网络），这些网络是通过何种方案连接在一起（VPC Peering/Transit VPC/Transit Gateway），亚马逊云科技云云外网络通过何种方式连接到亚马逊云科技云（DX-VGW/DX-DXGW-Transit Gateway/VPN/SDWAN）等？

另外，当用户面临迁移场景时最关注的问题之一是迁移本身将对业务造成什么样的影响？例如：由迁移造成的业务宕机时间？迁移后是否需要对业务系统的配置、业务自身的代码进行修改、什么样的修改等？ 站在用户角度，他们希望最小化一切对业务的影响，为实现这个目标，用户在做迁移方案设计时也需要结合他们自身的实际情况，用户可以参考如下因素（场景）：

• 原则上，新基础架构应在一套全新的账号下创建，这样做的好处是新建的基础架构完全与原账号下环境隔离，在新基础架构下做的任何操作、测试均不会影响到原账号下的业务；但此处要特别注意的是，当需要线下站点与新建基础架构间进行测试、业务迁移前的演练时，建议单独为此目的准备相应的线下测试环境，以避免使用现有线下架构测试，对生产业务造成影响。
• 当存在如下情况时，用户可以考虑在创建新基础架构时复用原账号下的部分架构，以避免后期迁移环节对业务造成过大的影响：
  • 原账号下存在特定的业务应用，如将其迁移至新的业务账号下整体迁移成本高、存在数据丢失、损坏等风险，这种情况下，可考虑将该业务保留在原账号下，待到原账号下的其他业务迁出后，原账号作为专门承载该业务的业务账号纳入多账号体系。
  • 用户想尽可能减少迁移过程中对网络架构的调整，避免由于网络架构变化引发的对线下线路、线下设备的配置调整，这种场景下用户可考虑将原账号下的业务迁出，将原账号作为多账号体系中的网络账号，适当配置后为其他业务账号下业务提供网络连通能力。
• 如前文所述，创建基础架构时，需要在业务账号下创建VPC及内部资源作为迁移业务的载体，相关VPC资源的创建建议采取“镜像”方式，即严格参照原账号下VPC的配置进行对应业务账号下的VPC资源创建，推荐这么做的理由是：既然业务迁移前，原账户下的VPC可以支撑业务的正常运行，那当相同业务被迁移到新业务账户下的VPC中时，也应该可以被天然的支持，而不需要对业务配置及相关代码本身做任何的调整。

2、原基础架构信息采集：

原基础架构信息采集阶段的主要任务是根据上阶段输出的规划设计方案，对原账号环境下对欲迁移应用进行承载的VPC及其组件详细配置进行收集、以及对原账号下组网架构信息进行收集；同时要了解、记录各业务间、各网络间的详细通讯需求，具体采集信息可参考：

VPC相关信息采集（包括但不限于）：

• VPC选项、DHCP-Option，SG，NACL等；
• VPC中存在哪些子网及详细配置；
• VPC关联或部署的各种网关的情况；
• 路由表详细配置、路由表和子网的关联关系等；
• 各路由表中的路由条目；
• VPC内其他组件或服务配置细节

组网架构相关信息采集（包括但不限于）：

• 了解当前单账号环境下采用的组网方式（Transit Gateway/Transit VPC/VPC Peering）；
• 如当前仍采用VPC Peering方式进行组网，收集相关细节；并建议在新架构中改为以中转网关为核心的组网；
• 如当前采用Transit VPC方案进行组网，收集相关细节，并建议在新架构中改为以中转网关为核心的组网；
• 如已采用中转网关为核心组网方式，了解哪些网络连接至中转网关（包含亚马逊云科技云内部VPC、通过DX专线、VPC、SDWAN等方式连接的亚马逊云科技云外部网络）；这些网络与中转网关的挂载类型（Attachment），对于VPC类型的中转网关挂载，还应关注中转网关具体连接到该VPC的哪些可用区的哪些子网，对于Connect类型的网络需进一步关注对应的Connect Peers信息；中转网关中创建了哪些中转网关路由表，路由表分别关联和宣告了哪些挂载网络？ 路由表中各种静态创建或动态创建的路由条目状态、以及PLR相关的配置

需要注意，本阶段的主要任务就是尽量收集原账号环境下的详细配置信息，尤其当用户决定采用 “镜像”的方式创建新的基础环境时；但这意味着如果通过人工方式进行相关信息的收集可能会消耗较多时间，用户可以考虑使用亚马逊云科技云提供的丰富的API资源、结合SDK编写自动化工具，借助自动化的手段进一步提升信息收集的效率和准确性。

3、新基础架构创建：

新基础架构创建阶段主要任务是基于设计阶段中确定的“待迁移业务-业务账号”的对应关系，以及在原基础架构信息采集阶段获取的承载业务的VPC的详细配置信息，在对应业务账号中进行VPC的创建；基于原基础架构信息采集阶段获取的原账号下的网络架构信息，在网络账号下创建资源并实现组网能力，建议新基础架构中的组网方案统一修改为以中转网关为核心的组网。

需要注意的是，为了加快新基础架构的资源创建速度，同时通过人为操作方式引发错误配置等情况，用户同样可以考虑尝试亚马逊云科技云广泛支持的API, 通过自动化编程或IAC方式快速创建基础架构。

4、连通性测试：

本阶段主要任务是根据业务迁移后的通信需求，在多账户架构下进行连通性测试，（包括VPC间、VPC与亚马逊云科技云云外的网络）。

结合案例的说明：

本文将结合一个案例讲解在上文中建议的4个阶段中应执行的具体工作：

案例背景介绍：

在本案例中某客户将在亚马逊云科技云中的所有业务均部署在单一账号（ Acocunt_ID尾号778 ）中，绝大部分资源部署在us-west-2区域，少量部署在us-west-1区域；连网以中转网关为核心组件实现本区域内、区域间的VPC间通信、以及VPC与亚马逊云科技云外网络间的通信，具体细节如下：

• 客户在us-west-2区域中部署了2个业务VPC（vpc-app-1、vpc-app-2）在us-west-1区域中部署1个业务VPC(vpc-app-3) 分别用于承载不同业务，vpc间的流量通过中转网关中转，由于vpc-app-3分布于与vpc-app-1/vpc-app-2不同的区域,为实现它们间跨区域通信，客户在us-west-1/ us-west-2两区域均部署了中转网关，并通过中转网关对等（ Peering）方式进行互联；
• 云内VPC与亚马逊云科技云外网络通信由中转网关中转，客户线下数据中心通过DX专线（DXGW）与中转网关互联；客户总部及绝大多数分支站点通过部署在本地的CPE设备与云端部署的SDWAN-Edge互联（部署在vpc-transport内），SDWAN-Edge通过Connect挂载类型（BGP Over GRE）与中转网关连接并动态交互路由；少数站点通过IPsec  VPN的方式连接中转网关（该方式中国区暂不支持）；

1、基础架构规划设计（结合案例）：

本案例中业务迁移计划：客户准备将原账号（778尾号）us-west-2下的业务app1/app2分别迁出到新的业务账号的us-west-2区域（尾号为869和048），业务迁移后，各业务网络连通需要保持不变；为了减少迁移准备阶段对客户业务的影响，本案例采取在新的多账号体系中准备基础架构环境；原账号us-west-1区域下的所有业务VPC迁出到新的业务账号下、连网功能迁出到新的网络账号：

• 结合业务迁移需求，分别在尾号869和048在业务账号的us-west-2区域新建VPC,VPC新建将通过“镜像”原账号下对应VPC配置的方式，以尽可能的减少业务迁移后对业务系统配置及业务代码的更改需求；
• 参照原账号（778尾号）us-west-2下中转网关配置，在新的网络账号下（尾号674）us-west-2下创建中转网关并支持原账号下的所有组网能力;

2、原基础架构信息采集（结合案例）：

本环节主要根据上一阶段的设计产出，收集承载业务VPC详细配置信息、以及中转网关为核心的组网细节信息，以为下一阶段架构资源的创建提供准确、完整的输入，由于本案例中客户决定采用“镜像”的方式进行新架构资源的创建，即需要完全参照原账号下VPC配置或及中转网关配置进行对应新架构资源的创建，如采集阶段对原账号下的VPC或中转网关等组件的配置细节采集不够完整，则“镜像”出的VPC或中转网关则可能无法预期“无缝”的支持迁移后的业务应用，所以用户需认真梳理对所有相关组件需采集的信息细节； 另外，整个采集过程如通过手工方式完成，工作量较大、还可能产生人为错误，建议用户尝试利用亚马逊云科技云开放的API结合自动化手段完成对信息的采集。

3、 新基础架构创建（结合案例）：

基于 “业务VPC-业务账号”的对应关系及在信息收集阶段获取的原账号下VPC及其内组件的配置信息，在对应的业务账号中“镜像”创建VPC；基于信息收集获取的原账号下的中转网关及相关组件的细节详细信息，在网络账号下“镜像”创建中转网关为核心的组网架构，需要注意的是为了加快新网络基础架构的创建进度，同时避免配置过程中由人为操作引发的错误配置等情况，建议用户尝试利用亚马逊云科技云开放的API,通过自动化编程或基础架构即代码IAC方式快速创建架构。

关于在业务账号下“镜像”创建VPC的详细过程由于篇幅原因略去；接下来重点介绍在网络账号下创建中转网关组网架构的流程：

（1）在网络账号下的us-west-2区域创建新的中转网关，中转网关属性配置可参照上一阶段获取的信息。

（2）将网络账号下新建中转网关通过RAM（Resource Access Manager）分享给业务账号（尾号869/048）。

（3）切换至业务账号（尾号869/048），确认可发现由网络账号共享的中转网关。

（4）在业务账号下（尾号869/048），分别为新创建的VPC创建VPC类型的中转网关挂载（Attachment）,具体配置参照上一阶段获取信息，完成相关VPC类型中转网关挂载的创建后，回到网络账户下确认可发现业务账号下新创建的VPC类型中转网关挂载，并选择接受。

（5）接下来，在网络账号下继续为中转网关创建其他类型的中转网关挂载,具体配置参照原账号下对应中转网关挂载配置。

（6）在网络账号下在中转网关创建中转网关路由表并配置相关细节，包括：关联（Associations）/传播

（Propagations）/前缀列表引用（PLR）/静态路由，具体配置参照原账号下对应组件配置。

（7）对于网络账号中vpc-transport下新部署的SDWAN Edge，可复用原账号下SDWAN Edge的配置，仅需保证Edge用于与中转网关建立GRE连接的地址与中转网关配置一致。

4、连通性测试（结合案例）：

由于整个基础网络架构创建过程并未对原账号进行任何配置修改，原则上新建基础网络架构上进行连通性测试不会影响客户在原账号下的业务。客户可直接在新建架构上对云上VPC 间的连通性进行测试，如需结合线下站点进行连通性测试，请为线下站点单独搭建测试环境或为原账号下业务申请宕机窗口后对线下设备配置进行修改，以避免因测试对原账号下业务产生潜在负面影响！

测试预期为：

• vpc-app-1/vpc-app-2: 不通；
• vpc-app-1/vpc-app-2与vpc-app-3: 通；
• vpc-app-1/vpc-app-2与远程VPN站点：通；
• vpc-app-1/vpc-app-2与SDWAN：通；

在业务账号（尾号869/048）对应的vpc（vpc-app-1/vpc-app-2）中部署ec2,通过ping程序测试到其他账号下VPC的连通性，测试与远程VPN网络、SDWAN网络的连通性，测试结果符合预期，细节请参考以下截图：

通过自动化工具实现基础架构环境的快速搭建：

本文前面提及，为了最大化减少为业务迁移需求搭建多账户架构下基础环境的时间，有效避免在对原架构中组件配置信息采集时产生遗漏以及在基础架构资源创建时由人为配置方式引发错误等问题，结合迁移过程中可能存在的其他需求，建议用户充分利用亚马逊云科技云提供的丰富的API、SDK、CDK或其他工具结合自己的实际需求开发自动化的迁移工具。

下图为针对本博文中提及的基础网络架构搭建需求开发的自动化工具流程图，供读者参考。

通过手工方式完成新的网络基础架构创建是个因人而异的过程，据评估，在技术人员熟悉相关工作涉及的亚马逊云科技云产品组件工作原理及相关配置的前提下，完成文中案例涉及的整套基础网络架构搭建及测通，整体耗时1～2天，但通过自动化工具实现整个过程仅需10～20分钟，且部署后可一次性通过连通性测试。

总结：

本文通过结合案例，介绍了当用户希望将其单账号下部署的业务应用迁移到多账号架构下时，应如何在多账号架构下为业务的平滑迁移提前准备好相应的基础架构环境；同时，本文介绍并展示了通过自动化手段如何快速的完成相关基础环境的搭建，从而有效的加快业务迁移进程。

本篇作者