/api/health
endpoint, causing ECS to kill and replace tasks every 60 seconds. It was a massive, silent leak—7,279 failed tasks since mid-August, yet no PagerDuty alert, no Slack notification, nothing. I slept through the entire disaster, but I didn't wake up to a crisis; I woke up to a solved problem.I’ve been testing how to bridge that gap between "something is wrong" and "someone actually noticed" by deploying an LLM agent workflow using Kiro Crew and the Model Context Protocol (MCP). Instead of waiting for a human to context-switch and fight through MFA/VPN hurdles, I let an autonomous agent handle the heavy lifting.
The Gap in Standard DevOps Monitoring #
In most enterprise environments, monitoring is reactive. PagerDuty is great, but it only works if you’ve already anticipated the failure mode and set a specific alarm for it. If you have a slow leak—like a Lambda timeout that’s just slightly too short, or a CodeBuild project that’s been failing silently for a week—you won't know until the bill arrives or a customer screams.
The traditional incident response timeline is a killer:
- Human wakes up (fatigue/stress)
- Logging into consoles (MFA/VPN delays)
- Hunting through CloudWatch (which log group? which timeframe?)
- Correlation (was it a deployment? a config change?)
How the AWS DevOps Agent works via MCP #
I integrated an AWS DevOps Agent into my Kiro Crew orchestration. By using MCP, I gave the agent a massive toolkit—34 different tools—to interact directly with my AWS environment. This isn't just a chatbot; it's a functional deployment of an AI workflow that can perform deep root-cause analysis.
When the failure loop started, the agent didn't just send a message. It spawned five parallel investigations. It called the AWS DevOps Agent to perform a health assessment and traversed the entire stack: ECS, CodeBuild, CodePipeline, and Lambda.
Technical Implementation: The MCP Config #
The integration relies on a specific configuration block that allows the agent to access the necessary AWS services through the MCP interface. Here is the conceptual setup for the agent's environment:
mcp_servers:
aws_devops:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-aws"]
env:
AWS_REGION: "us-east-1"
AWS_ACCESS_KEY_ID: "${AWS_ACCESS_KEY_ID}"
AWS_SECRET_ACCESS_KEY: "${AWS_SECRET_ACCESS_KEY}"
capabilities:
- cloudwatch_logs_read
- ecs_task_describe
- lambda_function_get_config
- codepipeline_get_execution
Real-world findings and autonomous fixes #
During the live run, the agent identified that the root cause wasn't just a random code error. It correlated a recent CodePipeline execution with a configuration drift in the ECS task definition.
The agent's "investigate" skill is what makes this different from a standard script. It doesn't just look for errors; it performs a deep dive. It can:
Analyze logs: It searched through CloudWatch to find the specific 404 errors on the health check endpoint.Correlate events: It checked if a deployment happened right before the failure loop spiked.Prioritize fixes: It didn't just dump data; it flagged the issue with a severity rating and proposed the exact configuration change needed to restore the/api/health
path.
By 3:24 AM—just seven minutes after the initial detection—the investigation was complete and the fix was ready for approval.
Is this safe for production? #
This is the question I get most often when rolling out AI agents in a corporate setting. The security model here is built on principle of least privilege. The agent doesn't have "Admin" access to the whole account; it uses scoped IAM roles provided through the MCP server. You aren't giving an LLM your root keys; you are giving a controlled process access to specific read/write actions within a defined boundary.
I've set this up as a cron job to run every 30 minutes. It acts as a continuous "sanity check" layer that sits underneath the traditional monitoring stack, catching the silent failures that standard alarms miss. It's not about replacing engineers, but about ensuring that when we do wake up, we're solving problems rather than just discovering them.
Next Managing four concurrent coding agents is where my productivity →
these real-world AI monetization case studies, with plenty of directly applicable cases.