{"slug": "i-built-an-aws-devops-ai-agent-using-kiro-crew-mcp", "title": "I Built an AWS DevOps AI Agent Using Kiro Crew + MCP", "summary": "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.", "body_md": "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`\n\nbut the container only served static content. Every 60 seconds, ECS killed the task and replaced it. Burning compute the entire time.\n\nNo alarm fired. I never set one up. No PagerDuty page. No Slack alert. Just a service churning through resources that nobody was watching.\n\nI slept through the whole thing. And woke up to a solved problem.\n\nNot 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.\n\nThis 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.\n\n*Watch the 12-min demo above to see the full autonomous investigation in action.*\n\nEvery DevOps team I've worked with has the same gap: the space between \"something went wrong\" and \"someone noticed.\"\n\nPagerDuty 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.\n\nThese aren't incidents. They're slow leaks. And they only become incidents when a customer complains or the bill arrives.\n\nI'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.\n\nHere's what incident response looks like at most organizations I've consulted for:\n\n| Step | Who | Time | Problem |\n|---|---|---|---|\n| Alert fires | PagerDuty/OpsGenie | 0 min | Only works if alarm exists |\n| Engineer wakes up | On-call human | 5-15 min | Context switch, fatigue, stress |\n| Login to console | Human | 5 min | MFA, VPN, finding the right account |\n| Check CloudWatch | Human | 10 min | Which metrics? Which log group? Which time window? |\n| Correlate signals | Human | 15-30 min | Was there a deployment? Config change? Upstream issue? |\n| Identify root cause | Human | 15-60 min | Experience-dependent, often wrong first guess |\n| Write fix | Human | 10-30 min | Under pressure, at 3 AM, with fatigue |\n| Apply + verify | Human | 10 min | Hope it doesn't make things worse |\nTotal MTTR |\n1-3 hours |\nAnd that's IF an alarm existed |\n\nThe real killer: **if no alarm was configured, this entire process never starts.** The failure just accumulates until someone notices manually.\n\n| Step | Who | Time | Difference |\n|---|---|---|---|\n| Cron fires (every 30 min) | Kiro Crew | 0 min | No alarm needed, proactive scanning |\n| Check all services | Crew + DevOps Agent | 30 sec | Parallel, covers everything |\n| Correlate signals | DevOps Agent | 60-90 sec | X-Ray, CloudWatch, deployments, topology |\n| Identify root cause | DevOps Agent | 2-3 min | Consistent, no fatigue, no wrong guesses |\n| Generate mitigation plan | DevOps Agent | 90 sec | Exact CLI commands, rollback steps included |\n| Apply fixes | Kiro Crew | 30 sec | Or: open PR for human review |\n| Verify healthy | Kiro Crew | 30 sec | Automated validation |\nTotal MTTR |\n5-7 minutes |\nNo human woken up |\n\nAWS 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).\n\nKiro Crew fills that gap. It takes DevOps Agent's mitigation plan and executes it (or opens a PR for human approval in production).\n\nThe separation:\n\nNeither alone solves the problem. Together: autonomous incident response that runs 24/7, catches issues before customers notice, and gets smarter with every incident.\n\nWhat if an agent checked for you? Every 30 minutes. Autonomously. While you sleep, eat dinner, or take your kid to the park.\n\nAWS DevOps Agent went GA in March 2026. Think of it as an always-on SRE that knows your AWS infrastructure intimately:\n\n**What it monitors:**\n\n**What it does with that data:**\n\nThe 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.\n\n**MCP Endpoint:** `https://connect.aidevops.{region}.api.aws/mcp`\n\n**A2A Endpoint (agent-to-agent):** `https://connect.aidevops.{region}.api.aws/a2a/*`\n\n**Supported Regions:** us-east-1, us-west-2, eu-west-1 (as of August 2026)\n\nConnecting 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.\n\n``` python\nimport json\n\nconfig = json.load(open('/home/ubuntu/.kiro/settings/mcp.json'))\nconfig['mcpServers']['aws-devops-agent'] = {\n    'url': 'https://connect.aidevops.us-east-1.api.aws/mcp',\n    'headers': {'X-Agent-Space-Id': '7ab2314d-15e8-4744-a1a7-3f96692fcd83'},\n    'description': 'AWS DevOps Agent (34 tools)',\n    'disabled': False\n}\njson.dump(config, open('/home/ubuntu/.kiro/settings/mcp.json', 'w'), indent=2)\n# Output: ✅ Added aws-devops-agent (10 total servers)\n```\n\nI verified the connection by calling `tools/list`\n\nagainst the MCP endpoint:\n\n```\nTools available:\n  • get_service\n  • list_agent_spaces\n  • get_agent_space\n  • create_agent_space\n  • update_agent_space\n  • create_access_token\n  • get_access_token\n  • list_access_tokens\n  • revoke_access_token\n  ... and 24 more\n\nEndpoint: https://connect.aidevops.us-east-1.api.aws/mcp\nSpace:    7ab2314d-15e8-4744-a1a7-3f96692fcd83\n```\n\n34 tools. Live connection confirmed. Your Crew agent can now call any of them.\n\n**Alternative: SigV4 authentication (recommended for production)**\n\nIf you don't want to manage bearer tokens, use AWS SigV4 via `mcp-proxy-for-aws`\n\n:\n\n```\n{\n  \"mcpServers\": {\n    \"aws-devops-agent\": {\n      \"command\": \"uvx\",\n      \"timeout\": 120000,\n      \"args\": [\n        \"mcp-proxy-for-aws@latest\",\n        \"https://connect.aidevops.us-east-1.api.aws/mcp\",\n        \"--service\", \"aidevops\",\n        \"--region\", \"us-east-1\"\n      ]\n    }\n  }\n}\n```\n\nThis uses your existing AWS credentials (from `~/.aws/credentials`\n\nor instance profile). No separate token to rotate.\n\nHere's the full autonomous pipeline:\n\n```\n┌──────────────────────────────────────────────────────────────┐\n│                       KIRO CREW                               │\n│                                                               │\n│  ┌───────────────┐     ┌──────────────────┐                  │\n│  │  Cron Job     │────▶│  Orchestrator    │                  │\n│  │  (*/30 * * *) │     │  (claude-sonnet) │                  │\n│  └───────────────┘     └────────┬─────────┘                  │\n│                                 │                             │\n│                    Spawns 5 parallel subagents                │\n│                                 │                             │\n│        ┌────────────────────────┼────────────────────┐       │\n│        ▼            ▼           ▼          ▼         ▼       │\n│  ┌──────────┐ ┌──────────┐ ┌────────┐ ┌────────┐ ┌──────┐  │\n│  │   ECS    │ │  CI/CD   │ │CloudW. │ │DevOps  │ │Lambda│  │\n│  │  Check   │ │  Check   │ │ Check  │ │ Agent  │ │Check │  │\n│  └────┬─────┘ └────┬─────┘ └───┬────┘ └───┬────┘ └──┬───┘  │\n│       │             │           │          │         │       │\n│       └─────────────┴───────────┴──────────┴─────────┘       │\n│                              │                                │\n│                    Consolidated findings                      │\n│                    (severity-prioritized)                     │\n│                              │                                │\n│                    ┌─────────▼──────────┐                    │\n│                    │  Coding Agent      │                    │\n│                    │  (writes fix, PR)  │                    │\n│                    └─────────┬──────────┘                    │\n└──────────────────────────────┼───────────────────────────────┘\n                               │\n              ┌────────────────┼────────────────┐\n              ▼                                 ▼\n   ┌────────────────────┐            ┌──────────────────┐\n   │  AWS DevOps Agent  │            │     GitHub       │\n   │  (MCP endpoint)    │            │  (Pull Request)  │\n   │                    │            │                  │\n   │  - chat            │            │  Human reviews   │\n   │  - investigate     │            │  in the morning  │\n   │  - recommend       │            │                  │\n   └────────────────────┘            └──────────────────┘\n```\n\nThe flow:\n\n`*/30 * * * *`\n\n)The agent can investigate but never deploy. That's the safety boundary.\n\nI triggered the investigation with one natural prompt:\n\n\"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.\"\n\nThe agent spawned 5 parallel subagents. I watched them work in real time:\n\n| Subagent | ID | Focus | Tools Used |\n|---|---|---|---|\n| ECS Investigation | 921383af | Service status, task definitions, health checks | 14 tools |\n| CI/CD Investigation | 6a99eac8 | CodeBuild status, CodePipeline state, build logs | 14 tools |\n| CloudWatch Investigation | 7e55ac60 | Alarms, logs, metrics for service health | 14 tools |\n| DevOps Agent Consultation | ae0b20b6 | MCP endpoint call via awscurl | 3 tools |\n| Lambda Investigation | 488d2596 | Timeouts, errors, Step Functions state | 11 tools |\n\nAll five running simultaneously. The DevOps Agent consultation alone took 67 seconds (it calls multiple AWS APIs behind the scenes). Total investigation: under 3 minutes.\n\nHere's what came back:\n\n**ECS Service in Terminal Failure Loop**\n\n| Finding | Detail |\n|---|---|\n| Failed tasks | 7,279 since August 13th |\n| Root Cause | Health check expects `/api/health` but nginx:alpine only serves static content |\n| Current State | 4 tasks running (should be 2), all UNHEALTHY, replaced every 60-90 seconds |\n| Resource Impact | Continuous failed task churn burning compute costs |\n| Cluster | payment-api-cluster |\n| Service | payment-api-service |\n\n**Complete CI/CD Pipeline Breakdown**\n\n| Finding | Detail |\n|---|---|\n| CodeCommit | Empty repository with no branches or code |\n| CodeBuild | FAILED (can't build from empty repo) |\n| CodePipeline | FAILED, can't find 'main' branch that doesn't exist |\n| Impact | Builds fail every time, pipeline permanently stuck |\n\nThe `Demo`\n\nfunction 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.\n\n**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.\n\n**None of these would have triggered a PagerDuty alert.** The ECS service was burning compute for four days straight with nobody noticing.\n\nBased on the agent's severity-prioritized recommendations, I applied two immediate fixes in the terminal:\n\n**Fix 1: Lambda timeout 3s to 30s**\n\n```\naws lambda update-function-configuration \\\n  --function-name Demo \\\n  --timeout 30 \\\n  --region us-east-1 \\\n  --query \"[FunctionName,Timeout]\" --output text\n# Output: Demo    30\n\naws lambda update-function-configuration \\\n  --function-name Demo-API \\\n  --timeout 30 \\\n  --region us-east-1 \\\n  --query \"[FunctionName,Timeout]\" --output text\n# Output: Demo-API    30\n```\n\n**Fix 2: Add CloudWatch alarms (was ZERO)**\n\n```\n# ECS task failure alarm\naws cloudwatch put-metric-alarm \\\n  --alarm-name \"ECS-PaymentAPI-TaskFailures\" \\\n  --metric-name CPUUtilization \\\n  --namespace AWS/ECS \\\n  --statistic Average \\\n  --period 300 \\\n  --threshold 0 \\\n  --comparison-operator LessThanOrEqualToThreshold \\\n  --evaluation-periods 2 \\\n  --dimensions Name=ClusterName,Value=payment-api-cluster \\\n               Name=ServiceName,Value=payment-api-service \\\n  --alarm-description \"Payment API: no tasks running\" \\\n  --region us-east-1\n# Output: ✅ ECS alarm created\n\n# Lambda error alarm\naws cloudwatch put-metric-alarm \\\n  --alarm-name \"Lambda-Demo-Errors\" \\\n  --metric-name Errors \\\n  --namespace AWS/Lambda \\\n  --statistic Sum \\\n  --period 300 \\\n  --threshold 1 \\\n  --comparison-operator GreaterThanOrEqualToThreshold \\\n  --evaluation-periods 1 \\\n  --dimensions Name=FunctionName,Value=Demo \\\n  --alarm-description \"Demo Lambda errors\" \\\n  --region us-east-1\n# Output: ✅ Lambda alarm created\n```\n\n**Verified state after fixes:**\n\n```\nLambda Demo:     30s (was 3s)\nLambda Demo-API: 30s (was 3s)\nAlarms:          2 active (was 0)\n```\n\nIn 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.\n\nHere's the cron that makes this autonomous. I added it through the Crew Schedule page:\n\n| Field | Value |\n|---|---|\n| Name | production-health-check |\n| Schedule | Every 30 minutes (`*/30 * * * *` ) |\n| Agent | default (claude-sonnet-4) |\n| Message | Check production health: ECS, CodeBuild, Pipeline, Lambda, CloudWatch. Flag issues with severity and fixes. |\n\nEvery 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.\n\nNo daemon process to maintain. No EC2 instance running a cron script. No custom monitoring infrastructure. One entry in the Schedule page.\n\n**Scaling this:** You can have multiple cron jobs for different concerns:\n\n```\nproduction-health    → */30 * * * *  → Full infrastructure scan\ncost-anomaly-check   → 0 8 * * *    → Daily cost spike detection  \nsecurity-drift       → 0 */6 * * *  → Every 6h IAM/SG audit\nrelease-readiness    → 0 9 * * 1-5  → Weekday pre-deploy check\n```\n\nThe `chat`\n\ntool is fast (seconds). But for real incidents, DevOps Agent has an `investigate`\n\nskill that runs 5 to 8 minutes of deep analysis across your infrastructure.\n\nWhat the investigation does:\n\nThis 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.\n\nIn the demo, the DevOps Agent subagent took 67 seconds to complete its assessment (you can see it in the recording: `174s • 3 tools`\n\non the subagent panel). That's because it's making multiple API calls behind the scenes to build the full picture.\n\n\"Autonomous agent fixing production\" sounds terrifying. After running this for weeks, here's why it's not:\n\n**1. DevOps Agent is read-only by default**\n\nThe IAM role uses `ReadOnlyAccess`\n\n. Full visibility, zero write permissions:\n\n```\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [{\n    \"Effect\": \"Allow\",\n    \"Principal\": {\"Service\": \"aidevops.amazonaws.com\"},\n    \"Action\": \"sts:AssumeRole\",\n    \"Condition\": {\n      \"StringEquals\": {\n        \"aws:SourceAccount\": \"123456789012\"\n      }\n    }\n  }]\n}\n```\n\nAttached policy: `arn:aws:iam::aws:policy/ReadOnlyAccess`\n\nIt can observe everything. It can change nothing.\n\n**2. Crew's deny patterns block destructive commands**\n\nEven if the agent tries to deploy, Crew blocks it:\n\n```\n{\n  \"deny_patterns\": [\n    \"kubectl apply\",\n    \"aws deploy create-deployment\",\n    \"terraform apply\",\n    \"aws ecs update-service\",\n    \"aws lambda update-function-code\",\n    \"aws cloudformation execute-change-set\"\n  ]\n}\n```\n\nThe agent can write code. It cannot execute deployments.\n\n**3. The output is always a Pull Request**\n\nNever a direct change to production. The agent creates a branch, writes the fix, and opens a PR with:\n\nHuman reviews and approves.\n\n**4. Full CloudTrail audit trail**\n\nEvery MCP call to DevOps Agent is logged with:\n\n```\n{\n  \"eventSource\": \"aidevops.amazonaws.com\",\n  \"eventName\": \"InvokeMcpTool\",\n  \"requestParameters\": {\n    \"agentSpaceId\": \"7ab2314d-...\",\n    \"accessTokenId\": \"at-...\",\n    \"protocol\": \"MCP\",\n    \"toolName\": \"chat\"\n  },\n  \"sourceIPAddress\": \"172.31.20.246\"\n}\n```\n\nEvery action traceable. Every tool invocation recorded.\n\n**5. Token scoping and rotation**\n\n| Control | Detail |\n|---|---|\n| Scope |\n`read` or `operate` (choose minimum needed) |\n| Expiration | 1 to 60 days (forced rotation) |\n| IP Allowlist | Optional, restrict to your Crew instance IP |\n| Client Type |\n`agent` (for autonomous integrations) |\n| Revocation | One-click disable all tokens |\n\nThe pattern: **observe everything, change nothing, suggest via PR, human approves.**\n\nHere's where Kiro Crew adds something DevOps Agent alone cannot do.\n\nFirst time the agent investigates the ECS failure loop, it learns:\n\n`/api/health`\n\ndoesn'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.\"\n\nAfter 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.\n\nThis 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.\n\nWhen you connect DevOps Agent via MCP, your Crew agent gets access to these tools:\n\n**Investigation & Monitoring:**\n\n| Tool | Description |\n|---|---|\n`chat` |\nInstant health check, cost analysis, architecture review, topology mapping |\n`investigate` |\nDeep async root-cause analysis across all monitored services |\n`create_investigation` |\nStart investigation with priority level (P1/P2/P3) |\n`list_recommendations` |\nGet AI-generated mitigations with severity |\n`get_recommendation` |\nDetailed mitigation specification |\n`list_journal_records` |\nStream investigation findings in real-time |\n`start_evaluation` |\nEvaluate against operational goals (SLOs) |\n`list_tasks` |\nTrack async investigation status |\n`get_task` |\nCheck if an investigation has completed |\n\n**Release & Deployment Safety:**\n\n| Tool | Description |\n|---|---|\n`create_release_readiness_review` |\nAnalyze PRs for production risk patterns |\n`create_release_testing_job` |\nRun exploratory tests on deployed apps |\n\n**Service & Space Management:**\n\n| Tool | Description |\n|---|---|\n`get_service` |\nDetailed service topology, dependencies, health |\n`list_agent_spaces` |\nManage multiple monitoring environments |\n`get_agent_space` |\nSpace configuration details |\n`create_agent_space` |\nProvision new monitoring environments |\n`update_agent_space` |\nModify space settings |\n\n**Access & Security:**\n\n| Tool | Description |\n|---|---|\n`create_access_token` |\nIssue new credentials programmatically |\n`get_access_token` |\nInspect token details |\n`list_access_tokens` |\nAudit all active tokens |\n`revoke_access_token` |\nRevoke compromised credentials immediately |\n\nPlus 14 more for full CRUD on spaces, associations, and configurations.\n\nYour agent picks the right tool based on context. Ask \"is anything broken?\" and it calls `chat`\n\n. Say \"investigate the payment API latency\" and it calls `investigate`\n\n. No routing logic. MCP handles tool selection.\n\nRunning this autonomously has cost implications worth understanding:\n\n**Kiro Crew costs:**\n\n`*/30`\n\n= roughly $1 to $4/day for continuous monitoring**AWS DevOps Agent costs:**\n\n**What this SAVES:**\n\nThe math: $2/day for continuous monitoring vs $200+ per missed incident. After one catch, it pays for itself for months.\n\n`aidevops:*`\n\nfor Agent Space management\n\n```\naws devops-agent create-agent-space \\\n  --name \"production-monitoring\" \\\n  --description \"Autonomous production health monitoring\" \\\n  --region us-east-1\n```\n\nSave the `agentSpaceId`\n\nfrom the output. You'll need it for every subsequent step.\n\nDevOps Agent needs a role to assume when accessing your account's resources:\n\n```\n# Create trust policy\ncat <<'EOF' > devops-agent-trust.json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [{\n    \"Effect\": \"Allow\",\n    \"Principal\": {\n      \"Service\": \"aidevops.amazonaws.com\"\n    },\n    \"Action\": \"sts:AssumeRole\",\n    \"Condition\": {\n      \"StringEquals\": {\n        \"aws:SourceAccount\": \"YOUR_ACCOUNT_ID\"\n      }\n    }\n  }]\n}\nEOF\n\n# Create the role\naws iam create-role \\\n  --role-name DevOpsAgentSourceRole \\\n  --assume-role-policy-document file://devops-agent-trust.json \\\n  --description \"Read-only access for AWS DevOps Agent monitoring\"\n\n# Attach ReadOnlyAccess (observe everything, change nothing)\naws iam attach-role-policy \\\n  --role-name DevOpsAgentSourceRole \\\n  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess\n```\n\n**Important:** Use `ReadOnlyAccess`\n\nnot `AdministratorAccess`\n\n. The agent needs to observe, not modify. Least privilege applies here.\n\n```\naws devops-agent associate-service \\\n  --agent-space-id YOUR_SPACE_ID \\\n  --service-id aws \\\n  --configuration '{\n    \"aws\": {\n      \"assumableRoleArn\": \"arn:aws:iam::YOUR_ACCOUNT_ID:role/DevOpsAgentSourceRole\",\n      \"accountId\": \"YOUR_ACCOUNT_ID\",\n      \"accountType\": \"monitor\"\n    }\n  }' \\\n  --region us-east-1\naws devops-agent update-agent-space \\\n  --agent-space-id YOUR_SPACE_ID \\\n  --access-token-configuration '{\"enabled\": true}' \\\n  --region us-east-1\naws devops-agent create-access-token \\\n  --agent-space-id YOUR_SPACE_ID \\\n  --name \"kiro-crew-monitor\" \\\n  --scope \"operate\" \\\n  --client-type \"agent\" \\\n  --expires-in-days 60 \\\n  --region us-east-1\n```\n\nSave the token value securely. You won't see it again.\n\nIn your Crew dashboard: **Agent Capabilities** > **Integrations (MCP)** > **Add**\n\n```\n{\n  \"mcpServers\": {\n    \"aws-devops-agent\": {\n      \"url\": \"https://connect.aidevops.us-east-1.api.aws/mcp\",\n      \"headers\": {\n        \"X-Agent-Space-Id\": \"YOUR_SPACE_ID\"\n      },\n      \"description\": \"AWS DevOps Agent (34 tools)\",\n      \"disabled\": false\n    }\n  }\n}\n```\n\nOr via the CLI:\n\n```\nkirocrew config mcp add aws-devops-agent \\\n  --url \"https://connect.aidevops.us-east-1.api.aws/mcp\" \\\n  --header \"X-Agent-Space-Id=YOUR_SPACE_ID\"\n```\n\nGo to **Schedule** in the Crew dashboard, click **+ Add Job**:\n\n| Field | Value |\n|---|---|\n| Name | production-health-check |\n| Schedule | `*/30 * * * *` |\n| Agent | default |\n| Message | Check production health via AWS DevOps Agent. Scan ECS, Lambda, CodeBuild, CodePipeline, and CloudWatch. Flag any issues found with severity and recommended fixes. |\n\nTrigger the cron manually by clicking **Run** in the Schedule page. You should see the agent:\n\nIf it returns \"Overall: HEALTHY\" with no flags, your infrastructure is in good shape. If it finds issues, you'll get severity-prioritized recommendations.\n\nThis 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.\n\nArticles 1 to 5 built the foundation. This one connects Crew to the real world, where production issues don't wait for business hours.\n\n**The full Kiro Crew series:**\n\n**GitHub repo with all configs:** [SimplyNadaf/kiro-crew-devops-agent](https://github.com/SimplyNadaf/kiro-crew-devops-agent)\n\nWhat'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.\n\n*Follow me for more on AWS architecture, DevOps, and AI infrastructure:*\n\n[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)", "url": "https://wpnews.pro/news/i-built-an-aws-devops-ai-agent-using-kiro-crew-mcp", "canonical_source": "https://dev.to/aws-builders/i-built-an-aws-devops-ai-agent-using-kiro-crew-mcp-fk0", "published_at": "2026-08-24 11:30:54+00:00", "updated_at": "2026-08-24 11:43:03.515122+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-tools", "mlops"], "entities": ["AWS", "ECS", "Kiro Crew", "MCP", "DevOps Agent", "PagerDuty", "CloudWatch", "CodeBuild"], "alternates": {"html": "https://wpnews.pro/news/i-built-an-aws-devops-ai-agent-using-kiro-crew-mcp", "markdown": "https://wpnews.pro/news/i-built-an-aws-devops-ai-agent-using-kiro-crew-mcp.md", "text": "https://wpnews.pro/news/i-built-an-aws-devops-ai-agent-using-kiro-crew-mcp.txt", "jsonld": "https://wpnews.pro/news/i-built-an-aws-devops-ai-agent-using-kiro-crew-mcp.jsonld"}}