AWS Well-Architected Agent Architecture Review: What It Can Actually Change

AWS introduced the public preview of its Well-Architected Agent on October 1, 2026, adding an AI service that can inspect cloud environments and Infrastructure as Code (IaC) before deployment. The interesting part is not that it produces another list of best-practice findings; it can return proposed changes to Terraform, CloudFormation, and AWS Cloud Development Kit (CDK) templates, alongside recommendations for running resources. That moves the service closer to the point where architecture decisions are made, but AWS also says its generative AI recommendations can contain errors or incomplete information and must be reviewed before implementation.

AWS Well-Architected Agent changes the review from a checklist to recommendations

The older AWS Well-Architected Tool is built around reviewing workloads against architectural best practices, while the new agent continuously analyzes configured environments and produces prioritized recommendations. AWS says the agent considers cost optimization, security, resilience, and performance, then ranks findings against goals defined by the customer. Instead of treating every finding as equally important, the system is designed to connect the recommendation to the business objective that the team selected. That distinction matters because a production system optimized for cost may require different trade-offs from one where resilience is the primary concern.

The agent generates three types of recommendations: resource, application, and architecture. Resource recommendations target individual services such as an Amazon Elastic Compute Cloud instance, Lambda function, or relational database, while application recommendations consider relationships between multiple resources. Architecture recommendations are different because they analyze IaC before deployment and can return updated templates that incorporate suggested changes. AWS currently describes application-level recommendations as beta, so that part of the service is still explicitly being refined.

The architecture review is where the new service becomes useful before deployment

An architecture review lets a developer or platform team submit an IaC project rather than waiting for the infrastructure to exist in a running AWS account. AWS supports Terraform, CloudFormation, and CDK templates for this workflow, allowing the agent to inspect the declared infrastructure design against selected Well-Architected guidance. The result can include recommendations and modified IaC that implements proposed fixes. For teams that already treat infrastructure as code, this creates a second review point before a change reaches production.

The distinction between the three recommendation levels is worth keeping clear. Resource and application findings are generated from the AWS environment, while architecture findings are generated from an explicit review of infrastructure templates. That means an architecture review can catch a design issue before deployment, whereas an environment recommendation may identify a problem only after AWS can observe the corresponding resources. AWS therefore has not replaced its existing review process with one universal scan; it has added a separate pre-deployment path.

The agent needs more context than simply pointing it at an AWS account

Setting up the service starts with an agent profile that defines which AWS accounts and Regions it can analyze, which optimization pillars matter, and what business goals should influence recommendation priority. AWS requires customer-managed Identity and Access Management (IAM) roles for this access model, including roles that allow the agent to discover resources across configured accounts. A single profile can cover up to 100 AWS accounts, which makes the feature relevant to organizations managing multiple environments rather than only individual developers. The permissions model is also significant because AWS says the access roles used for discovery are controlled by the customer.

Application context is another required part of the current setup for scheduled recommendations. Teams provide information such as the application's accounts, Regions, services, tags, architecture overview, and criticality so the agent has information that resource discovery cannot determine automatically. Without application context, AWS says a profile is considered invalid for scheduled recommendation generation. That requirement shows where the service's personalization comes from: some of the useful context still has to be supplied by the people who understand the application.

Its recommendations are prioritized by goals, impact, and effort

AWS is not simply returning a flat list of possible improvements. The agent uses the goals in the profile to prioritize findings and presents impact and effort information, while also showing trade-offs across the optimization pillars. A change intended to improve resilience, for example, may have cost or performance consequences that the service surfaces alongside the recommendation. This gives an engineering team more information for deciding whether a suggested change is appropriate instead of reducing the decision to a single best-practice score.

The recommendation dashboard can filter findings by recommendation type, optimization pillar, effort, impact, and AWS service. AWS says scheduled resource and application recommendations are generated roughly every 24 hours, with a minimum 24-hour cooldown between scheduled generation runs. After initial profile setup, the documentation says recommendations typically become available within 48 hours. Those delays mean the service is better suited to ongoing infrastructure review than to an interactive workflow where a developer expects a complete analysis immediately after every deployment.

The generated IaC is useful, but it is still generated code

The most consequential output is the updated infrastructure code that AWS can provide for architecture recommendations. Instead of leaving an engineer with a paragraph explaining that a configuration should change, the service can produce an implementation-oriented template that can be inspected and incorporated into the project. AWS also provides console walkthroughs and command-line instructions for other remediation paths. This shortens the distance between finding a problem and testing a possible fix.

That convenience does not remove the need for engineering review. AWS explicitly warns that generative AI capabilities can produce errors or incomplete information, and its documentation tells users to review recommendations before taking action. A generated template can be syntactically valid while still conflicting with an organization's networking model, compliance requirements, deployment process, or cost constraints. The safest interpretation is therefore that the agent proposes infrastructure changes; it does not become the person responsible for approving them.

IAM permissions are part of the architecture decision too

The service's access model deserves attention because the agent needs visibility into the infrastructure it is evaluating. AWS uses an execution role in the profile account and access roles in workload accounts, with role chaining used for cross-account discovery. AWS says the agent's access roles provide read-only access to resource metadata and configuration rather than permission to modify those resources directly. That limits the blast radius of the analysis path, while remediation remains an explicit action taken through the recommended workflow.

Teams should still treat the IAM configuration as part of the deployment rather than as an administrative detail. The profile determines which accounts and Regions are in scope, and the roles determine how the service reaches those environments. For a large organization, that makes the initial setup a meaningful architecture task of its own. The agent can analyze infrastructure at scale, but the organization still decides which infrastructure the agent is allowed to see.

The service has practical limits that change who should use it

AWS Well-Architected Agent is currently available in public preview, and access is not universal across AWS support tiers. The current documentation says customers need Business+ Support, Enterprise On-Ramp, Enterprise Support, or Unified Operations; Developer and Business support tiers do not include access. Agent profiles are hosted in US East (N. Virginia), US East (Ohio), and US West (Oregon), although AWS says those profiles can scan workloads across commercial AWS Regions. These restrictions matter before a team spends time designing an onboarding process around the service.

There are also hard analysis limits. AWS currently allows five architecture review generations per day for a profile, a maximum compressed ZIP upload of 25 MB, and a maximum Amazon Simple Storage Service folder size of 100 MB when that input method is used. A single file referenced from such a folder is limited to 1 MB. Those limits are unlikely to matter for a small Terraform project, but they can become relevant when teams try to submit a large infrastructure repository rather than a focused architecture project.

What developers should test before trusting the agent

The sensible first test is not whether the agent can produce a convincing recommendation; it is whether the recommendation survives comparison with the application's actual requirements. Start with a non-critical workload, define a specific goal, provide accurate application context, and inspect both the finding and the proposed remediation. For architecture reviews, compare the generated IaC with the original template and run the normal validation, security, and deployment checks before allowing the change near production.

The public preview also gives teams a chance to measure whether the service adds useful signal beyond existing AWS tools. AWS says the agent ingests findings from services such as Trusted Advisor and adds personalization, goal-based prioritization, and remediation guidance, so the practical question is whether those additions reduce the time engineers spend interpreting and acting on findings. If the recommendations repeatedly require substantial correction, the value may be in discovery rather than automation. If they consistently produce changes that pass the team's own review process, the architecture-review workflow becomes much more interesting as a regular part of infrastructure development.

The next test is whether AI recommendations can fit the existing deployment process

AWS has exposed the agent through APIs as well as the console, which means its recommendations can potentially become part of existing development and operations workflows. That makes the service more relevant to platform teams than a dashboard that engineers must remember to open manually. The useful integration point is not automatic production deployment; it is inserting an additional review signal into the same pull-request, infrastructure validation, and approval process teams already use.

For now, the strongest use case is therefore a controlled review loop: define the workload and goals, let the agent analyze deployed resources or IaC, inspect the recommendation, validate the generated change, and keep human approval before remediation. AWS is still collecting feedback on the preview, particularly around application-level recommendations. As the service develops, the important measure will be whether its proposed infrastructure changes remain accurate enough to save engineers time without moving architectural decisions out of the normal review process.