Architecture review becomes continuous
AWS has introduced Well-Architected Agent in public preview, presenting it as an AI-powered evolution of familiar cloud review tools. Announced on 1 October, the service analyses resource configuration, utilisation and application topology across more than 65 AWS services. Customers specify business goals and optimisation pillars, and the agent ranks recommendations by impact and effort rather than returning a flat checklist.
The service covers cost optimisation, security, performance and resilience. It can generate findings for individual resources, groups of resources within an application and broader architectures represented as infrastructure-as-code. This hierarchy is useful because a technically correct change to one resource may create a trade-off elsewhere. AWS says recommendations explain cross-pillar effects so teams can assess, for example, the cost of a resilience improvement before committing.
Infrastructure-as-code is reviewed before deployment
Teams can upload Terraform, AWS CloudFormation or AWS CDK projects for an on-demand architecture review. The agent can return updated templates intended to align the design with Well-Architected practices. Finding an issue before deployment is generally cheaper than repairing a live system, and code-form recommendations fit existing review and version-control processes better than a screenshot of console instructions.
Generated code should still enter the normal engineering workflow. Reviewers need to understand the proposed change, run validation and test in a safe environment. A template can be syntactically correct while misunderstanding a business requirement, network dependency or recovery objective. The service should be treated as a source of reviewable patches, not an authority allowed to rewrite production architecture without evidence.
Recommendations arrive with several remediation paths
AWS describes console walkthroughs, command-line guidance, Systems Manager runbooks and updated infrastructure-as-code as possible implementation packages. Some Trusted Advisor-derived findings use deterministic, tested runbooks that can be triggered with consent. AI-generated resource, application and architecture recommendations use guided actions that may include commands or code. That distinction matters because the assurance behind a tested runbook differs from newly generated instructions.
Every path needs an approval and rollback plan proportionate to the change. A command that modifies a database, identity policy or network route can have immediate effects. Operators should check permissions, affected resources and expected cost before execution, then verify the result independently. The agent can reduce the work of assembling a remediation plan, but the account owner remains responsible for accepting its operational consequences.
Access spans accounts and regions
An agent profile defines accounts, regions, pillars, goals and application context. AWS documentation says one profile can analyse up to 100 accounts and resources in commercial regions, while profiles are hosted in US East or US West regions. Customer-managed IAM roles provide cross-account access. This gives customers control over permissions, but it also makes role design a critical part of deployment.
The access role should be restricted to the resources and data required for analysis. Administrators should review trust policies, log role assumptions and separate people who configure the profile from those who approve remediation. Australian customers can onboard workloads from commercial regions, but should evaluate where profile data and generated recommendations are processed, particularly when internal architecture information has residency or confidentiality constraints.
Preview limitations are explicit
Preview users should begin with advisory access and a limited account scope. They can compare findings with an existing architecture review, track false positives and confirm that suppressing a recommendation does not hide a broader risk. This creates a baseline before remediation privileges expand.
The service can also change the relationship between cloud teams and business owners. Declared goals determine how findings are prioritised, so a vague objective can produce a technically sensible but commercially unhelpful queue. Teams should document who set each goal and revisit it when workloads or risk tolerance change. Cost, security, performance and resilience often pull in different directions; a recommendation should make those tensions visible rather than collapse them into one score. Architecture boards can use the output as structured evidence, recording why a change was accepted, deferred or rejected. That decision history will matter when the same finding returns during the next scheduled review.
AWS says access requires a Business+ or higher AWS Support plan and is available through profiles hosted in three US regions. Initial recommendations can take time to generate, with documentation describing scheduled refreshes and setup prerequisites such as Cost Explorer for accurate figures. Existing Well-Architected tools remain available for manual reviews. The agent is therefore an additional service, not a replacement that every AWS customer receives automatically.
Most importantly, AWS warns that generative recommendations can contain errors or incomplete information and that customers must evaluate them. That caveat should shape operating practice from the start. Well-Architected Agent can make optimisation findings more contextual and actionable, but its value depends on review quality, least-privilege access and measured results after remediation. A useful preview will show not only more recommendations, but fewer incidents and better cost or performance outcomes.