What's Actually Running in Your Cloud? A Practical Audit Guide for Enterprises With a Billing Problem

At some point in the lifecycle of most enterprise cloud environments, a finance leader looks at the monthly invoice and asks a deceptively simple question: what exactly are we paying for? The IT team produces a list of known workloads. The list does not reconcile with the bill. The difference—sometimes modest, sometimes alarming—represents the shadow stack: the collection of resources that are consuming capacity and generating costs without appearing in any active operational inventory.

This is not a niche problem. Research from multiple cloud cost management firms consistently estimates that enterprise organizations waste between 30 and 35 percent of their total cloud spend on unused or underutilized resources. For large US enterprises with annual cloud budgets in the tens of millions, that figure translates to a material and recoverable expense.

The following guide provides a structured approach to identifying, quantifying, and reconciling the gap between what your organization believes it is running and what your cloud providers are actually billing.

Step 1: Establish a Baseline Inventory Across All Accounts and Regions

Before any meaningful audit can begin, the enterprise must have a complete picture of its cloud footprint—every account, every region, every service category. In practice, this is more difficult than it sounds. Large organizations frequently have dozens of AWS accounts, Azure subscriptions, or GCP projects distributed across business units, subsidiaries, and development teams. Many of these were provisioned independently, with limited coordination at the organizational level.

Begin by aggregating billing data across all accounts into a single view. AWS Cost Explorer, Azure Cost Management, and GCP Billing Reports each provide native tools for this purpose. Third-party platforms—including CloudHealth, Apptio Cloudability, and Flexera—offer cross-cloud consolidation for multi-provider environments.

The output of this step should be a complete list of active accounts and their associated monthly spend, segmented by service category and region. Accounts generating spend that no one in the organization can immediately attribute to a known workload are the first candidates for deeper investigation.

Step 2: Identify Orphaned and Idle Resources

Orphaned resources are cloud assets that continue to consume capacity after their associated workload or project has concluded. They are created intentionally and abandoned unintentionally—the byproduct of projects that end without a formal decommissioning process.

The most common categories of orphaned resources in enterprise environments include:

• Unattached storage volumes: Elastic Block Store (EBS) volumes in AWS, managed disks in Azure, and persistent disks in GCP that were associated with compute instances since terminated. These volumes continue to incur storage charges indefinitely.

• Idle compute instances: Virtual machines running at near-zero CPU utilization. These are often development or testing instances that were never shut down after their intended use concluded.

• Orphaned database instances: RDS instances, Azure SQL databases, and Cloud SQL instances that are no longer connected to any application but remain in a running state, accruing both compute and storage charges.

• Unused load balancers and elastic IP addresses: Network resources that were provisioned for specific applications and never decommissioned after those applications were retired.

• Stale snapshots: Point-in-time backups that accumulate over time without a defined retention policy, generating persistent storage costs with diminishing recovery value.

Cloud provider native tools—AWS Trusted Advisor, Azure Advisor, and GCP Recommender—identify many of these resources automatically and should be the first stop in any audit process. Their recommendations are not exhaustive, but they provide a practical starting point.

Step 3: Audit Forgotten Test and Development Environments

Test and development environments represent a disproportionate share of shadow stack costs in enterprise cloud settings. They are provisioned rapidly, often with minimal governance oversight, and decommissioned inconsistently. In many organizations, the responsibility for cleaning up development environments is diffuse—it belongs to everyone in principle and no one in practice.

Conduct a systematic review of all environments tagged or named with development, staging, test, QA, or sandbox designations. For each environment, verify:

• The last date of meaningful activity (deployment, data write, or authenticated access)
• Whether the project or initiative it supports is still active
• Whether the environment has an assigned owner who is still with the organization

Environments that fail these checks should be flagged for decommissioning, subject to a brief confirmation period that allows project teams to object if the environment is still needed. In most audits, a significant percentage of flagged environments are decommissioned without objection—their owners had already moved on.

Step 4: Evaluate Resource Tagging Consistency

Resource tagging is the foundational mechanism for attributing cloud spend to business units, projects, cost centers, and applications. When tagging is inconsistent, incomplete, or entirely absent, cost attribution breaks down—and the shadow stack grows, because untagged resources cannot be assigned to an owner who is accountable for their continued operation.

Audit your current tagging posture by querying for resources that lack required tags. Most organizations define a standard tag taxonomy that includes fields such as environment, owner, project, cost center, and application. Resources missing any of these fields represent attribution gaps.

For each untagged resource, the remediation process involves two steps: applying the correct tags based on available context (account structure, naming conventions, deployment history) and assigning ownership to a named individual or team who is responsible for the resource going forward. Without that ownership assignment, the same resource is likely to reappear in the next audit cycle.

Step 5: Right-Size Actively Running Workloads

Not all waste in the cloud bill is attributable to forgotten or abandoned resources. A meaningful portion comes from active workloads running on oversized instance types or storage tiers selected during initial provisioning and never revisited.

Cloud providers publish rightsizing recommendations based on observed utilization patterns. An m5.2xlarge EC2 instance running consistently at 15 percent CPU utilization is a candidate for downsizing to an m5.large—a change that may reduce that instance's cost by 75 percent with no impact on application performance.

Rightsizing reviews should be conducted on a quarterly basis for compute, database, and memory-optimized workloads. Establish a baseline utilization threshold—commonly 40 percent average CPU utilization over a 30-day window—below which instances are reviewed for downsizing or consolidation.

Step 6: Institutionalize the Audit as a Recurring Process

A one-time cloud audit is valuable. A recurring cloud audit program is transformative. The shadow stack problem is not solved by a single remediation exercise—it is managed through continuous inventory discipline.

Establish a quarterly cloud inventory review as a standing operational process, with defined ownership at the team level and executive visibility into the outcomes. Integrate tagging compliance and orphaned resource identification into the CI/CD pipeline so that governance requirements are enforced at the point of provisioning rather than discovered months later in an audit.

The organizations that close the gap between their cloud bill and their actual workloads—and keep it closed—are those that treat cloud inventory management as an ongoing operational discipline rather than a periodic cleanup exercise. The financial return on that discipline, measured in recovered spend and improved budget predictability, consistently justifies the investment.