OpsCenter and Incident Tracking

Welcome back, students. This lesson explains AWS Systems Manager OpsCenter and how it supports incident aggregation, structured incident records, automated remediation with runbooks, and lifecycle tracking. OpsCenter is designed to reduce mean time to detection and resolution by centralizing operational data and linking remediation actions to incidents. Key OpsCenter capabilities:

Aggregate incidents from multiple AWS services
Structure incident data into OpsItems with contextual metadata
Automate remediation using runbooks (SSM Automation documents)
Track resolution and the OpsItem lifecycle

A slide titled "OpsCenter and Incident Tracking" showing four colored boxes: Aggregate Incidents (collect from multiple AWS services), Structure Data (create OpsItems with context), Automate Response (execute runbooks for remediation), and Track Resolution (manage incident lifecycle).

OpsCenter centralizes incidents by creating OpsItems—structured records that capture the details needed to investigate, remediate, and audit operational events. OpsItems can be created automatically by integrated AWS services or manually via the console/API.

OpsItems: structured incident records

An OpsItem typically includes:

Core metadata: Title, Source, Severity, Status, Category, Priority — answers the “where” and “how severe”.
Operational data: links to Automation documents, affected resource identifiers, deduplication string, and custom keys (e.g., cost center, owner).
Related resources: up to 100 AWS resources associated with the OpsItem (EC2, RDS, S3, Lambda, CloudFormation stacks, EventBridge rules, etc.).

A presentation slide titled "OpsItems – Structured Incident Records" showing three categories (Core Metadata, Operational Data, Related Resources) and a list describing related resources like EC2, RDS, S3, Lambda, CloudFormation, EventBridge linking, manual addition via console/API, and a 100-resource limit per OpsItem. The slide is copyrighted by KodeKloud.

Event sources and automated OpsItem creation

OpsItems can be created from multiple sources. Common built-in event sources include:

Amazon CloudWatch Alarms
AWS Config
AWS Security Hub
Amazon EventBridge
Manual creation (console or API)

Using EventBridge or integrated services to auto-create OpsItems delivers consistent metadata, reduces manual steps, and shortens the time from detection to remediation.

A slide titled "Event Sources Creating OpsItems" displaying icons and labels for CloudWatch Alarms, AWS Config, AWS Security Hub, AWS EventBridge, and Manual Creation. It lists AWS event sources that can generate OpsItems.

Automatic creation benefits:

Immediate, consistent incident records
Eliminates manual ticket creation
Standardized data for automation and analytics

A presentation slide titled "Automatic vs Manual OpsItem Creation" showing a card for "Automatic Creation via EventBridge" with bullets explaining EventBridge auto-creates OpsItems (with consistent metadata and AWS Config-triggered items) and a list of advantages like immediate incident creation, no manual intervention, and reduced MTTD.

Manual OpsItem creation is useful for one-off or external incidents that cannot be captured by existing event sources. For frequent or high-volume incidents, prefer automating ingestion so your OpsItems retain consistent structure and avoid operational overhead. Below is an example EventBridge target configuration that submits an OpsItem. This representative JSON shows the RoleArn EventBridge uses and example OpsItem fields (Title, Source, Severity, Category, and OperationalData). Adapt field names and JSON path references to match your EventBridge rule’s input transformer or target settings.

{
  "RoleArn": "arn:aws:iam::123456789012:role/OpsCenter-EventBridge-Role",
  "OpsItemTargetParameters": {
    "Title": "Config Compliance Violation: $.detail.configRuleName",
    "Source": "aws.config",
    "Severity": "2",
    "Category": "Security",
    "OperationalData": {
      "/aws/resources": {
        "Value": "[\"$.detail.resourceId\"]",
        "Type": "SearchableString"
      }
    }
  }
}

Runbooks and automated remediation

Runbooks (SSM Automation documents) can be associated with OpsItems to automate remediation workflows. You can:

Associate runbooks with OpsItems so responders can execute them from the OpsCenter console.
Start runbooks programmatically using the StartAutomationExecution API.
Link execution records and outputs back to the OpsItem to track remediation steps and outcomes.

A slide titled "Runbooks and Automated Remediation" that lists three steps—01 Associate Runbooks, 02 Execute Remediation, and 03 Track Resolution—each with short descriptions and colorful icons. The second step notes one-click runbook execution from the OpsCenter console or via StartAutomationExecution API.

Common runbook mappings include:

High CPU utilization → restart instance or scale out (e.g., AWS-RestartEC2Instance or an auto-scaling runbook)
Low disk space → expand or attach volumes (custom runbook)
Security group violation → apply remediation policy (custom automation)
Patch non-compliance → AWS-RunPatchBaseline or patch orchestration runbooks

A presentation slide titled "Runbooks and Automated Remediation" showing a boxed list of common runbook associations. It lists examples like High CPU utilization → AWS-RestartEC2Instance, Disk space low → custom disk expansion, Security group violation → custom security remediation, and Patch non-compliance → AWS-RunPatchBaseline.

Integration with ITSM and cross-account aggregation

OpsCenter can integrate with IT Service Management (ITSM) platforms such as ServiceNow or Jira using EventBridge, Lambda, and the external system’s REST API. You must map OpsItem fields to the third-party incident fields to ensure consistent data flow. When centralizing OpsItems across multiple AWS accounts, configure cross-account EventBridge delivery and grant suitable IAM permissions so source accounts can send events to the central account.

A presentation slide titled "Cross-Account Incident Aggregation" showing a three-step flow (Source Accounts → Cross-Account Delivery → Central OpsCenter) and a highlighted "Service Limit" note. The note states "300 rules per event bus (soft limit)" and advises planning architecture carefully when aggregating from many source accounts.

Be aware of service limits when aggregating events. For example, EventBridge has a soft limit of 300 rules per event bus—plan your architecture (partitioning, multiple event buses, or pre-filtering) to avoid throttling and ensure timely delivery.

OpsCenter vs CloudWatch vs X‑Ray

These AWS services complement one another for robust observability:

Service	Primary role	Example use case
OpsCenter	Centralized incident management and lifecycle tracking	Correlate alarms, traces, and config events into OpsItems and attach runbooks
CloudWatch	Metrics, logs, dashboards, alarms	Trigger alarms for CPU, memory, or custom metrics; create OpsItems via EventBridge
X‑Ray	Distributed tracing and request-level diagnostics	Diagnose application latency and errors at the request level, link traces to OpsItems

A presentation slide titled "OpsCenter vs CloudWatch vs X‑Ray" showing three colorful cards. Each card has an icon and a short description of the corresponding AWS monitoring/tracing service.

CloudWatch alarms can create OpsItems that link back to dashboards for metric context. X‑Ray traces can be referenced by an OpsItem to provide request-level diagnostic detail. Combining these services yields comprehensive observability across metrics, logs, traces, and incidents.

A flowchart titled "Integration Pattern for Comprehensive Observability" showing two parallel paths from CloudWatch Alarm and X‑Ray. Each path leads to creating an OpsCenter OpsItem and linking to metrics or traces, converging on "Complete Observability."

Enable AWS CloudTrail for all API activity (not only OpsCenter) to maintain a complete audit trail of changes and automation executions. CloudTrail logs are essential for post-incident forensics and compliance.

Best practices

Incident classification — define clear severity levels and mappings (critical, high, medium, low, informational).
Automate repeatable incidents — use EventBridge, CloudWatch, AWS Config, and Security Hub integrations to auto-create OpsItems and trigger runbooks for high-frequency issues.
Measure operational excellence — track mean time to detection (MTTD) and mean time to resolution (MTTR) by category and severity; iterate on runbooks and playbooks.
Data hygiene and retention — archive or export older OpsItems (for example, older than 90 days) to Amazon S3 for long-term retention and auditing.
Cross-account design — if aggregating from many accounts, design EventBridge/event bus strategy and IAM roles to avoid hitting service limits.

Key takeaways

OpsCenter (AWS Systems Manager) centralizes incident records (OpsItems) and supports automation with SSM runbooks.
EventBridge is commonly used to create OpsItems automatically from CloudWatch, AWS Config, and Security Hub events.
OpsItems include structured metadata, operational data, related resources, and links to remediation runbooks.
Combine OpsCenter with CloudWatch (metrics/logs/alarms) and X‑Ray (tracing) for end-to-end observability across infrastructure and application layers.
Storage for OpsItems is free, but API calls and automation executions may incur minor charges—monitor usage and design for service limits.

References

AWS Systems Manager OpsCenter: https://docs.aws.amazon.com/systems-manager/latest/userguide/opscenter.html
Amazon EventBridge: https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html
Amazon CloudWatch: https://docs.aws.amazon.com/cloudwatch/index.html
AWS Config: https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html
AWS Security Hub: https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html
AWS X‑Ray: https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html
AWS CloudTrail: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html

That’s it for OpsCenter.

Introduction

Domain 1 - SDLC Automation

Domain 2 - Configuration Management and IaC

Domain 3 - Resilient Cloud Solutions

Domain 4 - Monitoring and Logging

Domain 5 - Incident and Event Response

Domain 6 - Security and Compliance

OpsCenter and Incident Tracking

OpsItems: structured incident records

Event sources and automated OpsItem creation

Runbooks and automated remediation

Integration with ITSM and cross-account aggregation

OpsCenter vs CloudWatch vs X‑Ray

Best practices

Key takeaways

References

Watch Video

​OpsItems: structured incident records

​Event sources and automated OpsItem creation

​Runbooks and automated remediation

​Integration with ITSM and cross-account aggregation

​OpsCenter vs CloudWatch vs X‑Ray

​Best practices

​Key takeaways

​References

Watch Video

OpsItems: structured incident records

Event sources and automated OpsItem creation

Runbooks and automated remediation

Integration with ITSM and cross-account aggregation

OpsCenter vs CloudWatch vs X‑Ray

Best practices

Key takeaways

References