AWS describes a way to turn AWS DevOps Agent investigation summaries into remediation workflows using Amazon EventBridge, AWS Lambda Durable Functions, and Amazon Bedrock. The workflow runs read-only tools autonomously and pauses for an on-call engineer’s approval before making infrastructure changes.
For cloud architects, the central design choice is where to place authority to act. The investigation agent supplies a diagnosis; a separate workflow selects from approved tools and controls execution. In its remediation implementation guide, AWS presents this as a route from an investigation summary to a pre-validated fix that an engineer can approve with a single action.
Keep investigation and execution separate
AWS says DevOps Agent can diagnose production incidents and recommend actions, using correlated metrics, logs, and application topology to investigate problems. Its guide describes organizations typically keeping observability agents in an observe-and-report mode, without permission to modify production resources directly.
A separate AWS account of Property Finder’s incident-management implementation describes a per-session permission guardrail enforcing read-only infrastructure access for AWS DevOps Agent. That account supports the distinction between investigation and execution; it is a separate implementation, rather than independent validation of the remediation guide.
The architectural implication is that a useful diagnosis does not itself authorize a production change. The remediation workflow needs its own tools, permissions, and approval boundary. Adding automation therefore means defining how an investigation becomes an executable action, as well as deciding which actions require human review.
Assemble the event, orchestration, and tool layers
According to AWS’s detailed walkthrough, deployment requires Python 3.14 or later and an active AWS DevOps Agent space. Its AWS CDK stack provisions an Amazon EventBridge rule and three Lambda functions:
| Function | Role in the documented workflow |
|---|---|
| <code>devops-agent-trigger</code> | Fetches investigation summaries from the AWS DevOps Agent journal. |
| <code>devops-agent-remediation-durable</code> | Orchestrates remediation and invokes Amazon Bedrock. |
| <code>devops-agent-lambda-tool</code> | Provides approved remediation tooling for selection through a curated allowlist. |
The stack grants EventBridge lambda:InvokeFunction permission for devops-agent-trigger. The trigger function receives aidevops:ListJournalRecords to fetch investigation summaries, while the durable remediation function receives bedrock:InvokeModel to invoke Bedrock.
These permission assignments make the division of responsibilities concrete: event delivery, access to investigation records, and model invocation have distinct roles. They describe specific grants in the example, rather than a complete permissions specification for every production environment.
Bedrock identifies available remediation tools from the curated allowlist. For an architect adapting the pattern, that makes the tool catalog a central design decision: the workflow’s available actions depend on the approved functions exposed to it. The model’s involvement does not remove the need to define those tools carefully.
Run read-only steps and pause before changes
For read-only actions, AWS describes an autonomous loop in which the durable function calls Bedrock, executes approved tools, and feeds their results back into the conversation. This allows the workflow to continue through tool interactions without requiring approval for each read-only step.
When an action would change infrastructure state, the workflow suspends and waits for human approval. AWS says it checkpoints progress and can pause for minutes, hours, or days without consuming compute resources during the pause, then resume after an approval signal.
Lambda Durable Functions supplies the persistence behind this sequence. AWS describes it as a Lambda capability for resilient, multi-step applications and AI workflows that can run for up to one year. It automatically checkpoints progress, suspends execution during long-running tasks, and recovers from failures.
That persistence matters because approval and execution need not happen in one uninterrupted session. The workflow can retain its progress while an engineer considers a proposed change. Human review remains part of the execution path, even though the surrounding orchestration is automated.
What the design establishes—and what remains unproven
AWS calls the proposed fixes pre-validated, but that description should not be read as an independently demonstrated guarantee of correctness. The supplied implementation evidence establishes the tool allowlist, permission assignments, durable execution, and approval boundary. It does not establish a measured success rate for proposed fixes or quantify the reduction in incident-resolution time for this workflow.
The practical value of the pattern is its explicit handoff from diagnosis to controlled execution. Evaluating it means examining the approved tools and the point at which infrastructure changes require approval, alongside the agent’s investigation quality. The guide provides an architecture for that handoff; production effectiveness still depends on whether the proposed actions resolve the incidents they target.
