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

> Source: <https://dev.to/aws-builders/i-built-an-aws-devops-ai-agent-using-kiro-crew-mcp-fk0>
> Published: 2026-08-24 11:30:54+00:00

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)