Engineering
Security
What is a Cloud CMDB (and is it needed)?
CMDBs (Configuration Management Databases) have been around for over 25 years, pioneered by companies like BMC, IBM, HP, and later ServiceNow and Jira. But with the rise of cloud computing, things have changed quite a bit. So, let’s dive into the big questions:
- What does a CMDB look like in a cloud environment?
- If it’s so different, should we even call it a CMDB anymore? To make matters more confusing, ServiceNow, Jira and other modern ITSMs are called “Cloud CMDBs” because they run in the Cloud, but they are actually not for managing cloud environments.
We'll break it down and see why a Cloud CMDB isn't exactly what it sounds like, and why we might need a new term altogether.
What is a CMDB? #
At its core, a Configuration Management Database (CMDB) is what it sounds like: a database for IT teams that keeps track of IT infrastructure.
Traditional (Current) CMDBs #
- Usually part of IT Service Management (ITSM) platforms like ServiceNow, Jira, Freshworks…
- Originally designed to track physical assets like servers, laptops, and networking gear.
- Helps with asset management, compliance, and change tracking.
- Often started as a glorified spreadsheet, later adding automation to pull in and update asset data automatically.
- Typically tracks Configuration Items (CIs), which are individual units like servers or applications.
Why Do Companies Need CMDBs? #
- Avoid losing track of hardware – Every company needs to document its physical assets to make sure it’s not lost when it is replaced, changes hands or employees are leaving.
- Better decision-making – Know when to replace or upgrade equipment and plan for the cost of doing so.
- Change management – Keep records of what changed and why, and plan changes ahead of time
- Regulatory compliance – Auditors love a well-maintained CMDB.
What is a Cloud CMDB (or CMDB for Cloud Environments)? #
If you Google it, you’ll find a simple definition: a CMDB that tracks cloud assets. Sounds reasonable, right? But here’s the thing—Cloud CMDBs don’t really exist in the way traditional CMDBs do.
Why a Cloud CMDB Isn’t Really a Thing #
A traditional CMDB exists to prevent asset loss, but in the cloud, that exact problem doesn’t exist:
- You can’t physically lose an AWS EC2 instance (you can forget you spawned it but you will be able to find it via the API).
- Cloud providers (AWS, Azure, GCP) already track all your resources via APIs, which is basically a CMDB that is just accessible via the API.
- Infrastructure is typically managed via Infrastructure-as-Code (IaC) (Terraform, CloudFormation, etc.), not through ITSM workflows.
- Cloud assets are ephemeral—instances, lambda and other resources get spun up and down dynamically..
So Why Would You Need a Cloud CMDB? #
While you don’t need a CMDB to track hardware in the cloud, there are still some big challenges:
- Security & Compliance – Are your cloud assets configured correctly and securely?
- Discoverability – Can you easily and quickly find and understand all your resources?
- Incident Response – When something breaks, can you quickly figure out what’s affected?
- Cost - Do you know what costs you money and can you put guardrails to avoid waste?
- Change Management - If we want to change or move infrastructure, what services are going to be affected?
#
Key Differences Between Traditional and Cloud CMDBs #
- No CIs – Traditional CMDBs track specific “Configuration Items” (CIs), but in the cloud, infrastructure is more fluid, AWS has over 1,000 of APIs when each API generates a different data type that cannot always fit to the same CI.
- No physical loss – Cloud assets are always accounted for in billing APIs.
- Change Management is Different – Traditional CMDBs tie changes to ticketing systems; in the cloud, changes are managed through GitOps and IaC.
- Data Complexity – Cloud environments generate way more data than on-prem IT setups.
Why a Traditional CMDB Model Fails in the Cloud #
A spreadsheet-style CMDB can’t handle cloud complexity. You can’t just take cloud data and throw it into a single ITSM table. Here’s why:
- Data Volume – Cloud environments have thousands of dynamic resources.
- Complex Data Structures – Cloud APIs expose deeply nested, constantly changing data that cannot be effectively represented in a traditional CMDB.
- Real-Time Needs – Cloud infrastructure is always evolving, so a static database isn’t enough.
A Better Alternative: A Cloud-Native Approach #
Instead of a traditional CMDB, we need a new model:
- Automated data ingestion – Continuously pull data from cloud APIs.
- Data warehousing – Store current states and historical snapshots.
- Powerful querying – Use SQL to search across cloud resources.
- Powerful transformations - Cloud resources can be exposed and linked in different ways depending on the organization so there need to be a way to add custom views and transformation to expose data in an accessible way.
- Integrations with other tools - Many companies already have data warehouses and BI tools to monitor this type of information. An effective model needs to integrate with these systems and services.
What Does This Mean in Practice? #
If we ditch the idea of a “Cloud CMDB,” what do we get instead? Something closer to an Operational Lake that can serve as the basis to a “Cloud Governance platform”:
- Aggregates data from multiple sources (cloud providers, security tools, etc.).
- Provides fast, queryable access to infrastructure state.
- Integrates with security, compliance, and FinOps tools.
- Lets you ask complex questions using SQL instead of clicking through CMDB spreadsheets or exporting data into another tool.
This approach not only enhances visibility and control over cloud assets but also supports proactive governance and compliance efforts.
Do You Need a Cloud CMDB (or an Operational Lake)? #
The answer, as always: it depends.
- Is your cloud environment big and complex enough to require one?
- Could it serve as an alternative to a much more expensive CNAPP solution?
- Do you need to bridge the gap between security tooling (CNAPP), FinOps tools and cloud assets to understand and analyze governance at scale across business units?
- Do need to monitor and govern the state of your infrastructure across cloud, SaaS applications, on-prem and custom data.
If the answer to one or more of these questions is yes, then a Cloud CMDB or Operational Lake may be the right answer.
Final Thoughts #
Traditional CMDBs were built for ITSM workflows, but the cloud world plays by different rules. Instead of trying to shoehorn cloud data into a legacy CMDB model, we need a near real-time, queryable infrastructure data platform.
Whether you call it a Cloud CMDB or an Operational Lake, the idea is the same: you need a modern way to track, query, and analyze cloud infrastructure in near real time over time to achieve a well governed cloud and SaaS infrastructure..
Curious to take CloudQuery platform for a spin? Reach out here to get a personalized demo!
Written by Yevgeny Pats
Yevgeny Pats is the Co-Founder & CEO at CloudQuery. Prior to establishing CloudQuery, he successfully founded and exited other startups. He has a background in software engineering and cybersecurity.
