从 Cloud-First 到 Cloud-Smart：AWS 迁移的新规则
Source: Dev.to
请提供您想要翻译的具体文本内容，我将按照要求将其翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！
云优先时代
曾经，迁移到云端是一种大胆、几乎是叛逆的举动。
企业在董事会会议上低声讨论它。
架构师在白板会议中争论它。
领导者把它视为一次信仰的飞跃，承诺摆脱老化的数据中心和僵硬的基础设施。
今天，这一章节已经结束。
- 云迁移不再是新鲜事。
- 它不再具争议性。
- 而且它显然已经不够了。
大多数大型组织已经以某种形式使用 AWS。有的拥有 数百个账户；有的在后台悄悄运行 数千个工作负载。然而，这些组织中的许多仍在自问一个令人不安的问题：
如果我们已经在云上，为什么仍然感觉如此困难？
这正是从 cloud‑first 向 cloud‑smart 转变的起点，重新定义在 2026 年及以后应如何进行 AWS 迁移和现代化。
什么是云优先的承诺
当云优先策略首次出现时，它们承载着一个强大的承诺：
| 承诺 | 含义 |
|---|---|
| 速度 | 团队可以在几分钟内完成基础设施的供应，而不是几周。可以快速创建、测试并拆除新环境，无需漫长的审批流程。 |
| 可扩展性 | 系统可以在需求高峰时自动扩容，在流量下降时自动缩容，免去为最坏情况购买服务器的需求。 |
| 逃离 | 摆脱老旧数据中心、硬件更新周期，以及基础设施团队被视为阻碍的看法。 |
对于早期采用者来说，这种思路完全合理。另一种选择——停滞——往往比大胆跃进更昂贵且更具风险。
经验教训
快速前进并不总是意味着向前
在无数企业中，云优先悄然变成了大规模的 lift‑and‑shift：
- 应用程序被原样迁移。
- 为本地环境设计的架构几乎未作更改就直接部署到 AWS。
- 成功的衡量标准是迁移的服务器数量，而不是随后交付的价值。
结果：
- 云费用的增长速度超过了业务价值的提升。
- EC2 实例被过度配置，所谓的“以防万一”。
- 存储被分配后被遗忘。
- 由于应用程序从未为分布式环境设计，出现了性能问题。
安全团队难以跟上步伐。影子 IT 随之出现，团队在治理模型之外创建资源，使合规审计变得更困难，而不是更容易。
成本难题
当今最常见的讨论之一并不是 关于迁移到 AWS，而是 为什么 AWS 成本如此高。
- CFO 们提出严峻的问题：云支出每个季度都在增长，但收入增长却没有同步。
- “按需付费”的承诺开始感觉像是 “为你忘记的东西付费”。
当团队进一步挖掘时，常见的模式浮现：
- 为峰值流量预配的 EC2 实例却从未进行合适的规模调整。
- 附加在已不再存在的工作负载上的存储卷。
- 快照被无限期保留，因为没有人负责清理。
- 从本地环境迁移而来的数据库许可证未进行优化。
这些问题 并非恶意；它们是快速推进而缺乏长期策略的自然结果。
混合现实
Enterprises now operate hybrid environments that include:
- 本地系统。
- 多个 AWS 区域。
- 数十或数百个账户。
Additional complexities:
- 合规要求因地区而异。
- 团队分布在不同时区。
- 运营责任在 DevOps、安全、财务和产品团队之间共享。
曾经看似简单的事情已经变得复杂。没有明确的运营模型，这种复杂性会进一步叠加。
Source:
云智能转型
云智能意味着有意的云采用。
这是一种方法，所有工作负载、架构决策和 AWS 服务选择都直接关联到 业务成果——不是因为它现代或新颖，而是因为它能带来可衡量的价值。
在云智能组织中，AWS 迁移和现代化 不是一次性项目；它是一项 持续的纪律。
云智能组织的核心原则
-
以业务成果为导向的架构
- 根据收入影响、风险降低、客户体验或运营效率来评估工作负载。
- 如果系统不支持明确的成果，就会受到质疑。
-
适度规模而非过度扩展
- 精准胜于冗余。
- 设计反映真实的使用模式，而非假设的峰值。
-
嵌入式安全、治理和成本控制
- 这些从第一天起就是架构的一部分，而不是事后考虑或清理任务。
-
选择性现代化
- 并非每个应用都需要重构。
- 只有在能够产生杠杆效应的地方才进行现代化。
云优先 vs. 云智能
| 方面 | 云优先 | 云智能 |
|---|---|---|
| 假设 | 迁移所有内容；云会自动让一切变得更好。 | 询问应该迁移什么、何时迁移以及为何迁移？ |
| 方法 | 默认采用提升迁移（lift‑and‑shift）；快速、感觉安全，降低即时风险。 | 根据结果混合使用重新托管、重新平台化、重构以及有选择的现代化。 |
| 决策 | 动量驱动。 | 结果驱动。 |
这种转变听起来微妙，但它改变了一切。它用结果驱动的决策取代了动量驱动的决策。
结束语
云的早期故事是 简洁：更少的移动部件，更少的基础设施管理，更专注于构建产品。
当今的现实是一个复杂的混合环境，其中 有意性 和 以业务为中心的决策 是释放真正云价值的关键。
采用 云智能 思维方式可确保每一次 AWS 迁移和现代化工作都能产生可衡量的成果，控制成本，并使组织在 2026 年及以后实现可持续增长。
云智能迁移与现代化
关键洞见： 选择，而非统一。
1. 成本管理思维
| 环境 | 方法 |
|---|---|
| Cloud‑first | 成本控制是 被动 的——团队在支出 发生后 才注意到，并争抢着去修复。 |
| Cloud‑smart | FinOps 是 主动 的——预算、警报和责任感已内置于系统。治理是 自动化 的，策略 一致 地执行。 |
2. 提出不舒服的问题
- 哪些应用真正 创造收入？
- 哪些应用 降低风险？
- 哪些仅因 没有人质疑它们 而存在？
许多组织会发现 僵尸应用——消耗资源却几乎没有价值的系统。
迁移这些并 不会 带来进展；退役它们才会。
3. 将工作负载与结果挂钩
云智能迁移在任何技术工作开始前，将每个工作负载关联到明确的结果。
4. 迁移策略（没有一刀切）
| 策略 | 适用情形 |
|---|---|
| Rehosting | 速度至关重要且风险容忍度低 |
| Replatforming | 使用托管服务快速获益，无需完整重写 |
| Refactoring | 对业务 具有差异化 的系统 |
| Retiring | 往往是最被低估的举措 |
错误： 强行让所有工作负载走同一条路。
最佳实践： 在 AWS 迁移与现代化计划中构建 灵活性。
5. 成本优化——设计决策
- 将架构与 AWS Well‑Architected 框架 对齐。
- 明确定义 身份与访问。
- 提前绘制 合规要求。
- 在系统中内建 可观测性，而不是后期添加。
结果： 更少的意外，技术和管理团队的信心更高。
6. 迁移后——真正的价值
- 性能提升
- 成本降低
- 可靠性提升
这些往往 超出 迁移本身的价值。
优化循环： 衡量 → 调整 → 改进 —— 持续循环。
7. 需要关注的信号
- AWS 成本增长 快于使用量 → 不匹配。
- 迁移后 性能下降 → 重新审视架构决策。
- 手动流程和工具蔓延 → 复杂性接管。
这些是 信号，而非失败。
8. 当 CFO 质疑云的 ROI 时
- 问题很少在于云本身，而是 云的使用方式。
- 尽管已采用云，发布周期仍慢 → 运营模型瓶颈。
- 创新被基础设施决策阻碍 → 云的承诺未实现。
回应： 重置，而非放弃。
9. 第 1 阶段：清晰
- 应用合理化
- 成本基准
- 风险识别
- 诚实的云就绪评估
领导者在 优先级与约束 上保持一致，防止后期返工。
10. 第 2 阶段：结构化迁移
- 绘制 依赖关系；规划 波次。
- 谨慎 排序；测试 回滚计划。
*目标：
组织之间的区别在于 有意的使用。
暂停重新评估的领导者会发现 惊人的机会 来：
- 简化
- 优化
- 智能化地现代化
最终思考
未来属于 云智能组织 —— 不是因为它们率先行动，而是因为它们 学会了明智地行动 。