迁移到AWS：实现平稳过渡的分步检查清单

迁移到Amazon Web Services (AWS) 可以提升可扩展性、恢复选项和部署速度，但仓促的迁移也可能导致服务中断和意外账单。难点不在于启动云资源，而在于了解当前环境、安全迁移数据，并在具备回滚路径的情况下切换流量。

使用此检查清单按阶段规划工作：评估、迁移、切换以及迁移后优化。

第一阶段：规划与评估

初始阶段对于为迁移奠定坚实基础至关重要。彻底的规划和评估有助于了解当前环境、定义目标并制定稳健的迁移策略。

1.1 定义业务目标和成功指标

在开始任何技术工作之前，明确阐述为什么要迁移到AWS。关键的业务驱动因素是什么？

确定目标： 降低总拥有成本、提升应用性能、增强灾难恢复、加速创新、扩大全球覆盖、实现更高敏捷性。
建立关键绩效指标： 定义可衡量的目标，例如月度运行成本、p95延迟、恢复时间目标、恢复点目标、部署频率或事件发生率。

1.2 当前环境的清单与发现

深入了解现有基础设施、应用和数据。这通常涉及手动收集与自动化工具的结合。

应用与服务器清单： 列出所有应用、虚拟机、物理服务器、操作系统和数据库。
依赖关系映射： 识别应用间、应用到数据库以及网络依赖关系。AWS Application Discovery Service 或第三方解决方案可以自动化此过程。
数据评估： 了解数据量、增长率、访问模式和合规要求。
网络与安全审查： 记录当前网络拓扑、防火墙、安全组和合规框架（例如 HIPAA、GDPR、PCI DSS）。

1.3 分析成本并制定商业案例

开发一个全面的财务模型，比较当前本地成本与预估的AWS成本。

总拥有成本分析： 包括本地硬件、软件许可、电力、冷却、设施和人员成本。
AWS成本估算： 使用AWS Pricing Calculator，并包含通过Savings Plans、适当使用预留实例以及迁移后调整规模可能节省的成本。
构建强有力的商业案例： 向利益相关者展示财务和战略优势，以获得支持和资金。

1.4 制定云迁移策略

AWS迁移规划通常使用“R”策略。为每个应用或工作负载选择最合适的路径，而不是强制所有内容采用一种方法。

重新托管（直接迁移）： 将应用原样迁移到EC2实例。速度最快，但可能无法立即优化云优势。
- 示例： 将在Windows Server VM上运行的遗留应用直接迁移到EC2实例。
更换平台（迁移并调整）： 将应用迁移到云端，并进行小幅优化以利用云功能，而不改变核心架构。
- 示例： 将数据库从本地迁移到Amazon RDS。
重新架构（重构）： 修改或重写应用代码，以充分利用云原生服务。高投入，高回报。
- 示例： 使用AWS Lambda和Amazon API Gateway将单体应用拆分为微服务。
重新购买（替换）： 用云原生SaaS解决方案替换现有应用。
- 示例： 用Salesforce替换本地CRM，或用Amazon WorkMail替换本地邮件服务器。
保留： 将部分应用保留在本地，特别是那些不适合云迁移的应用（例如，高度专业化的硬件、监管限制）。
停用： 停用不再需要的应用，节省资源和成本。
迁移（重新定位）： 将兼容的工作负载迁移到云基础设施，应用变更最小，例如在环境匹配时将VMware工作负载迁移到VMware Cloud on AWS。

1.5 建立AWS着陆区

一个架构良好的着陆区提供安全、可扩展的多账户AWS环境。

AWS Organizations： 为多个AWS账户设置组织结构。
身份与访问管理： 配置身份提供商、角色和策略以实现安全访问。
网络配置： 定义VPC、子网、路由和连接（例如AWS Direct Connect、VPN）。
安全基线： 实施安全服务（例如AWS WAF、GuardDuty、Security Hub）、日志记录（CloudTrail、CloudWatch Logs）和备份策略。
成本管理： 通过AWS Cost Explorer设置预算、成本分配标签和监控。

提示： AWS Control Tower 是治理多账户环境的常用起点。一些组织中可能仍存在旧的AWS Landing Zone实现，但新构建应在复制旧设置之前评估当前的AWS指南。

第二阶段：执行与迁移

此阶段涉及按照规划阶段定义的策略，将数据和应用实际迁移到AWS。

2.1 确定应用和数据优先级（波次规划）

并非所有应用都能或应该一次性迁移。将它们分组为波次。

从小处着手： 从不太关键、更简单的应用开始，以积累经验并优化流程。
按依赖关系分组： 将相互依赖的应用一起迁移，以最大限度地减少中断。
试点迁移： 进行小规模、受控的迁移，以测试策略和工具。

2.2 数据迁移

数据迁移通常是迁移中最耗时且最关键的部分。

数据库迁移： 使用AWS Database Migration Service进行异构（例如Oracle到Aurora）和同构数据库迁移，实现最小停机时间。
存储迁移： 对于大型数据集，使用AWS DataSync、AWS Snowball系列设备或通过VPN或AWS Direct Connect到Amazon S3、Amazon EFS或Amazon FSx的直接网络传输。
数据同步： 在迁移期间实施持续数据复制，以最大限度地减少切换停机时间。

2.3 应用迁移

为每个应用实施所选的6R策略。

重新托管： 使用AWS Application Migration Service将服务器自动直接迁移到EC2实例。如果在现有计划中看到对CloudEndure Migration的旧引用，请在执行前根据当前AWS迁移工具进行验证。
更换平台/重新架构： 将应用部署到云原生服务，如Amazon EC2、Amazon ECS/EKS、AWS Lambda、Amazon RDS或无服务器产品。
基础设施即代码： 使用AWS CloudFormation或Terraform自动化基础设施配置。
CI/CD管道： 使用AWS CodePipeline、CodeBuild、CodeDeploy设置持续集成和持续交付管道，以实现自动化部署。

2.4 测试与验证

在上线前，彻底测试是不可妥协的。

功能测试： 确保所有应用功能在AWS环境中按预期工作。
性能测试： 验证应用是否满足性能基准并能有效扩展。
安全测试： 进行漏洞扫描、渗透测试和访问控制验证。
用户验收测试： 让业务用户参与，确认功能性和可用性。
灾难恢复测试： 验证关键应用的恢复点目标和恢复时间目标。

2.5 切换

将流量切换到新AWS环境的最后一步。

计划停机： 规划迁移窗口，并沟通预期影响、负责人、验证检查和回滚决策点。
数据同步： 执行最终数据同步以确保一致性。
DNS更新： 在可能的情况下，在切换前降低DNS TTL，然后更新记录指向新的AWS端点，例如在Amazon Route 53中管理的记录。
回滚计划： 制定清晰、经过测试的回滚计划，以应对不可预见的问题。

第三阶段：迁移后优化

迁移不是一次性事件；它是在云端持续改进之旅的开始。

3.1 成本优化

主动管理和降低AWS支出。

调整规模： 持续监控资源利用率（CPU、内存），并根据实际需求使用AWS Compute Optimizer调整EC2实例类型、EBS卷和其他服务。
定价模型： 对可预测的工作负载利用预留实例或Savings Plans。
无服务器和托管服务： 探索用完全托管或无服务器替代方案（例如EC2到Lambda、自管理数据库到Amazon RDS）替换自管理服务的机会，以减少运营开销并通常降低成本。
存储分层： 将不常访问的数据移动到更便宜的存储类别，例如根据检索需求选择Amazon S3 Standard-IA、S3 Glacier Instant Retrieval、S3 Glacier Flexible Retrieval或S3 Glacier Deep Archive。
自动关闭： 在非工作时间关闭非生产资源。

3.2 性能优化

确保应用高效运行并提供良好的用户体验。

监控与日志记录： 使用Amazon CloudWatch、AWS X-Ray等工具监控应用性能、资源利用率和日志。
自动扩展： 为EC2实例实施Auto Scaling Groups，或利用无服务器可扩展性功能高效处理可变负载。
内容分发网络： 使用Amazon CloudFront将内容缓存到离用户更近的位置，减少延迟并提高性能。
数据库优化： 微调数据库查询、索引和配置。

3.3 安全增强

持续改善云中的安全态势。

定期审计： 进行定期的安全审计和漏洞评估。
合规检查： 使用AWS Config和AWS Security Hub持续监控对内部策略和外部法规的合规性。
最小权限： 对IAM用户和角色强制执行最小权限原则。
安全最佳实践： 定期审查并应用AWS Well-Architected Framework的安全支柱指南。

3.4 运营卓越与自动化

简化运营并减少手动工作。

基础设施即代码： 使用CloudFormation或Terraform维护和发展基础设施定义。
自动化： 使用AWS Systems Manager、Lambda函数和事件驱动架构自动化日常任务。
CI/CD管道： 将所有应用部署完全集成CI/CD，以确保快速、一致和可靠的发布。
监控与告警： 优化CloudWatch告警和通知，实现主动问题检测。

3.5 旧基础设施的退役

一旦对AWS环境充满信心且所有依赖关系都已切断，就退役旧的本地基础设施。

验证： 仔细检查所有应用和数据是否已成功迁移并在AWS中正常运行。
备份： 在退役前创建旧系统的最终备份。
退役： 关闭旧服务器、移除计划任务、撤销过期的凭据、更新文档，并终止与已退役系统相关的合同或许可证。

关键要点

将AWS迁移视为一个受控的变更项目，而不是周末的复制工作。首先构建着陆区，按波次迁移，在切换前测试每个工作负载，并在流量迁移后持续优化成本、安全和运营。