What is a Cloud Asset Inventory?

I recently caught up with an old friend who works for a low-code application deployment platform. Like a lot of our audience (and users), he is in a DevOps and Platform Engineering team, and during our talk, he asked several great questions about CloudQuery. Questions like: “What is a Cloud Asset Inventory, and why would you need one?”

So, let’s answer that today.

The core of any Cloud Asset Management solution is a Cloud Asset Inventory. Fundamentally, a Cloud Asset Inventory is a centralized database of all the cloud assets you’re paying for.

In many ways, they are similar to a DCIM (Data Centre Infrastructure Management) database in that they enable you to search through and monitor your assets, create dashboards, and analyze changes to deployments, access, and usage. But instead of tracking physically deployed assets, cabling, and circuits, it tracks cloud-deployed assets, networks, and connections.

A Cloud Asset Inventory is constructed by collecting information from the various Cloud Platform APIs (e.g. AWS, Google Cloud, Azure, etc.) and storing it in an accessible format, such as a SQL database.

A Cloud Asset Inventory enables engineers to identify, preempt, and mitigate a wide array of issues while simultaneously allowing engineers to perform risk and impact assessments quickly. They also enable otherwise complicated and expensive requests, such as identifying the source of a cost spike (in both simple single-cloud/single-account and complicated multi-cloud/multi-account platforms).

Let’s look at some real-world examples:

You work at a company that uses AWS, and your COO has requested a summary of why there has been a drastic increase in cloud costs over the last month.

Step 1: Open AWS Billing and Cost Management and navigate to Cost Explorer; you see that over the last month, there was a spike in the costs attributed to “EC2-Other”.

Step 2: You filter through the different regions in the report parameters to identify which region the offending resources are in, and find out that it was in “US-East-1”.

Step 3: You switch the report granularity to Daily and find out which day the change was introduced

Step 4: You check the changelogs/terraform plans for that day for mistakes and compare them against the active deployment. You do keep the changelogs, right?

Step 5: You write a report that states that due to a typo, 64 Blocks of 256 Public IP Addresses were allocated instead of the expected Single Block of 64 Public IP Addresses.

COO asks why there is a sudden increase in cloud costs.

Step 1: Open AWS Billing and Cost Management and navigate to Cost Explorer”…

Step 1: You write a SQL query that fetches the costs over the last two months, grouping by region and month; you see a spike in the costs attributed to “EC2-Other” in “us-east-1”.

Step 2: You alter the query to look specifically at ec2-other over the last month in us-east-1, grouping by day and hour.

Step 3: You write a query that shows the ec2 resources (excluding ec2-instances) deployed on the precise hour in us-east-1. You see that 64 Blocks of 256 Public IP Addresses were allocated instead of the expected Single Block of 64 Public IP Addresses.

Step 4: You create a dashboard (e.g., in Grafana) that takes in a start date, an end date, and a bucket size, which shows a chart of costs grouped by category and a table of resources deployed and supports filtering by region and resource type.

Step 6: You send a report identifying the root cause of the issue, a link to the dashboard, and a readme so that the COO can access this information directly.

COO sees an increase in the costs, looks at the dashboard, and asks why there is a sudden increase in the allocated Elastic Block Storage in us-east-2 as this appears to be increasing costs drastically.

Step 1: You see a typo in the terraform, causing the allocation of 22 volumes per instance instead of the expected allocation of two per instance, and write a report.

Note: Even if your COO isn’t technical enough to read the dashboard, you can, so in any case, you have still reduced the time-to-response from a few hours to less than 10 minutes.

Cloud Asset Inventories are a core part of any Cloud Asset Management strategy, making it easier to query your cloud estate and reconcile intended changes with the deployed estate. This reduces Time-To-Respond and Time-To-Fix for infrastructure deployment issues, as well as helping you to keep a handle on your cloud costs.

A Cloud Asset Inventory is also a key part of a good Cloud Security Posture Management strategy, but this is a whole subject on its own - so let’s leave that for a future post.

Want to find out more? We have tutorials (like this one Create a Multi-Cloud Dashboard using CloudQuery and Grafana) that can take you from Zero-to-Deployed in under 20 minutes.

Share your horror stories that a Cloud Asset Inventory could have prevented on social media!