Skip to main content
← Back to Currents

AWS Well-Architected Agent: What an AI Review Can't Decide

November 4, 2026

AWSArchitectureCloud Migration
An AI robot with a clipboard scans the outside of a locked cabinet while the human-side expert opens the door to reveal the gears and belts inside: automated review reads the surface, judgment opens the machinery.

On October 1, 2026, AWS handed its architecture review to an agent. The AWS Well-Architected Agent, now in preview, scans your accounts, ranks what it finds against goals you declare, and hands back fixes as console steps, infrastructure-as-code changes, or CLI commands. So does a company still need a person for its AWS review?

Yes, for a narrower job than before. The agent produces the findings list. It can't decide which findings matter to your business, which ones are safe to apply to an older application, or in what order to apply them. We run AWS migrations and readiness reviews for mid-market companies, and the findings list has rarely been the hard part.

What does the AWS Well-Architected Agent actually do?

It turns the Well-Architected Framework into a continuous, ranked list of recommendations. AWS says it covers more than 65 services, ranks each recommendation by impact and effort against your declared goals, and pulls in findings from services such as Trusted Advisor. AWS's user guide adds that one agent profile can analyze up to 100 accounts, and that it can review infrastructure-as-code templates on demand. It needs an AWS Support plan, and the preview runs in three US regions.

It doesn't apply changes. You review each recommendation and deploy the fix yourself. AWS also states that the recommendations are AI-generated and may contain errors or incomplete information. That caveat is the right frame for everything below.

Where the agent's view stops

The agent reads your AWS environment: resources, utilization, topology, and templates. Much of what decides whether a change is safe lives somewhere else.

The application inside the instance. A ColdFusion server on EC2 looks like any other instance from the outside. Its datasources, scheduled tasks, and mappings live in the ColdFusion Administrator, not in AWS configuration. A recommendation to resize, move, or rebuild that instance can be right for AWS and wrong for the application.

The systems that aren't in AWS yet. Most companies we work with are partway through a move. The on-premises database, the file share, and the vendor integration that allows exactly one IP address don't exist for a tool that reads only your AWS accounts.

The goals nobody wrote down. The ranking is only as good as the declared goals. "Reduce cost" and "improve resilience" pull in opposite directions on the same workload. Someone has to decide which one wins, and put it in writing, before the ranking means anything.

Which recommendations are safe on an older application?

Treat every recommendation as a proposed change, and judge it by what it can break. Some changes are low risk almost anywhere: tightening an open security group in a test account, or removing unattached storage volumes once you confirm nothing needs them. Others reach into the application: a runtime upgrade, a new instance family, a change to how an old database driver connects. On a 15-year-old application, those are the changes that fail at 2 a.m.

Our working rule is simple. An infrastructure-as-code change from the agent gets the same treatment as a pull request from a new engineer. It runs in a non-production account first. It carries a rollback step. A named person approves it. The agent wrote the change. It doesn't own it.

How we would use it

Run it early, and treat the output as input. The agent is a fast way to get a full list of known issues across many accounts, and it doesn't share the assumptions of whoever set those accounts up. That makes it useful before a migration review, not a replacement for one.

Then do the part it can't. Settle the goals. Add the systems it can't see. Sort the findings into safe now, risky, and after the migration. Sequence them against your change windows. Some of the highest risks we find are about people and billing rather than configuration, like the gaps in our pre-go-live account continuity checklist, and a resource scan sees those only in part.

If you want a review that starts from the agent's list and ends with a sequenced plan, that's how our AWS migration and readiness work runs now.

Have a problem worth solving?

Tell us what you are trying to build or modernize, and we will tell you honestly how we would approach it.