What is AWS auto remediation?
AWS auto remediation connects a detected condition to an action intended to correct it. A useful implementation also checks whether the problem actually improved. An alarm, a successful command and a recovered application are three different observations.
For a stable, well-understood failure, a maintained runbook may be exactly what you need. When the cause changes, someone must investigate, choose or adapt the fix, and test its effect. That surrounding work is the part to evaluate when considering AI remediation.
Three jobs: detect, decide and execute
- Detect
- A monitoring source reports a symptom. Record the affected resource, observation time and relevant context. An old alarm must not be treated as current proof.
- Decide
- Inspect the target and compare likely causes. Select a suitable known resolution or generate a new plan from the available evidence. Identify what would disprove the diagnosis.
- Execute and verify
- Use the permitted identity and execution path, capture the result, then run the agreed functional check. Keep a failed check separate from a successful command exit.
AWS provides native automation building blocks. Systems Manager Automation orchestrates runbooks. Run Command sends work to configured managed nodes. EventBridge integration connects supported events and automation. These can be useful parts of the same remediation workflow.
A runbook or an AI remediation platform?
| Decision | A maintained runbook | AutoSolve evaluation |
|---|---|---|
| The cause is known | Encode the tested procedure, inputs and conditions. | Reuse a suitable resolution; avoid unnecessary generation. |
| The same symptom has a new cause | A person or additional orchestration must establish which procedure fits. | Investigate current evidence; adapt or generate a solution when no suitable match exists. |
| The target differs | Maintain supported variants and target parameters. | Resolve target identity, runtime and tools before preparing execution. |
| The command succeeds, the app still fails | Define a functional check and exception path. | Inspect verification evidence and the failure-recovery path; do not accept an exit code as recovery. |
This is a workflow comparison, not a claim that AWS cannot perform complex automation. The question is how much investigation, adaptation and maintenance remains with your people.
Example: an application returns HTTP 503
Consider an application hosted on an EC2 instance that starts returning HTTP 503 after a configuration change. A restart might mask the symptom or achieve nothing. Begin by checking the affected service, recent changes, relevant logs and configuration, and whether its dependencies are reachable.
If evidence points to an invalid data path, a useful plan identifies the correct path from authoritative application context, limits the change to the intended configuration, retains a backup and checks the application afterward. If evidence points elsewhere, the plan must change. The alarm text alone is not permission to replace files.
This EC2 sequence is an evaluation scenario. The related recorded AutoSolve application repair actually recovered an isolated Linux application from HTTP 503 to HTTP 200 with data loaded. That run used a native agent and human approval, not AWS SSM. It demonstrates evidence gathering, AI-generated repair and functional verification; it does not establish this EC2 deployment.
How AutoSolve uses AWS Systems Manager
AutoSolve's AWS execution adapter sends a prepared command through Systems Manager to the resolved instance and region. The adapter selects the PowerShell or POSIX command document from the resolved runtime, and retains the provider request ID, output and execution status.
Before evaluating that path, confirm the node is managed and reachable, the execution identity has the required scoped permissions, the target runtime and tools are available, and policy authorizes the actual plan. Inventory access and command access are different. A Windows workstation submitting a ticket does not make the affected cloud host a Windows target.
AutoSolve can use company resolution history or generate a new solution when no suitable match fits. Cloud remediation with AutoSolve connects those decisions to execution and result checking. Approval follows the organization's configured policy; a changed plan must obtain the authorization it requires.
What to measure before expanding
Use a representative non-production incident, an agreed target and a functional definition of recovery. Record who supplied each piece of evidence and every point where a person intervened.
- Known cause: does the system reuse the appropriate resolution?
- Changed cause: does it inspect the difference rather than repeat a stale fix?
- Unavailable access: does it report what is missing without claiming success?
- Failed verification: does it retain the failed check and produce an understandable next step?
- Revised plan: does it preserve the authorization boundary and original audit evidence?
Compare total elapsed resolution time, hands-on minutes, verified recoveries and exceptions against your current approach. Measure investigation and verification as well as the final command. A successful evaluation produces evidence for a buying decision, not an assumed percentage saving.