本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 按优先顺序排列的应用程序评估
前一阶段，即[产品组合发现和初步规划](portfolio-discovery-initial-planning.md)，其关键结果之一是[确定一部分应用程序的优先顺序](prioritization-and-migration-strategy.md#prioritizing-applications)以进行详细评估。本节探讨对应用程序的详细评估。
尽早查看一些应用程序的详细信息将推动加速。评估和未来的架构设计过程揭示了潜在的障碍，并阐明了更大规模迁移之前的重要任务。这些任务包括收集要求以建立 AWS 基础（例如着陆区） AWS，或者扩展和验证现有着陆区。这次评估也是考虑迁移步骤和策略的时候。
该阶段的主要结果如下：
+ 经过验证的优先级应用程序列表
+ 记录在案的当前状态架构
+ 记录了迁移候选者的初始目标架构和迁移策略
+ 确定的迁移模式和工具
+ 记录在案的平台要求（安全、 AWS 基础架构和运营）
+ 记录在案的迁移规划的切换注意事项
+ 估计 AWS 运行速率
# 了解详细的评估数据要求
下表描述了获取迁移中应用程序及其相关基础架构的完整产品组合视图所需的信息。
这些表使用以下缩写：
+ R，表示必填项
+ O，表示可选
+ 不适用，因为不适用
**应用程序**
| **属性名称** | **描述** | **发现、设计和迁移策略** | **估计运行速率** | **建议的保真度级别（最低）** |
| --- |--- |--- |--- |--- |
| 唯一标识符 | 例如，应用程序 ID。通常可在现有 CMDBs 或其他内部库存和控制系统上使用。 IDs 如果您的组织中未定义这些内容，请考虑创建唯一值。 | R | O | 高 |
| 应用程序名称 | 您的组织知道此应用程序的名称。如果适用，请包括商业 off-the-shelf (COTS) 供应商和产品名称。 | R | R | 高 |
| 是 COTS 吗？ | 是或否。 无论是商业应用程序还是内部开发 | R | R | 高 |
| COTS 产品和版本 | 商用软件产品名称和版本 | R | R | 高 |
| 说明 | 主要应用程序功能和上下文 | R | O | 高 |
| 严重性 | 例如，战略性或创收应用程序，或支持关键功能 | R | O | 高 |
| Type | 例如，数据库、客户关系管理 (CRM)、Web 应用程序、多媒体、IT 共享服务 | R | O | 高 |
| 环境 | 例如，生产、预制版、开发、测试、沙箱 | R | R | 高 |
| 合规与监管 | 适用于工作负载（例如 HIPAA、SOX、PCI-DSS、ISO、SOC、FedRAMP）和监管要求的框架 | R | O | 高 |
| 依赖项 | 内部和外部应用程序或服务的上游和下游依赖关系 | R | 不适用 | 高 |
| 基础设施映射 | 映射到构成应用程序的物理 and/or 虚拟资产 | R | R | 高 |
| 许可证 | 商用软件许可证类型（例如，微软 SQL Server Enterprise） | R | R | 高 |
| 成本 | 软件许可、软件操作和维护成本 | 不适用 | R | 中高 |
| 业务部门 | 例如，营销、财务、销售 | R | O | 高 |
| 所有者详情 | 应用程序所有者的联系信息 | R | O | 高 |
| 架构类型 | 例如，Web 应用程序、2 层、3 层、微服务、面向服务的架构 (SOA) | R | R | 高 |
| 恢复点目标 (RPO)、恢复时间目标 (RTO) 和 /服务级别协议 (SLA) | 当前的服务管理属性 | R | R | 高 |
| 创收应用程序还是业务战略应用程序？ | 是的，如果申请直接或间接影响公司收入或被企业视为具有战略意义。 | R | O | 中高 |
| 用户数（并发） | 例如，内部或外部用户或内部 and/or 外部用户/客户 | R | R | 中高 |
| 用户位置 | 用户会话的起源 | R | R | 中高 |
| 风险和问题 | 已知风险和问题 | R | O | 中高 |
| 迁移注意事项 | 任何可能与迁移相关的其他信息 | R | R | 中高 |
| 迁移策略 | 例如，迁移的 AWS 6 R 之一 | R | R | 中高 |
| 数据库详情 | 例如，分区、加密、复制、扩展、安全套接字层 (SSL) 支持 | R | R | 高 |
| Support 团队 | 例如，应用程序运营团队名称 | R | O | 中高 |
| 监控解决方案 | 用于监视此应用程序的产品 | R | O | 中高 |
| Backup 要求 | 中所需的备份时间表 AWS | R | R | 中高 |
| 灾难恢复信息 | 例如，此应用程序的灾难恢复组件 | R | R | 中高 |
| 目标 AWS 要求 | 例如，组件、账户设置、网络、安全 | R | R | 高 |
**基础设施**
| | | | | |
| --- |--- |--- |--- |--- |
| **属性名称** | **描述** | **发现、设计和迁移策略** | **估计运行速率** | **建议的保真度级别（最低）** |
| 唯一标识符 | 例如，服务器 ID。通常可在现有 CMDBs 或其他内部库存和控制系统上使用。 IDs如果您的组织中未定义这些内容，请考虑创建唯一值。 | R | O | 高 |
| 网络名称 | 网络中的资产名称（例如，主机名） | R | O | 高 |
| DNS 名称（完全限定域名或 FQDN） | DNS 名称 | O | O | 中高 |
| IP 地址和网络掩码 | 内部 and/or 公有 IP 地址 | R | R | 高 |
| Asset type | 例如，物理或虚拟服务器、虚拟机管理程序、容器、设备、数据库实例 | R | R | 高 |
| Product name | 商业供应商和产品名称（例如， VMware ESXiIBM Power Systems、Exadata） | R | R | 高 |
| 操作系统 | 例如，REHL 8、Windows Server 2019、AIX 6.1 | R | R | 高 |
| 配置 | 分配的 CPU、内核数、每个内核的线程数、总内存、存储空间、网卡 | R | R | 高 |
| 利用率 | CPU、内存和存储峰值和平均值。数据库实例吞吐量。 | R | R | 高 |
| 许可证 | 商品许可证类型（例如，RHEL 标准） | R | R | 高 |
| 是共享基础架构吗？ | “是” 或 “否” 表示提供共享服务的基础架构服务，例如身份验证提供商、监控系统、备份服务和类似服务 | R | O | 高 |
| 应用程序映射 | 在此基础架构中运行的应用程序或应用程序组件 | R | O | 高 |
| 通信数据 | 例如，在进程级别，服务器到服务器 | R | 不适用 | 中高 |
| 目标 AWS 要求 | 例如，实例类型、账户、子网、安全组、路由 | R | R | 高 |
| 迁移策略、模式和工具 | 例如，迁移的 6 R 之一、特定的技术模式、迁移工具 | R | O | 高 |
| 风险和问题 | 已知风险和问题 | R | O | 中高 |
# 详细的应用程序评估
详细的应用程序评估的目标是全面了解目标应用程序及其相关基础架构（计算、存储和网络）。高保真数据是避免陷阱所必需的。例如，组织通常会假设他们完全了解该应用程序。这是很自然的，在许多情况下也是如此。但是，为了最大限度地降低业务风险，必须通过尽可能多地获取计划数据来验证机构知识和静态文档。这将完成发现过程的繁重工作。您可以专注于来自其他来源的数据元素，例如特定于业务的信息、战略路线图等。
关键是要避免在迁移期间和迁移之后进行最后一刻的更改。例如，在迁移时，重要的是要避免基于未识别的依赖关系进行更改，因为这些更改可能需要将服务器纳入正在进行的迁移浪潮中。迁移后不久，重要的是要避免根据相关的平台要求进行更改，以允许流量或部署其他服务。这类计划外更改会增加出现安全和操作问题的风险。我们强烈建议在执行详细的应用程序评估时使用编程发现工具来验证流量模式和依赖关系。
在评估开始时，您必须确定应用程序的利益相关者。这些通常是以下内容：
+ 业务部门负责人
+ 应用程序所有者
+ 建筑师
+ 运营和支持
+ 云支持团队
+ 特定平台团队，例如计算、存储和网络
详细发现有两种方法。自上而下的发现从应用程序开始，甚至从用户开始，一直延伸到基础架构。当应用程序的标识很清楚时，推荐使用这种方法。相反，自下而上的发现从基础架构开始，一直延伸到应用程序或服务及其用户。当迁移计划由基础设施团队推动且 application-to-infrastructure映射不清楚时，这种方法非常有用。通常，您可能会将两者结合使用。
要深入研究应用程序，现有的架构图是一个不错的开端。如果这些都不可用，请根据当前知识创建一个。不要低估这项任务的重要性，即使对于简单的重新托管或搬迁迁移策略也是如此。绘制架构图可以帮助您识别低效问题，在云端进行细微更改即可快速解决这些问题。
根据您执行的是自上而下还是自下而上的方法，初始图表将绘制应用程序组件和服务或基础设施组件（例如服务器和负载均衡器）。识别出主要组件和接口后，使用发现工具和应用程序性能监控工具中的编程数据对其进行验证。这些工具必须支持依赖关系分析并提供组件之间的通信信息。必须标识构成此应用程序的每个组件。接下来，记录与其他应用程序和服务（包括内部和外部）的依赖关系。
由于缺乏用于验证依赖关系和映射的工具，因此需要手动方法。例如，您可以登录基础架构组件并运行脚本来收集通信信息，例如打开的端口和已建立的连接。同样，您可以识别正在运行的进程和已安装的软件。不要低估手动发现所需的精力。编程工具可以在几天内捕获并报告大多数依赖关系，但间隔较长（通常是很小的百分比）的依赖关系除外。手动发现可能需要数周时间才能收集和合并所有数据点，而且仍然很容易出现错误和数据丢失。
继续获取[数据要求](understanding-detailed-assessment-data-requirements.md)部分中为每个优先级应用程序和映射的基础架构指定的信息。接下来，使用以下问卷指导您完成详细的评估过程。与已确定的利益相关者会面，讨论这些问题的答案。
## General
+ 此应用程序的临界程度是多少？ 它能创造收入吗？ 它是业务战略应用程序还是支持业务应用程序？ 它是其他系统共享的核心基础设施服务吗？
+ 此应用程序是否有正在进行的改造项目？
+ 这是面向内部还是面向外部的应用程序？
## 架构
+ 当前的架构类型是什么（例如 SOA、微服务、整体架构）？ 架构有多少层？ 它是紧耦合还是松耦合？
+ 有哪些组件（例如，计算、数据库、远程存储、负载均衡器、缓存服务）？
+ 什么是 APIs？ 描述这些内容，包括 API 名称 URLs、操作、端口和协议。
+ 组件之间以及组件与其他应用程序或服务之间允许的最大延迟是多少？
## 操作
+ 此应用程序在哪些位置运行？
+ 谁在运营应用程序和基础架构？ 这些是由内部团队还是 AWS 合作伙伴团队运营？
+ 如果此应用程序出现故障，会发生什么？ 谁受到影响？ 什么是影响？
+ 用户或客户在哪里？ 他们如何访问应用程序？ 并发用户数量是多少？
+ 上一次技术更新是什么时候？ 将来会安排更新吗？ 如果是，什么时候？
+ 此应用程序有哪些已知风险和问题？ 中断、中等严重程度和高严重性事件的历史如何？
+ 使用周期是多少（以工作时间为单位）？ 运营时区是什么？
+ 变更冻结期是多少？
+ 使用什么解决方案来监视此应用程序？
## 性能
+ 收集的绩效信息显示了什么？ 使用量是尖峰还是恒定且可预测？ 可用性能数据的时间范围、间隔和日期是多少？
+ 是否有此应用程序的一部分或与之交互的定时批处理作业？
## 软件生命周期
+ 当前的变化率是多少（每周、每月、每季度或每年）？
+ 什么是开发生命周期（例如，测试、开发、QA、UAT、预生产、生产）？
+ 应用程序和基础架构的部署方法有哪些？
+ 什么是部署工具？
+ 此应用程序或基础架构是否使用持续集成 (CI) /持续交付 (CD)？ 自动化水平是多少？ 手动任务有哪些？
+ 应用程序和基础设施的许可要求是什么？
+ 什么是服务级别协议 (SLA)？
+ 目前的测试机制是什么？ 测试阶段是什么？
## 迁移
+ 迁移注意事项有哪些？
此时，请注意迁移此应用程序时的所有注意事项。要获得更完整、更准确的评估，请从不同的利益相关者那里获得这个问题的答案。然后对比他们的知识和观点。
## 弹性
+ 当前的备份方法是什么？ 哪些产品用于备份？ 备份时间表是什么？ 什么是备份保留政策？
+ 当前的恢复点目标 (RPO) 和恢复时间目标 (RTO) 是什么？
+ 此应用程序是否有灾难恢复 (DR) 计划？ 如果是，灾难恢复解决方案是什么？
+ 上一次灾难恢复测试是什么时候？
## 安全与合规
+ 适用于此应用程序的合规和监管框架有哪些？ 上次和下次审计日期是什么时候？
+ 此应用程序是否托管敏感数据？ 什么是数据分类？
+ 数据是在传输中加密还是静态加密，还是两者兼而有之？ 加密机制是什么？
+ 此应用程序是否使用 SSL 证书？ 什么是签发机构？
+ 用户、组件以及其他应用程序和服务的身份验证方法是什么？
## 数据库
+ 此应用程序使用什么数据库？
+ 数据库的典型并发连接数是多少？ 最小连接数和最大连接数是多少？
+ 连接方法是什么（例如，JDBC、ODBC）？
+ 连接字符串是否记录在案？ 如果是，在哪里？
+ 数据库架构有哪些？
+ 数据库是否使用自定义数据类型？
## 依赖项
+ 组件之间的依赖关系是什么？ 请注意任何无法解决且需要将组件一起迁移的依赖关系。
+ 组件是否在不同位置拆分？ 这些位置（例如，广域网、VPN）之间的连接如何？
+ 此应用程序与其他应用程序或服务有哪些依赖关系？
+ 操作依赖关系是什么？ 例如，维护和发布周期，例如修补窗口。
# AWS 应用程序设计和迁移策略
设计和记录应用程序的未来状态是成功迁移的关键因素。我们建议为任何类型的迁移策略创建设计，无论多么简单或复杂。创建设计将揭示潜在的障碍、依赖关系和优化应用程序的机会，即使在架构预计不会发生变化的情况下也是如此。
我们还建议从迁移策略的角度来看待应用程序 AWS 的未来状态。在此阶段，请务必定义迁移后应用程序 AWS 的外观。由此产生的设计将作为迁移后进一步发展的基础。
以下列表包含有助于设计过程的资源：
+ AWS A@@ [rchitecte Center](https://aws.amazon.com/architecture/) 结合了工具和指南，例如 Well-Arch AWS itected 框架。此外，它还提供了可用于应用程序的参考架构。
+ [Amazon Builders](https://aws.amazon.com/builders-library/) Library 包含一些关于亚马逊如何构建和运营软件的资源。
+ [AWS 解决方案库](https://aws.amazon.com/solutions/)提供了一系列基于云的解决方案，这些解决方案经过审核 AWS，可解决数十个技术和业务问题。它包括大量参考架构。
+ [AWS 规范性指导](https://aws.amazon.com/prescriptive-guidance/)提供了有助于设计过程和迁移最佳实践的策略、指南和模式。
+ [AWS Documentation](https://docs.aws.amazon.com/)包含有关 AWS 服务的信息，包括用户指南和 API 参考。
+ [入门资源中心](https://aws.amazon.com/getting-started/)提供了几个动手教程和深入研究，以学习基础知识，以便您可以开始进行构建 AWS。
根据您在云之旅中所处的位置， AWS 基础可能已经存在。这些 AWS 基础包括以下内容：
+ AWS 区域 已被识别。
+ 账户已创建或可以按需获取。
+ 通用联网已经实现。
+ 基础 AWS 服务已在账户中部署。
相反，你可能还处于这个过程的初期，而且 AWS 基础尚未建立。缺乏既定的基础可能会限制应用程序设计的范围，或者需要进一步的工作来定义它们。如果是这样的话，我们建议与应用程序设计工作并行定义和实现着陆区的基础设计。应用程序设计有助于确定 AWS 账户 结构、网络、虚拟私有云 (VPCs)、无类域间路由 (CIDR) 范围、共享服务、安全和云运营等需求。
[AWS Control Tower](https://aws.amazon.com/controltower/)提供了设置和管理安全的多账户 AWS 环境（称为 landing zone）的最简单方法。 AWS Control Tower 使用创建您的 landing zone AWS Organizations，它提供持续的账户管理和治理，并在成千上万的客户迁移到云端时实施基于 AWS 最佳实践的体验。
## 应用程序 future 状态
首先为该应用程序制定初始迁移策略。目前，该策略被认为是初步的，因为它可能会随着未来状态设计的一部分而发生变化，从而发现潜在的局限性。要验证初始假设，请参阅 [6 R 决策树](prioritization-and-migration-strategy.md#migration-r-type)。此外，还要记录潜在的迁移阶段。例如，是否会在单个事件中迁移此应用程序（同时迁移所有组件）？ 还是分阶段迁移（有些组件稍后会迁移）？
请注意，给定应用程序的迁移策略可能不是唯一的。这是因为可以使用多个 R 类型来迁移应用程序组件。例如，最初的方法可能是在不做任何更改的情况下提升和转移应用程序。但是，应用程序的组件可能位于不同的基础设施资产中，可能需要不同的处理方式。例如，一个应用程序由三个组件组成，每个组件在单独的服务器上运行，其中一个服务器运行云端不支持的旧操作系统。该组件将需要采用重新平台的方法，而在支持的服务器版本中运行的另外两个组件可以重新托管。为要迁移的每个应用程序组件和关联的基础架构分配迁移策略是至关重要的。
接下来，记录上下文和问题，并链接定义当前状态的现有工件：
+ 为什么要迁移此应用程序？
+ 拟议的变更有哪些？
+ 有什么好处？
+ 有重大风险或阻碍因素吗？
+ 目前的缺点是什么？
+ 范围之内和范围外有什么？
## 可重复性
在整个设计工作中，请考虑如何将该应用程序的解决方案和架构重复用于其他应用程序。这个解决方案可以概括吗？
## 要求
记录此应用程序的功能和非功能要求，包括安全性。这包括当前和未来的状态要求，具体取决于所选择的迁移策略。使用在详细的应用程序评估期间收集的信息来指导此过程。
## 未来架构
描述此应用程序的 future 架构。考虑创建一个可重复使用的逻辑示意图模板，其中包含源环境（本地）和目标 AWS 环境（例如目标 AWS 区域 VPCs、账户和可用区）的构建块。
创建一个表，列出正在迁移的组件和将要迁移的新组件。包括与该应用程序交互的其他应用程序和服务（本地或云端）。
下表列出了示例组件。它不代表参考架构或经过审查的配置。
| **名称** | **描述** | **详细信息** |
| --- |--- |--- |
| 应用程序 | 外部服务（入站连接） | 服务使用来自公开的 API 的数据。 |
| DNS | 名称解析（内部） | Amazon Route 53 作为基本账户设置的一部分进行部署 |
| 应用程序负载均衡器 | 在后端服务之间分配流量 | 取代本地负载均衡器。迁移池 A |
| 应用程序安全性 | DDoS 防护 | 通过使用实现 AWS Shield |
| 安全组 | 虚拟防火墙 | 限制通过端口 443（入站）访问应用程序实例。 |
| Server A | 前端 | 使用亚马逊弹性计算云 (Amazon EC2) 进行重新托管。 |
| Server B | 前端 | 使用 Amazon EC2 进行重新托管。 |
| 服务器 C | 应用程序逻辑 | 使用 Amazon EC2 进行重新托管。 |
| 服务器 D | 应用程序逻辑 | 使用 Amazon EC2 进行重新托管。 |
| 亚马逊关系数据库服务（亚马逊 RDS）— 亚马逊 Aurora | 数据库 | 取代服务器 E 和 F |
| 监控和提醒 | 变更控制 | Amazon CloudWatch |
| 审计日志记录 | 变更控制 | AWS CloudTrail |
| 修补和远程访问 | Maintenance | AWS Systems Manager |
| 资源访问权限 | 安全访问控制 | AWS Identity and Access Management (IAM) |
| 身份验证 | 用户访问权限 | Amazon Cognito |
| 证书 | SSL/TLS | AWS Certificate Manager |
| API 1 | 外部 API | Amazon API Gateway |
| 对象存储 | 图片托管 | Amazon Simple Storage Service（Amazon S3） |
| 凭据 | 证书的管理和托管 | AWS Secrets Manager |
| AWS Lambda 函数 | 检索数据库凭证和 API 密钥 | AWS Lambda |
| 互联网网关 | 出站互联网接入 | 通往 VPC 的互联网网关 |
| 私有子网 1 | 后端和数据库 | 可用区 1 — VPC 1 |
| 私有子网 2 | 后端和数据库 | 可用区 2 — VPC 1 |
| 公有子网 1 | 前端 | 可用区 1 — VPC 1 |
| 公有子网 2 | 前端 | 可用区 2 — VPC 1 |
| Backup 服务 | 数据库和 EC2 实例备份 | AWS Backup |
| DR | 亚马逊 EC2 弹性 | AWS 弹性灾难恢复 |
识别出组件后，使用您的首选工具将它们绘制在图表中。与应用程序的主要利益相关者共享初始设计，包括应用程序所有者、企业架构师以及平台和迁移团队。考虑问以下问题：
+ 团队普遍同意这个设计吗？
+ 运营团队能否提供支持？
+ 设计可以演变吗？
+ 还有其他选择吗？
+ 设计是否符合建筑标准和安全政策？
+ 是否缺少任何组件（例如，代码存储库、 CI/CD 工具、VPC 端点）？
## 架构决策
作为设计过程的一部分，您可能会为整体架构或其中的特定部分找到更多选项。将这些选项与首选或选定选项的理由一起记录下来。这些决策可以记录为架构决策。
确保列出和描述主要选项时要有足够的细节，让新读者了解决定使用一个选项而不是另一个选项背后的选项和原因。
## 软件生命周期环境
记录对当前环境的任何更改。例如，将在中重新创建测试和开发环境， AWS 而不是迁移。
## 标签
描述每个基础架构组件的必备标签和建议标记，以及此设计的标签值。
## 迁移策略
到目前为止，应验证有关迁移策略的初始假设。确认已就所选的 R 策略达成共识。记录总体应用程序迁移策略和各个应用程序组件的策略。如前所述，不同的应用程序组件可能需要不同的 R 类型进行迁移。
此外，根据关键业务驱动因素和结果调整迁移策略。另外，请描述任何分阶段的迁移方法，例如不同迁移事件中组件的移动。
有关确定 6 R 的更多信息，请参阅[AWS Migration Hub 策略建议](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/)。
## 迁移模式和工具
通过为应用程序和基础架构组件定义的迁移策略，您现在可以探索特定的技术模式。例如，重新托管策略可以通过迁移工具来实现，例如[AWS Application Migration Service](https://aws.amazon.com/application-migration-service/)。如果您不需要复制状态或数据，则可以通过使用 Amazon 系统映像 (AMI) 和应用程序部署管道重新部署应用程序来实现相同的结果。
同样，要对应用程序进行平台重构或重构（重新架构），可以使用诸如、() [AWS App2Container](https://aws.amazon.com/app2container/)、[AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/)、[AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/)之类的工具。AWS SCT[AWS DataSync](https://aws.amazon.com/datasync/)要进行容器化，你可以使用亚马逊[弹性容器服务 (Amazon ECS)、亚马逊 Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/ecs/) [或](https://aws.amazon.com/eks/)。[AWS Fargate](https://aws.amazon.com/fargate/)回购时，您可以将 AMI 用于特定产品或中的软件即服务 (SaaS) 解决方案。[AWS Marketplace](https://aws.amazon.com/marketplace/)
评估可用于实现目标的不同模式和选项。考虑利弊以及迁移操作准备情况。为了帮助您进行分析，请使用以下问题：
+ 迁移团队能否支持这些模式？
+ 成本和收益之间的平衡是什么？
+ 能否将此应用程序、服务或组件移至托管服务？
+ 为实现这种模式付出了什么努力？
+ 是否有任何法规或合规政策禁止使用特定模式？
+ 这种模式可以重复使用吗？ 首选可重复使用的图案。但是，有时一种模式只能使用一次。考虑在一次性模式与替代可重复使用的模式之间取得平衡。
[AWS 规范性指导](https://aws.amazon.com/prescriptive-guidance/)包含各种迁移模式和技术。
## 服务管理和运营
在创建要迁移到的应用程序设计时 AWS，请考虑操作就绪性。在与您的应用程序和基础架构团队一起评估就绪性要求时，请考虑以下问题：
+ 他们准备好操作它了吗？
+ 是否定义了事件响应程序？
+ 预期的服务级别协议 (SLA) 是什么？
+ 是否需要职责分离？
+ 不同的团队准备好协调支持行动了吗？
+ 谁应对什么负责？
## 切换注意事项
考虑到迁移策略和模式，在应用程序迁移时需要了解哪些重要信息？ 切换计划是一项设计后的活动。但是，请记录可以预期的活动和要求的所有注意事项。例如，记录执行概念验证的要求（如果适用），并概述测试、审计或验证要求。
## 风险、假设、问题和依赖关系
记录所有未解决的风险、假设和尚未解决的潜在问题。为这些项目分配明确的所有权，并跟踪进度，以便批准总体设计和战略以供实施。此外，请记录实现此设计的关键依赖关系。
## 估算运行成本
要估算目标 AWS 架构的成本，请使用定[AWS 价计算器](https://calculator.aws/)。根据您的设计添加基础架构组件，并获得估计的运行成本。将应用程序组件所需的软件许可证考虑在内，但尚未包含在将要使用的 AWS 服务中。