PaaS Resources
Series Recap
This is Part 2 of a six-part series on how ITOM architecture decisions become licensing costs. Part 1 covered Servers and VMs – the largest SU driver in most enterprise environments and the category where Discovery scope and ITOM scope are most often mistakenly treated as the same thing.
Part 2 covers PaaS Resources. The mechanics are similar: CI type mappings and ITOM application scope determine what counts. The risk profile is different. Cloud environments provision resources faster than governance cycles catch up, and the 1:3 ratio creates a perception of low exposure that frequently does not reflect actual consumption at enterprise scale.
One framework note that applies across all six parts: a resource can exist in the CMDB without consuming a Subscription Unit. Three conditions must all be true before a CI counts – it is in a table mapped to a licensable category, it is in scope for an ITOM product, and any category-specific requirements are satisfied. Unresolved Monitored Objects are the exception: a UMO is counted when ITOM Health receives an event or metric that cannot be resolved to any CI in CMDB, independent of CMDB table mappings or scope configuration.
Note that certain connector types – specifically endpoint-oriented Service Graph Connectors – may affect SU consumption even for resources not yet in full ITOM management scope. Confirm connector-specific behavior with your ServiceNow account team before relying on scope exclusions as a licensing control.
How PaaS SUs Are Triggered
Cloud platform services – including cloud app servers, cloud databases, DynamoDB tables, cloud directories, cloud gateways, cloud messaging services, and cloud webservers from major cloud providers – are ingested via certified Service Graph Connectors or Cloud Discovery and Service Mapping patterns, and counted when their CI types are mapped to the PaaS licensable category for the relevant ITOM product.
The standard PaaS ratio is 1:3, meaning three PaaS resources consume one SU. That ratio is more favorable than the 1:1 server rate on a per-unit basis. It is also the number most often cited to justify enabling cloud connectors broadly without a prior classification review.
Important: Cloud functions may be counted under a separate FaaS licensable category depending on your release and contract terms. Do not assume PaaS classification applies to serverless functions without confirming with your ServiceNow account team. Miscategorization in either direction produces inaccurate exposure estimates and will be covered in depth in Part 5.
The only lever for controlling PaaS SU exposure is deciding which resources should be managed by ITOM at all – and that decision must be made before the Service Graph Connector is enabled broadly. Resources that land in CMDB without that filter in place will affect the next daily CI count and begin contributing to the rolling 90-day average.
The Scale Problem
The 1:3 ratio can create a false sense of security. Cloud environments provision resources at a velocity that no ratio advantage can offset at scale, and unlike servers there is no architectural workaround that reduces exposure without reducing what you manage.
The comparison below illustrates how a mid-size enterprise with 500 servers and a reasonably active cloud footprint carries more PaaS SU exposure than Server SU exposure – despite the more favorable ratio.
|
Resource Type
|
Count
|
SU Ratio
|
Total SUs
|
|---|---|---|---|
|
Servers
|
500
|
1:1
|
500 Server SUs
|
|
PaaS Resources
|
4,500
|
1:3
|
1,500 PaaS SUs
|
|
Per-unit ratio and total exposure are different numbers. In cloud environments, total exposure is the one that matters. The primary cost lever is classification policy: which CMDB classes are mapped to the PaaS licensable category. That policy must be established and validated before the cloud connector is enabled broadly - not after cloud resources are already landing in CMDB.
|
|||
Ingestion Paths
PaaS resources follow a simpler ingestion picture than servers. Service Graph Connectors are the standard mechanism. Cloud Discovery patterns exist for some resource types but are not the primary path for broad cloud inventory.
Ratios in this series reflect the ServiceNow ITOM Subscription Unit Overview effective February 1, 2024. Customers contracted prior to that date may be subject to different ratios. Confirm which version governs your executed agreement before using these figures for planning or renewal modeling.
|
Ingestion Path
|
How It Works
|
Example Tools
|
SU Ratio
|
Counts?
|
|---|---|---|---|---|
|
Service Graph Connectors / Cloud provider integrations
|
Certified SGC pulls PaaS resource inventory from cloud provider APIs into CMDB CI tables
|
AWS SGC, Azure SGC, GCP SGC
|
1:3
|
YES - by default, any resource classified into a CMDB class mapped to the PaaS licensable category will consume SUs at 1:3
|
|
Classification Policy
|
Classification policy - which CMDB classes map to the PaaS licensable category and which do not - must be defined before the connector is enabled broadly. Resources that land without that filter begin contributing to the rolling 90-day average immediately, and cloud environments provision fast enough that the gap between review cycles can be significant.
|
|||
Real-World Scenario: PaaS Volume Risk
An organization runs 500 servers and enables cloud Service Graph Connectors broadly across their AWS and Azure environments without a prior classification policy. Their cloud footprint includes cloud databases, cloud app servers, and other PaaS-class resources provisioned across multiple teams over two years. At the next review cycle they find 4,500 active PaaS-category CIs mapped to the PaaS licensable category.
|
Approach
|
PaaS Resources Ingested
|
ITOM-Managed
|
PaaS SUs
|
Unintended SUs
|
|---|---|---|---|---|
|
Broad SGC enabled, no classification policy
|
4,500
|
4,500 - all classified into PaaS licensable CMDB classes, no exclusions defined
|
1,500
|
1,100 unintended - unreviewed cloud resources consuming SUs with no deliberate scoping decision made
|
|
SGC enabled with pre-classification policy
|
4,500
|
1,200 - classified as ITOM-relevant before connector enabled; remaining 3,300 exist in CMDB but outside PaaS licensable category
|
400
|
None - unclassified resources remain in CMDB but do not consume SUs
|
|
Key Takeaway
|
Both approaches produce identical CMDB coverage. The difference is 1,100 PaaS SUs, eliminated not by changing the ingestion tool or method, but by defining which CMDB classes map to the PaaS licensable category before the connector runs.
|
|||
Common Misconceptions
“Cloud resources are cheaper to license than servers, so broad cloud discovery is low-risk.”
The 1:3 ratio is more favorable per unit, but cloud environments provision at a pace that eliminates the advantage quickly. As the table above shows, 4,500 PaaS resources generate three times the SU exposure of 500 servers. Per-unit ratio and total exposure are different numbers.
“If we deprovision the cloud resource, it stops counting.”
Not automatically. If the CI remains in CMDB after the resource is deprovisioned – which happens when reconciliation and aging rules are not configured – it can continue to affect daily CI counts unless retired, reclassified, or aged out. In practice, stale CIs from terminated resources are a common source of unexplained SU growth between review cycles.
“We tagged everything in AWS, so our ITOM scope is already controlled.”
Cloud-side tags do not automatically control ITOM licensing scope in ServiceNow. Tags can be used as inputs to classification and scoping logic, but that mapping must be explicitly configured within the platform. Tagging in the cloud provider console and having that tag respected by the ITOM Licensing module are two separate things.
“Disabling the Service Graph Connector will reduce our SU count.”
Disabling the connector stops new resources from being ingested. It does not remove CIs already in CMDB, and those existing CIs continue to count until they are reclassified or aged out. Turning off the connector without addressing existing CIs does not reduce current SU exposure.
Closing: What to Review Before Your Next Cloud Connector Expansion
If any of the following questions produce uncertainty, that uncertainty has a dollar value attached to it.
- Was a PaaS classification policy in place and validated before your cloud connectors were enabled? If not, has a retroactive review been completed?
- Are there stale CIs from deprovisioned cloud resources still mapped to a licensable PaaS category? When did reconciliation and aging rules last run?
- Are cloud-side tags explicitly mapped to ITOM Licensing scope within ServiceNow, or is the assumption that tagging in the provider console controls what counts?
- Has someone confirmed with your ServiceNow account team which CI types are mapped to PaaS versus FaaS? Miscategorization between those two categories produces SU estimates that are six times off in either direction.
PaaS exposure is a classification and timing problem, not a volume problem. The resources being managed are not the issue – the question is whether the governance was in place before they started counting.
Up Next: Part 3 – Your Container Count Is Probably Wrong
Part 3 covers Containers – the category with the most favorable ratio after FaaS and the most underestimated total exposure. Container environments do not scale like server estates, and the most common modeling error is measuring point-in-time counts instead of 90-day daily averages. A cluster that runs 1,200 pods at peak and 300 at off-hours is not a 300-container environment for SU purposes.
