9 min read - AWS Well-Architected Agent: Put AI Remediation Behind Change Control

AWS released the public preview of AWS Well-Architected Agent on 1 October 2026. The service examines resource configuration, utilisation signals and application topology, then ranks recommendations against the goals a customer supplies. It can also return updated Infrastructure as Code, CLI commands, console instructions and, for some findings, Systems Manager runbooks.

That shortens the distance between an architecture finding and a production change. It also removes the pause in which engineers usually question scope, test assumptions and arrange a rollback. The useful operating model is therefore clear: let the agent prepare evidence and a candidate fix, while your existing delivery controls decide whether anything changes.

For a startup or mid-market platform team, the preview is best treated as a new source of change proposals, not as a new production operator.

What AWS launched, and where the boundary sits

The AWS launch announcement describes recommendations at resource, application and architecture levels across cost, security, performance and resilience. AWS says the agent analyses more than 65 services, accepts Terraform, CloudFormation and CDK projects for pre-deployment reviews, and can supply implementation material with each finding.

The current AWS user guide adds three limits that belong in any adoption decision. The service remains in preview, application-level recommendations remain in beta, and AWS tells customers to review every AI-generated recommendation before acting. Agent profiles are hosted in three US Regions, although they can scan resources in commercial AWS Regions, and access requires an eligible AWS Support plan.

The remediation path also matters. AWS distinguishes pre-built Systems Manager runbooks associated with Trusted Advisor checks from AI-generated guided actions. According to the implementation guide, the agent does not execute AI-generated steps for you. Those steps may include commands, SDK code or an updated template, but the customer must review, test and run them.

Keep that distinction in your interface and audit trail. A tested runbook and a generated shell command may appear beside each other in the console; they do not carry the same provenance or assurance.

Separate observation from execution

Start with two lanes. The observation lane lets the service inspect an agreed scope and produce findings. The execution lane is your normal repository, CI pipeline, approval policy and deployment tooling.

AWS environment -> agent finding -> owned change record -> reviewed IaC diff
                                                       -> test environment
                                                       -> approved deployment
                                                       -> verification or rollback

Do not give the observation lane a shortcut around the execution lane. Copy generated IaC into a branch, pin the recommendation identifier and affected resource ARNs, and let the same policy checks run as they would for a human-authored change. If a recommendation only supplies console steps or CLI commands, convert the desired end state into versioned IaC when practical. Where that conversion is unsafe or impossible, record the exact commands, operator, preconditions and recovery steps before execution.

NIST's AI Risk Management Framework Core supports this separation. It calls for defined human oversight, testing before deployment and while a system operates, documented third-party controls, override mechanisms, recovery and change management. The framework is voluntary and technology-neutral; here, it provides an independent test for the operating model rather than a certification claim.

Scope access for inspection, not convenience

AWS WA Agent uses customer-managed IAM roles and role chaining for multi-account discovery. The AWS access model recommends running profiles from a dedicated account without production workloads, limiting access roles, monitoring API activity in CloudTrail and removing access when an account no longer needs analysis.

Turn those recommendations into an onboarding contract:

• name the profile owner, target accounts, Regions, applications and optimisation pillars;
• document every role ARN, trust relationship and managed or custom policy;
• keep scanning permissions read-only and separate them from deployment credentials;
• exclude sandbox, client or regulated environments until their owners approve the scope;
• set a review date for the profile, its business goals and every connected account;
• test revocation before assuming that deleting a profile ends all relevant sessions.

A broad scan can produce a fuller picture, but it also increases the number of teams, resources and data flows involved. Begin with one owned application whose tags and account boundaries are already reliable. Poor inventory does not become trustworthy because an agent correlates it.

For France, Morocco or cross-border operations, the US-hosted profile detail deserves a written review. The public documentation states where profiles are hosted and where resources may be scanned; it does not, by itself, answer every organisation's questions about telemetry, support access, retention, transfers or contractual duties. Map the actual service data flows and obtain the appropriate privacy, security and legal review for your context. Exceev does not infer a compliance outcome from the hosting-region list.

Make each recommendation earn a change

Create one change record per recommendation or tightly coupled group. The record should preserve what the agent saw and make the human decision reproducible:

Then move the proposal through four decision points.

First, validate the finding. Confirm that the resources still exist, the application mapping is correct and the recommendation addresses a current condition rather than a stale or intentionally accepted design.

Second, inspect the fix. Read every generated line. Resolve policy-as-code results, provider-version changes, replacement operations and hidden defaults. A syntactically valid template can still delete or recreate a stateful resource.

Third, test the change in a representative non-production environment. Exercise steady state, failure, monitoring and rollback. Cost recommendations need performance and resilience checks; resilience changes need an explicit cost review. The agent's cross-pillar explanation is an input to this work, not the result.

Fourth, deploy through the usual approval window and verify the intended outcome against live evidence. Close the record only after checking both the target metric and unexpected effects. If the recommendation returns on the next weekly refresh, decide whether the change failed, detection lagged or the proposed fix did not address the real cause.

NIST SP 800-53 Revision 5 includes configuration change control as part of its wider control catalogue. Its change-control treatment covers review, approval, documentation, testing and monitoring of system changes. You do not need to claim NIST compliance to use that sequence as a practical minimum.

A pilot should measure decisions, not recommendation volume

An agent that produces many findings can create work faster than a small platform team can assess it. Cap the pilot backlog and choose one pillar that matches an existing objective. If the team is already handling reliability debt, for example, do not simultaneously open cost, security and performance queues simply because the dashboard allows it.

Track measures that expose decision quality:

• recommendations accepted, rejected, deferred or marked as already addressed;
• rejection reasons, including wrong scope, stale state, unacceptable trade-off and duplicate finding;
• review time and engineering effort before a proposal becomes deployable;
• test failures, policy failures, rollbacks and post-change incidents;
• repeated findings after a supposedly successful remediation;
• changes that improved the target metric without degrading another agreed guardrail.

Avoid a target based on the percentage of recommendations closed. It rewards suppression and rushed fixes. The decision record should show why a change improved the workload, or why leaving the architecture alone was the safer choice.

The pilot also needs a stop condition. Pause intake if unreviewed findings outrun team capacity, if resource mapping is repeatedly wrong, if generated changes bypass the repository, or if operators cannot reconstruct who approved an action. A preview should have to prove that it improves the existing architecture-review process.

Our architecture review guide for legacy teams explains how to establish data boundaries, owners and exit criteria before implementation. The same discipline applies here. Exceev's services approach can connect cloud assessment, engineering changes and operational handover without turning a vendor recommendation into an automatic mandate.

The go or wait decision

Use the preview now when you have a clean AWS account structure, dependable tags, version-controlled IaC, an existing change workflow and enough review capacity. Keep the initial profile narrow. The likely gain is faster discovery and a better prepared first draft of remediation work.

Wait when production changes still happen directly in the console, ownership is unclear, rollback is rarely tested or the profile's hosting and access model has not passed internal review. Adding generated commands to that environment will magnify the missing control rather than repair it.

Before approval, ask six questions:

1. Which accounts, applications and pillars may the agent inspect?
2. Which role grants that access, and how is it revoked and monitored?
3. Where does every generated fix become a versioned, reviewable change?
4. Who tests cross-pillar effects and approves the production window?
5. Which evidence proves success, and which signal triggers rollback?
6. Who reviews repeated, rejected and suppressed recommendations?

If the team cannot answer them, the next task is change-control design, not agent onboarding.

Sources and limitations

We opened and reviewed every source below on 2 October 2026.

• AWS's 1 October launch announcement establishes the public-preview status, analysis scope, recommendation levels, IaC review and available remediation formats.
• The AWS WA Agent user guide documents the weekly analysis model, beta application recommendations, review warning, support-plan eligibility, scale and profile-hosting Regions.
• The AWS remediation guide distinguishes pre-built SSM automation from AI-generated guided actions and assigns review, testing and execution to the customer.
• The AWS access model documents customer-managed roles, cross-account role chaining, revocation and AWS's dedicated-account and CloudTrail recommendations.
• The NIST AI RMF Core supplies independent, voluntary guidance on human oversight, testing, third-party risk, override, recovery and change management.
• NIST SP 800-53 Revision 5 supplies independent configuration change-control guidance.

We did not activate the preview, inspect an AWS account, validate generated recommendations, execute a runbook or measure business results. AWS may change features, eligibility, Regions, quotas, documentation and preview behaviour after the review date. The controls above are an operating pattern, not legal advice, an AWS endorsement or a compliance finding for Exceev or any client.