Well-Architected Review 中最常见的指摘事项 - 现场工程师容易忽视的 5 个设计错误
解析 AWS Well-Architected Review 中反复被指出的设计问题，聚焦于单可用区部署、备份未设置、日志未活用、成本优化放置和安全组过度许可这 5 个方面。
什么是 Well-Architected Review
AWS Well-Architected Review 是由 AWS 解决方案架构师或认证合作伙伴从 6 大支柱（卓越运营、安全性、可靠性、性能效率、成本优化、可持续性）的角度审查客户工作负载的项目。使用 Well-Architected Tool 也可以自助进行审查。审查以问答形式进行，根据各问题的回答识别「高风险」和「中风险」问题。AWS 解决方案架构师实施数千次审查的经验表明，反复被指出的问题存在规律。
指摘 1：单可用区部署 - 最常见的可靠性问题
生产环境工作负载部署在单可用区是 Well-Architected Review 中最频繁被指出的问题。EC2 实例仅存在于一个可用区、RDS 为单可用区部署、ELB 仅关联到一个可用区的子网等模式。单可用区部署时，该可用区发生故障服务将完全停止。AWS 的可用区故障每年发生数次，绝非罕见事件。修复相对简单：在 Auto Scaling Group 的子网中指定多个可用区，RDS 启用 Multi-AZ，ELB 关联到所有可用区的子网。
指摘 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 的需求。
指摘 4：成本优化的放置 - 未使用资源的放置
为开发测试启动的资源被放置、产生不必要成本的情况是成本优化支柱中最常见的指摘。典型模式包括忘记停止的 EC2 实例、未附加的 EBS 卷、未使用的 Elastic IP 地址（未附加的 EIP 每小时收费 0.005 美元）、无流量的 NAT Gateway（每小时 0.045 美元 + 数据处理费）。AWS Trusted Advisor 的成本优化检查可以自动检测这些浪费的资源。
指摘 5：日志和监控的不足
CloudTrail 未启用、CloudWatch 告警未设置、应用程序日志未结构化等日志和监控的不足是卓越运营支柱中最常见的指摘。CloudTrail 默认记录管理事件，但如果未设置向 S3 的传送（创建跟踪），超过 90 天的事件将丢失。生产环境中务必创建跟踪，将日志长期保存到 S3。未设置 CloudWatch 告警会导致故障检测延迟。最低限度应设置 CPU 使用率、内存使用率（自定义指标）、磁盘使用率、ELB 的 5xx 错误率的告警。