---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# AWS events-driven discovery

# AWS events-driven discovery {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of AWS events-driven discovery

AWS events-driven discovery in ServiceNow leverages Amazon Web Services (AWS) Config service event notifications to automatically update Configuration Management Database (CMDB) records.
When AWS Config detects changes in cloud resources, it sends event notifications via Simple Notification Service (SNS) to ServiceNow's Cloud Events REST API, enabling near real-time CMDB updates.
Show full answer Show less  

## Key Features

* **Integration with AWS Config and SNS:** Configure AWS Config to send SNS notifications to ServiceNow, allowing event-driven updates.
* **Event Handling and Storage:** Events such as SubscriptionConfirmation, ConfigurationItemChangeNotification, and tag changes are stored in the Cloud Events \[sncmpcloudevent\] table for processing.
* **Cloud Event Scheduler:** Processes events in batches from the Ready state, updating CMDB records based on event details.
* **Response Mapping and Discovery Patterns:** The `sncmp.cloudevent.useresponsemappingaws` property controls whether response mappings or discovery patterns are used to update or create Configuration Items (CIs) in the CMDB. This property defaults to True from the Yokohama release onward.
* **Scalability:** The `sncmp.cloudevent.parallelschedulercount` property allows running multiple Cloud Event Schedulers in parallel to handle higher event inflow rates efficiently.
* **Domain Assignment and Error Handling:** During processing, events are assigned to service account domains. To avoid failed events being visible across all domains, the `sncmp.errorevents.defaultdomain` property can be set to restrict visibility of such events to only the service-provider domain administrator.

## Key Outcomes

* Automated, timely updates to CMDB records reflecting the current state of AWS cloud resources.
* Improved accuracy and completeness of CMDB data due to real-time event-driven updates.
* Enhanced scalability and performance in event processing through parallel scheduler configuration.
* Controlled visibility of error events, improving domain security and administrative clarity.  
The Amazon Web Services (AWS) Config
service can raise events for any changes in the life-cycle state or the configuration of a cloud
resource. The ServiceNow® event-driven discovery uses the events to auto-update
the latest resource information in the Configuration Management Database (CMDB).  
Figure 1. Overview of the AWS events-driven discovery  
Configure the AWS Config service to send Simple Notification Service (SNS) notifications to the ServiceNow instance. For more information, see [Configure AWS Config event notifications](https://servicenow-prod.fluidtopics.net/VvALSUxnGShmIWNqsCcyOQ "Configure the Amazon Web Services (AWS) Config service to send event notifications to the ServiceNow instance for any changes in the lifecycle state of a resource."). After you configure the service, it starts sending event notifications to the ServiceNow Cloud Events REST API. When an event meets any one of the following criteria, the API writes it to the Cloud Events \[sn_cmp_cloud_event\] table:

* The Type of the event is SubscriptionConfirmation.
* The Type of the event is Notification and messageType is ConfigurationItemChangeNotification.
* Amazon CloudWatch has raised the event for a change in the tag associated with the Configuration Item (CI).
{#aws-events-driven-discovery__ul_pb3_rhz_vvb}

The Cloud Event Scheduler then picks the events in the Ready state for batch processing. During event processing, the event-driven discovery uses response mappings or patterns to update the details of the affected resource in the CMDB. The sn_cmp.cloud_event.use_response_mapping_aws property determines the CMDB update method. To understand the status of an event, review its state in the Cloud Events \[sn_cmp_cloud_event\] table.

Starting with the Yokohama release, the sn_cmp.cloud_event.use_response_mapping_aws property is set to True by default. When this property is set to True, and suitable response mappings are available,
the event-driven discovery uses the response mappings to create or update the CI in the CMDB. Otherwise, the event-driven discovery triggers the appropriate patterns to discover the affected resource and create or update the CI in the CMDB.

Starting with the Yokohama release, use the
sn_cmp.cloud_event.parallel_scheduler_count property to scale the Cloud
Event Scheduler per the event inflow rate. Running multiple cloud event schedulers in parallel
helps to improve the event processing rate of the instance. For more information on scaling the
Cloud Event Schedulers, see [Scale the AWS cloud event schedulers](https://servicenow-prod.fluidtopics.net/Ypw2G3XT~2KeSmTOD0TCrA "Scale the cloud event schedulers to improve the Amazon Web Services (AWS) event processing rate of the ServiceNow instance.").

During event processing, the Cloud Event Scheduler identifies the domain of the service account and assigns to the event. If an error occurs in identifying the domain before processing, the event can
sometimes stay unassigned and become visible to all domains. To prevent the failed events visibility to all domains, you can set the sn_cmp.error_events.default_domain property to sys_id of the
service-provider domain so that the failed events appears only to the service-provider domain administrator.

