FaaS Resources
Series Recap
This is Part 5 of a six-part series on how ITOM architecture decisions become licensing costs. Parts 1 through 4 covered Servers, PaaS, Containers, and EUC Devices – each with a different mechanism by which implementation decisions produce unplanned SU costs. The common thread: the exposure was visible at design time. It was rarely prioritized there.
Part 5 covers FaaS Resources. The 1:20 ratio is the most favorable in the ITOM model. It is also the one most likely to produce a false sense of security – because the resource type that scales the fastest is the one that gets the least governance attention.
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 FaaS SUs Are Triggered
FaaS resources – serverless compute functions such as AWS Lambda, Azure Functions, and Google Cloud Functions – are ingested via certified Service Graph Connectors or Cloud Discovery patterns and counted when their CI types are mapped to the FaaS licensable category for the relevant ITOM product.
The same conditions that apply across every other resource type apply here: CI type mapping and ITOM application scope determine what counts. The difference is that serverless functions can proliferate at a scale that makes the ratio advantage irrelevant – and they do so without any infrastructure gate that creates a natural review point.
Unlike servers, which require provisioning decisions, or containers, which require cluster configuration, FaaS functions are created by individual developers in response to application requirements. A single cloud-native application can generate dozens of functions. A mature serverless estate across multiple teams can reach tens of thousands. There is no equivalent of a Discovery schedule configuration or a Kubernetes namespace policy that forces a licensing conversation before the function exists in CMDB.
The Scale Problem
The 1:20 ratio is real and meaningful at low volumes. At enterprise scale in an active serverless environment, volume overtakes the ratio advantage entirely. The table below shows an organization with 500 servers and 15,000 active FaaS functions – a scale reached by mature cloud-native organizations with multiple development teams building serverless applications over two or more years.
|
Resource Type
|
Count
|
SU Ratio
|
Total SUs
|
|---|---|---|---|
|
Servers
|
500
|
1:1
|
500 Server SUs
|
|
FaaS Functions (active, production + non-production)
|
15,000
|
1:20
|
750 FaaS SUs
|
Per-unit ratio and total exposure are different numbers. In FaaS environments, both work against accurate estimation: the favorable ratio suppresses concern, and the lack of an infrastructure gate means the function count grows without triggering a review. A classification policy must be in place before connectors are enabled, and functions deleted in the cloud provider do not automatically leave CMDB – stale CIs can continue to affect daily counts unless reconciliation and aging rules remove them.
The Classification Risk
FaaS carries a second exposure that no other resource type in this series shares at the same magnitude: miscategorization. Current discovery documentation maps Azure Functions and AWS Lambda to cmdb_ci_cloud_function, and the ITOM overview maps that class to the FaaS resource type – so the default path should land correctly. The risk is that customizations, outdated connector content, or non-standard CI type configurations could cause FaaS resources to land in the PaaS category at 1:3 rather than 1:20. Validate FaaS category mappings in the ITOM Licensing module before enabling cloud connectors broadly. Miscategorization in either direction produces inaccurate exposure estimates.
|
Functions
|
Correct Category
|
Incorrect Category
|
SU Difference
|
|---|---|---|---|
|
15,000
|
FaaS at 1:20 = 750 SUs
|
PaaS at 1:3 = 5,000 SUs
|
4,250 excess SUs from miscategorization alone
|
|
Confirm Before Enabling
|
Confirm with your ServiceNow account team that FaaS CI types are correctly mapped to the FaaS licensable category before enabling cloud connectors broadly.
|
||
Ingestion Paths
FaaS resources share the same ingestion mechanism as PaaS – Service Graph Connectors and Cloud Discovery patterns. The critical distinction is category mapping: whether the CI types created by the connector are mapped to the FaaS licensable category or fall into PaaS by default.
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 Discovery patterns
|
Certified SGC or Cloud Discovery pulls FaaS resource inventory from cloud provider APIs into CMDB CI tables
|
AWS SGC, Azure SGC, GCP SGC, Cloud Discovery patterns
|
1:20
|
YES - when CI types are mapped to the FaaS licensable category. Resources landing in the PaaS category instead will count at 1:3. Confirm category mappings before enabling connectors broadly.
|
|
Classification Risk
|
See The Classification Risk section above. Review category mappings in the ITOM Licensing module before any cloud connector expansion that includes serverless resources.
|
|||
Real-World Scenario: FaaS Volume Risk
An organization runs 500 servers and has enabled cloud Service Graph Connectors across AWS and Azure. Their development teams have been building serverless applications for two years across multiple product lines. At the next review cycle they find 15,000 active FaaS-category CIs – functions their development teams created incrementally with no single provisioning event that would have triggered a licensing review.
|
Approach
|
FaaS Resources Ingested
|
ITOM-Managed
|
FaaS SUs
|
Unintended SUs
|
|---|---|---|---|---|
|
Broad SGC enabled, no classification policy
|
15,000
|
15,000 - all mapped to FaaS licensable category, no exclusions defined
|
750
|
375 unintended - non-production and inactive functions consuming SUs with no operational return
|
|
SGC enabled with pre-classification policy
|
15,000
|
7,500 - production functions only; dev, staging, and inactive functions excluded via CI type mappings
|
375
|
None - excluded functions remain in CMDB but do not consume SUs
|
|
Key Takeaway
|
Both approaches produce identical CMDB coverage. The difference is 375 FaaS SUs, eliminated not by changing the ingestion tool or method, but by defining which functions map to the FaaS licensable category before the connector runs. At 1:20, the per-unit cost is low. At 15,000 functions the volume still matters.
|
|||
Common Misconceptions
“FaaS is so cheap at 1:20 that broad ingestion carries no meaningful risk.”
The 1:20 ratio is the most favorable in the ITOM model, but serverless environments scale faster than any other resource type in this series. As the table above shows, 15,000 functions generate 750 SUs – more than the entire server estate. At 30,000 functions, the exposure reaches 1,500 SUs. Per-unit ratio and total exposure are different numbers.
“Our FaaS resources are already covered by our PaaS classification policy.”
FaaS is a distinct licensable category from PaaS, and a PaaS classification policy does not automatically extend to FaaS functions. If FaaS CI types land in PaaS at 1:3 instead of 1:20, the SU exposure is six times higher than the correct rate. See The Classification Risk section above for the full breakdown.
“Deleting a Lambda function removes it from our SU count.”
Deleting a function in the cloud provider removes it from the cloud environment. It does not automatically remove the CI from CMDB. Without reconciliation and aging rules configured to retire or delete stale CIs, deleted functions remain in CMDB and can continue to affect daily FaaS SU counts until manually removed or aged out. Review stale FaaS CIs as part of any ITOM licensing optimization effort.
Closing: What to Confirm Before Your Next Serverless Expansion
If any of the following questions produce uncertainty, that uncertainty has a dollar value attached to it.
- Are FaaS CI types explicitly mapped to the FaaS licensable category in the ITOM Licensing module, or could they be landing in PaaS at 1:3? This confirmation must happen before cloud connectors are enabled broadly – not after functions are already in CMDB.
- When did someone last review the function count against what development teams have actually deployed? FaaS estates grow without provisioning events that trigger licensing reviews. The count from six months ago is not the count today.
- Are non-production, staging, and inactive functions excluded from the FaaS licensable category, or are they all classified together with production workloads?
- Are reconciliation and aging rules configured to retire stale FaaS CIs when functions are deleted in the cloud provider? Stale CIs can continue to affect daily counts until they are removed from CMDB.
FaaS SU exposure is a governance problem, not a volume problem. The functions are being built by development teams doing their jobs. The question is whether classification policy and connector scope were defined before those functions started landing in CMDB.
Up Next: Part 6 – Unresolved Monitored Objects
Part 6 covers Unresolved Monitored Objects – the only cost driver in the ITOM model that requires no deliberate decision at all. UMOs emerge from configuration database coverage gaps. They accrue before anyone knows to look, and gap-period usage may already be captured in prior daily counts before remediation begins. The final part also includes a full architecture checklist spanning all six resource types.
