What permissions does a CMDB need to discover AWS and Azure resources?

Agentless cloud discovery normally needs read-only API access. In AWS, that usually means an IAM role the CMDB assumes in each account, often deployed across AWS Organizations so new accounts are covered automatically. AssetSonar's AWS Cloud Integration, for example, assumes an IAM role secured with an External ID (setup guide). In Azure, it usually means a service principal granted the Reader role at the subscription or management group level. Host-level and process-level discovery need more: an agent on the workload, or SSH and WinRM credentials for agentless scanning. Before shortlisting, get each vendor's exact permission set, how it stores and rotates credentials, and what happens when a new account appears without the role.

How often should a cloud CMDB refresh AWS and Azure discovery data?

Use event-driven updates plus periodic full reconciliation rather than one fixed interval. A daily scan is usually too slow for production services that autoscale or redeploy several times a day. On AWS, AWS Config publishes a Configuration Item Change event to Amazon EventBridge when a recorded resource changes (AWS docs). On Azure, Azure Event Grid delivers resource-created, updated, and deleted events to a subscription (Microsoft Learn). Events keep the CMDB current between scans, while full scans catch anything they miss. Set the cadence by service tier: services with the most change reviews need the shortest gap between a cloud change and the CMDB reflecting it.

How should a CMDB handle cloud resources that are destroyed and recreated?

Treat the instance as temporary and its role as durable. Instead of attaching service relationships to an individual EC2 instance or Azure VM ID, model them on a more stable CI such as an Auto Scaling group, a Kubernetes deployment, a load balancer, or an application component. Identify that CI through tags or infrastructure-as-code identifiers from Terraform or AWS CloudFormation. When a resource disappears, the CMDB should retire the CI with its history intact rather than delete it, so incident reviews can see what existed at the time. In a demo, recreate a resource and check whether its service assignment survives without manual repair.

Can a cloud CMDB map Kubernetes and serverless dependencies?

Partially, and coverage varies by vendor. Pods live too briefly to be useful as individual CIs, so CMDBs typically model Kubernetes at the cluster, namespace, deployment, and service level. For example, ServiceNow documents Kubernetes cluster discovery on AWS, Azure, and Google Cloud (ServiceNow docs). Serverless functions such as AWS Lambda and Azure Functions can be discovered through cloud APIs, but their dependencies are defined by triggers and event sources, such as a queue, an API gateway route, or a storage event, rather than long-running connections. Traffic-based mapping often misses them. The proof is one function's trigger, downstream calls, and owning service shown in your own environment.

Can observability or APM tools replace CMDB dependency mapping?

Not fully, though they overlap. Application performance monitoring (APM) and distributed tracing tools such as Datadog, Dynatrace, and New Relic observe real calls between services, making them strong evidence of runtime dependencies. They generally don't capture the records change and incident processes need: service ownership, change history, contracts, licenses, support assignments, and approval rules. Trace data also reflects only the paths exercised during its retention window. The two work best together. For instance, AssetSonar is positioned to work alongside monitoring systems during outage response rather than replace them (AssetSonar CMDB). The evaluation question is whether the CMDB can reference runtime evidence and record its source and date.

Which cloud tags should be standardized before a CMDB rollout?

Tags are often the only link between a cloud resource and the business, so standardize a small required set before connecting discovery. A practical minimum is owner (a team, not a person), application or service name, environment (production, staging, development), and cost center. Some organizations add data classification and criticality. Enforce the set at creation time with AWS Organizations tag policies or Azure Policy, because a CMDB can only group resources by tags that exist and are spelled consistently. The next platform question is whether tags drive only grouping and ownership, or also automatically assign resources to business services.

How do you measure whether cloud CMDB data is accurate enough to trust?

Measure the data against the decisions it supports instead of counting CIs. Useful indicators include the share of production cloud CIs with an assigned owner, the share linked to a business service, the share of relationships verified within an agreed window, the number of duplicate or orphaned CIs, and how often incident or change reviews find a dependency the CMDB missed. Track them per critical service, not only in aggregate. A platform that reports these measures natively saves the team from building them, and CMDB accuracy that nobody measures tends to decay after go-live.

Is application dependency mapping licensed separately from the CMDB?

Often, yes. In enterprise ITOM suites, the base CMDB, cloud discovery, application dependency mapping, and service mapping can sit in different packages, and pricing may depend on discovered nodes, subscription units, or collectors. ServiceNow, for example, ties Discovery and Service Mapping to an ITOM Visibility subscription and offers a Cloud License Estimator for counting eligible cloud resources (release notes). Infrastructure and staff time for credentials and reconciliation add to the total. Request a three-year total cost of ownership (TCO) covering the exact scope tested in the proof of concept, including AWS accounts, Azure subscriptions, Kubernetes clusters and on-prem hosts, so comparisons reflect the same coverage.

What does a phased cloud CMDB rollout look like?

A phased rollout starts with one critical business service rather than the whole estate. Connect discovery for the AWS accounts and Azure subscriptions that the service uses, apply the tagging standard, model its service context, and assign owners. Then run a real change and a real incident through the CMDB and record where the map helped or failed. Expand to the next services only once refresh, reconciliation, and ownership work for the first one. This sequence exposes credential, tagging, and governance gaps while they are cheap to fix, and gives the CIO evidence about operating effort before committing to full discovery scope and licensing.

Can an organization start with a lighter CMDB and move to full ITOM later?

Yes, if the data model allows it. Most of the work that transfers between platforms is governance: tagging standards, service definitions, ownership assignments, and CI naming conventions. The new platform usually re-collects discovered data rather than migrating it. The real cost sits in manually modeled relationships and business service definitions, which are expensive to rebuild. Before choosing a lighter connected CMDB such as AssetSonar, confirm how it can export service definitions, relationships, and ownership records in a structured format. That keeps a later move to ServiceNow, BMC Helix Discovery, or another ITOM platform an upgrade rather than a restart.

AssetSonar Blog Cloud Cmdb Dependency Mapping

Your Cloud CMDB Found the Infrastructure. Can It Tell Operations What Breaks Next?

Published on October 28, 2026

Last updated on October 28, 2026

Danish Amir
7 minutes

Table of Contents

The overnight discovery job ran cleanly. The CMDB now lists every EC2 instance, every Azure VM, the managed databases, the Kubernetes clusters, and the load balancers in front of them. By CI count, the project is a success.

Then a change request arrives to adjust a production database on Thursday night.

IT Operations wants to know which business service depends on that database. Cloud Operations wants to know whether the relationships on the map were verified after last week’s redeployment. The CIO wants to know why answering either question still takes three consoles and a Slack thread.

Discovery found the infrastructure. It hasn’t connected those resources to the services, owners, and change operations decides on. My argument is that this connection, not resource coverage, separates a useful cloud CMDB from an expensive inventory. The strongest platform keeps dependencies accurate enough to support incident, change, and architecture decisions.

What is the difference between CMDB cloud discovery and operational context?

CMDB cloud discovery collects resources from AWS, Azure, and other providers, usually through their APIs, and answers “what exists?” Operational context answers a harder question: “If this resource changes or fails, which service is affected, and who owns the decision?” A CMDB can do the first well and still leave the second to people.

A useful way to separate the two is what I call the Cloud Operations Context Ladder.

Inventory: what exists? VMs, databases, storage, load balancers, accounts, and subscriptions.
Infrastructure topology: how are resources structurally connected? A VM in a subnet, the subnet in a VPC or VNet, a load balancer and its targets.
Runtime dependencies: what communicates with or relies on what? Application to database, service to API, process to process.
Service context: which components deliver a business service, and who owns it? A customer portal might rely on Azure identity, an AWS API tier, an AWS database, and an on-prem ERP connector.
Operational action: does the model change what IT does? Incident priority, change-risk review, and migration planning, each with an accountable owner.

Cloud APIs report structure, so API-based discovery on its own mostly reaches level two. Levels three and four need host, process, or traffic evidence plus human service modeling. Incident and change decisions happen at levels four and five.

Where does a cloud CMDB break during a real change?

Consider a hypothetical sequence. A payments team redeploys its AWS API tier behind a new load balancer. The instances are recreated with new IDs. Discovery adds them to inventory correctly on its next run. The team manually modeled the relationship linking the API tier to the Customer Payment Service on the old CIs, which are now retired. Nothing carries it over.

Two days later, the database change goes to review. The change manager runs an impact check. The map shows the database connected to the new API instances, but those instances belong to no business service, so the check returns no affected services. The change is approved as low risk.

Every record was accurate when it was written. The failure lies in the handoff between discovery, the service model, and the change workflow, and no one owned it.

Why does IT Operations need dependency context instead of more inventory?

During an incident, an inventory record tells an operator that a database exists. A dependency chain tells them the database feeds the payments API, which feeds checkout. The first starts a search. The second starts triage.

Root-cause analysis, change impact, and outage scoping all depend on relationships and service ownership. Without either, operators have to rebuild the chain from memory.

Why do cloud dependency maps go stale so quickly?

Cloud resources autoscale, redeploy, get recreated with new IDs, change tags, and pick up new dependencies with each release. A topology correct on Monday can be wrong by Wednesday without anyone touching the CMDB.

For Cloud Operations, the evaluation questions are about upkeep:

How often does discovery refresh, and can it respond to cloud events instead of a fixed schedule?
When a resource is recreated, what happens to the relationships and service assignments on the old CI?
How are conflicting records from multiple sources reconciled, and who reviews the exceptions?
Can you see what the topology looked like before an incident?

Cloud topology is operational data with a shelf life.

How much should you trust each line on a dependency map?

Each relationship on a map carries a different kind of evidence:

API-derived: structure reported by the cloud provider. Reliable for architecture, silent about runtime behavior.
Tag-derived: grouping and ownership inferred from tags. Only as good as your tagging discipline.
Process-derived: what runs on a host and what it calls. Strong evidence, usually needing agents or credentials.
Traffic-derived: observed network communication. Strong for runtime dependencies, can miss rarely used paths.
Manually modeled: relationships an architect declared. Essential for business services, and the first to go stale.

The map is only as trustworthy as the evidence behind each line. A platform that records each relationship’s source, last-verified date, and owner gives reviewers something to check.

Is AWS and Azure discovery the same as cross-cloud dependency mapping?

No. A vendor can discover resources in both AWS and Azure and still hold them as two separate inventories. Cross-cloud dependency mapping means modeling one service chain that runs from AWS to Azure to an on-prem system, with relationships that stay continuous across each boundary. The only convincing demonstration uses your own architecture.

How should a CIO decide how much discovery depth to buy?

Match discovery depth to the operating model. A lightweight connected CMDB fits when you need to link assets, users, software, service records, and basic infrastructure relationships. An infrastructure-discovery platform fits when hybrid visibility, migration planning, and dependency analysis are core. A full ITOM and service-mapping platform fits when high change volume, expensive outages, and automated impact analysis justify the implementation, licensing, and governance overhead. The right level matches your operational risk.

Which CMDB platforms provide the strongest operational cloud context?

These five platforms sit at different points on the Context Ladder. Each description reflects the vendor’s public documentation as of October 2026. Disclosure: I work on AssetSonar at EZO.

ServiceNow: best for full ITOM and service-aware multi-cloud operations

ServiceNow Discovery uses cloud discovery patterns for AWS, Azure, Google Cloud, and other providers, while Service Mapping maps dependencies top-down from an application service (ServiceNow docs). Both feed native incident and change workflows. The trade-off is investment: these functions require an ITOM Visibility subscription (release notes), plus implementation and ongoing governance.

BMC Helix Discovery: best for hybrid and multi-cloud discovery depth

BMC Helix Discovery combines cloud API data with host-level scans and links applications that span more than one cloud provider (BMC docs). It suits organizations that treat discovery accuracy as a strategic priority.

Device42: best for infrastructure-centric discovery and ADM

Device42 offers agentless discovery with optional agents, an application dependency mapping (ADM) module, and impact charts built for migrations and change control (Device42). It sits between lightweight CMDBs and full ITOM suites. Confirm cloud-native dependency coverage for the specific AWS and Azure services you run.

Jira Service Management Assets: best for Atlassian-centric IT Operations

Assets is included in Jira Service Management Standard and above and keeps CMDB context next to incidents and changes (Atlassian). Assets Discovery is an agentless network scanner, and AWS, Azure, and Google Cloud data arrive through import integrations (Atlassian docs). Clarify which relationships those imports create and which your team models by hand.

AssetSonar: best for connected ITAM, ITSM and CMDB context without enterprise ITOM overhead

AssetSonar’s IT Graph connects assets, users, software, licenses, tickets, contracts, and CIs in one model. Its AWS Cloud Integration connects an AWS account through an IAM role, imports supported AWS resources on scheduled syncs, and maps supported relationships between them. Some relationships still need to be added manually (IT Graph guide). EZO’s public CMDB documentation lists AWS as its cloud infrastructure source, so Azure-heavy teams should confirm coverage. AssetSonar is not built to match ServiceNow or BMC on automated multi-cloud dependency mapping. It fits mid-market and growing IT teams that need connected context without a separate enterprise ITOM architecture.

What should you test before buying a cloud CMDB?

Run three tests on your own architecture.

The change test. Give each vendor this scenario: our customer payment service uses an AWS-hosted application tier, Azure identity services, an AWS database, and an on-prem ERP integration, and we are changing the database configuration tonight. Ask which dependencies were auto-discovered, imported, inferred, or modeled by hand, when each was last verified, and which downstream services are at risk. Then ask what happens if the Azure component is recreated tomorrow.

The incident test. Checkout latency spikes. Can the platform show which CIs are implicated, which service is affected, and which recent changes touched those dependencies? Can a service desk agent move from incident to CI to dependencies without leaving the ticket?

The CIO test. What operational problem disappears, such as manual impact analysis or war-room reconstruction? What new burden appears, such as collectors, credentials, reconciliation, and licensing? What decision does this map improve that your monitoring tools cannot already answer?

Which cloud CMDB should you choose?

If your main need is	Consider	Cloud evidence in public docs (Oct 2026)
Deep service-aware ITOM tied to ITSM, with budget for the complexity	ServiceNow	Cloud discovery patterns for AWS, Azure and GCP; Service Mapping
Hybrid and multi-cloud discovery depth	BMC Helix Discovery	Cloud API plus host scans; cross-provider application linking
Infrastructure discovery and ADM for migration and impact analysis	Device42	Agentless AWS and Azure discovery; ADM module and impact charts
Atlassian ITSM context with moderate CMDB needs	Jira Service Management Assets	AWS, Azure and Google Cloud import integrations
Connected ITAM, ITSM and CMDB context without the deepest ITOM topology engine	AssetSonar	AWS Cloud Integration with supported relationship mapping

What is the one question to ask a cloud CMDB vendor?

Cloud Operations needs a map that stays current. IT Operations needs a map it can act on during an incident or a change. The CIO needs that map to create more value than burden.

So pick one production service and ask: for every dependency on this map, can you show where the evidence came from, when it was last verified, and who is accountable for keeping it right?

Match the CMDB depth to the operations problem

Bring one AWS service architecture to an AssetSonar demo and trace it through the IT Graph. If the connected context covers your incidents and changes, you have your answer. If not, you likely need a deeper standalone ITOM discovery layer. Compare with the Atlassian option. See AssetSonar vs. Jira Service Management.

Was this helpful?

Thanks for your feedback!

Danish Amir

Product Management Lead

EZO

Danish Aamir is a product management leader at EZO who writes about AI in IT service management, enterprise asset intelligence, and the convergence of ITAM and ITSM. His work explores how connected asset, user, and software context can help organizations move beyond basic ticket automation toward governed, context-aware service delivery.

Frequently Asked Questions

What permissions does a CMDB need to discover AWS and Azure resources?
Agentless cloud discovery normally needs read-only API access. In AWS, that usually means an IAM role the CMDB assumes in each account, often deployed across AWS Organizations so new accounts are covered automatically. AssetSonar's AWS Cloud Integration, for example, assumes an IAM role secured with an External ID (setup guide). In Azure, it usually means a service principal granted the Reader role at the subscription or management group level. Host-level and process-level discovery need more: an agent on the workload, or SSH and WinRM credentials for agentless scanning. Before shortlisting, get each vendor's exact permission set, how it stores and rotates credentials, and what happens when a new account appears without the role.
How often should a cloud CMDB refresh AWS and Azure discovery data?
Use event-driven updates plus periodic full reconciliation rather than one fixed interval. A daily scan is usually too slow for production services that autoscale or redeploy several times a day. On AWS, AWS Config publishes a Configuration Item Change event to Amazon EventBridge when a recorded resource changes (AWS docs). On Azure, Azure Event Grid delivers resource-created, updated, and deleted events to a subscription (Microsoft Learn). Events keep the CMDB current between scans, while full scans catch anything they miss. Set the cadence by service tier: services with the most change reviews need the shortest gap between a cloud change and the CMDB reflecting it.
How should a CMDB handle cloud resources that are destroyed and recreated?
Treat the instance as temporary and its role as durable. Instead of attaching service relationships to an individual EC2 instance or Azure VM ID, model them on a more stable CI such as an Auto Scaling group, a Kubernetes deployment, a load balancer, or an application component. Identify that CI through tags or infrastructure-as-code identifiers from Terraform or AWS CloudFormation. When a resource disappears, the CMDB should retire the CI with its history intact rather than delete it, so incident reviews can see what existed at the time. In a demo, recreate a resource and check whether its service assignment survives without manual repair.
Can a cloud CMDB map Kubernetes and serverless dependencies?
Partially, and coverage varies by vendor. Pods live too briefly to be useful as individual CIs, so CMDBs typically model Kubernetes at the cluster, namespace, deployment, and service level. For example, ServiceNow documents Kubernetes cluster discovery on AWS, Azure, and Google Cloud (ServiceNow docs). Serverless functions such as AWS Lambda and Azure Functions can be discovered through cloud APIs, but their dependencies are defined by triggers and event sources, such as a queue, an API gateway route, or a storage event, rather than long-running connections. Traffic-based mapping often misses them. The proof is one function's trigger, downstream calls, and owning service shown in your own environment.
Can observability or APM tools replace CMDB dependency mapping?
Not fully, though they overlap. Application performance monitoring (APM) and distributed tracing tools such as Datadog, Dynatrace, and New Relic observe real calls between services, making them strong evidence of runtime dependencies. They generally don't capture the records change and incident processes need: service ownership, change history, contracts, licenses, support assignments, and approval rules. Trace data also reflects only the paths exercised during its retention window. The two work best together. For instance, AssetSonar is positioned to work alongside monitoring systems during outage response rather than replace them (AssetSonar CMDB). The evaluation question is whether the CMDB can reference runtime evidence and record its source and date.
Which cloud tags should be standardized before a CMDB rollout?
Tags are often the only link between a cloud resource and the business, so standardize a small required set before connecting discovery. A practical minimum is owner (a team, not a person), application or service name, environment (production, staging, development), and cost center. Some organizations add data classification and criticality. Enforce the set at creation time with AWS Organizations tag policies or Azure Policy, because a CMDB can only group resources by tags that exist and are spelled consistently. The next platform question is whether tags drive only grouping and ownership, or also automatically assign resources to business services.
How do you measure whether cloud CMDB data is accurate enough to trust?
Measure the data against the decisions it supports instead of counting CIs. Useful indicators include the share of production cloud CIs with an assigned owner, the share linked to a business service, the share of relationships verified within an agreed window, the number of duplicate or orphaned CIs, and how often incident or change reviews find a dependency the CMDB missed. Track them per critical service, not only in aggregate. A platform that reports these measures natively saves the team from building them, and CMDB accuracy that nobody measures tends to decay after go-live.
Is application dependency mapping licensed separately from the CMDB?
Often, yes. In enterprise ITOM suites, the base CMDB, cloud discovery, application dependency mapping, and service mapping can sit in different packages, and pricing may depend on discovered nodes, subscription units, or collectors. ServiceNow, for example, ties Discovery and Service Mapping to an ITOM Visibility subscription and offers a Cloud License Estimator for counting eligible cloud resources (release notes). Infrastructure and staff time for credentials and reconciliation add to the total. Request a three-year total cost of ownership (TCO) covering the exact scope tested in the proof of concept, including AWS accounts, Azure subscriptions, Kubernetes clusters and on-prem hosts, so comparisons reflect the same coverage.
What does a phased cloud CMDB rollout look like?
A phased rollout starts with one critical business service rather than the whole estate. Connect discovery for the AWS accounts and Azure subscriptions that the service uses, apply the tagging standard, model its service context, and assign owners. Then run a real change and a real incident through the CMDB and record where the map helped or failed. Expand to the next services only once refresh, reconciliation, and ownership work for the first one. This sequence exposes credential, tagging, and governance gaps while they are cheap to fix, and gives the CIO evidence about operating effort before committing to full discovery scope and licensing.
Can an organization start with a lighter CMDB and move to full ITOM later?
Yes, if the data model allows it. Most of the work that transfers between platforms is governance: tagging standards, service definitions, ownership assignments, and CI naming conventions. The new platform usually re-collects discovered data rather than migrating it. The real cost sits in manually modeled relationships and business service definitions, which are expensive to rebuild. Before choosing a lighter connected CMDB such as AssetSonar, confirm how it can export service definitions, relationships, and ownership records in a structured format. That keeps a later move to ServiceNow, BMC Helix Discovery, or another ITOM platform an upgrade rather than a restart.