Closed-loop incident response: connect AWS DevOps Agent to OpenSearch

We’ve all experienced it: an alert fires at 2 AM, you wake up, log in, and spend thirty minutes digging through logs to find what broke. By then, your team is already in the incident channel. What if that entire investigation—log searches, metric correlation, error pattern matching—happened automatically before a human ever saw the alert? AWS DevOps Agent now supports exactly this through integration with Amazon OpenSearch Service via the Model Context Protocol (MCP). Instead of receiving a symptom, you get context: the root cause, affected services, and correlated events, all waiting when you open your laptop.

Here’s what’s happening under the hood. When an alert triggers in OpenSearch, it can invoke AWS DevOps Agent, which acts as an autonomous investigator. The agent connects to your OpenSearch cluster through MCP—a standardized protocol that lets AI systems safely query external tools and data sources. The agent then runs intelligent queries against your observability data: it searches logs for error patterns, pulls metrics from the time window around the incident, checks for recent deployments, and identifies which services showed abnormal behavior. All of this happens in seconds. You get back a structured investigation report rather than raw data, which AWS DevOps Agent can further route to incident management tools, Slack channels, or runbooks that auto-remediate common issues. This is “closed-loop” because the system doesn’t just alert—it observes, investigates, acts, and reports back.

Technically, you have three paths to implement this. First, you can self-manage an MCP server on Amazon ECS—useful if you want full control over environment variables, secrets, and scaling policies. Second, you can use Amazon Bedrock AgentCore as your hosting layer, which handles the infrastructure and scales automatically but gives you less customization. Third, if you’re on OpenSearch 3.3 or newer, the MCP server is built-in, which is the simplest path for many teams. Regardless of your hosting choice, you’ll need to handle alert routing (which alerts trigger investigation?) and Fine-Grained Access Control (FGAC) role mapping, so the agent queries only the data it should see. A security team might restrict the agent to application logs but not infrastructure secrets, for example.

Practically, this changes your incident lifecycle. A spike in 5xx errors at 2 AM no longer requires waking someone immediately—the agent investigates and either resolves it automatically (if it’s a known issue) or escalates with full context. A team supporting distributed microservices can have the agent correlate errors across service boundaries, which humans often miss in their first pass. An on-call engineer returning to work the next morning finds a complete incident summary, not a wall of alerts. If you’re running multi-tenant systems or comply with audit requirements, FGAC ensures each investigation respects data boundaries. Start small: pick one non-critical alert, connect it to DevOps Agent and OpenSearch, and let it run investigations for a week. You’ll quickly see which investigations are valuable and which need tuning.