Well-Architected Review 中常见的审查意见 - 一线工程师忽略的 5 个设计错误
将 AWS Well-Architected Review 中反复被指出的设计问题聚焦为单可用区部署、未设置备份、未利用日志、忽视成本优化和安全组过度放行这 5 个方面进行解说。
什么是 Well-Architected Review
AWS Well-Architected Review 是一项由 AWS 解决方案架构师或认证合作伙伴审查客户工作负载的计划。审查从 6 大支柱（卓越运营、安全性、可靠性、性能效率、成本优化、可持续性）的角度进行。可持续性是 2021 年 12 月新增的最新支柱。使用 Well-Architected Tool，也可以以自助方式实施审查。审查以问答形式进行，根据对各问题的回答识别出“高风险”“中风险”的问题。被指出的问题存在规律，其中多数并非特定服务固有的难题，而是由于原样保留了设计时的初始设置。下面介绍审查中常见的 5 个代表性审查意见。这些并不是技术上高深的问题，而是“如果知道就能避免”的基本设计错误。
意见 1：单可用区部署 - 可靠性支柱中常见的问题
生产环境的工作负载部署在单个可用区的情况，是可靠性支柱中常被指出的问题。具体模式包括：EC2 实例只存在于 1 个可用区、RDS 采用单可用区部署、负载均衡器只关联了部分可用区的子网等。Application Load Balancer 在创建时必须指定 2 个以上可用区的子网（官方文档记载的要求 / 截至 2026 年 8 月）。因此，负载均衡器一侧的问题会以“没有将后来开始使用的可用区的子网添加到负载均衡器”“该可用区的目标没有注册”的形式出现。在单可用区部署中，一旦该可用区发生故障，服务就会完全停止。AWS 并未公布可用区故障的发生频率，但在单个可用区内完成的结构，存在“1 个可用区的异常会直接导致全部中断”的结构性风险。如果分散在多个可用区，原本只会损失部分容量的事件，在单可用区下会表现为服务全部停止。修复相对简单。只需在 Auto Scaling Group 的子网中指定多个可用区，将 RDS 改为多可用区部署，并为负载均衡器关联多个可用区的子网。多可用区部署带来的成本增加因部署方式而异。RDS 的多可用区数据库实例部署是增加 1 台备用实例的 2 台结构，因此实例费用约为 2 倍（截至 2026 年 8 月 / 官方文档记载的结构）。拥有 2 台可读备用实例的多可用区数据库集群部署是 3 台结构，因此约为 3 倍（截至 2026 年 8 月 / 官方文档记载的结构）。无论哪种情况，与服务停止造成的损失相比，都是合理的投资。开发 / 测试环境使用单可用区也没有问题，但生产环境请务必采用多可用区。
意见 2：未设置备份 - 数据丢失的风险
EBS 卷没有创建快照、RDS 的自动备份被禁用、DynamoDB 的时间点恢复（PITR）被禁用等备份缺失，也是常见的审查意见。也有因信赖 S3 的 11 个 9 的持久性而疏于备份的情况。但是，S3 的持久性针对的是物理性的数据丢失，并不防止误删除或恶意删除。如果没有启用 S3 的版本控制，被删除的对象就无法恢复。使用 AWS Backup，可以统一管理 EC2、EBS、RDS、DynamoDB、EFS、S3 的备份。定义备份策略，按照计划自动创建备份，并按照保留期限自动删除旧备份。不仅是创建备份，定期的还原测试也是重要的。即使存在备份，如果没有确立还原步骤，故障时也无法恢复。
意见 3：安全组放行 0.0.0.0/0
在安全组的入站规则中允许来自 0.0.0.0/0（所有 IP 地址）的访问的情况，是安全性支柱中代表性的审查意见。特别是将 SSH（端口 22）或 RDP（端口 3389）向 0.0.0.0/0 开放的情况属于高风险。互联网上的机器人一直在扫描开放的端口 22 和 3389，并自动执行暴力破解攻击。对策是将 SSH/RDP 的访问来源限定为特定的 IP 地址，或者使用 Systems Manager Session Manager 完全取消 SSH/RDP。使用 Session Manager 可以通过 IAM 认证访问实例，无需在安全组中开放端口。对于 Web 服务器，将 HTTP（80）和 HTTPS（443）向 0.0.0.0/0 开放是正当的。但推荐的设计是将其部署在 ALB 之后，EC2 实例的安全组仅允许来自 ALB 安全组的访问。
意见 4：忽视成本优化 - 放置不用的资源
为开发 / 测试而启动的资源被放置不管，持续产生不必要成本的情况，是成本优化支柱中常见的审查意见（以下费用为截至 2026 年 8 月 / 弗吉尼亚北部和东京的值）。典型的模式是忘记停止的 EC2 实例、未挂载的 EBS 卷、未使用的公有 IPv4 地址、没有流量的 NAT Gateway。自 2024 年 2 月 1 日起，无论公有 IPv4 地址是否挂载到服务，每小时都会收取 0.005 美元。不要只查找未挂载的 Elastic IP 就结束，停止状态的 EC2 实例以及未使用的负载均衡器 / NAT Gateway 持有的公有 IPv4 也请纳入盘点范围。NAT Gateway 每小时在弗吉尼亚北部收取 0.045 美元、在东京收取 0.062 美元，另加数据处理费用。因此，即使没有流量，只是放在那里，每月费用也会累积起来。AWS Trusted Advisor 的成本优化检查会自动检测这些浪费的资源。Cost Explorer 的“使用率低的资源”报告也是有效的。另一个常见的审查意见是没有利用 Savings Plans 或 Reserved Instances 的情况。AWS 对 Savings Plans 的说明是，与按需价格相比最多节省 72%（截至 2026 年 8 月）。让运行时间可预测的生产环境工作负载一直以按需价格运行，就等于原样错失了这部分折扣。请通过 Cost Explorer 的 Savings Plans 推荐功能确认最佳的承诺金额。
意见 5：日志与监控的不足
CloudTrail 未启用、未设置 CloudWatch 告警、应用程序日志未结构化等日志与监控的不足，是卓越运营支柱中常见的审查意见。CloudTrail 默认记录管理事件，但如果没有设置向 S3 的传送（创建跟踪），超过 90 天的事件就会丢失。在生产环境中，请务必创建跟踪，并将日志长期保存在 S3 中。如果没有设置 CloudWatch 告警，故障的检测就会延迟。请至少为 CPU 使用率、内存使用率（自定义指标）、磁盘使用率、ELB 的 5xx 错误率、RDS 的连接数设置告警。将应用程序日志以 JSON 格式结构化并发送到 CloudWatch Logs，就可以在 CloudWatch Logs Insights 中用类似 SQL 的查询进行分析。非结构化的文本日志在故障调查时只能用 grep 搜索，在大规模环境中并不实用。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。