AWS Well-Architected Agent 预览：把「架构最佳实践」变成可自动执行的修复

2026 年 10 月 2 日，AWS 宣布 AWS Well-Architected Agent 进入预览。按 AWS 的表述，它是一个 AI 驱动的服务，是 AWS Trusted Advisor 与 AWS Well-Architected Tool 的「下一代演进」：跨成本、安全、性能与可靠性四个维度分析并优化 AWS 基础设施，把关键指标与应用拓扑对照 Well-Architected 最佳实践，并分析 Terraform、CDK 与 CloudFormation 模板，在适用时给出「可直接执行」的修复。它最有意思的地方不是「AI 帮你看架构」，而是它把长期停留在「建议清单」层面的最佳实践，第一次推到了「带 runbook 的修复」这一侧。

一、它到底是什么：两个老工具的「Agent 化」

先把事实列清楚。按 AWS 的公告，AWS Well-Architected Agent 是一个 AI 驱动的服务，是 AWS Trusted Advisor 与 AWS Well-Architected Tool 的下一代演进。它要跨成本、安全、性能与可靠性四个维度分析和优化 AWS 基础设施，并交付按业务目标排序的情境化建议；同时它会自动关联关键指标与应用拓扑，对照 Well-Architected 最佳实践，并分析 Terraform、CDK 与 CloudFormation 模板。这个定位很关键：它不是又一个「合规打分面板」，而是把已经用了多年的 Well-Architected 框架，换成一个会读你真实环境的 Agent 来填空。服务于 2026 年 10 月进入预览。

# What AWS announced, in one object. The framing matters: this is not a
# new dashboard. It is the next-generation evolution of two existing
# tools, now driven by an agent.

WELL_ARCHITECTED_AGENT = {
    "announced": "2026-10-02 (preview)",
    "kind": "AI-powered service",
    "evolves": ["AWS Trusted Advisor", "AWS Well-Architected Tool"],
    "pillars": ["cost", "security", "performance", "reliability"],
    "output": "contextualized recommendations prioritized by business goals",
}

# The pillar set is the same Well-Architected frame teams already use;
# what changes is that an agent reads your actual estate to fill it in.

不是新面板，而是两个老工具的下一代演进

二、分析什么：实时信号 + 代码模板

按 AWS 的描述，这套分析是基于证据、而非基于清单的。它把关键指标与应用拓扑自动关联起来，对照 Well-Architected 最佳实践进行分析；同时把基础设施即代码也纳入视野——分析 Terraform、CloudFormation 与 CDK 模板，识别其中的差距，并返回为对齐最佳实践所需的具体代码改动。也就是说，它的输入一头是运行时的实时信号，另一头是你仓库里的模板，两者一起决定了建议的准确性。对已经在用 IaC 的团队来说，后半部分往往比前半部分更省事：改动直接落到代码，而不是落到某个人脑子里的待办。

# The analysis is meant to be evidence-based, not checklist-based.
# AWS describes correlating live signals against best practices.

ANALYSIS_INPUTS = {
    "key_metrics": "correlated automatically",
    "application_topology": "correlated against Well-Architected best practices",
    "infrastructure_as_code": ["Terraform", "CDK", "CloudFormation"],
}

def review(estate, goals):
    findings = correlate(estate.metrics, estate.topology, BEST_PRACTICES)
    findings += review_iac(estate.iac)       # identifies gaps in templates
    return prioritize(findings, by=goals)

# Where applicable, the IaC review returns the actual code changes needed
# to align with Well-Architected best practices.

三、按业务目标排序：让建议真的能用

「排序」是让这类工具真正可用的关键。按 AWS 的说明，团队可以定义业务目标，然后获得在资源、应用与架构三个层级上、按影响与工作量排序的建议。官方给了一个具体例子：一个把可靠性放在首位的团队，可能会收到「给一个关键数据库加上多可用区故障转移」的建议，随附一份可自动执行该配置变更的 SSM runbook，以及一份跨支柱分析，展示这次改动在提交之前会对成本与性能产生什么影响。这里的「跨支柱」视角，恰恰是大多数工具缺失的部分——针对某一根支柱的修复，往往是另一根支柱上的成本或延迟变化。

# Prioritisation is the feature that makes this usable. You define
# business goals, and recommendations come back ranked by impact and
# effort at three levels.

LEVELS = ["resource", "application", "architecture"]

def example_reliability_first():
    """A team prioritising reliability gets specific, actionable output."""
    return {
        "recommendation": "add multi-AZ failover to a critical database",
        "delivered_with": [
            "an SSM runbook that automates the configuration change",
            "a cross-pillar analysis of cost and performance impact",
        ],
        "before_you_commit": "see the effect on cost and performance",
    }

# The cross-pillar view is the part most tools miss: a fix for one pillar
# is a cost or latency change in another.

一次修复，牵动多根支柱：跨支柱分析是关键

四、可直接执行：从「建议」到「修复物」

这套服务的真正转变，是把输出从「建议」推进到「修复物」。按 AWS 的说明，在适用的情况下，建议会随附 SSM runbooks、可直接执行的 CLI 脚本以及分步控制台指引；对 IaC 模板，它还会返回为对齐最佳实践所需的具体代码改动。对工程团队而言，这意味着产物可以进入既有的代码审查与变更流程，而不是停在某一封邮件里。当然，实践上仍应把每一个生成的 runbook 当作「一位手速很快的同事写的代码」：先读、先在沙箱或预发环境验证、并始终保留回滚路径。

# The recommendations are automation-ready, which is the real shift
# from advice to execution.

AUTOMATION_READY_OUTPUTS = [
    "SSM runbooks that automate the configuration change",
    "prescriptive CLI scripts",
    "guided console walkthroughs",
    "IaC code changes for Terraform / CloudFormation / CDK templates",
]

def apply_safely(rec, env):
    if env == "production":
        return "review runbook + stage change + roll back on regression"
    return "apply in sandbox first, then promote"

# Treat every generated runbook like code from a fast teammate: read it,
# stage it, and keep a rollback path.

五、可用范围与前置条件

落地前先看清边界。按 AWS 的公告，AWS Well-Architected Agent 及其建议的访问目前开放于三个区域：美国东部（弗吉尼亚北部）、美国东部（俄亥俄）与美国西部（俄勒冈）；不过你可以从任何 AWS 商业区域接入工作负载。该服务由 AWS Support 交付，面向拥有 AWS Support 计划的 AWS 客户提供；上手入口是 AWS Well-Architected 控制台，细节见其用户指南。换句话说，分析发生在受支持的区域，而修复可以发生在任何商业区域。

# Region and entitlement limits to plan around before you start.

AVAILABILITY = {
    "analysis_regions": ["US East (N. Virginia)",
                        "US East (Ohio)",
                        "US West (Oregon)"],
    "onboard_workloads_from": "any AWS commercial Region",
    "delivered_by": "AWS Support",
    "requires": "an AWS Support plan",
    "get_started": "AWS Well-Architected console",
}

def rollout_plan(workloads):
    # Analyse in a supported region, remediate wherever the workload runs.
    return [{"workload": w, "analyse": "supported region",
             "remediate": "any commercial region"} for w in workloads]

先看清可用范围与前置条件，再规划铺开

六、怎么把它接进日常运维

把这份公告转成流程：第一，先明确你的业务目标，再去读建议——不问目标的优化清单只会变成噪音。第二，从一个真实的关键工作负载开始，而不是全量铺开，先验证建议质量与 runbook 的可执行性。第三，把 IaC 检查纳入 CI：让返回的模板改动走 PR 评审，用 Diff 检查器对比变更、用代码复杂度分析器守住重构质量。第四，用本站的 API 限流计算器与 API 响应时间计算器，把「可靠性建议」翻译成可度量的 SLO 数字，避免只凭感觉判断。第五，把定期审查纳入日程——用 Cron 表达式生成器排一个每周架构复查任务，让「最佳实践」从一次性动作变成持续工程。