Wiring AWS DevOps Agent into ServiceNow: The Observability-to-ITSM Loop

In my build vs buy post on AWS DevOps Agent, I argued that the managed agent handles investigation and your custom agents handle remediation. That post was about the agent in isolation.

This one is about where it actually lives: wedged between your observability stack and your ticketing system, displacing a piece of infrastructure most enterprises don’t think about until it breaks.

The alert correlation layer.

The Layer Nobody Talks About

Walk into any large enterprise operations team and you will find three tiers, whether they’ve named them or not.

At the bottom: monitoring tools. Infrastructure monitors, network monitors, APM, cloud security posture. Each one watches a slice of the estate and emits alarms.

At the top: the system of record. Usually ServiceNow. Incidents, tickets, CMDB, change records, SLAs. This is where humans coordinate and where the audit trail lives.

Between them sits a layer that gets almost no attention: alert correlation. Something has to take the flood of raw alarms from the monitoring tools, deduplicate them, map severity, identify which resource is actually affected, and decide whether to open a ticket. For a lot of enterprises that job is done by a dedicated AIOps product like MoogSoft.

Here is the thing people misunderstand about a tool like MoogSoft. It is not a monitoring tool. It does not watch CPU or disk or network. It sits on top of the tools that do, ingests their alarms, cross-references the CMDB to figure out what a given alert maps to, deduplicates, and maps severity tiers to incident priorities. Platinum and Gold map to P1 and P2, Silver and Bronze map to P3 and P4. That’s the whole job.

It is glue. Important glue, but glue. And glue is exactly the kind of thing an autonomous agent is good at replacing.

The Current Flow

Let me sketch the pattern I keep seeing, generalized across a few large enterprises migrating to AWS. Picture a global manufacturer with a legacy agent-based infrastructure monitor covering thousands of devices, a separate network monitoring product, and partial CloudWatch coverage for the workloads already on AWS.

[Legacy infra monitor] + [Network monitor] + [CloudWatch alarms (partial)]
                     |
                     v
        [AIOps correlation engine: MoogSoft]
        (deduplication + severity mapping via CMDB)
                     |
                     v
        [ServiceNow: CMDB classification, ticket creation]

This works, in the narrow sense that tickets get created. But it has structural problems that no amount of tuning fixes.

Apps that aren’t wired into the correlation engine operate in complete silos. The legacy infra monitor tends to cover servers well and containers not at all, which becomes a real problem the moment workloads shift to EKS or ECS. Severity mapping is static. And critically, the correlation engine cannot investigate. It can tell you three alerts are probably the same incident. It cannot tell you why the incident is happening.

That last gap is the whole opportunity.

The Target Architecture

Here’s the layered architecture I’ve been proposing. Same three tiers, but the middle layer is now an agent.

+----------------------------------------------------+
|          ServiceNow (System of Record)             |
|   Incidents, tickets, CMDB, change records, SLAs   |
+-------------------+----------------+---------------+
                    | triggers       ^ write-back RCA
                    v                |
+-------------------+----------------+---------------+
|          AWS DevOps Agent (Intelligence)           |
|  Correlates, deduplicates, investigates            |
|  autonomously, produces RCA, recommends            |
|  + proactive prevention + on-demand SRE            |
|  Connects via: native ServiceNow + MCP + webhooks  |
+---------------------------+------------------------+
                            ^ reads telemetry from
                            |
+---------------------------+------------------------+
|      AWS CloudWatch (Observability)                |
|  Metrics, Logs, Traces, Alarms, Synthetics, APM    |
|  + OpenTelemetry (ADOT) framework                  |
+------------------+----------------+----------------+
                   |                |
      +------------v----+   +-------v----------+
      | AWS Workloads   |   | On-Prem / Hybrid |
      | (ECS, Lambda,   |   | (via OTel +      |
      |  EC2, EKS)      |   |  existing tools) |
      +-----------------+   +------------------+

The bottom layer is CloudWatch plus OpenTelemetry. The migration story here is its own project: replacing a legacy agent-based monitor with the CloudWatch Agent, the AWS Distro for OpenTelemetry (ADOT), and Container Insights. OTel matters because it’s the vendor-neutral way to instrument both AWS-native workloads and the on-prem estate that hasn’t moved yet. You get metrics, logs, and traces in one framework, and you stop being locked to an agent that can’t see containers.

The middle layer is DevOps Agent, and it does what the correlation engine did plus everything the correlation engine couldn’t. It correlates and deduplicates, yes. But it also investigates autonomously, produces root cause analysis, recommends mitigations, and runs proactive pattern analysis across historical incidents.

The top layer stays ServiceNow. That’s deliberate. You do not rip out the system of record. Humans still coordinate there, the audit trail still lives there, and the CCMDB still classifies resources there. What changes is that the agent reads incidents from ServiceNow to trigger investigations, and writes RCA findings back into the ticket.

That bidirectional link is the payoff. The ticket stops being a manually-updated record of what a human eventually figured out. It becomes a live document that the agent populates with root cause, timeline, and mitigation plan.

How the Layers Actually Connect

The interesting engineering is in the wiring between CloudWatch and ServiceNow. There are four mechanisms, and you’ll likely use more than one.

The AWS Service Management Connector for ServiceNow. This is GA and it’s the simplest path. It auto-creates ServiceNow incidents from CloudWatch alarms. If all you want is “alarm fires, ticket appears,” this is the out-of-the-box answer and you should start here. It is not intelligent, but it’s reliable plumbing.

CloudWatch to EventBridge to a ServiceNow webhook. When you need more flexible routing than the connector gives you, a CloudWatch alarm triggers an EventBridge rule, which invokes an API Destination pointed at the ServiceNow REST API. This is the path for conditional logic: route P1s differently from P3s, enrich the payload before it hits ServiceNow, fan out to multiple targets.

Managed Grafana as a bridge. If the enterprise already standardized on Grafana for dashboards, there’s a documented path to push CloudWatch metrics into ServiceNow through Grafana. Worth knowing about, mostly relevant when Grafana is already entrenched and you don’t want to introduce another integration surface.

The DevOps Agent native ServiceNow integration. This is the one that changes the model. It’s bidirectional. The agent reads incidents from ServiceNow to trigger investigations, and writes back RCA findings, mitigation plans, resolution notes, and status updates. The first three mechanisms are about getting an alarm into a ticket. This one is about getting intelligence out of the agent and back into the record.

The reason this matters: the first three mechanisms replace the correlation engine’s plumbing. The fourth replaces its brain, and adds a brain it never had.

Then there’s MCP. DevOps Agent supports custom Model Context Protocol servers, which is how you reach the tools that aren’t on the native integration list. Your CMDB has custom fields for change control? MCP server. Your security posture tool is Wiz? MCP server. Your internal runbooks live in a wiki? MCP server. The native integrations cover the common stack. MCP covers everything else.

The Displacement Argument

The clean way to frame this to an operations team: the agent replaces the correlation engine’s function, not the correlation engine’s box.

A legacy AIOps correlation product does deduplication, severity mapping, and CMDB-based resource identification. DevOps Agent does all of that, and then keeps going: autonomous investigation, multi-tool topology, proactive prevention, and ServiceNow write-back that the legacy product structurally cannot do.

You are not adding a tool. You are removing one and getting more capability in the process. That’s a rare architecture conversation where the simpler end state is also the more capable one.

The migration is phased, and it should be. The pattern I’d recommend:

Phase one, get basic CloudWatch monitoring in place and let alarms create ServiceNow incidents through the Service Management Connector. No agent yet. Just prove the telemetry pipeline.

Phase two, turn on centralized cross-account logging and let the agent start correlating log patterns for RCA. Still in shadow mode, still humans acting.

Phase three, add synthetic monitoring and let the agent feed proactive prevention, displacing the manual weekly and monthly service reports that somebody currently assembles by hand.

Phase four, full autonomous investigation. CloudWatch signals flow to the agent, the agent produces RCA, and it writes back to ServiceNow. This is the point where the legacy correlation engine comes out of the flow.

Phase four is the convergence point. Everything before it is prerequisite.

CloudWatch Investigations Is Not the Same Thing

One point of confusion worth clearing up, because I’ve watched teams conflate these two.

CloudWatch Investigations is a feature inside CloudWatch. It’s AI-assisted correlation of CloudWatch signals, it’s included in CloudWatch pricing, and its scope is AWS data only. It assists an operator who kicks it off from the console or an API.

AWS DevOps Agent is a standalone service. It’s autonomous rather than assistive, its scope is multi-tool rather than AWS-only, and it triggers automatically from webhooks. It maintains a live topology across AWS, multi-cloud, and on-prem, and it has the native bidirectional ServiceNow integration that CloudWatch Investigations lacks entirely.

The mental model I use: CloudWatch Investigations is the eyes. It correlates AWS-native signals well. DevOps Agent is the brain and hands. It takes those signals as one input among many, investigates across every tool, delivers RCA, and writes back to the system of record.

CloudWatch Investigations = the "eyes" (correlates AWS-only signals)
         |
         | feeds into (as one data source among many)
         v
AWS DevOps Agent = the "brain + hands" (investigates across all tools,
                   delivers RCA, writes to ServiceNow, acts via MCP)

For a lot of enterprises the right call is to use CloudWatch Investigations as the free baseline and bring in DevOps Agent when you need multi-tool correlation, ServiceNow write-back, and proactive prevention. They are complementary, not competing. The mistake is scoping a phase-four “AI-powered RCA” workstream around CloudWatch Investigations alone and only later discovering that the write-back and multi-tool correlation you actually wanted lives in the other product.

Where the Real Difficulty Is

The architecture diagram is clean. The reality has friction, and it’s worth naming.

The observability foundation has to exist first. If distributed tracing is at zero, if there are no service-level objectives, if the lift-and-shift into AWS came with no instrumentation, then the agent has thin telemetry to reason over. An agent investigating a poorly-instrumented estate produces poorly-grounded RCA. Fix the golden signals before you expect the brain to be smart.

Tool access is a plumbing problem that eats more time than people budget. The agent needs credentials to the observability tools it reads. If observability lives in a segmented VPC with no egress, granting that access is non-trivial and belongs in the PoC plan, not the rollout.

Multi-region and multi-account fragmentation is real. When each region runs its operations independently with its own tooling choices, there is no single topology to hand the agent. You either standardize first or you accept that the agent’s view is regional.

And alert hygiene sets the ceiling. If the monitoring stack already emits hundreds of noisy alarms a day with a high false-positive rate, the agent inherits that noise. It amplifies signal, it does not manufacture it. Clean the alerting before you wire in the intelligence, or you’ll conclude the agent is noisy when the input was.

Honest Recommendation

If you’re running a legacy AIOps correlation engine feeding ServiceNow, DevOps Agent is a genuine displacement opportunity, not just another tool to bolt on. It does the correlation engine’s job and adds investigation, topology, prevention, and write-back that the correlation engine never could. The end state is simpler and more capable at the same time, which almost never happens in enterprise architecture.

But sequence it honestly. The observability layer is the prerequisite, and it tends to be the harder, less glamorous half of the project. CloudWatch plus OpenTelemetry has to be solid before the agent layer earns its keep. Start with the Service Management Connector for basic alarm-to-ticket flow, run the agent in shadow mode against real incidents, and only pull the correlation engine out of the flow once the agent’s RCA accuracy is proven on your estate.

The convergence point, where telemetry, agent, and system of record become one coherent loop, is worth reaching. Just don’t skip the plumbing to get there.