AWS Well-Architected Agent Previews Live and IaC Audits
The AWS Support preview reviews deployed workloads and infrastructure code, then proposes fixes that cloud teams must evaluate and implement themselves.
Listen
AI narration
13:16
0:00 / 13:16
AI SummaryGenerated from this article
Condensed Summary (98 words)
AWS launched a preview of its Well-Architected Agent, an AI service analyzing deployed cloud infrastructure and infrastructure-as-code projects to generate optimization recommendations across cost, performance, resilience, and security. The agent inspects configurations, utilization metrics, and application topology across more than 65 AWS services, generating prioritized recommendations within 24 hours. Available in three US regions with an AWS Support plan, it can review workloads from any commercial AWS region. Remediation guidance includes console instructions, CLI commands, and infrastructure-code changes, but AWS warns that recommendations may contain errors. Customers must evaluate and implement fixes themselves through their own change-control processes.
AWS’s Well-Architected Agent offers cloud teams two paths to an architecture review: inspect deployed infrastructure or upload infrastructure as code before deployment. It produces prioritized recommendations and remediation instructions, but the preview does not autonomously apply fixes.
In its October 1, 2026 preview announcement, AWS says the agent connects resource configurations, utilization metrics, and application topology with business goals. Findings can come with console instructions, CLI commands, or infrastructure-code changes.
Access requires an AWS Support plan. AWS also warns that generated recommendations can contain errors or incomplete information. The public preview is not an independently validated replacement for architecture review. A bounded pilot gives cloud teams a way to assess whether its findings are verifiable and its proposed changes safe to approve.
Preview Access Requires an AWS Support Plan
AWS says Well-Architected Agent is delivered through AWS Support and is available to customers with an AWS Support plan. The announcement does not specify tier-by-tier eligibility or a separate price for the agent. Teams should confirm access and commercial terms with their AWS Support contacts.
The preview’s access Regions are:
US East (N. Virginia)
US East (Ohio)
US West (Oregon)
These are the Regions where customers access the agent and its recommendations. Workloads can be onboarded from any commercial AWS Region, according to AWS, so they do not have to run in one of those three Regions to be included.
Setup begins in the AWS Well-Architected console. An agent profile defines the accounts, Regions, optimization focus, and goals to analyze. For deployed-environment inspection, customers must also provision customer-managed IAM roles that let the agent read resource configurations, utilization metrics, and application topology. Teams should review that access scope before the first scan.
The Preview Inspects Deployed Resources and Uploaded IaC
For deployed environments, AWS says the agent correlates signals across more than 65 AWS services and evaluates them against Well-Architected best practices. The inputs cover what resources are configured to do, how they are being used, and how they relate within an application.
These inputs provide different kinds of evidence. Configuration alone may reveal a questionable setting; utilization and application context can help establish whether changing it makes sense. The service count, however, does not prove that every feature or architectural dependency receives equivalent scrutiny.
Work with Zeniteq
Let’s work together
We’re open to thoughtful collaborations with teams building in AI. Explore the ways we can work together.
Resource and application recommendations are generated within 24 hours after profile creation, according to AWS, and updated periodically. Neither statement establishes real-time detection. The 24-hour statement should not be treated as a completion guarantee for every uploaded architecture review.
For pre-deployment analysis, teams can upload a ZIP file containing a Terraform, AWS CloudFormation, or AWS Cloud Development Kit (CDK) project or repository, then select a Well-Architected lens for the review.
Code can expose intended infrastructure, but it cannot by itself demonstrate actual production utilization or application behavior. An uploaded project supports review of a proposed design; a deployed system adds operational signals.
Business Goals Shape the Recommendation Queue
The agent’s configurable focus areas are cost optimization, performance, resilience, and security. AWS says customers declare goals for those areas, and the agent prioritizes recommendations by impact and effort against those goals.
Teams can add application context, including accounts, Regions, services, tags that narrow resource scope, and application details. A technically valid recommendation may still be wrong for a particular workload.
For example, reducing spare capacity might deserve attention in a cost-focused development environment but require much closer examination in a production service with demanding availability requirements. This is an illustrative trade-off, not a reported result from testing the preview.
AWS describes three levels of output:
Resource findings with step-by-step remediation and dollar impact where applicable.
Consolidated findings across multiple resources within an application.
Broader architectural recommendations with IaC changes intended to align the design with Well-Architected practices.
The existing AWS Well-Architected Tool supports guided self-review, documented decisions, identified risks, and improvement tracking. AWS presents the two services as complementary: the agent generates recommendations from infrastructure and code, while the Tool remains useful for structured reviews and governance.
A Remediation Package Includes Evidence, Not Just Code
According to AWS’s recommendation-viewing documentation, each recommendation has a detail page explaining what was detected, why the finding was generated, and which resources are affected.
The page includes priority, optimization pillar, fix effort, detection date, and recommendation source. AWS lists Trusted Advisor as an example source. Supporting signals can reference specific resource ARNs and configuration states, giving engineers concrete evidence to investigate.
Impact estimates appear where available. Teams can also inspect cross-pillar benefits and trade-offs, including risk descriptions and mitigation guidance, to assess whether an apparently attractive cost change affects performance, security, or resilience.
After reviewing a finding, users can choose a remediation path:
Console walkthroughs provide step-by-step instructions.
Updated IaC provides changes to incorporate into the infrastructure codebase.
AWS CLI commands provide another implementation route.
The console’s “Start remediation” action opens this guided workflow; it does not give the agent permission to change infrastructure autonomously. AWS describes customers rolling out the instructions and verifying the result themselves.
Recommendations are also available through APIs, allowing teams to connect them to existing development and operations workflows. That integration can make findings easier to route and track. Engineering review, change control, and execution remain separate responsibilities: generated remediation is not an approved deployment.
A Useful First Pilot Follows One Finding Through Delivery
A large recommendation count tells teams less than following a finding from detected evidence to an approved change. The useful test is whether engineers can make that journey without having to reconstruct the finding’s reasoning.
A practical pilot could follow this sequence:
Choose a bounded scope. Start with one application or a limited account-and-Region selection. Check the customer-managed IAM roles before allowing deployed-resource inspection. For an IaC review, choose a project whose intended architecture the reviewing team understands.
Provide meaningful context. State the optimization goals and describe the application. Include relevant account, Region, service, and tag information; do not expect the agent to infer every business constraint.
Validate one recommendation. Inspect the cited resource state, supporting signals, affected resources, estimated impact, and trade-offs. Ask whether the finding remains relevant when compared with the application’s actual requirements.
Treat the generated fix as a proposed change. Review an IaC update through the normal repository process, or scrutinize the console instructions and CLI commands before execution. Test where practical, define rollback steps, and verify the outcome after implementation.
These are suggested evaluation practices, not additional capabilities claimed for the preview. They test whether the output is useful enough to survive an engineering review.
The documented workflow also supports marking recommendations complete, suppressing irrelevant findings, and submitting usefulness feedback. Those controls help teams manage the queue. Marking a finding complete should follow their own verification that the intended change actually worked.
AWS Leaves Evaluation and Safeguards With the Customer
AWS explicitly warns that generative-AI recommendations may contain errors or incomplete information. Customers are responsible for evaluating recommendations in their own context and implementing appropriate oversight and safeguards.
That warning applies equally to polished explanations and implementation-ready code. A detailed change can still conflict with an unstated requirement, target the wrong scope, or make assumptions that do not hold for the workload. Supporting evidence and trade-offs on the detail page are material for review, not a substitute for it.
The announcement provides no independent measurements of recommendation accuracy, achieved savings, or engineering time saved. Claims about contextual intelligence and ready-to-implement fixes remain AWS’s description of the product. The preview documentation also states that the service is subject to change.
For teams evaluating AI products for cloud operations, the strongest evidence would be a recommendation that identifies a real issue, proposes an appropriate change, and produces the expected result after controlled implementation. The preview offers a concrete way to run that experiment. Its value should be judged by verified changes and the cost of reviewing them, not the apparent completeness of generated fixes.
Frequently Asked Questions
3 questions
1
Does AWS Well-Architected Agent automatically apply fixes?
No. The documented preview provides console instructions, CLI commands, and IaC changes for customers to evaluate and implement. Selecting “Start remediation” opens a guided workflow without autonomously changing infrastructure. AWS says customers remain responsible for evaluating AI-generated recommendations and implementing appropriate oversight and safeguards before acting.
2
Can AWS Well-Architected Agent review Terraform and CDK?
Yes. AWS says the preview supports pre-deployment reviews of Terraform, AWS CloudFormation, and AWS CDK projects uploaded as a ZIP file. Teams select a Well-Architected lens for the review. This code-based assessment is distinct from deployed-environment analysis, which can also use resource configurations, utilization metrics, and application topology.
3
Where is the Well-Architected Agent preview available?
Preview access is available in US East (N. Virginia), US East (Ohio), and US West (Oregon), and requires an AWS Support plan. AWS says workloads can be onboarded from any commercial AWS Region. The announcement does not specify tier-by-tier Support eligibility or a separate agent price, so teams should confirm those details with AWS Support.
