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

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.

Table of Contents

• The problem nobody talks about
• What AWS DevOps Agent actually is
• The integration: one MCP config block
• The architecture
• Live demo: what the agent found
• Applying the fixes
• The cron job: check every 30 minutes
• The investigate skill: deep root-cause analysis
• The security model: why this is safe
• The self-learning layer
• 34 tools at your agent's fingertips
• Cost considerations
• Try it yourself (complete walkthrough)

The problem nobody talks about

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.

The enterprise reality today

Here's what incident response looks like at most organizations I've consulted for:

The real killer: if no alarm was configured, this entire process never starts. The failure just accumulates until someone notices manually.

How our approach changes this

The architectural insight

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:

• DevOps Agent = the brain (read-only, investigates, produces exact fix commands)
• Kiro Crew = the hands (orchestrates, executes, verifies, learns from past incidents)

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 enterprises gain

1. No more silent failures. Cron catches issues whether or not alarms exist.
2. Consistent investigation quality. DevOps Agent doesn't get tired at 3 AM or skip steps under pressure.
3. 75% lower MTTR. AWS reports 75% reduction in customers using DevOps Agent. Adding Crew automation pushes it further.
4. Institutional memory. Crew's Knowledge base remembers every past incident. New team members inherit years of operational wisdom.
5. Audit trail by default. Every investigation, every fix, every decision logged in CloudTrail and Crew sessions.
6. Human-in-the-loop when you want it. Trust mode for non-critical environments, PR approval for production.

What if an agent checked for you? Every 30 minutes. Autonomously. While you sleep, eat dinner, or take your kid to the park.

What AWS DevOps Agent actually is

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:

• Amazon ECS (services, tasks, deployments, health checks)
• AWS Lambda (invocations, errors, duration, throttles, cold starts)
• Amazon API Gateway (5xx errors, latency, integration failures)
• Amazon RDS (connections, CPU, storage, replication lag)
• Amazon DynamoDB (throttles, capacity, latency)
• Amazon EC2 (status checks, CPU, network)
• Amazon S3 (error rates, request patterns)
• Amazon CloudWatch (alarms, metrics, anomalies)

What it does with that data:

• Discovers and maps your service topology automatically
• Correlates signals across metrics, traces, deployments, and configuration changes
• Investigates incidents with deep async root-cause analysis (takes 5 to 8 minutes per investigation)
• Generates recommendations with specific, actionable mitigations prioritized by severity
• Reviews releases by checking pull requests for production risk patterns before they ship

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)

The integration: one MCP config block

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.

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.

The architecture

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:

1. Cron fires every 30 minutes (*/30 * * * *)
2. Orchestrator (claude-sonnet-4) spawns 5 parallel subagents
3. Each subagent checks one domain: ECS, CI/CD, CloudWatch, DevOps Agent consultation, Lambda
4. All run simultaneously (not sequential, this matters for speed)
5. Results consolidated into severity-prioritized findings
6. If actionable: Coding Agent writes the fix, opens a PR on GitHub
7. Human reviews the PR in the morning

The agent can investigate but never deploy. That's the safety boundary.

Live demo: what the agent found

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:

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:

🚨 CRITICAL OUTAGE (4+ Days Down)

ECS Service in Terminal Failure Loop

Complete CI/CD Pipeline Breakdown

🟡 MEDIUM PRIORITY: Configuration Hardening

• Set health check grace period to 30+ seconds (currently 0)
• Add proper logging and monitoring configuration
• Implement proper security groups and networking

⚠️ Lambda Timeout Issue

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.

📊 CloudWatch: Zero Observability

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.

Applying the fixes

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.

The cron job: check every 30 minutes

Here's the cron that makes this autonomous. I added it through the Crew Schedule page:

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 investigate skill: deep root-cause analysis

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:

1. Pulls CloudWatch metrics: invocations, errors, duration, throttles, anomaly bands
2. Checks recent deployments: CodeDeploy, ECS task definitions, Lambda versions
3. Correlates downstream latency: X-Ray traces, API Gateway integration errors
4. Analyzes temporal patterns: did this start after a specific deployment?
5. Checks resource topology: which services depend on the failing component?
6. Returns root-cause analysis with prioritized recommendations

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.

The security model: why this is safe

"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:

• Investigation findings in the description
• Severity assessment
• Links to relevant CloudWatch metrics
• Diff showing exactly what changes

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

The pattern: observe everything, change nothing, suggest via PR, human approves.

The self-learning layer

Here's where Kiro Crew adds something DevOps Agent alone cannot do.

First time the agent investigates the ECS failure loop, it learns:

• payment-api uses nginx:alpine as the base image
• The health check path /api/health doesn't exist in that container
• Health check grace period of 0 seconds means immediate failure on deploy
• 7,279 tasks failed before anyone noticed because zero alarms were configured

Crew 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.

34 tools at your agent's fingertips

When you connect DevOps Agent via MCP, your Crew agent gets access to these tools:

Investigation & Monitoring:

Release & Deployment Safety:

Service & Space Management:

Access & Security:

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.

Cost considerations

Running this autonomously has cost implications worth understanding:

Kiro Crew costs:

• Claude Sonnet 4 token usage per cron run (approximately $0.02 to $0.08 depending on investigation depth)
• 48 runs per day at */30 = roughly $1 to $4/day for continuous monitoring
• Compare with: a single on-call engineer costs $200+/night

AWS DevOps Agent costs:

• Included with your Agent Space (no per-API-call charges for chat/investigate as of August 2026)
• The IAM role uses ReadOnlyAccess, so no resource creation costs from the agent itself

What this SAVES:

• 4 days of ECS task churn burning compute (in my case: ~$15-20 wasted before I noticed)
• Engineer investigation time (30-60 min per incident at $100+/hr senior rate)
• Customer-facing downtime (the real cost nobody measures until it happens)

The math: $2/day for continuous monitoring vs $200+ per missed incident. After one catch, it pays for itself for months.

Try it yourself (complete walkthrough)

Prerequisites

• Kiro Crew installed and running (install guide)
• AWS account with resources to monitor (at minimum: one Lambda function or ECS service)
• IAM permissions: aidevops:* for Agent Space management
• AWS CLI v2 configured with credentials
• Region: us-east-1, us-west-2, or eu-west-1

Step 1: Create an Agent Space

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.

Step 2: Create an IAM role for DevOps Agent

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.

Step 3: Associate your AWS account with the Agent Space

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

Step 4: Enable access tokens on the Agent Space

aws devops-agent update-agent-space \
  --agent-space-id YOUR_SPACE_ID \
  --access-token-configuration '{"enabled": true}' \
  --region us-east-1

Step 5: Create an access token for Kiro Crew

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.

Step 6: Add MCP server to Kiro Crew

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"

Step 7: Add the production health cron job

Go to Schedule in the Crew dashboard, click + Add Job:

Step 8: Verify it works

Trigger the cron manually by clicking Run in the Schedule page. You should see the agent:

1. Check available MCP tools
2. Call DevOps Agent's chat tool for a health assessment
3. Return findings with severity levels

If it returns "Overall: HEALTHY" with no flags, your infrastructure is in good shape. If it finds issues, you'll get severity-prioritized recommendations.

What's next

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:

1. Introducing Kiro Crew
2. I Spent a Day With Kiro Crew
3. Cron Jobs Replaced 4 Hours of Weekly Toil
4. The Security Model That Got CISO Approval
5. I Built a Custom App in 5 Minutes
6. This article: Crew + DevOps Agent autonomous ops

GitHub repo with all configs: 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 | LinkedIn | Dev.to | YouTube | X | AWS Builder Center