AWS Well-Architected Agent 將架構審查改為每週流程

For years, the Well-Architected review was an event: a week-long workshop, a spreadsheet of high and medium risks, and then six months with nobody opening the report. On 10/01/2026 AWS put AWS Well-Architected Agent into preview, which replaces the event with a cycle: scheduled scans, up to 30 recommendations per run, weekly refresh. The question that interests me is not "is the agent right?", it's "who triages 30 findings a week, and what happens to what it cannot see?". After 16 years operating financial platforms on AWS, I've learned that a findings tool without a triage owner becomes just another red dashboard everyone learns to ignore.

The numbers that shape the design

100: accounts per profile. scanning every commercial Region from us-east-1, us-east-2 or us-west-2
30: recommendations per run. with a 7-day cooldown between scheduled runs of the same profile
5/dia: IaC reviews per profile. zip up to 25 MB; S3 folder up to 100 MB, file up to 1 MB

The signal: an aggregator with an opinion

Strip the AI layer and what AWS shipped is an aggregator with an opinion. The related-services documentation is explicit: the agent ingests Trusted Advisor findings as baseline signals, uses Compute Optimizer rightsizing signals for EC2, Lambda and RDS, consumes Security Hub CSPM, Resilience Hub assessment data (with its RTO/RPO) and Cost Optimization Hub. On top of that it adds three things: prioritization against goals you write, cross-pillar trade-off analysis, and ready remediation (console, updated IaC, aws CLI commands and Systems Manager runbooks).

Recommendations come at three levels. Resource: one instance, one function, one database, with dollar impact where applicable. Application: consolidated findings across related resources, a format the documentation itself marks as beta. Architecture: generated from CloudFormation, Terraform or CDK templates sent as a zip or S3 URI, before deployment.

Two operational details change result quality. Without Cost Explorer enabled, the agent estimates cost from public pricing, which ignores Savings Plans, Reserved Instances and contractual discounts; in an account with an EDP, the "dollar impact" can be inflated enough to invert prioritization. And access requires a Business+ Support plan or higher: Business+ gets 2 profiles and 7 applications per profile; Enterprise On-Ramp, Enterprise and Unified Operations get 10 and 30. Developer and Business are excluded.

What changes for architects

Goals became configuration: up to 10 goals per profile, plain text, one pillar each, and they order the queue. A badly written goal mis-prioritizes without raising any error.
Continuous review has fixed throughput: 30 recommendations per run and a 7-day cooldown mean a triage ceiling per profile. The bottleneck becomes the team, not the tool.
Shift-left with a quota: 5 IaC reviews per day per profile cannot back a gate on every pull request. They fit on merge to the release branch.
Criticality is declared, not inferred: application context accepts MISSION_CRITICAL, BUSINESS_CRITICAL, NON_CRITICAL and TEST_DEVELOPMENT. Whoever skips it gets recommendations tuned for the average case.
Silence is not compliance: the unsupported type list includes AWS::WAFv2::WebACL, AWS::Organizations::Policy and AWS::IAM::RolePolicy. No finding there proves nothing.

The blind spot that matters in a bank

The quotas page carries a long table of CloudFormation resource types the agent does not analyze. Most are peripheral (IoT Analytics, DeviceFarm, Evidently). But a few are exactly the controls an auditor checks first in an environment under BACEN 4.893 or PCI-DSS:

AWS::WAFv2::WebACL, WebACLAssociation, IPSet and RuleGroup: the entire WAF edge.
AWS::Organizations::Policy: SCPs, that is, the organization's data perimeter.
AWS::IAM::RolePolicy, UserPolicy and GroupPolicy: inline policies, where the "Action": "*" nobody remembers writing usually lives.
AWS::OpenSearchService::Domain, AWS::Shield::Protection and Security Hub's own configuration.

The failure mode here is silent. The report arrives clean on the security pillar, someone takes the screenshot to the risk committee, and the absence of WAF findings is read as a well-configured WAF. It isn't: it's an unanalyzed WAF.

The mitigation is cheap and has to be explicit. Keep those controls covered by AWS Config conformance packs and Security Hub CSPM directly, outside the agent, and write in the governance document which types the agent does not cover and which tool covers each one. The list is marked preview and should shrink, so review it every quarter instead of assuming it is stable.

Where the agent reads, where it writes

Role chain in a dedicated account, input signals and remediation paths. Only the IaC path goes back through the pipeline.

🔐 AWS: Conta de tooling dedicada

Agent profile us-east-1 · 10 metas (ai)
Execution role trust wellarchitected.amazonaws.com (security)
CloudTrail API wellarchitected:* (security)

🟧 AWS: Contas de workload (até 100)

Access role WellArchitectedAgentResourceScanning (security)
Recursos todas as regiões comerciais (compute)

📡 AWS: Sinais de entrada

Trusted Advisor Security Hub CSPM (data)
Compute Optimizer Cost Optimization Hub (data)
Cost Explorer sem ele: preço público (data)

📤 Saída: Remediação

IaC atualizado PR no repositório (ci)
AWS CLI / SSM runbook só em sandbox (external)

Flows

profile -> exec: assumes
exec -> access: sts:AssumeRole, ExternalId = profile ARN
access -> res: config read
ta -> profile: baseline findings
co -> profile: rightsizing and cost
ce -> profile: actual cost per resource
profile -> ct: audit
profile -> owner: 30 recommendations/week
owner -> iac: accepts and versions
owner -> cli: tests outside prod

IAM: the design is good, the default less so

The access model deserves credit. Instead of a service-linked role, the agent uses customer-managed roles in a chain: an execution role in the profile account, trusting wellarchitected.amazonaws.com and holding only sts:AssumeRole, and an access role in each workload account, with the read-only WellArchitectedAgentResourceScanning managed policy. The profile ARN is used as the external ID, which closes the confused deputy, and there is an iam:PassRole check at creation. The documentation states neither role allows modifying resources. Onboarding is opt-in per account.

That said, three adjustments I'd make before turning it on in production:

Dedicated account: AWS itself recommends hosting the profile in an account with no workloads. In a Control Tower environment, that is the tooling or audit account, never the management account.

Trust by exact ARN: use the execution role ARN, with the service-role/ path the console creates, not the account root. Roll out access roles via StackSets with the same name in every account (the common-name pattern the profile accepts) so that revoking is one operation, not a hundred.

Processing residency: the profile can only live in us-east-1, us-east-2 or us-west-2, even though it scans sa-east-1. Configuration metadata and tags leave the Region for analysis. If your tagging policy carries customer names or CPF numbers in tags (I've seen it), that becomes a conversation with the DPO under LGPD before it becomes one with the auditor.

Four remediation paths, four maintenance costs

Criterion	Console	Updated IaC	AWS CLI	SSM runbook
Creates drift	Yes	No	Yes	Yes, unless the runbook updates the code
Review trail	CloudTrail only	Pull request with approval	CloudTrail only	SSM execution history
Where I use it	Understanding the finding	Production	Sandbox	Repeatable action with no IaC state, e.g. orphaned snapshot

How I'd position it today

The agent doesn't replace a human Well-Architected review, it changes what the human review has to cover. The mechanical work (oversized instance, bucket without versioning, single-AZ RDS tagged MISSION_CRITICAL) leaves the workshop agenda. What remains for people is what the agent admittedly cannot see: SCPs, WAF, inline policies, and architecture decisions that show up in no configuration at all, like why a settlement flow is synchronous.

In practice, three design decisions:

One profile per regulatory domain, not per team: with 10 profiles on Enterprise, separate what has distinct SLOs and regimes (payments, data, internal platform). On Business+, with 2 profiles and 7 applications, the choice is harder: regulated production in one, everything else in the other.

Goals versioned in a repository: plain-text goals are a ranking parameter. Treat them as code: a file in the platform repository, applied through the wellarchitected namespace API, with review. A goal like "reduce cost" is weak; "reduce non-production compute cost by 20% without touching the core's 15-minute RTO" gives the agent a trade-off to respect.

A queue with an owner and an SLA: 30 recommendations a week is about 120 a month per profile. Without an owner who marks items complete or suppresses them with a reason, the backlog grows linearly and the tool loses credibility in two months. I'd turn on cost and resilience first, where the cost of error is low, and security only later, with the unsupported list beside it.

Anti-patterns you can already predict

Running the CLI command in production: it fixes the finding and creates drift; the next terraform apply reverts the fix and nobody notices until the next scan.
Reading a clean security pillar as attestation: with WAF, SCPs and inline policies out of scope, a clean report is partial coverage, not compliance.
Prioritizing by dollars without Cost Explorer: the agent falls back to public pricing and ignores Savings Plans and EDP; the cost queue ends up sorted by a number that isn't yours.
Profile in the management account: it concentrates the role that reaches 100 accounts in the place with the largest blast radius in the organization.
IaC gate on every PR: 5 reviews per day per profile run out before lunch; the gate either fails open or blocks the team.

The goal is the new prompt: The goals text defines the order of the remediation queue across 100 accounts. That is production configuration with effects on money and risk, written in natural language with no validation. Whoever edits goals needs the same change control as whoever edits SCPs.

Curator's note: I'd turn the agent on this week in a dedicated tooling account, cost and resilience only, with Cost Explorer enabled before the first run. Access roles go out through StackSets, trust pinned to the exact execution role ARN, and goals live in a versioned file. The lesson I carry from years of Trusted Advisor and Security Hub: the cost of a findings tool is not the license, it's the weekly triage someone has to sustain for years. If there is no named owner for the queue, I'd rather not turn it on.

Verdict

Adopt now if you already have a Business+ plan or higher, Control Tower with a tooling account, and a platform team able to triage about 120 items a month per profile: the agent removes the mechanical work from reviews and delivers IaC remediation that fits your pipeline. Wait if your main need is security evidence for regulatory audit: while WAF, SCPs and inline policies are out of scope, it complements AWS Config and Security Hub CSPM, it does not replace them. Either way, production remediation goes only through the IaC path.

Rating: Adotar com escopo / Adopt with scope

References

Originally published at fernando.moretes.com. By Fernando F. Azevedo: Senior Solutions Architect.