SGC for Azure/AWS - How are organizations handling CI retirement when cloud resources are deleted?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
22m ago - last edited 21m ago
We are looking for feedback from customers who have implemented Service Graph Connector for Azure and/or AWS and have addressed the challenge of retiring CIs when the corresponding cloud resources are deleted from the cloud provider.
Our expectation was that when a cloud resource is removed from Azure or AWS and is no longer reported through the Service Graph Connector, the associated CI would eventually be transitioned out of an operational state through an out-of-the-box process.
After working with ServiceNow Support, we learned that resource deletion is not directly tracked by the connector and that CI retirement is generally handled through lifecycle/staleness processes. Following further investigation, ServiceNow recommended using CMDB Data Manager policies as the primary mechanism to govern retirement and deletion of cloud CIs, citing improved control over lifecycle management and CI relationships.
Before adopting this as our long-term strategy, we would like to understand how other customers have approached this requirement.
Specifically:
- How do you identify that a cloud resource has been deleted from Azure or AWS?
- Are you relying on CMDB Data Manager to retire cloud CIs, or are you using another approach?
- Have you successfully implemented retirement through Service Graph Connector lifecycle management alone?
- Do you use custom automation, integration logic, or governance policies to mark cloud CIs as retired?
- How do you handle dependent relationships and downstream CIs during the retirement process?
- Has anyone found a recommended alternative to CMDB Data Manager for this use case?
