AWS Builder Center
The AI NOC Engineer: Building an Autonomous DevOps Agent with Amazon Q and CloudWatch

The AI NOC Engineer: Building an Autonomous DevOps Agent with Amazon Q and CloudWatch

Building a Production-Ready, Autonomous AIOps Agent on AWS with Fargate, LangGraph, and AWS Q

A Step-by-Step Guide to Automating Incident Investigation, Analysis, and Remediation to Drastically Reduce MTTR
"If u think the price of winning is too high then , wait until u get a bill from regret."
In enterprise IT operations, that bill is downtime. For over 90% of large enterprises, one hour of downtime costs over $300,000, with 41% bleeding $1 million to over $5 million per hour. Globally, downtime burns $400 billion annually.
As a national-level martial artist, the mat drilled discipline and calm under fire into everything I do, a mindset I apply directly to debugging nasty architectural bugs and building reliable distributed systems. But human resilience isn't enough when engineering teams are drowning in alert fatigue, where up to 83% of alerts are false positives. The diagnosis phase alone consumes 40-60% of the Mean Time to Resolution (MTTR).
It is time to automate the work we are avoiding. Here is the blueprint for an autonomous "AI NOC Engineer" that investigates issues, reports findings, and performs safe remediation, leveraging a high-level architecture flow: CloudWatch -> SNS -> SQS -> Fargate Service (LangGraph Agent) -> Tool-Lambdas -> Amazon Q / Bedrock -> Step Functions (HITL) -> Slack.
 

Part 1: The Trigger - Building a Resilient Alert Ingestion Pipeline

To build a system that won't drop critical events under heavy load, we must decouple the alert source from the processing agent. We start by creating an Amazon SQS Queue. Next, we configure a CloudWatch Alarm (e.g., for Lambda execution errors) to publish notifications to an SNS topic, which then forwards the full JSON event structure directly to our SQS queue. The agent will specifically target the nested Message field containing the raw alarm data for its investigation.
 

Part 2: The Agent - Deploying a Persistent Investigator on AWS Fargate

AWS Lambda's 15-minute timeout is a bottleneck for long-running AI investigations. Instead, we deploy a persistent, scalable service on AWS Fargate.
  • Containerization: Using an official AWS base image, we write a complete Dockerfile for our application.
  • The Polling Service: We build a Python script (agent_service.py) that runs in a continuous loop, performing long-polling on the SQS queue.
  • Infrastructure & Cost Optimization: We push the image to an ECR repository, create an ECS Cluster, and define a Task Definition. To prevent unnecessary compute spend, we configure an auto-scaling ECS Service tied to the ApproximateNumberOfMessagesVisible SQS metric, allowing the cluster to scale down to zero when alerts stop.
 

Part 3: The Brain - Orchestrating the Investigation with LangGraph

We utilize a hybrid orchestration model. While AWS Step Functions excels at deterministic orchestration, LangGraph's code-centric architecture is built specifically for the cyclical, agentic reasoning loops an LLM requires. Relying on solid fundamentals in Python, we define the graph's state (AIOpsGraphState) using Python's TypedDict. We write modular "tool" functions embedded with specific IAM permissions to fetch data from CloudWatch Logs Insights and AWS X-Ray. We then map the LangGraph workflow, utilizing a conditional edge (should_analyze) to route the agent's logic dynamically based on the telemetry it uncovers.
 

Part 4: The Analyst - Advanced Root Cause Analysis with LLMs

Once the data is aggregated, we deploy advanced prompt engineering for a "Five Whys" root cause analysis. We instruct Amazon Q to act as an expert SRE, providing it with rich context (alarm data, logs, traces) and a strict JSON output contract. Because LLMs can occasionally return malformed JSON, we implement LLM Chaining. We execute a secondary call to an Anthropic Claude model on Amazon Bedrock. Using Boto3 and Anthropic's "tool use" feature, this secondary model's sole job is to act as a parser (parse_llm_output_with_claude) to guarantee the output is a perfectly valid JSON object before it touches our downstream infrastructure.
 

Part 5: The Reporter - Delivering Actionable Insights to Slack

Actionable insights are useless if they aren't delivered securely. We store our Slack Webhook URL in AWS Secrets Manager. Using the slack_sdk in Python, the agent retrieves the secret and utilizes Slack's Block Kit to transform the heavily structured "Five Whys" JSON report into a richly formatted, highly readable message for the engineering team.
 

Part 6: Human-in-the-Loop - A Secure Approval Gate with Step Functions

AI should recommend; humans must authorize. For high-risk remediation, we implement a ChatOps approval gate using AWS Step Functions. When the LangGraph Agent hits a remediation step, it triggers a Step Function configured with the .waitForTaskToken integration pattern, pausing the workflow. A Lambda function instantly fires an interactive Slack message featuring "Approve" and "Reject" buttons embedded with the task token. Once an engineer clicks a button, an API Gateway-triggered Lambda executes send_task_success or send_task_failure to safely resume or terminate the state machine.
 

Part 7: The Remediator - Executing Safe, Autonomous Actions

Safety first: all AI actions are restricted by strict idempotency, least privilege, and deterministic IAM controls. Upon human approval, the agent executes autonomous remediation:
  1. Ticket Creation: Using the jira library and Secrets Manager, it autonomously generates a detailed bug ticket with the AI-generated analysis attached.
  2. Deployment Rollback: For critical production failures, the agent executes the Boto3 call codedeploy_client.stop_deployment(autoRollbackEnabled=True) to instantly halt the bleeding and restore the last stable state.
 

Reclaiming the MTTR

By fusing Fargate's persistent compute, LangGraph's cyclical reasoning, and Amazon Bedrock's analytical horsepower, we effectively automate the diagnosis phase that historically consumed 60% of our MTTR. This isn't just about building cool tech; it is about eliminating the multi-million dollar burn rate of manual alert triage and giving engineers their time back.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article