Cloud Resource tagging for VMs (POC, Experimentation, etc.)

[varunkumar11863]

Hi All,

Looking for suggestion the best way to handle cloud resources where we cannot map APM tags.

While it makes sense to create an Application (APM) and tag it in the Cloud Resources, how do we handle tagging for scenarios where subscriptions (and resources) are created for POCs, experimentations, etc.? E.g. I want to test xyz thing on the VM, hence raised the request and worked on it for 1 week. This needs to be reported as well because we are looking out for the IAAS VMs where vulnerability can occur. If we put this POC as an APM record, it will flood the table. What is the best way to report them as well as not save them in APM record? Shall we keep them Orphan CIs (from APM pov)?

Thanks

[AJ-TechTrek · Accepted solution]

Hi @varunkumar11863 ,

This is a great question — this is a very common challenge in real-world ServiceNow Cloud CMDB and APM integrations.


As per my Understanding , Here’s how you can approach it, including best practices:

Solution & Best Practice:
1. Do not create separate APM records for POCs / experimental resources.
* This will clutter your APM tables and distort your application portfolio by mixing short-lived or non-production items with managed apps.

2. Use a dedicated “POC / Experimental” Business Application or Service Offering:
* Create a single “POC / Experimental Resources” application in APM (or a similar placeholder).
* Tag all these ephemeral resources to this application so you can report and track them without flooding your production application list.

3. Tag in Cloud Resources / CMDB:
* Apply a custom tag, e.g., Purpose=POC or Environment=POC, to identify and group these resources.
* Many organizations also add metadata like Owner, Expiry Date, and Justification to keep visibility and manage lifecycle.

4. Mark them as “Orphan” or “Non-business-critical” in CMDB:
* If you don’t want to map them to an application at all, you can flag them as Orphan CI or set a CI attribute (cmdb_ci field like u_apm_mapped = false).
* You can use these flags in dashboards/reports to exclude them from core production app reports but still report them in compliance/security views.

5. Automate cleanup:
* Configure automated jobs to:
* Decommission CIs older than X days marked as POC.
* Notify owners before deletion.

6. Reporting:
* Build dedicated dashboards or reports in Performance Analytics / CMDB Workspace to track all POC tagged resources, so you maintain visibility for security and cost.

Summary As per my Understanding :-


1. Tag short-lived cloud resources as POC or Experimental.


2. Use a single “POC” APM placeholder application (if you want them to show in APM).


3. Keep them flagged as “Orphan” / non-critical in CMDB to separate from production apps.


4. Automate cleanup and reporting.

This approach keeps your APM clean, CMDB organized, and still provides traceability for compliance & vulnerability scanning.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[varunkumar11863]

Hi @AJ-TechTrek Thanks. I am also in-line with the placeholder approach.