Managing AWS/Azure VM Instances and avoiding duplicate CI records and broken relationships

[Brigham]

How are folks managing their cloud estate so that CIs remain clean and accurate and relationships (like software allocations or business application mappings) remain intact?

Looking at our CMDB for Azure or AWS hosted servers. I see multiple records in ServiceNow CMDB with same Name but different serial# and Object IDs. It appears this is because the VM is spinning down and back up in the cloud host and ServiceNow Discovery is treating it as a newly discovered CI.

I recognize that technically this is true, but it wreaks havoc with CMDB health in regard to deduplication, ensuring the 'older' CIs are properly retired so we are not impacting our ServiceNow license costs with extraneous CIs that are not real. Not to mention things like software license allocation to these cloud hosted servers which will be constantly broken by this duplication behavior. As I think about it this also potentially makes a mess of reporting for Incident management and Change management reporting as well.

[AJ-TechTrek]

Hi Brigham,

You can configure the Identification and reconciliation rule which help-to avoid this situations.

Refer the below Docs.

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/co...

Apart from that use the De-duplication Task to activate and below docs will help for that.

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/co...

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

https://www.softwebsolutions.com/resources/servicenow-cmdb-duplicates.html

https://servicenowhelpdesk.com/cloud-discovery/

Please mark as helpful or accept solution if applicable.

Thanks

Ajay

[Brigham]

Hi Ajay,

Thanks for the response. I understand that IRE rules should help to avoid duplication. But I am asking for best practices specifically in the context of cloud servers like AWS where each time the server instance spins down and back up it appears to get a new unique object ID (Source Native Key) and new unique Serial#; which is going to cause SN to consider this a new CI.

From what I can see it appears that the only thing remaining consistent is the Name, which is arguably insufficient. So I am hoping someone could offer specific suggestions on best practice for IRE rules to avoid this, or perhaps even some config on AWS to keep Object ID and serial# when a server spins down and back up again.

[Meher Shanti]

Hi Brigham, Wondering if you ever found a solution to this issue? Could you please share, if yes? Thanks much!

Regards,

Meher.

[Brigham]

Hi Meher, alas I have not found a good solution to this yet.