I'm new to the ServiceNow Cloud Discovery module and I'm currently working on AWS Cloud Discovery.

[AvinashU]

I understand how to configure the cloud account and run a discovery schedule. My question is about what to do after the discovery completes.

Once the AWS resources are discovered:

1. How do I validate that the discovered data is correct?
2. Which CMDB tables should I verify first?
3. How can I confirm that all expected AWS resources (EC2, VPCs, Subnets, Security Groups, RDS, etc.) have been discovered?
4. How do I validate the relationships between the discovered CIs?
5. Which logs or reports should I review to identify missing or failed discoveries?
6. What are the recommended post-discovery validation steps before moving to production?
7. Are there any best practices or checklists that you follow after every AWS Cloud Discovery?

I'm looking for a step-by-step verification process that a beginner can follow after running an AWS Cloud Discovery.

[Vikram Reddy]

Hi @AvinashU,

Post-discovery validation for Cloud Discovery really comes down to three passes: check the run itself, spot-check the CMDB, then check the relationships. Do them in that order, a bad run makes everything downstream look wrong even when the platform behaved fine.

• Open Discovery > Status for the schedule, confirm it actually completed, and look at the CI created/updated counts against what you'd roughly expect for that account.
• Pull the Discovery Log for that run and scan for pattern errors or warnings. Logs don't sit around forever on most instances, so review them soon after the run instead of coming back weeks later.
• Spot-check the actual CMDB tables rather than trusting the summary counts: EC2 lands in cmdb_ci_ec2_instance (extends cmdb_ci_vm_instance), VPCs in cmdb_ci_network, subnets in cmdb_ci_cloud_subnet, security groups in cmdb_ci_compute_security_group, and RDS in cmdb_ci_cloud_database. Filter by discovery source and last discovered date, then compare row counts to what the AWS console shows for that account.
• If you're running the Service Graph Connector or event-based discovery, also check sys_object_source. It logs everything the connector actually pulled before Identification and Reconciliation processes it, which is the fastest way to tell "never fetched" apart from "fetched but dropped."
• Check CMDB Identification and Reconciliation > Identification Log for "No Matches Found" or "Multiple Matches Found" entries. Those flag CIs that failed to reconcile cleanly or got duplicated.
• For relationships, open a handful of EC2 CIs and check the Relationships related list or the dependency map. Each instance should show links back to its VPC, subnet, security group, and cloud account, that wiring is what makes Service Mapping and blast-radius views usable later.
• Before calling it production-ready, run the CMDB Health Dashboard against the AWS classes. The Completeness, Correctness, and Relationships KPIs surface missing attributes and orphaned CIs a lot faster than manual spot-checking does.

Worth knowing upfront: the table names above apply to pattern-based Discovery and the native Service Graph Connector. If you're still on the older AWS Service Management Connector app, several of these land in scoped app tables instead, so confirm which integration you're actually running before you go table-hunting.

Thank you,
Vikram Karety
Octigo Solutions INC

[Harish Bainsla · Accepted solution]

Hi  

1. How do I validate that the discovered data is correct?

For this first thing you have to Verify Discovery Job is completed or not .

2. Table to check data 

AWS Account	cmdb_ci_cloud_service_account
EC2 Instance	cmdb_ci_vm_instance
VPC	cmdb_ci_network
Subnet	cmdb_ci_cloud_subnet
Security Group	cmdb_ci_compute_security_group
EBS Volume	cmdb_ci_storage_volume
RDS Instance	cmdb_ci_cloud_database
Load Balancer	cmdb_ci_cloud_load_balancer
Network Interface	cmdb_ci_nic
Availability Zone	cmdb_ci_availability_zone

FOR rest check this link cover all details 

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2184482

if my answer helps you mark helpful and accept solution

[AvinashU]

Hello Harish,

I have checked everything, and all the above conditions have been met.

Could you please let me know when the identification process will come into the picture and what the next steps are? Do we need to share any details with the AWS team?

Also, we have discovered one AWS account (a non-production account). In this case, how should we configure it? At what stage do we need to set up the CMDB Health Dashboard?

I just wanted to understand what the next step is.