Azure Cosmos DB, Functions, and Key Vault in CMDB: Closing the PaaS Discovery Gap

#TLDR

Azure Platform-as-a-Service (PaaS) resources are invisible to traditional CMDB discovery tools because they have no operating system and accept no agents. Yet Azure Cosmos DB, Azure Functions, Azure Key Vault, Azure Storage Accounts, and PostgreSQL Flexible Server are real configuration items — they change, they fail, and they support business services.

This article covers how each Azure PaaS service maps to a CMDB CI, what attributes matter for change and compliance management, and how Virima 6.1.1 brings Azure PaaS into your configuration model.

The PaaS Discovery Gap in Azure Environments

Enterprise IT teams running Azure environments typically have good CMDB coverage for Azure Virtual Machines. VMs have an OS, a hostname, and an IP address — the traditional CMDB discovery model fits them well. Azure Arc extends that coverage to on-premises and multi-cloud VMs.

But the fastest-growing part of most Azure environments is not VMs. It is PaaS: managed databases, serverless functions, security vaults, and storage services that Azure operates on the customer’s behalf. Analysts report that 60-70% of new Azure workloads in enterprise environments use PaaS services as primary compute or data services.

These PaaS resources are real IT assets. They store regulated data. They run business-critical code. They consume budget. They change. And they fail. But they are largely absent from most enterprise CMDBs because:

1. Traditional discovery agents require an OS to run on. PaaS services have no OS the customer controls.
2. Cloud discovery tools built for VM enumeration often stop at virtual machine inventories.
3. CMDB teams assume that because Azure manages the underlying infrastructure, there is nothing to track at the CMDB level.

The third assumption is incorrect. Azure manages the infrastructure. The customer manages the configuration: the database consistency settings, the function runtime version, the Key Vault access policies, the storage account replication type. These are configuration attributes. Changes to them are change events. Incidents tied to them need accurate CI data for effective resolution.

Why Azure PaaS Is Different from Azure VMs in CMDB

The practical difference for CMDB discovery:

Dimension	Azure VM	Azure PaaS Service
Discovery method	Agent-based or agentless OS scan	Azure Resource Manager API
OS attributes	Yes (OS version, patches, software)	No OS attributes
Network attributes	Private IP, NIC, NSG	Endpoint URL, private endpoint, firewall rules
Change events	Software installs, OS patches, config changes	API-detected attribute changes, resource tier changes
CMDB CI type	Server, Virtual Machine	Service-specific CI type

Azure PaaS discovery requires querying the Azure Resource Manager (ARM) API for resource attributes. Virima’s Azure Discovery integration handles this API-based discovery for PaaS services alongside VMs and Kubernetes workloads in a single unified pipeline. This is API-only discovery: no agent, no OS access, no port scanning. The CMDB CI for an Azure Cosmos DB account contains the attributes that the ARM API exposes — resource ID, location, consistency level, throughput settings, replication regions — not OS-level attributes.

Azure Cosmos DB: Global-Scale Database as a CI

Azure Cosmos DB is Microsoft’s globally distributed, multi-model database service. It is a fully managed PaaS offering that requires no server administration, no storage provisioning, and no manual replication configuration. Enterprises use Cosmos DB as the data layer for high-throughput applications, real-time analytics, and globally distributed systems.

What Makes Cosmos DB a CMDB CI

A Cosmos DB account is an Azure resource with persistent configuration that change management needs to track:

• Account name and resource ID — stable identity
• API type — NoSQL (Core), MongoDB, Cassandra, Gremlin, or Table; changing the API type is a major reconfiguration
• Consistency level — Strong, Bounded Staleness, Session, Consistent Prefix, or Eventual. Consistency level changes affect application data integrity behavior and are significant configuration changes.
• Replication regions — the Azure regions where data is replicated. Adding or removing a region is a change with cost and availability implications.
• Multi-region writes — enabled or disabled; determines whether write operations are active in all regions or a single primary
• Throughput provisioning — Request Units (RUs) per second, autoscale vs. provisioned; throughput changes directly affect cost
• Backup policy — backup interval, retention, and type
• Private endpoint associations — network security configuration

Why Cosmos DB Matters for Change Management

A consistency level change from Session to Eventual on a Cosmos DB account is not an operational trivial change — it can cause application data behavior to change in ways that create support incidents. A region removal can degrade latency for users in that region. A throughput reduction can cause throttling that breaks application SLAs.

None of these changes require touching a server. All of them are configuration changes. Without Cosmos DB in the CMDB, none of them generate change records. The CMDB gap enables configuration drift that goes undetected until an incident surfaces it.

Azure Functions: Serverless Compute on Azure

Azure Functions is Microsoft’s serverless compute platform — the Azure equivalent of AWS Lambda. Like Lambda, Azure Functions runs code in response to events without requiring the customer to provision or manage servers.

The primary CI unit for Azure Functions is the Function App: a container that hosts one or more individual function definitions and shares a runtime, hosting plan, and storage account.

Function App Attributes as CI Data

• Function App name and resource ID — stable identity
• Runtime stack and version — the language runtime (Node.js, Python, .NET, Java, PowerShell) and its version. Runtime version changes are configuration changes.
• Hosting plan — Consumption (pay-per-execution), Premium (pre-warmed instances), or Dedicated (App Service Plan). Moving between plans is a significant configuration change.
• OS type — Windows or Linux; affects available runtimes and container support
• Storage account association — the Azure Storage account that the Function App uses for its internal state and code deployment
• Application settings — environment variables passed to functions; changes here affect function behavior
• Custom domains and TLS certificates — if the Function App has a custom domain

Individual Functions as Sub-CIs

Within a Function App, individual functions can be tracked as sub-CIs or attributes:

• Function name
• Trigger type — HTTP, Timer, Queue, Event Hub, Cosmos DB, Service Bus
• Authorization level — Anonymous, Function, Admin

Azure Functions and Change Management

Azure Functions deployment — publishing new function code — is a change event. In many DevOps pipelines, function deployments happen continuously with minimal formal change review. The CMDB visibility creates the opportunity to correlate function deployment events with subsequent incidents, even when the deployment occurred through an automated CI/CD pipeline. For a foundational guide to CMDB data quality and change governance, see how to create and maintain a reliable CMDB.

Azure Key Vault: Security Infrastructure in CMDB

Azure Key Vault is a managed service for storing cryptographic keys, secrets, and certificates. Applications use Key Vault to retrieve sensitive configuration — database passwords, API keys, TLS certificates — without storing that data in application code or configuration files.

Key Vault occupies a unique position in CMDB: it is security infrastructure. Changes to Key Vault directly affect application security posture and compliance.

Key Vault as a CMDB CI

• Vault name and resource ID — stable identity
• Location and resource group — Azure region and organizational context
• SKU — Standard or Premium; Premium adds Hardware Security Module (HSM)-backed key storage
• Access policies — which applications and users have permission to read secrets, manage keys, or access certificates. Access policy changes are security change events.
• Soft delete and purge protection — retention settings that affect disaster recovery
• Private endpoint associations — whether the vault is accessible only from private network endpoints
• Firewall rules — IP access restrictions to the vault

Keys, Secrets, and Certificates as CMDB Attributes

The contents of Key Vault — keys, secrets, and certificates — are not stored in the CMDB for obvious security reasons. But their metadata is CMDB-relevant:

• Certificate names and expiration dates — certificate expiry is a compliance event; CMDB-tracked expiry dates enable proactive certificate rotation
• Key names and key types — RSA, EC, or symmetric; key type changes affect encryption compatibility
• Secret names (not values) — the existence of specific secrets; removing or renaming a secret breaks any application that references it

Key Vault Compliance Value

Key Vault in the CMDB delivers direct compliance value. Auditors asking for evidence of cryptographic key management can receive a CMDB-sourced report of all Key Vaults, their access policies, their certificate expiry dates, and their network access configurations — without requiring manual inventory collection.

Azure Storage Accounts: Storage Infrastructure for Data Governance

Azure Storage Accounts are the foundational storage layer for Azure: blob storage (object storage), queue storage, table storage, and file shares all live within a storage account. Almost every Azure application uses at least one storage account.

Storage Account Attributes in CMDB

• Account name and resource ID
• Account kind — StorageV2 (general purpose v2), BlobStorage, BlockBlobStorage, FileStorage
• Replication type — LRS (locally redundant), ZRS (zone redundant), GRS (geo-redundant), GZRS (geo-zone-redundant). Replication type changes affect disaster recovery posture.
• Access tier — Hot, Cool, or Cold; affects storage cost and retrieval latency
• TLS minimum version — a compliance-relevant security setting
• Public access — enabled or disabled; public blob access is a security configuration attribute
• Private endpoint associations
• Soft delete retention — for blobs and containers

Data Governance Applications

Storage accounts frequently hold regulated data — backups, logs, compliance archives. A CMDB record of storage accounts, their replication configuration, and their access settings supports data governance programs by providing a centralized inventory of where data lives and how it is protected.

PostgreSQL and Neo4J on Azure: Database CIs Beyond SQL Server

Enterprise Azure environments increasingly run database workloads beyond the traditional SQL Server pairing. Two examples worth noting:

Azure Database for PostgreSQL – Flexible Server

Azure’s managed PostgreSQL offering (Flexible Server) is a PaaS database service with attributes relevant to CMDB:

• Server name and resource ID
• PostgreSQL version — major version upgrades are significant change events
• Compute tier and SKU — Burstable, General Purpose, or Memory Optimized; tier changes affect cost and performance
• Storage size and IOPS
• High availability mode — Zone Redundant HA or same-zone standby
• Backup retention period and geo-redundancy
• Firewall rules and private endpoint configuration

Neo4J on Azure (via Azure Marketplace)

Graph database deployments on Azure, including Neo4J via Azure Marketplace or Azure-hosted VMs, represent a growing CI type for enterprises using graph databases for knowledge graphs, fraud detection, or network topology analysis. The CMDB CI structure for these follows the VM model if hosted on Azure VMs, or a custom CI type if deployed via managed marketplace offerings.

Azure AKS: A Note on Kubernetes

Azure Kubernetes Service (AKS) is technically a PaaS offering — Microsoft manages the Kubernetes control plane, and you manage the node pools. For a full treatment of AKS CMDB discovery, including cluster CIs, node pools, workload CIs, and service mapping, see the companion article: Kubernetes CMDB Discovery: How to Track EKS, ECS, AKS, and Containerized Workloads in Your CMDB.

AKS clusters discovered via Virima 6.1.1 populate the CMDB alongside the Azure PaaS services described in this article, enabling a complete picture of Azure infrastructure — IaaS, PaaS, and Kubernetes — in a single CMDB.

How Virima 6.1.1 Supports Azure PaaS Discovery

Virima 6.1.1 extends IT Discovery beyond virtual machines to include PaaS services via the Azure Resource Manager API.

The 6.1.1 release adds native CI discovery for Azure Cosmos DB accounts, Azure Functions (Function Apps), Azure Key Vault instances, and Azure Storage Accounts. Discovered resources populate the CMDB as structured CIs with their key configuration attributes captured. Azure PostgreSQL Flexible Server instances and other Azure database services are part of the expanded Azure PaaS discovery coverage.

All Azure PaaS CIs participate in ViVID Service Mapping, enabling IT operations teams to see how Cosmos DB accounts, Key Vaults, and Function Apps connect to the applications and business services that depend on them.

For enterprise IT teams running hybrid Azure environments — VMs, PaaS services, and Kubernetes workloads side by side — Virima 6.1.1 closes the PaaS discovery gap that has left a growing share of Azure infrastructure invisible to the CMDB.

For a complete guide to every cloud service Virima discovers — including AWS Lambda, EKS, and AKS — see the complete cloud discovery coverage guide.

Ready to Discover Your Azure PaaS Environment?

See how Virima 6.1.1 discovers Cosmos DB, Azure Functions, Key Vault, and more — and maps them to your business services.

Schedule a Demo at virima.com