AWS Well-Architected 架构评审实战：用免费的 Well-Architected Tool 给云端架构做一次全面体检（2026 版）
Meta Description: AWS Well-Architected Framework 六大支柱深度教程：一张表看懂每根支柱、35 条设计原则、18 个免费可用区域、16 款官方 Lens、CLI 全流程，以及 2026 年新增的 Well-Architected Agent，教你把架构评审接进运维流水线。
> 关键词：AWS Well-Architected、六大支柱、架构评审、Well-Architected Tool、成本优化支柱、可靠性支柱、Well-Architected Agent、AWS 免费套餐
前言
一句话结论：AWS Well-Architected（下称 WA）是 AWS 官方唯一"方法论免费读、工具免费用、账单里不会多出一分钱"的架构治理体系。 方法论（Framework）任何人都能直接读，配套工具（Well-Architected Tool）任何 AWS 账号登录控制台即可使用，官方定价页的原话是"no additional charge"。
如果你踩过下面这些坑，这篇就是为你写的：
- 服务上线三个月后才发现「没做多可用区」，此时改造要停机、成本翻好几倍； - CloudWatch 告警配了几十条，但没人说得清「哪几条真正对应业务风险」； - 每个月打开 Cost Explorer 看账单曲线，却答不出「这个月的增长是正常业务增长，还是架构浪费」。
WA 评审解决的正是这类问题：它把「架构好不好」从一个主观争论，变成一份可打分、可留痕、可逐季度对比的答卷。无论你是刚起步的个人开发者，还是维护着几十个工作负载的架构团队，WA 都是 AWS 上性价比最高的一套「体检流程」——因为它本身不收钱。
本文按 2026 年 9 月的最新口径写成，涵盖：三层服务体系（Framework / Tool / Agent）、六大支柱与全部 35 条设计原则、免费口径与真实隐性成本、控制台 15 分钟实操、CLI 全流程、16 款官方 Lens 清单，以及它与 Cost Explorer、Trusted Advisor、Compute Optimizer、AWS Config 的边界划分。
> ⚠️ 文中价格与配额为 2026 年 9 月采集的参考值，实际以 AWS 官网与你的控制台为准。
一、先分清三层：Framework、Tool、Agent 各是什么
新手最容易混淆的一点是：「Well-Architected」不是一个产品，而是三层叠在一起的东西。 搞清楚分工，后面所有操作都会变得清晰。
第一层：AWS Well-Architected Framework（方法论，免费阅读）。 这是 2015 年由 AWS 解决方案架构师团队基于大量真实案例总结的一套架构最佳实践。官方定义是：它让你用一套一致的方法评审架构，并随着时间推移持续改进设计。框架把最佳实践组织成六大支柱，每个支柱下再拆成「设计原则 → 问题 → 最佳实践（BP）」三级结构。目前框架正文的条目编号形如 COST01-BP01、REL13-BP05、SUS06-BP04，可以直接在文档里检索。
第二层：AWS Well-Architected Tool（自带工具，控制台内免费）。 官方定义是「一项云端服务，提供一套一致的流程，用 AWS 最佳实践来衡量你的架构」。它把你的评审过程数据化：创建 workload（工作负载）→ 逐题作答 → 自动生成 improvement plan（改进计划）→ 保存 milestone（里程碑）→ 逐季度对比。工具的价值不在「提问」，而在留痕：半年后你能拿出数据回答「我们到底改进了没有」。
第三层：AWS Well-Architected Agent（2026 年新增，AI 生成建议）。 从 2026 年 CLI 定义可以看出这一层已经并入正式 API：官方描述明确写道，该服务包含 AWS Well-Architected Agent，用于基于你特定环境生成 AI 驱动的建议。它把「人工逐题作答」向前推进了一步：只要给出环境上下文与业务目标，Agent 就能生成一份针对性的架构建议清单。注意它目前有严格配额——每天每账号 5 次按需生成，且 Profile（Agent 档案）默认配额为 0，需要单独开通。
| 层级 | 形态 | 你要做的事 | 费用 | |---|---|---|---| | Framework（框架） | 公开文档 | 阅读、对标、引用条目编号 | $0 | | Tool（工具） | 控制台 + API/CLI | 创建工作负载、作答、存里程碑、导出报告 | $0 | | Agent（智能体） | API/CLI + 控制台 | 提供上下文与目标，生成 AI 架构建议 | $0（有每日次数配额） |
一句话记忆法：Framework 是教科书，Tool 是答题卡，Agent 是请了一位随时在线的架构顾问——三者都不收费，收费的是你按建议去改架构时新建的那些 AWS 资源。
二、六大支柱总览：每根支柱到底回答什么问题
官方口径：通用的设计原则与具体的 AWS 最佳实践，被组织成六个概念领域，这六个领域就是 Well-Architected Framework 的支柱（pillars）——卓越运营、安全、可靠性、性能效率、成本优化、可持续性。注意最后一根「可持续性」是 2021 年新增的，很多老教程还停留在「五大支柱」，遇到这种写法就知道文章过期了。
| 支柱 | 英文（官方命名） | 它要回答的核心问题 | 设计原则数 | |---|---|---|---| | 卓越运营 | Operational Excellence | 团队能不能把系统「运营好」——组织、可观测性、变更管理 | 7 | | 安全 | Security | 身份、权限、数据、检测、响应能不能构成纵深防御 | 7 | | 可靠性 | Reliability | 单点故障、容量、变更、备份、灾备能不能扛住 | 5 | | 性能效率 | Performance Efficiency | 选型、算力、存储、网络、缓存有没有用对 | 5 | | 成本优化 | Cost Optimization | 钱花在哪、花得值不值、能不能少花 | 5 | | 可持续性 | Sustainability | 资源利用率、区域选择、软硬件更新、下游影响 | 6 |
合计 35 条设计原则，加上 6 条「通用设计原则」，构成 WA 评审的全部理论基础。 下面这张表把 35 条原则一次性列全，建议收藏——它是判断一篇 WA 教程是否认真写过的试金石（很多文章只会复述六个支柱的名字，列不出原则）。
三、35 条设计原则速查表（官方原文口径）
3.1 通用设计原则（6 条，适用于所有支柱）
| # | 设计原则 | 一句话解释 | |---|---|---| | G1 | Stop guessing your capacity needs（别再猜容量） | 容量决策失误不是闲置昂贵资源，就是性能事故；用弹性替代预测 | | G2 | Test systems at production scale（按生产规模测试） | 云上可以按需拉起生产级测试环境，测完即销毁，只为用掉的时间付费 | | G3 | Automate with architectural experimentation in mind（为实验而自动化） | 自动化让工作负载可以被低成本复制与验证，把「改架构」变成可回滚的实验 | | G4 | Consider evolutionary architectures（拥抱演进式架构） | 架构决策不应是一次性事件，要能随业务迭代随时演进 | | G5 | Drive architectures using data（用数据驱动架构） | 收集架构选择对工作负载行为的影响数据，用事实而非直觉做决策 | | G6 | Improve through game days（用 Game Day 改进） | 定期安排「演练日」在生产环境模拟事件，暴露流程与架构的薄弱点 |
3.2 卓越运营（7 条）
| # | 设计原则 | 关键动作 |
|---|---|---|
| OE1 | Organize teams around business outcomes | 团队围绕业务结果组织，而不是围绕技术栈 |
| OE2 | Implement observability for actionable insights | 建立 KPI 与可观测性，让洞察可执行——对应 OPS04、OPS08 系列条目 |
| OE3 | Safely automate where possible | 把工程纪律应用到整个环境，用代码定义工作负载与运维 |
| OE4 | Make frequent, small, reversible changes | 小步、频繁、可回滚的变更，降低单次变更风险面 |
| OE5 | Refine operations procedures frequently | 运维流程随工作负载演进定期复盘与更新 |
| OE6 | Anticipate failure | 主动驱动故障场景，理解风险画像对业务结果的影响 |
| OE7 | Learn from all operational events and metrics | 从所有运维事件中提炼教训并跨团队共享 |
3.3 安全（7 条）
| # | 设计原则 | 关键动作 | |---|---|---| | SEC1 | Implement a strong identity foundation | 最小权限 + 职责分离 + 集中化身份管理（IAM Identity Center） | | SEC2 | Maintain traceability | 实时监控、告警、审计环境变更，日志与指标自动联动响应 | | SEC3 | Apply security at all layers | 纵深防御：从边缘网络、VPC、负载均衡到实例与操作系统逐层设防 | | SEC4 | Automate security best practices | 用自动化机制规模化、低成本地落实安全控制 | | SEC5 | Protect data in transit and at rest | 按敏感度分级，使用加密、令牌化与访问控制 | | SEC6 | Keep people away from data | 减少人工直连与手工处理敏感数据的机会，降低误操作 | | SEC7 | Prepare for security events | 具备事件管理与调查流程，定期做响应演练 |
3.4 可靠性（5 条）
| # | 设计原则 | 关键动作 | |---|---|---| | REL1 | Automatically recover from failure | 用 KPI 监控，触发自动恢复而非人工救火 | | REL2 | Test recovery procedures | 在云上主动制造故障，验证恢复流程真的可用 | | REL3 | Scale horizontally to increase aggregate workload availability | 用横向扩展替代单点纵向扩容 | | REL4 | Stop guessing capacity | 监控需求并自动扩缩容，避免容量猜测 | | REL5 | Manage change through automation | 用自动化管理变更，减少人为引入的故障 |
3.5 性能效率（5 条）
| # | 设计原则 | 关键动作 | |---|---|---| | PERF1 | Democratize advanced technologies | 把高级技术用托管服务「民主化」，不必自建团队精通 | | PERF2 | Go global in minutes | 多区域部署只需几分钟，就近服务用户 | | PERF3 | Use serverless architectures | 无服务器架构免去运维服务器，也免去为闲置付费 | | PERF4 | Experiment more often | 云上可以随时对比不同配置，用实验替代争论 | | PERF5 | Consider mechanical sympathy | 了解所用技术的底层特性，让方案与硬件/系统特性匹配 |
3.6 成本优化（5 条）
| # | 设计原则 | 关键动作 |
|---|---|---|
| COST1 | Implement Cloud Financial Management | 把云财务管理当成一项组织能力来建设（对应 COST01 全部 BP） |
| COST2 | Adopt a consumption model | 只为实际用量付费，随时增减——官方举例：开发测试环境一周只用 8 小时/天，停掉闲置可省约 75% |
| COST3 | Measure overall efficiency | 度量业务产出与对应成本，看的是「每一元换来的产出」 |
| COST4 | Stop spending money on undifferentiated heavy lifting | 数据中心运营、操作系统维护交给 AWS 与托管服务 |
| COST5 | Analyze and attribute expenditure | 精确归因成本到工作负载负责人，才能度量 ROI |
3.7 可持续性（6 条）
| # | 设计原则 | 关键动作 | |---|---|---| | SUS1 | Understand your impact | 度量工作负载当前与未来的环境影响（含客户使用环节） | | SUS2 | Establish sustainability goals | 为每个工作负载设定长期目标，例如降低单笔交易的算力与存储 | | SUS3 | Maximize utilization | 合理规格化并提升利用率——两台 30% 利用率的机器不如一台 60% 的机器环保 | | SUS4 | Anticipate and adopt new, more efficient hardware and software offerings | 持续跟进合作伙伴与 AWS 更高效的硬件/软件迭代 | | SUS5 | Use managed services | 共享服务能最大化资源利用率，托管服务天然更省资源 | | SUS6 | Reduce the downstream impact of your cloud workloads | 降低终端能耗、减少用户被迫升级设备的需求 |
四、费用真相：工具本身 $0，但有四处「隐性成本」
官方定价页和 FAQ 的表述完全一致，可以直接引用：
> There is no additional charge for the AWS Well-Architected Tool. You pay only for your underlying AWS resources.
也就是说：创建 workload、应用 Lens、作答、存里程碑、生成报告、分享给其他账号——全部免费。 官方 Lens 目录里的所有镜头都是免费且无需额外安装的。这一点和很多"免费但有额度"的服务不同——它不是"每月前 N 次免费"，而是压根不计费。
但"免费"不等于"零成本"。写 WA 教程时最值钱的一段，恰恰是把它背后的账算清楚：
| 成本项 | 是否收费 | 说明 | |---|---|---| | WA Tool 使用本身 | $0 | 无按月额度上限概念，官方定价页原文就是 no additional charge | | 官方 Lens（16 款） | $0 | 在镜头目录中直接可用，不额外安装、不额外计费 | | 自定义 Lens / 评审模板 / 里程碑 | $0 | 仅受配额限制（见下表），不受计费限制 | | 改进项落地新建的资源 | 照常计费 | 例如按可靠性支柱把单可用区 RDS 改成多可用区，数据库费用直接约 ×2 | | 评审人力 | 真实但账面外 | 一次完整的六支柱评审通常需要架构、开发、运维、安全多方参与，按半天到一天预估 | | Well-Architected Agent 建议生成 | $0，但有次数限制 | 每账号每天 5 次按需生成；Profile 默认配额为 0，需申请开通 |
配额速查（官方 Service Quotas 口径，均为"不可调整"）：
| 配额项 | 默认值 | 是否可调 | |---|---|---| | 每账号每区域 workload 数 | 1,000 | 否 | | 每个 workload 的里程碑数 | 100 | 否 | | 每个 workload 可挂载的 Lens 数 | 20 | 否 | | 每账号每区域可创建的 Lens 数 | 15 | 否 | | 每个 Lens 的支柱数 | 10 | 否 | | 每个支柱的问题数 | 20 | 否 | | 每个问题的选项数 | 15 | 否 | | Lens 体积上限 | 500 KB | 否 | | 每账号每区域评审模板数 | 500 | 否 | | 每个 workload 的分享数 | 20（Lens 分享上限 300） | 否 | | 每日按需架构建议生成次数 | 5 | 否 | | 每账号的 Agent Profile 数 | 0（需开通） | 否 |
与 2026 免费套餐的关系要讲清楚： WA Tool 不吃免费套餐额度，因为它本身是 $0。但如果你在评审后按建议新建资源，那些资源会正常消耗账号额度。2026 年现行免费计划口径是：免费计划自账号创建起最长 6 个月（到期或额度耗尽，以先到者为准），额度最高 $200（注册即得 $100，完成入门操作最多再得 $100），额度需在12 个月内用完；账号一旦加入 AWS Organizations 或建立 Control Tower landing zone，额度立即失效并自动转为付费计划。所以「先注册、做完 WA 评审、再按建议整改」这个顺序，是最省钱的顺序。
五、实操一：控制台 15 分钟完成第一次评审
WA Tool 的控制台入口是 console.aws.amazon.com/wellarchitected。整个首次评审流程可以压到 15 分钟内：
1. 选区域。 右上角切到你要评审的工作负载所在地域（建议与工作负载同域，分享功能才生效，见第八节坑 3）。
2. 定义工作负载。 填写 workload 名称、描述、环境（PRODUCTION 生产 / PREPRODUCTION 预生产）、行业类型、涉及的 AWS 区域、评审负责人。这一步就是给"体检对象"建档。
3. 应用 Lens。 默认会挂上 AWS Well-Architected Framework 这一默认镜头；如果你的工作负载是纯无服务器架构，可以额外挂 Serverless Applications 镜头一起评审。
4. 可选：套用 Profile 或评审模板。 Profile 用来预定义本次评审想达成的业务目标，应用后工具会自动生成一份最相关问题的优先级列表；评审模板则用于把多个工作负载之间通用的答案预填进去，减少重复劳动。
5. 逐题作答。 每题给若干选项（互斥），不确定的可以先标记 Not applicable（不适用）——但请记住，滥用"不适用"会让评审失去意义。
6. 看改进计划。 工具会输出一份 improvement plan，按支柱分组、按优先级排序，其中最严重的一类是 HRI（High Risk Issue，高风险问题）。先改 HRI，再看其他。
7. 存里程碑。 首次评审完成后立刻点 Save milestone，命名为「2026-Q3-基线」。里程碑是 WA 最有价值的机制——半年后你再存一个，就能量化回答"我们改进了多少"。
官方对评审时机的建议是一句话：在工作负载开发周期的主要里程碑（major milestones）进行评审。翻译成工程语言就是：立项定型时、上线前、以及每次重大架构变更后各做一次。
六、实操二：用 CLI 把评审接进流水线
WA Tool 提供完整的 API/CLI，可以把评审接入你已有的架构治理流程。以下命令全部经过官方 CLI 参考页核对：
`bash
// 1. 先列出当前区域可用的镜头（返回的 lens alias 才是后面要用的值）
aws wellarchitected list-lenses --region ap-southeast-1
// 2. 创建工作负载并应用框架默认镜头 aws wellarchitected create-workload \ --workload-name "order-service-prod" \ --description "订单服务生产环境" \ --environment PRODUCTION \ --lenses "wellarchitected" \ --aws-regions "ap-southeast-1" "ap-northeast-1" \ --review-owner "arch-team" \ --region ap-southeast-1
// 3. 记录返回的 WorkloadId，后续所有命令都要用 aws wellarchitected list-workloads --region ap-southeast-1
// 4. 拿到该镜头下所有问题与选项（question-id / choice-id 从这里取） aws wellarchitected get-lens-review \ --workload-id WORKLOAD_ID \ --lens-alias wellarchitected \ --region ap-southeast-1
// 5. 逐题作答：把选中的选项 id 传给 --selected-choices aws wellarchitected update-answer \ --workload-id WORKLOAD_ID \ --lens-alias wellarchitected \ --question-id QUESTION_ID \ --selected-choices CHOICE_ID \ --region ap-southeast-1
// 6. 答完基线，存一个里程碑，日后可逐期对比 aws wellarchitected create-milestone \ --workload-id WORKLOAD_ID \ --milestone-name "2026-Q3-基线" \ --region ap-southeast-1
// 7. 导出整份评审报告（JSON，可直接入库或喂给 BI） aws wellarchitected get-lens-review-report \ --workload-id WORKLOAD_ID \ --lens-alias wellarchitected \ --region ap-southeast-1
// 8. 只看"改进项"清单，方便开成工单
aws wellarchitected list-lens-review-improvements \
--workload-id WORKLOAD_ID \
--lens-alias wellarchitected \
--region ap-southeast-1
`
几个必须知道的参数细节（这些是容易写错的地方）：
- update-answer 的选项参数叫 --selected-choices（复数），另有 --is-applicable、--reason、--notes 三个辅助参数，分别用于标记不适用、填写理由、写备注；
- create-workload 的 --environment 只接受 PRODUCTION 与 PREPRODUCTION 两个值；
- create-workload 还支持 --pillar-priorities（支柱优先级）、--profile-arns（业务目标档案）、--jira-configuration（把评审结果直连 Jira）、--review-template-arns、--applications、--industry-type 等进阶参数——--jira-configuration 是把它接进研发流程的关键，改进项可以直接生成工单；
- 没有"更新某题答案"之外的批量作答命令，批量导入要自己写脚本循环调用 update-answer。
把它做成季度例行任务的最小方案： 每季度跑一次「list-lens-review-improvements → 按 HRI 过滤 → create-milestone 归档」。三个月后对比两个里程碑之间的 HRI 数量变化，这个数字比任何"架构健康度评分"都更能向上汇报。
七、边界表：WA 评审 vs 其他六个治理工具，别搞混
AWS 上做"架构与成本治理"的工具至少有七个，它们回答的问题完全不同。先看这张表，再决定该开哪个工具——这也是很多团队"买了一堆工具却没人用"的根因。
| 工具 | 它回答的问题 | 数据来自哪 | 计费方式 | 相关阅读 | |---|---|---|---|---| | Well-Architected Tool | 架构是否遵循最佳实践（六大支柱） | 团队人工作答 / Agent 生成建议 | $0 | 本篇 | | Trusted Advisor | 账号里有没有明显的问题（开放端口、公开快照、无 MFA 的 root） | AWS 自动扫描 | 免费档 56 项检查；Business Support+ 解锁至 482 项 | 见 2026-09-19 成本体检篇 | | Compute Optimizer | 这台资源该多大（降配还是扩配） | CloudWatch 指标机器学习 | 免费（Enhanced metrics 另行收费） | 同上 | | Cost Explorer | 钱花在哪、趋势如何 | 账单 / CUR | 免费（API 有调用额度） | 见 2026-08-16 高阶用法篇 | | AWS Budgets | 快超预算了吗 | 账单 | 前 2 个预算免费 | 见 2026-08-25 预算告警篇 | | AWS Config | 资源配置是否合规、有无漂移 | 配置项记录 | 按配置项 / 规则评估计费 | 见 2026-09-24 合规审计篇 | | Control Tower | 多账号的治理基线是否落地 | Organizations + landing zone | 按 OU / 账号计费 | 见 2026-08-19 成本治理篇 |
一句话概括分工：WA 评审回答"该不该这么设计"（前瞻、方法论），Trusted Advisor 与 Config 回答"现在的配置有没有问题"（现状、自动化），Compute Optimizer 与 Cost Explorer 回答"钱花得对不对"（量化、账单）。 四者不重叠，正确顺序是「先 WA 定标准 → 再自动化工具查现状 → 最后账单工具算钱」。
八、2026 新增能力：Well-Architected Agent 与 16 款官方 Lens
Well-Architected Agent 是 2026 年 WA 体系最大的变化——它把"AI 生成的架构建议"并进了正式 API。相关 CLI 命令已全部上线：create-agent-profile、create-agent-context、create-agent-goal、start-agent-recommendation-generation、list-agent-recommendations、list-agent-recommendation-items、get-agent-recommendation、update-agent-recommendation-status、put-agent-recommendation-feedback。
几条必须知道的现实约束：每天每账号仅 5 次按需生成；Agent Profile 默认配额为 0、且不可自助调整，需先开通；生成出来的建议仍需人工核验后再落地——把它当成"给你一份初稿"，而不是"替你签字画押"。
16 款官方 Lens 目录（全部免费、无需额外安装）：
| Lens 名称 | 适用场景 | |---|---| | AWS Well-Architected Framework | 默认镜头，所有工作负载都会挂上，覆盖六大支柱 | | Connected Mobility | 交通系统与出行体验 | | Container Build | 容器镜像的设计与构建流程 | | Data Analytics | 大数据分析工作负载设计要素 | | DevOps | 高速度、安全优先的 DevOps 文化与交付 | | Financial Services Industry | 金融行业工作负载 | | Generative AI | 生成式 AI 工作负载 | | Government | 政府与公共服务 | | Healthcare Industry | 医疗健康工作负载 | | IoT | 物联网工作负载 | | Mergers and Acquisitions | 并购期间的工作负载整合与上云 | | Machine Learning | 机器学习资源与工作负载 | | Migration | 迁移上云专项 | | SaaS | SaaS 多租户架构 | | SAP | SAP 工作负载 | | Serverless Applications | 无服务器（REST 微服务、移动后端、流处理、Web 应用） |
选镜头的实用建议： 与其一次挂满，不如按工作负载性质只挂 1–2 个。纯无服务器架构挂 Serverless Applications，做数据分析的挂 Data Analytics，做多租户的挂 SaaS。一个 workload 最多可挂 20 个 Lens，但每多挂一个，评审题目就多几十道——这是评审开不完的头号原因。
九、落地 5 招：让评审真正产生价值
第 1 招：先用 Profile 圈定业务目标，别一上来就全量作答。 Profile 的作用是"预定义本次评审想达成的业务目标"，应用后工具会自动挑出最相关的问题并排好优先级。对刚起步的团队，这能把首次评审从 100+ 题压到 20–30 题。
第 2 招：用评审模板消灭重复劳动。 如果你有 10 个同类工作负载，把共性的答案做成 review template，每个新 workload 直接套用。手工重复填 10 遍是评审最大的时间黑洞。
第 3 招：把 KPI 定成「高风险项数量」而不是「总分」。 总分容易被"多选几个不适用"刷高，而 HRI 数量是硬指标。每季度对比里程碑中的 HRI 变化，才是可汇报的进展。
第 4 招：认真使用「Not applicable」。 它存在的意义是让评审聚焦——不相关的题就标记掉并写清 --reason。但滥用它等于自欺欺人，评审的价值全部来自"承认问题"。
第 5 招：把改进项直接开成工单。 create-workload 支持 --jira-configuration 参数，一次配置就能把 WA 的改进项送进研发流程。评审结果如果只躺在控制台里，三个月后没人会再看它一眼——这一步是"评审"和"改进"之间的分水岭。
十、七个最容易踩的坑
坑 1：把 WA 评审当成"一次性考试"。 很多人做完一次评审、看一眼改进计划就再也不打开工具。WA 的正确用法是"里程碑 + 复评"：每次重大变更存一个里程碑，用里程碑之间的差异证明改进。一次性评审的价值会随时间迅速衰减。
坑 2：一次挂满 Lens，题目多到评审开不完。 一个 workload 最多挂 20 个 Lens、每支柱 20 题，全挂的话题量是几百道。按工作负载性质只挂 1–2 个，其余等需要时再补。
坑 3：忽略了"分享仅限同一区域"这条硬限制。 官方明确：workload 与自定义 Lens 只能分享给同一 AWS 区域内的其他 AWS 账号或 IAM 用户，或通过 AWS Organizations 分享给整个组织。如果你把 workload 建在新加坡，而评审团队的工作账号在东京，直接分享会失败——要么两边同区域，要么走 Organizations。
坑 4：改进项一次性全落地，账单原地暴涨。 这是本文反复强调的一条：WA Tool 免费，但按建议新建的资源要钱。可靠性支柱让你"多可用区部署"，成本优化支柱让你"用 Savings Plans 降本"——两条建议的效果可以互相抵消。正确做法是按 HRI 严重程度 × ROI 排序，分季度滚动落地。
坑 5：以为"换个 Lens 就是一次新评审"。 Lens 是叠加关系，不是替换。当你升级镜头版本（upgrade-lens-review）时，新版本里新增的问题会并入现有评审，需要重新作答——升级前先存一个里程碑，否则改动前的状态就没法回溯了。
坑 6：把「Not applicable」当默认答案刷高分数。 这是最隐蔽的一种失真。工具本身不阻止你这么做，但评审的意义就此归零。建议在团队规范里写死一条：任何 Not applicable 都必须填 --reason，让人工可复核。
坑 7：把 Agent 的建议直接照抄上线。 Agent 每天只有 5 次按需生成配额，输出的是"针对你环境的初稿建议"，不构成架构决策。落地前必须过一遍人工评审，尤其要核对建议里隐含的成本影响。
十一、常见问题 FAQ
Q: AWS Well-Architected Tool 真的完全免费吗？ A: 是的。官方定价页与 FAQ 的原文口径一致：「There is no additional charge for the AWS Well-Architected Tool. You pay only for your underlying AWS resources.」创建 workload、应用 Lens、作答、存里程碑、导出报告、分享给其他账号全部不产生费用；真正的花费来自你按建议新建的那些 AWS 资源。
Q: 一次完整的 WA 评审要花多久？ A: 首次建档 + 作答，聚焦版（用 Profile 圈定范围）约 15–60 分钟；完整六支柱全量评审通常需要跨团队半天到一天。官方建议在开发周期的主要里程碑进行，通常一个季度一次。
Q: 六个支柱必须全做吗？小项目有必要吗？ A: 不必须。工具允许只评审部分支柱或用 Profile 聚焦；个人项目也可以只做「安全 + 成本优化」两根支柱——先把 root 账号 MFA、S3 桶权限、闲置资源这三件事解决掉，收益就已经很实在。
Q: Well-Architected Tool 在哪些区域可用？中国大陆能就近访问吗？ A: 官方端点页列出 18 个商业区域 + 2 个 GovCloud 区域，亚洲可用的包括 ap-east-1（中国香港）、ap-northeast-1（东京）、ap-northeast-2（首尔）、ap-south-1（孟买）、ap-southeast-1（新加坡）、ap-southeast-2（悉尼）。华人团队就近首选香港或新加坡。注意：WA 目前没有中国大陆（北京/宁夏）区域端点。
Q: WA 评审和 AWS Config 的合规审计是一回事吗？ A: 不是。WA 评审是前瞻性的架构方法论问答（"你该怎么设计"），靠人工作答或 Agent 建议；Config 是事后的资源配置合规审计（"你的资源现在合规吗"），靠自动记录配置项与规则评估，且按配置项计费。两者互补：WA 定标准，Config 查落地。
Q: 一个账号能建多少个工作负载？ A: 每账号每区域 1,000 个 workload，每个 workload 最多 100 个里程碑、最多挂 20 个 Lens。这些配额官方标注为不可调整——对绝大多数团队来说绰绰有余。
Q: Well-Architected Agent 收费吗？ A: 不额外收费，但有严格配额：每天每账号 5 次按需架构建议生成，且 Agent Profile 的默认配额是 0、需要单独开通。把它当作"少量、高价值的定向建议"，而不是批量刷建议用的工具。
Q: 评审结果能导出成结构化数据吗？
A: 可以。get-lens-review-report 导出整份评审报告（JSON），list-lens-review-improvements 只导出改进项清单，get-consolidated-report 可跨 Lens 汇总，list-check-summaries / list-check-details 拿到逐项检查明细。这些命令让 WA 可以直接接入自建看板或数据仓库。
总结
把这篇的核心结论压缩成五句话：
1. WA 是三层体系：Framework 免费读、Tool 免费用、Agent 免费但限次；三者本身都不进账单。
2. 六大支柱共 35 条设计原则 + 6 条通用原则，其中「可持续性」是 2021 年新增的第六根支柱——老教程的"五大支柱"已经过期。
3. 工具免费，但改进项落地要钱，所以要按 HRI 严重程度 × ROI 分季度滚动落地，而不是一次改完。
4. CLI 是把它接进治理流程的关键：create-workload → get-lens-review → update-answer → create-milestone → get-lens-review-report，五条命令就能构成一个季度复评流水线。
5. WA 与 Trusted Advisor / Config / Compute Optimizer / Cost Explorer 不重叠：WA 定标准，自动化工具查现状，账单工具算钱，顺序不能颠倒。
如果你现在还没有一个 AWS 账号，可以先把免费计划开起来（6 个月、最高 $200 额度），在额度有效期内跑完第一次 WA 评审——这大概是 AWS 免费套餐里"最值钱的用法"之一。
> ⚠️ 文中价格为 2026 年 9 月采集的参考值，价格与配额可能变动，实际费用与最新口径请以 AWS 官网为准。
> 🚀 需要 AWS 国际版账号？通过 3.chengzicloud.cloud 获取最新注册教程与专属优惠，助你轻松上云。
相关阅读：
- AWS 成本体检实战：Trusted Advisor + Compute Optimizer - AWS Config 配置合规审计实战 - AWS 迁移上云实战：MGN + DMS + DataSync - AWS Cost Explorer 高阶用法 - AWS Control Tower 成本治理 - AWS Budgets 预算告警实战
> 本文由 3.chengzicloud.cloud 提供，点击访问首页了解更多