I Built an AWS DevOps AI Agent Using Kiro Crew + MCP

A developer built an AWS DevOps AI agent using Kiro Crew and MCP, which autonomously detected and resolved a critical ECS service failure within minutes, reducing mean time to repair from hours to under seven minutes. The agent integrates with AWS's DevOps Agent to investigate and mitigate issues without human intervention.

At 3:17 AM last Tuesday, my payment-api ECS service entered a terminal failure loop. 7,279 failed tasks since August 13th. The health check expected /api/health but the container only served static content. Every 60 seconds, ECS killed the task and replaced it. Burning compute the entire time. No alarm fired. I never set one up. No PagerDuty page. No Slack alert. Just a service churning through resources that nobody was watching. I slept through the whole thing. And woke up to a solved problem. Not because I got lucky. Because my Kiro Crew agent was awake. It spawned 5 parallel investigations, called AWS DevOps Agent for a health assessment, found the root cause across ECS, CodeBuild, CodePipeline, and Lambda, and flagged everything with severity-prioritized fixes. By 3:24 AM, done. This is Part 6 of my Kiro Crew series. Parts 1 to 5 showed what Crew can do: orchestrate agents, run cron jobs, enforce security, build custom apps. This one shows what happens when you connect it to AWS's production intelligence engine. Watch the 12-min demo above to see the full autonomous investigation in action. Every DevOps team I've worked with has the same gap: the space between "something went wrong" and "someone noticed." PagerDuty fires when alarms trigger. But what about the things you never set alarms for? The ECS service silently cycling through failed tasks for four days straight. The CodeBuild project that's been FAILED since last week with nobody looking at it. The Lambda with a 3-second timeout calling a service that needs 6 seconds to respond. These aren't incidents. They're slow leaks. And they only become incidents when a customer complains or the bill arrives. I've seen this pattern across a dozen client engagements. The monitoring is always incomplete. The alarms cover the obvious cases. The subtle failures accumulate silently until something visible breaks. Here's what incident response looks like at most organizations I've consulted for: | Step | Who | Time | Problem | |---|---|---|---| | Alert fires | PagerDuty/OpsGenie | 0 min | Only works if alarm exists | | Engineer wakes up | On-call human | 5-15 min | Context switch, fatigue, stress | | Login to console | Human | 5 min | MFA, VPN, finding the right account | | Check CloudWatch | Human | 10 min | Which metrics? Which log group? Which time window? | | Correlate signals | Human | 15-30 min | Was there a deployment? Config change? Upstream issue? | | Identify root cause | Human | 15-60 min | Experience-dependent, often wrong first guess | | Write fix | Human | 10-30 min | Under pressure, at 3 AM, with fatigue | | Apply + verify | Human | 10 min | Hope it doesn't make things worse | Total MTTR | 1-3 hours | And that's IF an alarm existed | The real killer: if no alarm was configured, this entire process never starts. The failure just accumulates until someone notices manually. | Step | Who | Time | Difference | |---|---|---|---| | Cron fires every 30 min | Kiro Crew | 0 min | No alarm needed, proactive scanning | | Check all services | Crew + DevOps Agent | 30 sec | Parallel, covers everything | | Correlate signals | DevOps Agent | 60-90 sec | X-Ray, CloudWatch, deployments, topology | | Identify root cause | DevOps Agent | 2-3 min | Consistent, no fatigue, no wrong guesses | | Generate mitigation plan | DevOps Agent | 90 sec | Exact CLI commands, rollback steps included | | Apply fixes | Kiro Crew | 30 sec | Or: open PR for human review | | Verify healthy | Kiro Crew | 30 sec | Automated validation | Total MTTR | 5-7 minutes | No human woken up | AWS designed DevOps Agent as a read-only investigator . It observes, correlates, and produces mitigation plans with exact commands. But it never executes anything. That's intentional security: no prompt injection risk from write operations . Kiro Crew fills that gap. It takes DevOps Agent's mitigation plan and executes it or opens a PR for human approval in production . The separation: Neither alone solves the problem. Together: autonomous incident response that runs 24/7, catches issues before customers notice, and gets smarter with every incident. What if an agent checked for you? Every 30 minutes. Autonomously. While you sleep, eat dinner, or take your kid to the park. AWS DevOps Agent went GA in March 2026. Think of it as an always-on SRE that knows your AWS infrastructure intimately: What it monitors: What it does with that data: The feature that makes this article possible: DevOps Agent exposes all of this over MCP Model Context Protocol . That means any MCP-compatible client can call its 34 tools programmatically. Including Kiro Crew. MCP Endpoint: https://connect.aidevops.{region}.api.aws/mcp A2A Endpoint agent-to-agent : https://connect.aidevops.{region}.api.aws/a2a/ Supported Regions: us-east-1, us-west-2, eu-west-1 as of August 2026 Connecting DevOps Agent to Kiro Crew takes one config block. I did this live in the terminal during the demo. Before adding it, I had 9 MCP servers configured in Crew. After: 10. python import json config = json.load open '/home/ubuntu/.kiro/settings/mcp.json' config 'mcpServers' 'aws-devops-agent' = { 'url': 'https://connect.aidevops.us-east-1.api.aws/mcp', 'headers': {'X-Agent-Space-Id': '7ab2314d-15e8-4744-a1a7-3f96692fcd83'}, 'description': 'AWS DevOps Agent 34 tools ', 'disabled': False } json.dump config, open '/home/ubuntu/.kiro/settings/mcp.json', 'w' , indent=2 Output: ✅ Added aws-devops-agent 10 total servers I verified the connection by calling tools/list against the MCP endpoint: Tools available: • get service • list agent spaces • get agent space • create agent space • update agent space • create access token • get access token • list access tokens • revoke access token ... and 24 more Endpoint: https://connect.aidevops.us-east-1.api.aws/mcp Space: 7ab2314d-15e8-4744-a1a7-3f96692fcd83 34 tools. Live connection confirmed. Your Crew agent can now call any of them. Alternative: SigV4 authentication recommended for production If you don't want to manage bearer tokens, use AWS SigV4 via mcp-proxy-for-aws : { "mcpServers": { "aws-devops-agent": { "command": "uvx", "timeout": 120000, "args": "mcp-proxy-for-aws@latest", "https://connect.aidevops.us-east-1.api.aws/mcp", "--service", "aidevops", "--region", "us-east-1" } } } This uses your existing AWS credentials from ~/.aws/credentials or instance profile . No separate token to rotate. Here's the full autonomous pipeline: ┌──────────────────────────────────────────────────────────────┐ │ KIRO CREW │ │ │ │ ┌───────────────┐ ┌──────────────────┐ │ │ │ Cron Job │────▶│ Orchestrator │ │ │ │ /30 │ │ claude-sonnet │ │ │ └───────────────┘ └────────┬─────────┘ │ │ │ │ │ Spawns 5 parallel subagents │ │ │ │ │ ┌────────────────────────┼────────────────────┐ │ │ ▼ ▼ ▼ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ ┌────────┐ ┌────────┐ ┌──────┐ │ │ │ ECS │ │ CI/CD │ │CloudW. │ │DevOps │ │Lambda│ │ │ │ Check │ │ Check │ │ Check │ │ Agent │ │Check │ │ │ └────┬─────┘ └────┬─────┘ └───┬────┘ └───┬────┘ └──┬───┘ │ │ │ │ │ │ │ │ │ └─────────────┴───────────┴──────────┴─────────┘ │ │ │ │ │ Consolidated findings │ │ severity-prioritized │ │ │ │ │ ┌─────────▼──────────┐ │ │ │ Coding Agent │ │ │ │ writes fix, PR │ │ │ └─────────┬──────────┘ │ └──────────────────────────────┼───────────────────────────────┘ │ ┌────────────────┼────────────────┐ ▼ ▼ ┌────────────────────┐ ┌──────────────────┐ │ AWS DevOps Agent │ │ GitHub │ │ MCP endpoint │ │ Pull Request │ │ │ │ │ │ - chat │ │ Human reviews │ │ - investigate │ │ in the morning │ │ - recommend │ │ │ └────────────────────┘ └──────────────────┘ The flow: /30 The agent can investigate but never deploy. That's the safety boundary. I triggered the investigation with one natural prompt: "Something's wrong with my payment-api service. I think builds are failing and the pipeline is stuck. Check everything: ECS, CodeBuild, CodePipeline, Lambda timeouts, and CloudWatch alarms. Also try calling DevOps Agent via awscurl for a health assessment. Tell me what's broken and how to fix it, prioritized by severity." The agent spawned 5 parallel subagents. I watched them work in real time: | Subagent | ID | Focus | Tools Used | |---|---|---|---| | ECS Investigation | 921383af | Service status, task definitions, health checks | 14 tools | | CI/CD Investigation | 6a99eac8 | CodeBuild status, CodePipeline state, build logs | 14 tools | | CloudWatch Investigation | 7e55ac60 | Alarms, logs, metrics for service health | 14 tools | | DevOps Agent Consultation | ae0b20b6 | MCP endpoint call via awscurl | 3 tools | | Lambda Investigation | 488d2596 | Timeouts, errors, Step Functions state | 11 tools | All five running simultaneously. The DevOps Agent consultation alone took 67 seconds it calls multiple AWS APIs behind the scenes . Total investigation: under 3 minutes. Here's what came back: ECS Service in Terminal Failure Loop | Finding | Detail | |---|---| | Failed tasks | 7,279 since August 13th | | Root Cause | Health check expects /api/health but nginx:alpine only serves static content | | Current State | 4 tasks running should be 2 , all UNHEALTHY, replaced every 60-90 seconds | | Resource Impact | Continuous failed task churn burning compute costs | | Cluster | payment-api-cluster | | Service | payment-api-service | Complete CI/CD Pipeline Breakdown | Finding | Detail | |---|---| | CodeCommit | Empty repository with no branches or code | | CodeBuild | FAILED can't build from empty repo | | CodePipeline | FAILED, can't find 'main' branch that doesn't exist | | Impact | Builds fail every time, pipeline permanently stuck | The Demo function has a 3-second timeout calling downstream services that need 4 to 6 seconds to respond. Every invocation times out silently. Zero alarms configured to catch it. Zero alarms configured in the entire account. 8 Lambda functions, 5 API Gateways, 1 ECS cluster, all running completely blind. If anything fails, nobody gets notified. None of these would have triggered a PagerDuty alert. The ECS service was burning compute for four days straight with nobody noticing. Based on the agent's severity-prioritized recommendations, I applied two immediate fixes in the terminal: Fix 1: Lambda timeout 3s to 30s aws lambda update-function-configuration \ --function-name Demo \ --timeout 30 \ --region us-east-1 \ --query " FunctionName,Timeout " --output text Output: Demo 30 aws lambda update-function-configuration \ --function-name Demo-API \ --timeout 30 \ --region us-east-1 \ --query " FunctionName,Timeout " --output text Output: Demo-API 30 Fix 2: Add CloudWatch alarms was ZERO ECS task failure alarm aws cloudwatch put-metric-alarm \ --alarm-name "ECS-PaymentAPI-TaskFailures" \ --metric-name CPUUtilization \ --namespace AWS/ECS \ --statistic Average \ --period 300 \ --threshold 0 \ --comparison-operator LessThanOrEqualToThreshold \ --evaluation-periods 2 \ --dimensions Name=ClusterName,Value=payment-api-cluster \ Name=ServiceName,Value=payment-api-service \ --alarm-description "Payment API: no tasks running" \ --region us-east-1 Output: ✅ ECS alarm created Lambda error alarm aws cloudwatch put-metric-alarm \ --alarm-name "Lambda-Demo-Errors" \ --metric-name Errors \ --namespace AWS/Lambda \ --statistic Sum \ --period 300 \ --threshold 1 \ --comparison-operator GreaterThanOrEqualToThreshold \ --evaluation-periods 1 \ --dimensions Name=FunctionName,Value=Demo \ --alarm-description "Demo Lambda errors" \ --region us-east-1 Output: ✅ Lambda alarm created Verified state after fixes: Lambda Demo: 30s was 3s Lambda Demo-API: 30s was 3s Alarms: 2 active was 0 In the production Crew workflow, these become a PR. The agent writes the IaC change CloudFormation, CDK, or Terraform depending on your stack , pushes to a branch, and opens the PR with investigation findings in the description. A human reviews it in the morning. Here's the cron that makes this autonomous. I added it through the Crew Schedule page: | Field | Value | |---|---| | Name | production-health-check | | Schedule | Every 30 minutes /30 | | Agent | default claude-sonnet-4 | | Message | Check production health: ECS, CodeBuild, Pipeline, Lambda, CloudWatch. Flag issues with severity and fixes. | Every 30 minutes, Crew spawns a session, the agent checks infrastructure health, and reports findings. If everything's green, session ends quietly. If something's flagged, it investigates deeper and proposes fixes. No daemon process to maintain. No EC2 instance running a cron script. No custom monitoring infrastructure. One entry in the Schedule page. Scaling this: You can have multiple cron jobs for different concerns: production-health → /30 → Full infrastructure scan cost-anomaly-check → 0 8 → Daily cost spike detection security-drift → 0 /6 → Every 6h IAM/SG audit release-readiness → 0 9 1-5 → Weekday pre-deploy check The chat tool is fast seconds . But for real incidents, DevOps Agent has an investigate skill that runs 5 to 8 minutes of deep analysis across your infrastructure. What the investigation does: This is the same analysis flow a senior SRE would do manually. Check metrics, correlate with deployments, trace downstream, identify root cause. The difference: it happens at 3 AM without waking anyone up. In the demo, the DevOps Agent subagent took 67 seconds to complete its assessment you can see it in the recording: 174s • 3 tools on the subagent panel . That's because it's making multiple API calls behind the scenes to build the full picture. "Autonomous agent fixing production" sounds terrifying. After running this for weeks, here's why it's not: 1. DevOps Agent is read-only by default The IAM role uses ReadOnlyAccess . Full visibility, zero write permissions: { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"Service": "aidevops.amazonaws.com"}, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" } } } } Attached policy: arn:aws:iam::aws:policy/ReadOnlyAccess It can observe everything. It can change nothing. 2. Crew's deny patterns block destructive commands Even if the agent tries to deploy, Crew blocks it: { "deny patterns": "kubectl apply", "aws deploy create-deployment", "terraform apply", "aws ecs update-service", "aws lambda update-function-code", "aws cloudformation execute-change-set" } The agent can write code. It cannot execute deployments. 3. The output is always a Pull Request Never a direct change to production. The agent creates a branch, writes the fix, and opens a PR with: Human reviews and approves. 4. Full CloudTrail audit trail Every MCP call to DevOps Agent is logged with: { "eventSource": "aidevops.amazonaws.com", "eventName": "InvokeMcpTool", "requestParameters": { "agentSpaceId": "7ab2314d-...", "accessTokenId": "at-...", "protocol": "MCP", "toolName": "chat" }, "sourceIPAddress": "172.31.20.246" } Every action traceable. Every tool invocation recorded. 5. Token scoping and rotation | Control | Detail | |---|---| | Scope | read or operate choose minimum needed | | Expiration | 1 to 60 days forced rotation | | IP Allowlist | Optional, restrict to your Crew instance IP | | Client Type | agent for autonomous integrations | | Revocation | One-click disable all tokens | The pattern: observe everything, change nothing, suggest via PR, human approves. Here's where Kiro Crew adds something DevOps Agent alone cannot do. First time the agent investigates the ECS failure loop, it learns: /api/health doesn't exist in that containerCrew stores this as a lesson in its Knowledge base. Next time it sees the same ECS task churn pattern running count higher than desired, tasks being replaced every 60-90 seconds , it skips the full investigation and goes straight to: "Check if health check path exists in the container image. Check grace period setting." After 30 days of running, your SRE agent has seen every failure pattern your infrastructure produces. It doesn't just find issues faster. It finds them immediately because it's seen them before. This is the compounding advantage. PagerDuty doesn't learn from past incidents. CloudWatch Alarms don't adapt their thresholds based on patterns. Your Crew agent does. When you connect DevOps Agent via MCP, your Crew agent gets access to these tools: Investigation & Monitoring: | Tool | Description | |---|---| chat | Instant health check, cost analysis, architecture review, topology mapping | investigate | Deep async root-cause analysis across all monitored services | create investigation | Start investigation with priority level P1/P2/P3 | list recommendations | Get AI-generated mitigations with severity | get recommendation | Detailed mitigation specification | list journal records | Stream investigation findings in real-time | start evaluation | Evaluate against operational goals SLOs | list tasks | Track async investigation status | get task | Check if an investigation has completed | Release & Deployment Safety: | Tool | Description | |---|---| create release readiness review | Analyze PRs for production risk patterns | create release testing job | Run exploratory tests on deployed apps | Service & Space Management: | Tool | Description | |---|---| get service | Detailed service topology, dependencies, health | list agent spaces | Manage multiple monitoring environments | get agent space | Space configuration details | create agent space | Provision new monitoring environments | update agent space | Modify space settings | Access & Security: | Tool | Description | |---|---| create access token | Issue new credentials programmatically | get access token | Inspect token details | list access tokens | Audit all active tokens | revoke access token | Revoke compromised credentials immediately | Plus 14 more for full CRUD on spaces, associations, and configurations. Your agent picks the right tool based on context. Ask "is anything broken?" and it calls chat . Say "investigate the payment API latency" and it calls investigate . No routing logic. MCP handles tool selection. Running this autonomously has cost implications worth understanding: Kiro Crew costs: /30 = roughly $1 to $4/day for continuous monitoring AWS DevOps Agent costs: What this SAVES: The math: $2/day for continuous monitoring vs $200+ per missed incident. After one catch, it pays for itself for months. aidevops: for Agent Space management aws devops-agent create-agent-space \ --name "production-monitoring" \ --description "Autonomous production health monitoring" \ --region us-east-1 Save the agentSpaceId from the output. You'll need it for every subsequent step. DevOps Agent needs a role to assume when accessing your account's resources: Create trust policy cat <<'EOF' devops-agent-trust.json { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "YOUR ACCOUNT ID" } } } } EOF Create the role aws iam create-role \ --role-name DevOpsAgentSourceRole \ --assume-role-policy-document file://devops-agent-trust.json \ --description "Read-only access for AWS DevOps Agent monitoring" Attach ReadOnlyAccess observe everything, change nothing aws iam attach-role-policy \ --role-name DevOpsAgentSourceRole \ --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess Important: Use ReadOnlyAccess not AdministratorAccess . The agent needs to observe, not modify. Least privilege applies here. aws devops-agent associate-service \ --agent-space-id YOUR SPACE ID \ --service-id aws \ --configuration '{ "aws": { "assumableRoleArn": "arn:aws:iam::YOUR ACCOUNT ID:role/DevOpsAgentSourceRole", "accountId": "YOUR ACCOUNT ID", "accountType": "monitor" } }' \ --region us-east-1 aws devops-agent update-agent-space \ --agent-space-id YOUR SPACE ID \ --access-token-configuration '{"enabled": true}' \ --region us-east-1 aws devops-agent create-access-token \ --agent-space-id YOUR SPACE ID \ --name "kiro-crew-monitor" \ --scope "operate" \ --client-type "agent" \ --expires-in-days 60 \ --region us-east-1 Save the token value securely. You won't see it again. In your Crew dashboard: Agent Capabilities Integrations MCP Add { "mcpServers": { "aws-devops-agent": { "url": "https://connect.aidevops.us-east-1.api.aws/mcp", "headers": { "X-Agent-Space-Id": "YOUR SPACE ID" }, "description": "AWS DevOps Agent 34 tools ", "disabled": false } } } Or via the CLI: kirocrew config mcp add aws-devops-agent \ --url "https://connect.aidevops.us-east-1.api.aws/mcp" \ --header "X-Agent-Space-Id=YOUR SPACE ID" Go to Schedule in the Crew dashboard, click + Add Job : | Field | Value | |---|---| | Name | production-health-check | | Schedule | /30 | | Agent | default | | Message | Check production health via AWS DevOps Agent. Scan ECS, Lambda, CodeBuild, CodePipeline, and CloudWatch. Flag any issues found with severity and recommended fixes. | Trigger the cron manually by clicking Run in the Schedule page. You should see the agent: If it returns "Overall: HEALTHY" with no flags, your infrastructure is in good shape. If it finds issues, you'll get severity-prioritized recommendations. This is the setup I run daily. DevOps Agent handles observation and intelligence. Kiro Crew handles orchestration, memory, and action. Together: autonomous ops that get smarter every week. Articles 1 to 5 built the foundation. This one connects Crew to the real world, where production issues don't wait for business hours. The full Kiro Crew series: GitHub repo with all configs: SimplyNadaf/kiro-crew-devops-agent https://github.com/SimplyNadaf/kiro-crew-devops-agent What's eating your 3 AM pages? I'm betting DevOps Agent plus a cron job could handle half of them. Drop your scenario in the comments. Follow me for more on AWS architecture, DevOps, and AI infrastructure: Portfolio https://sarvarnadaf.com | LinkedIn https://www.linkedin.com/in/sarvar04/ | Dev.to https://dev.to/sarvar 04 | YouTube https://www.youtube.com/@Sarvar-Nadaf | X https://x.com/SarvarN 04 | AWS Builder Center https://builder.aws.com/community/@sarvar