Skip to content
NexusBook a demo

Cloud & IT Operations integration

Turn AWS events into governed ServiceNow incidents and changes.

CloudWatch, SNS, SQS and S3 events are enriched and opened as ServiceNow incidents or change requests. Infrastructure actions run only when policy and approval allow.

Discuss this integration All integration patterns

The problem

Why AWS + ServiceNow needs a governed process

Cloud alerts land in chat or email, tickets are opened by hand, and remediation happens without a change record. Audit and post-incident review struggle to reconstruct what happened.

Responsibility

How the systems divide responsibility

Infrastructure and signal source

Amazon Web Services

EC2, S3, IAM, Lambda and cloud telemetry.

Operational record

ServiceNow

Incidents, change requests, tickets and CMDB items.

Capabilities

What Nexus orchestrates

Pre-built action groups used in this pattern. Anything else runs through an API, protocol or database step, or Rules + Code, in the same workflow.

Amazon Web Services

61 ACTIONS

  • EC215
  • S315
  • IAM21
  • Lambda10

ServiceNow

55 ACTIONS

  • Incidents12
  • Change Management10
  • CMDB12
  • Tickets10

Architecture

One governed run across both systems

Trigger: AWS CloudWatchIntegration: AWS + ServiceNowRules + CodeHuman ApprovalSystem Action: AWSAudit

How work starts

AWS CloudWatch, CloudWatch Events, SNS, SQS, S3 and ServiceNow

AWS CloudWatch, CloudWatch Events, SNS, SQS and S3 are trigger sources. ServiceNow can also start the run when a change is approved.

When a pre-built action does not cover it

Pre-built ActionAPI / Protocol / DBRules + Code

Workflow patterns

What teams run across AWS + ServiceNow

01

Alarm to enriched incident

A CloudWatch alarm is enriched with resource and CMDB data and opened as a ServiceNow incident with the evidence attached.

02

Approved remediation

An approved ServiceNow change triggers the EC2 or Lambda action it authorises, and the result is written back.

03

S3 and IAM exposure review

An S3 or IAM finding opens a ticket. Access changes only run after the security owner approves.

04

Queue-driven runbooks

SNS or SQS messages start runbooks that open, update or close ServiceNow records.

Direction and ownership

Which way each change moves

Signals flow from AWS to ServiceNow. Approved changes flow from ServiceNow back to AWS actions. ServiceNow stays the record of what was decided.

  • Amazon Web Services ServiceNow

    Enriched event context, affected resources and CMDB matches.

  • ServiceNow Amazon Web Services

    Approved change that authorises an EC2, S3, IAM or Lambda action.

Control

Approvals and exception handling

Human approval

Operators approve production-affecting remediation through the ServiceNow change. Read-only enrichment and ticketing run by policy.

Exceptions

  • Unmatched resources route to a triage group with the raw event.
  • Failed AWS actions keep the change open and record the error.
  • Duplicate alerts update the existing incident instead of opening new ones.

Security, audit and deployment

Every run leaves a reviewable record

  • The source event and enrichment results.
  • The incident or change created.
  • Approval of any infrastructure action.
  • Each AWS request and response.

Credentials for Amazon Web Services and ServiceNow are held in the vault and used only by the steps that need them. Role-based permissions decide who can edit, approve and run the workflow. Nexus runs on premises, in private cloud or air-gapped, so the execution record stays inside your deployment boundary. Governance and audit

Participating connectors

The connectors behind this pattern

Cloud / Infrastructure

Amazon Web Services connector

61 pre-built actions · Trigger source: AWS S3, AWS SNS, AWS SQS, AWS CloudWatch, AWS CloudWatch Events

View connector

ITSM / Support

ServiceNow connector

55 pre-built actions · Trigger source: ServiceNow

View connector

Related

Continue from here

FAQ

AWS + ServiceNow questions

Which AWS events can start a run?
AWS CloudWatch, CloudWatch Events, SNS, SQS and S3 are trigger sources.
Will Nexus change infrastructure on its own?
Only within policy. Production-affecting actions wait for an approved change.
Does this work in Azure too?
Azure has its own pre-built actions and trigger sources and can follow the same pattern.

Integration review

Discuss this integration

Bring your Amazon Web Services and ServiceNow process. We will map ownership, approval and the steps each system needs.

Discuss this integration Book a demo