评估 AWS 遗留环境

Source: Dev.to

介绍

您继承了一个历史不明的 AWS 账户。前任构建者在 18 个月前离职，承诺的文档也不见了。领导层想了解该环境是否可以现代化，但您首先需要一个清晰的全貌。

评估目标

回答三个简单的问题：

1. 我们在运行什么？
2. 它花费了我们多少？
3. 什么即将爆炸？

不要冗长的报告或花哨的图表——只要事实。

快速控制台演练

1. EC2 – 统计实例数量，检查它们的状态，并确认它们具有有意义的标签（而不是仅仅 i-0a1b2c3d4e5f）。
2. RDS – 列出数据库，记录引擎版本（查找过时的发行版）。
3. Lambda – 统计函数数量并尝试了解它们的用途。
4. Tags – 如果资源缺少标签，你将很难识别它们的角色。

成本优化

打开 Cost Explorer 并查看最近的账单。寻找明显的浪费：

• EC2 实例 24/7 运行，而实际上可以在夜间停止。
• 大量数据传输费用（例如，数 TB 数据下载到笔记本电脑）。
• NAT 网关的费用超过了它们所支持的应用程序。

常见的低垂果实

• 未附加的 EBS 卷 – 你在为“幽灵”存储付费。
• 空闲的负载均衡器 – 每个仍然约花费 ~$16 / 月。
• 未使用的弹性 IP – 每个地址每月 $3.60，累计很快。

安全检查

您不需要成为安全专家；只需验证一些基本事项：

• SSH 暴露 – 是否有安全组允许 0.0.0.0/0 访问 22 端口？
• 公共 S3 存储桶 – 除非明确需要，否则应设为私有。
• Root 账户使用 – 确保不用于日常任务。
• 访问密钥轮换 – 如果密钥从未轮换，这是一个危险信号。

AWS 工具如 Trusted Advisor 和 Security Hub 可以帮助发现这些问题，但手动控制台检查通常也能揭示相同的危险信号。

映射依赖关系

理解组件之间如何通信是难点。先从简单的开始：

1. 用户 → 负载均衡器
2. 负载均衡器 → 应用服务器
3. 应用服务器 → 数据库
4. 可选：S3 存储桶、Lambda 函数等。

如何发现连接

• 审查源代码（如果有的话）。
• 检查 CloudWatch 日志以了解流量模式。
• 与团队交流——初级开发者通常了解隐藏的线路。
• 在白板上快速绘制示意图：方框和箭头，无需精细打磨。

需要关注的警示信号

• 自 2019 年起运行的 EC2 实例，目的不明。
• 使用已到寿命终点的数据库引擎（例如 MySQL 5.6）。
• 通过 SSH 手动部署。
• 缺失或未测试的备份。
• 所有资源仅限于单个可用区。

成本高昂的做法

• 持续运行的过度配置实例。
• 使用自行管理的数据库，而 RDS 本可以更便宜、更容易。
• 缺乏自动伸缩，导致为未使用的容量付费。

根据“首先会对我们造成影响的”进行优先整改。

建立性能基准

在进行更改之前，捕获当前指标：

• 页面加载时间。
• 错误率。
• CPU / 内存利用率。
• 数据库查询延迟。

这些数字将成为您日后证明现代化价值的凭证。

文档检查清单

创建一份简洁的文档（Google Doc、Notion 等），包括：

• Inventory – 资源清单及其成本。
• Security issues – 按严重程度排序。
• Dependency map – 简单示意图。
• Technical debt – 优先级列表。
• Performance baseline – 上述捕获的指标。

不要 100 幻灯片的 PowerPoint，只需要点。

协作

• 验证所有内容；现有的 wiki 很可能已经过时。
• 让开发人员、运维人员以及值班工程师参与进来。
• 他们的见解将揭示隐藏在环境中的“尸体”。

时间线

• 评估：1–2 天，而不是几个月。
• 计数资源 可能很繁琐，但这是必不可少的。

下一步

现在你已经了解了正在运行的内容，可以开始规划：

• 哪些工作负载先迁移？
• 哪些资源可以退役？
• 哪些可以保持不动，因为它们运行良好？

目前，打开 AWS 控制台并开始点击。你很快就会看到环境的真实状态——并最终拥有前进所需的信息。