DEV Community

AWS Community Builders profile image Sarvar Nadaf
Sarvar Nadaf for AWS Community Builders

Posted on

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

#agents #ai #showdev #devops

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

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:

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.

How our approach changes this

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

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
      ]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

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       │            │                  │
   └────────────────────┘            └──────────────────┘
Enter fullscreen mode Exit fullscreen mode

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:

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:

🚨 CRITICAL OUTAGE (4+ Days Down)

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

🟡 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Verified state after fixes:

Lambda Demo:     30s (was 3s)
Lambda Demo-API: 30s (was 3s)
Alarms:          2 active (was 0)
Enter fullscreen mode Exit fullscreen mode

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:

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
Enter fullscreen mode Exit fullscreen mode

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"
      }
    }
  }]
}
Enter fullscreen mode Exit fullscreen mode

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"
  ]
}
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

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.

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:

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.

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

Step 7: Add the production health cron job

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.

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

Top comments (0)