酷云科技版本：1.0 适用对象：计划采用、迁移至或持续运营 AWS 云环境的中小企业管理者、IT 负责人、架构师与运维团队
本指南总结了酷云科技在 AWS 云规划、迁移、安全治理与运营管理方面的方法和项目经验，旨在帮助资源有限的中小企业以可控风险、可衡量成果和可持续运营的方式采用 AWS。
本文提供的是通用方法、检查清单和匿名化场景，不构成对特定业务结果、成本节省、性能提升、合规认证、可用性或恢复时间的保证。具体架构、服务、区域、指标、RTO、RPO 与安全控制应依据客户业务影响分析、风险评估、监管要求和实际测试结果确定。
本文中的案例已匿名化，不包含客户名称、AWS 账号、ACE 商机 ID、资源标识、联系人或商业条款。
中小企业采用云的难点通常不是“能否创建云资源”，而是如何在预算、人员和时间有限的条件下，建立一套安全、可扩展、可恢复且能长期运营的体系。一次成功的云项目应同时回答六个问题：
为什么上云： 业务目标、风险和价值是否明确？
迁移什么： 工作负载、数据、依赖和优先级是否清楚？
如何保护： 身份、网络、数据、日志和责任边界是否落实？
如何上线： 是否具备测试、切换、回退和验收机制？
如何运营： 是否有监控、告警、Runbook、补丁和事件响应？
如何持续优化： 是否能跟踪成本、性能、可靠性和业务成果？
酷云科技建议采用“评估—基础环境—试点—批次迁移—优化”的五阶段路线，并在每个阶段设置明确的进入条件、退出条件、责任人和证据。对于 5–20 个工作负载的典型 SMB 项目，该路线可以按范围裁剪，但不应省略安全基线、恢复验证、上线检查和知识移交。
云不是单纯的基础设施替换。项目启动前应将目标转换为可衡量的业务和技术指标，例如：
缩短新环境交付时间；
支撑促销或业务增长期间的弹性；
降低单点故障和不可恢复风险；
提升发布频率与回退能力；
建立可分配、可预测的云成本；
满足数据保护、审计或行业要求。
每个指标都应记录基线、目标、数据来源、测量周期和负责人。没有基线的“提升”无法被验证。
SMB 团队通常无法承受长时间冻结或“大爆炸”式切换。建议先选择低依赖、风险可控、能快速产生价值的工作负载作为试点，再按依赖关系形成迁移波次。每一波都执行相同的测试、切换和回退流程。
在业务需求允许时，优先考虑托管数据库、托管容器、对象存储、集中备份和原生监控，减少操作系统、控制平面和自建组件的维护负担。基础设施变更应尽可能通过 IaC 和受控流水线执行，而不是依赖人工控制台操作。
架构设计不能止于“资源已经创建”。上线前必须明确：谁接收告警、如何排障、如何恢复、如何打补丁、如何控制变更、如何查看成本、如何获得支持。每项关键操作都应有 Runbook 和证据记录。
AWS Cloud Adoption Framework（AWS CAF）从六个视角帮助组织识别云转型能力差距：业务、人员、治理、平台、安全和运营。SMB 项目可以简化活动，但不应只评估平台技术。
建议在项目初期完成以下访谈：
| CAF 视角 | 核心问题 | 典型输出 |
|---|---|---|
| 业务 | 为什么迁移？怎样衡量价值？ | 商业目标、KPI、优先级 |
| 人员 | 谁建设、审批和运营？有哪些技能缺口？ | RACI、培训计划、支持模式 |
| 治理 | 如何管理账户、成本、风险和变更？ | 治理原则、标签、预算、审批流 |
| 平台 | 当前架构、依赖和目标平台是什么？ | 资源清单、目标架构、迁移波次 |
| 安全 | 数据、身份、网络和合规要求是什么？ | 安全基线、风险清单、控制映射 |
| 运营 | 如何监控、响应、恢复和改进？ | SLI/SLO、Runbook、备份与 DR 计划 |
AWS Well-Architected Framework 可用于从运营卓越、安全性、可靠性、性能效率、成本优化和可持续性等方面检查设计。评审结果是风险发现和改进计划，不等同于配置已经实施；高风险或中风险问题应分配负责人、计划日期和验证证据。
主要活动：
访谈业务和技术负责人；
建立服务器、数据库、应用、域名、证书和依赖清单；
收集 CPU、内存、存储、网络和增长数据；
进行数据分类、业务影响分析和风险评估；
选择 7R 策略：Retire、Retain、Rehost、Relocate、Repurchase、Replatform 或 Refactor；
建立成本基线、目标 KPI 和迁移优先级。
退出条件： 范围已确认、依赖已识别、业务负责人已批准目标和迁移波次。
主要活动：
建立 AWS Organizations/Control Tower 或适合规模的账户结构；
配置集中身份、MFA、日志、配置审计和安全服务；
建立网络、DNS、连接、KMS、标签和预算基线；
通过 IaC 创建可重复环境；
验证客户团队可以接管日常管理。
退出条件： 账户、网络、身份、安全日志、备份和成本告警通过基线检查。
选择低风险但有代表性的工作负载，验证复制、部署、数据迁移、监控、备份、切换和回退。试点的目标是验证流程，而不是追求一次迁移最多资源。
退出条件： 功能、性能、安全、恢复、监控和回退测试均达到约定标准。
按依赖关系和业务窗口形成波次。每一波执行：准备—复制—测试—用户验收—切换—观察—关闭旧环境。变更必须经过审批，重大问题应触发回退。
完成规格优化、成本检查、安全复核、备份恢复测试、Runbook、培训、验收和后续改进计划。项目结束不代表运营结束，应建立月度或季度健康检查机制。
AWS 负责云基础设施本身的安全；客户负责其在云中部署和配置的内容。责任边界会随服务模型变化：使用 Amazon EC2 时，客户承担更多操作系统和应用责任；使用 Amazon RDS 等托管服务时，AWS 管理更多底层组件，但客户仍需负责账号、网络、身份、数据、参数、备份策略和应用访问。
项目应在 SOW 和 RACI 中明确：
AWS、客户和服务伙伴各自负责什么；
谁批准生产变更和高权限访问；
谁接收安全与运行告警；
谁执行备份检查和恢复演练；
谁维护操作系统、应用、中间件与数据库；
安全事件和服务中断如何升级；
项目结束后的访问撤销和资料交接方式。
根用户仅用于必须由根用户执行的少量任务；
启用 MFA，使用企业控制的邮箱和电话；
不创建或保留根用户访问密钥；
建立安全保管和紧急使用审批流程。
优先使用 IAM Identity Center、企业身份联合和 IAM Role。避免多人共享 IAM User 或长期 Access Key。权限设计应遵循：
默认拒绝与最小权限；
按岗位分组，不直接为个人长期叠加权限；
管理员、开发、运维、审计职责分离；
高权限操作使用临时凭证与审批；
定期执行访问复核，人员离职或角色变化时及时撤销；
使用 CloudTrail 记录管理事件。
服务伙伴访问客户账号时，建议使用受控跨账号角色、外部 ID、临时凭证和限定会话时长。项目结束后应撤销角色或信任关系，并形成访问关闭记录。
SMB 的 Landing Zone 不一定复杂，但必须能够分隔环境、集中审计并支持增长。常见结构包括管理、安全/日志、共享服务、非生产和生产账户；规模较小时可适度合并，但生产和非生产、管理和工作负载应有清晰边界。
网络基线建议：
VPC 跨至少两个可用区；
互联网入口、应用和数据层分区部署；
数据库、中间件和内部服务默认放置在私有子网；
安全组只开放必要协议、端口和来源，优先引用安全组；
NACL 作为补充控制，不替代安全组；
通过 VPC Endpoint 减少不必要的公网访问；
记录 VPC Flow Logs，并设置合理保留期；
互联网应用按风险使用 AWS WAF、Shield 和限流机制；
管理访问优先使用 Systems Manager，而非长期开放 SSH/RDP。
数据保护建议：
使用 TLS 保护传输中的数据；
对支持的服务启用静态加密；
使用 AWS KMS 管理密钥并限制使用权限；
使用 Secrets Manager 或 Parameter Store 管理凭证，不在代码、镜像、Runbook 或流水线日志中保存明文密码；
对 S3 启用 Block Public Access，并审查 Bucket Policy；
根据数据等级设置保留、归档和删除策略。
服务选择应从业务约束出发，而不是只比较单价。
| 场景 | 可考虑的 AWS 能力 | 关键决策因素 |
|---|---|---|
| 虚拟机快速迁移 | Amazon EC2、AWS MGN | OS 兼容、停机窗口、许可、运维能力 |
| 容器平台 | Amazon EKS、Amazon ECS | 团队技能、生态、控制需求、升级成本 |
| 关系型数据库 | Amazon RDS、Amazon Aurora | 引擎兼容、可用性、备份、扩展和成本 |
| 缓存 | Amazon ElastiCache | 数据一致性、容量、故障转移 |
| 对象与静态内容 | Amazon S3、CloudFront | 访问模式、缓存、安全和生命周期 |
| 消息与集成 | Amazon SQS、SNS、MSK 或适配服务 | 吞吐、顺序、延迟、运维复杂度 |
| 监控与审计 | CloudWatch、CloudTrail、AWS Config | 日志范围、告警、保留和查询成本 |
如果选择自建组件，应记录不能采用托管服务的原因、运维责任、备份、升级和高可用方案。
建议用业务关键性、技术复杂度、依赖数量、数据量、停机容忍度和团队准备度评分。优先迁移“业务价值较高、复杂度较低”的工作负载，避免首波同时处理所有高风险依赖。
使用 AWS MGN 等复制工具时，应验证：
源环境网络和代理连通性；
复制延迟、磁盘容量与变更率；
测试启动参数和目标网络；
安全组、IAM Role、监控、备份和补丁；
DNS、证书、外部接口和许可证；
切换前增量同步和回退条件。
使用 AWS DMS 或原生工具进行全量迁移与 CDC 时，应完成：
引擎、版本、字符集、时区和扩展兼容性评估；
表结构、主键、大对象和存储过程检查；
全量加载后的行数、校验和与业务抽样；
CDC 延迟监控；
应用连接切换、写入冻结和回退方案；
切换后的性能、备份和高可用验证。
上线计划至少包含：时间线、负责人、冻结窗口、数据同步点、DNS/流量切换、验证步骤、沟通对象、回退触发条件和观察期。项目应在生产切换前完成业务负责人签字或电子批准。
监控应从业务健康度出发。除 CPU、内存和磁盘外，还应关注请求成功率、错误率、延迟、队列积压、数据库连接、复制延迟、关键交易数量和单位业务成本。
建议为每项关键工作负载定义：
SLI：实际测量的指标；
SLO：期望达到的服务目标；
告警阈值和持续时间；
告警接收组、严重等级和升级时间；
对应 Runbook；
恢复后的复盘要求。
日志应集中收集并设置保留期。应用、ALB、CloudFront、RDS、EKS、VPC Flow Logs、CloudTrail 和安全服务日志应按风险纳入查询和告警。告警过多会造成疲劳，应定期删除无行动价值的告警并调整阈值。
一份可执行的 Runbook 至少包含：
目的和适用范围；
前置条件、权限和输入；
分步操作；
每一步的验证方式；
风险和回退方法；
升级路径与联系人角色；
需要保存的日志、截图或工单；
复盘和文档更新要求。
建议优先建立以下 Runbook：
高 CPU/内存/磁盘使用率；
应用 5xx 或延迟升高；
数据库连接耗尽或复制延迟；
EKS Pod 无法调度、节点异常；
证书即将到期；
备份失败或恢复失败；
成本异常增长；
安全告警、凭证泄露或异常登录；
发布失败和回滚。
重大事件结束后应进行无责复盘，记录时间线、根因、检测方式、响应差距和改进行动。
补丁和变更应遵循“先备份、先测试、再生产、可回退”的原则。
标准流程：
识别漏洞、补丁或变更需求；
评估业务影响、依赖、重启和停机窗口；
在隔离或非生产环境测试；
明确成功标准和回退方案；
获得批准并通知相关方；
使用 Systems Manager 或受控流水线执行；
验证应用、监控、日志和安全状态；
保存执行结果并更新 CMDB/文档。
紧急变更可以简化前置审批，但不能省略记录、验证和事后复盘。
先通过业务影响分析确定：
哪些数据和系统最关键；
可容忍的数据丢失量（RPO）；
可容忍的中断时间（RTO）；
数据保留、法律和审计要求；
恢复所需人员、凭证、网络和外部依赖。
可使用 AWS Backup 和服务原生能力建立集中策略：
按标签或资源清单纳管；
设置频率、保留期和生命周期；
使用 KMS 加密 Backup Vault；
按风险采用跨区域或跨账户副本；
对失败任务建立告警；
限制删除和修改权限；
定期执行恢复测试，而不是只检查“备份成功”。
| 策略 | 成本 | 恢复速度 | 适用场景 |
|---|---|---|---|
| 备份与恢复 | 低 | 较慢 | 非核心或可容忍较长中断 |
| Pilot Light | 中低 | 中等 | 关键数据持续存在，计算按需恢复 |
| Warm Standby | 中高 | 较快 | 需要较短恢复时间的核心业务 |
| 多站点/主动-主动 | 高 | 最快 | 极关键业务且具备持续运营能力 |
所有策略都必须通过演练验证。演练应记录开始时间、恢复步骤、实际恢复点、实际恢复时间、数据完整性、业务验证和回切结果。
基础设施、Kubernetes 配置和应用发布应进入版本控制。典型流水线包括：
代码审查与合并策略；
单元测试、集成测试和构建；
依赖、密钥、镜像、IaC 和配置扫描；
制品存储与可追溯版本；
非生产部署和自动验证；
生产审批；
滚动、蓝绿或金丝雀发布；
监控验证与自动/人工回滚。
Terraform、AWS CloudFormation 或 AWS CDK 等 IaC 工具应使用远程状态、锁定、最小权限和审查机制。生产环境的直接控制台修改应被限制并纳入漂移检测。
成本治理不是项目结束后的“砍费用”，而是从设计阶段开始的持续过程。
统一账号、环境、应用、负责人和成本中心标签；
使用 Cost Explorer、AWS Budgets 和异常检测；
定期输出按账号、应用和服务拆分的成本报告；
将成本与订单、用户、请求或数据量等业务单位关联。
删除闲置、重复和过期资源；
调整实例、数据库、存储和日志规格；
使用自动伸缩和按需调度；
优化数据传输和存储生命周期；
对稳定负载评估 Savings Plans 或 Reserved Instances；
对可中断、无状态工作负载评估 Spot。
使用 Spot 时应采用多实例类型、多可用区、容量优化策略、终止信号处理和按需容量兜底。任何成本节省比例都应基于同一时间范围和业务量进行前后比较。
运营移交应以“客户能够独立执行关键任务”为完成标准，而不是只交付文档。建议至少开展三类培训：
AWS 账号、身份和日常安全操作；
监控告警、常见故障和 Runbook；
成本、备份、恢复、扩缩容和变更流程。
移交包建议包含：
最终架构图和资源清单；
账号、权限和责任矩阵；
监控与告警清单；
Runbook 与升级路径；
备份、RTO/RPO 和恢复测试记录；
IaC、代码仓库和流水线说明；
成本预算和优化建议；
已知风险、待办事项和支持方式；
培训材料、签到和验收记录。
一家面向海外市场的电商企业需要建设新的云平台，以应对营销活动期间的流量波动，并降低小型运维团队管理基础设施的复杂度。
在多个可用区部署 VPC、公有入口和私有应用/数据子网；
使用 ALB、Amazon EKS 和 Amazon ECR 承载容器化应用；
使用 Amazon RDS/Aurora MySQL 和 ElastiCache 提供数据服务；
通过 Karpenter/自动伸缩管理节点容量，并为可中断工作负载评估 Spot；
使用 CloudWatch、AWS Config、KMS、备份和集中日志建立运营与安全基础；
在数据库选型前执行同口径基准测试，记录吞吐、延迟、CPU、存储和测试条件。
性能结论必须限定于具体数据集、版本、规格和测试工具；私有 EKS 需要在设计阶段解决镜像、STS、日志、软件包和运维访问路径；Spot 不能作为唯一容量来源。
一家电商企业计划将应用和数据从其他云平台迁移到 AWS，同时建立订单和业务数据的实时分析能力。
使用 Landing Zone 分隔生产、非生产、安全和日志职责；
使用 EKS、负载均衡、S3、CloudFront、RDS Multi-AZ 和 ElastiCache；
通过 DMS/DataSync 等工具执行数据迁移；
使用 CDC、流式平台、Amazon Redshift/Redshift Serverless 和 QuickSight 建立分析链路；
采用全量加载、持续复制、数据校验、低峰切换和回退步骤；
使用 KMS、Secrets Manager、WAF、CloudTrail、VPC Flow Logs 和 CloudWatch 建立控制与可观测性。
实时链路必须监控复制延迟、消息积压、失败重试和数据一致性；设计目标不能直接写成实际成果，必须通过上线后的监控和成本数据验证。
一家面向海外用户的酒店预订平台需要迁移到 AWS，在降低停机风险的同时现代化容器、数据库、缓存、搜索和消息组件。
使用 Route 53、CloudFront、WAF 和负载均衡构建访问层；
使用 EKS 运行应用，使用 Aurora MySQL、ElastiCache 和 OpenSearch 提供数据能力；
通过 DMS 全量迁移与 CDC 降低数据库切换窗口；
使用 IaC 建立网络和平台，分隔生产和测试环境；
切换前执行全量备份、依赖检查、数据校验和回退演练；
将监控、备份、密钥和日志纳入上线检查。
迁移成功应由已签署验收、真实生产运行、监控和数据校验证明；“文档中计划上线”不能替代实际完成证据。自建消息组件需要额外评估高可用、升级和恢复责任。
一家游戏企业需要为全球玩家提供稳定入口、低延迟访问和快速发布能力，同时建立多环境治理与自动化交付体系。
使用多账户 Landing Zone 分隔共享服务、日志、安全、开发测试和生产；
使用 EKS、RDS、DynamoDB 和 S3 承载应用与数据；
使用 CloudFront、Route 53 和 Global Accelerator 改善全球访问与故障切换；
使用 ECR、GitLab CI/CD、Terraform、Helm 和数据库版本工具建设交付流水线；
在流水线中执行 IaC 校验、构建、扫描、部署、审批和回退；
使用 CloudWatch、安全服务和健康检查支持运行监控。
全球加速方案应通过不同地区和运营商的真实测量验证；流水线必须保护密钥、隔离 Runner、保存制品和审计记录；固定 IP、ARN、账号、桶名等信息不得出现在公开材料中。
