How to Audit Cloud Spend When You Inherit a New Environment

Auditing cloud spend in an inherited environment means working out what you’re paying for, who owns it, and what you can safely remove, all without a baseline to compare against. That missing baseline is the hard part. In the infrastructure you built, you know why every resource exists. In the infrastructure you inherit, every line item is a question: what does this do, why was this pricing plan chosen, and is anything still depending on it?

Guessing is expensive in both directions. Keep everything, and you pay for waste indefinitely. Delete the wrong thing, and you could remove a service nobody documented.

This article gives you a repeatable process for auditing cloud spend in an inherited AWS, Azure, or Google Cloud environment, from reading the first invoice to setting the guardrails that keep the waste from coming back.

Auditing the costs of newly inherited environments has three main stages:

1. Data gathering: Collecting bills, resource utilization data, and details of historical budget overruns in order to quantify the environment’s cost
2. Cost of ownership analysis: Assessing the collected data to determine what’s normal and what future costs will look like through the environment’s remaining life
3. Monitoring, governance, and optimization: Implementation of new cost control systems to align the environment with existing infrastructure standards

Critically, the emphasis must be on gathering real data and understanding the bigger picture at each stage. It’s important not to make assumptions until you’ve researched each cost center’s background. For instance, a seemingly expensive service could in fact be the most cost-effective long-term option when compared with cheaper but less powerful alternatives.

Ready to uncover the silent costs in your inherited environments? Here are the key steps that’ll take you from a blank page to a clear understanding of what you’re spending:

1. Analyze existing billing data

Recent bills are the natural starting point for auditing spending. Use cloud provider invoices and cost monitoring dashboards to check the high-level details of what you’re being billed for. Compare how bills change over different time periods, such as the past three months or six months, to determine whether costs are generally constant or if there are unexpected spikes that need investigating.

This exercise won’t be exhaustive; it just sets the direction for what comes next. Consider leaning on FinOps tools or AI solutions to produce a standardized view of all your bills across providers, billing periods, and different service types. Once you can clearly see which billable infrastructure resources and services you’re using, you can begin deeper analysis of how they’re used and whether they’re really required.

2. Establish what’s actually running in the environment

Now it’s time to drill down to more granular data. Leverage available observability tools and cloud consoles, plus any relevant IaC config files, to discover what’s actually in the environment. At the same time, correlate usage statistics to check whether resources are needed, then scour deployment pipelines to find which projects provision each component.

Equipped with this data, you can begin matching the resources you’ve discovered to the line items on your bills. This will shine a clearer light on services you’re being billed for that might not be fully utilized in the environment. You’ll also start to recognize components that are running up disproportionately high bills compared to their neighbors.

This stage does depend on observability solutions already being implemented in the environment. If that’s not the case yet, your first priority should be introducing an infrastructure management platform so you can gain clear visibility into what you’ve just inherited.

3. Audit tags and track spending back to owners

A bill tells you what you spent, butit doesn’t tell you who spent it. Tags are the bridge between those two facts, and in an inherited environment that bridge is usually half built. Some resources could be tagged to a team that reorganized two years ago, some may be tagged by an unrecorded convention, and many are not tagged at all. Before you can hand any of this spend to a budget owner, you need an honest picture of how good the existing tagging actually is.

Auditing the current tagging system

By this stage you should have a good overview of what you’re being billed for and what’s deployed. Now check how much of that spend actually carries a tag, which keys are in use, and where the same idea shows up under two different names. Sort the untagged resources by cost rather than by count because a few expensive ones matter more than a long tail of cheap ones.

Using tags to attribute cost to resources and teams

Utilize your billing data, workload details, and resource metadata such as team ownership and IaC source repository to tag each piece of infrastructure with the business purpose it fulfills. Record the evidence that supports each attribution decision so future audits can easily verify why certain tags were applied.

One mechanical detail catches teams out on AWS: A tag does nothing for your bill until you activate that tag key for cost allocation in the Billing and Cost Management console, and activation isn’t retroactive, so earlier spend stays in the untagged bucket. In an inherited environment, that erases the history you most want to read.

Use the Backfill tags option on the same page and AWS applies your active tag keys to as much as 12 months of prior cost data, provided the resource carried the tag at the time. You need to be in the management account, the start month is the earliest thing you can pick, and you get one request a day.

By the end of this process, you should be able to precisely apportion the environment’s costs across individual teams and business areas. Start bringing in other stakeholders, such as team leaders and business execs, to analyze the data and investigate any anomalies it reveals.

4. Check for drift between IaC and reality

The IaC repository you inherited describes what someone intended to deploy, whereas the bill describes what actually exists. The gap between them is where unexplained spend hides.

Drift and unmanaged infrastructure are two problems that cost you differently. Drift is a managed resource someone changed by hand, like an instance resized during an incident and never resized back. Unmanaged infrastructure exists in the account but appears nowhere in code, so no plan flags it and no review questions it. In an inherited environment, unmanaged infrastructure is usually the more expensive problem. Catch drift with a refresh-only plan across every workspace.

terraform plan -refresh-only -detailed-exitcode

Terraform returns 0 for an empty diff, 1 for an error, and 2 when changes are present, so you can script this across every stack and collect exit codes instead of reading plan output.

Catch the second by diffing a provider inventory, from AWS Config, Azure Resource Graph, or Google Cloud Asset Inventory, against terraform state list. Adopt whatever is worth keeping with an import block, and let terraform plan -generate-config-out=adopted.tf draft the configuration for you.

Then automate it. Spacelift’s drift detection executes proposed runs on a cron schedule you define, marks drifted resources in the Resources view, and optionally reconciles them.

5. Sweep for orphaned and unused resources

An orphan still bills but no longer serves anything. Nothing depends on it, and nothing in your monitoring complains when it disappears. Detached disks, unassociated IP addresses, stale snapshots and machine images, load balancers with no healthy targets, and empty App Service plans are the usual finds.

Check public IP addresses first because AWS has billed every public IPv4 address since February 2024 whether it’s attached to anything or not.

For everything else, start with the provider’s own detection.

• AWS: Cost Optimization Hub takes idle and rightsizing recommendations from Compute Optimizer and commitment recommendations from Cost Explorer, then deduplicates overlapping savings. Trusted Advisor now surfaces the same checks. Both the Hub and Compute Optimizer have to be opted into, which an inherited account usually hasn’t been.
• Azure: The Cost tab in Azure Advisor flags unattached disks, empty App Service plans, underutilized virtual machines and scale sets, and reservations close to expiring.
• Google Cloud: Idle resource recommenders flag a persistent disk or IP address that’s spent 15 days unattached, and a custom image that’s gone that long unused. Idle VMs come from a separate recommender.

Treat the output as a candidate list. Snapshot anything holding data, tag it with a removal date and an owner, stop or detach it, then wait a full billing cycle before deleting. Anything silently load-bearing announces itself in that window, and you still have the snapshot.

6. Check utilization and right-sizing

Based on the data gathered previously, you can now hone in on parts of the environment that may need further optimization. Starting first with the teams, business units, and resources that are accruing the highest regular spending, use your monitoring stack to compare actual resource utilization to what’s been provisioned.

Search for instances provisioned well above what they actually use, over-specified database tiers, and unnecessary inter-cloud data transfers. Resizing these can provide substantial savings without any negative effect on your services. However, you should still hold off changing suspect resources until you’re sure of their original purpose.

For example, apparently underutilized instances could in fact be silent standbys that feature in the inherited environment’s disaster recovery plan.

7. Audit pricing commitments and subscriptions

Not all costs can be changed immediately. For this reason, you should create a register of reserved instances, savings plans, prepaid subscriptions, and other long-term commitments associated with the environment. Not only will this inform you of the contractual obligations you’ve inherited, but it’ll also serve as a reminder to review each service when it does come up for renewal.

Tracking down this information isn’t always straightforward, so make sure to thoroughly cross-reference billing portals and procurement records against the regular payments leaving your accounts. Don’t assume that payments will stay fixed throughout a commitment’s full term; check the contract to confirm whether fees will increase each year.

You may be better off paying the early cancellation penalties in order to migrate a service straight onto your existing infrastructure.

8. Consolidate your findings and prioritize optimizations

Simply auditing the spend you’ve inherited isn’t likely to be useful on its own. Instead, you should seek to use the audit’s results to now apply targeted optimizations that properly align the environment with your existing operations.

This means connecting your favorite FinOps platforms, introducing standard resource tagging practices, and implementing cost governance controls that will allow you to enforce your budgets going forward.

Any cost differences associated with the inherited environment should gradually diminish over time. Prioritize changes that will reduce total cost of ownership without disrupting critical workloads, then repeat your audit to assess the results of each adjustment.

Regularly cycling through data-based cost discovery, attribution, analysis, and optimization tasks is the best way to keep your cloud operations affordable. This applies to both carefully managed environments and inherited unknowns.

The waste you just cleaned up got there because nobody saw the cost of a change until the invoice arrived weeks later. Move that signal into the pull request and the economics change because the person who can fix an expensive change most cheaply is the person writing it, at the moment they write it.

Spacelift runs Infracost during the planning and applying phases of a run. To turn it on for a stack, add the infracost label and set an INFRACOST_API_KEY environment variable. Put that key in a context and attach the context to every stack that needs it, rather than copying the key from stack to stack.

Once it’s enabled, Spacelift posts a cost summary straight to your pull requests, so reviewers see the monthly delta next to the diff. The full breakdown also reaches your plan policies as JSON under third_party_metadata.infracost, which is where estimation becomes enforcement. A policy can block a change that pushes a stack past a budget:

package spacelift

deny[sprintf("monthly cost $%.2f exceeds the $%d limit", [monthly, limit])] {
  limit := 500
  monthly := to_number(input.third_party_metadata.infracost.projects[0].breakdown.totalMonthlyCost)
  monthly > limit
}

The same input carries pastBreakdown, so you can warn on percentage increases instead of absolute totals, which tends to work better on stacks that are already large.

Two environment variables are worth knowing: INFRACOST_CLI_ARGS appends arguments to the breakdown command, which is how you point Infracost at a usage file so metered services get priced against your real consumption instead of defaults. INFRACOST_WARN_ON_FAILURE, set to true, downgrades Infracost errors to warnings instead of failing the run, which matters while you roll this out across stacks you don’t fully understand yet.

Cost data also feeds the Spacelift Resources view, so you can see what each resource contributes rather than only a stack total. In an inherited environment, that view is the fastest answer to which of these things is actually expensive.

Estimates stay estimates. Infracost prices the resource, not your traffic, so data transfer and request-based charges still need watching in your billing data. The goal here is direction and magnitude before merge, not a forecast to the cent.

Beyond the key tasks explained above, keeping the following best practices in mind will help you quickly get to grips with inherited spending:

1. Start with the basics: Carefully reading existing bills and using tools like AWS Cost Explorer can guide you straight towards potential problem areas, enabling you to quickly pick the low-hanging fruit.
2. Don’t forget external and third-party costs: The resources within an environment don’t always tell the full story of its cost. It’s vital to also check whether components depend on paid external services, such as third-party SaaS subscriptions.
3. Analyze historical spending as well as the current situation: Looking only at recent spending data can misdirect. Instead, aim to also assess historical costs over extended time periods, such as 90 days, 1 year, or 3 years. This can help reveal otherwise hidden anomalies, such as a service that has only started accruing excess costs within the past few months.
4. Focus on grouping costs into specific cost centers: Tagging costs by service, team, and purpose makes it easier to analyze where your budget’s actually going. Once you’ve defined clear cost centers, you can align your analysis with your business priorities, instead of looking at raw resource costs individually.
5. Inquire why individual costs are valued: When you inherit an environment, try to talk to former engineers, infrastructure architects, and operators if you can. There could be important reasons why apparently expensive services were selected over cheaper alternatives, even when it looks like they’re not actually required.

The key thing to remember is that cloud cost auditing should be a periodic exercise. The costs of inherited environments may change drastically as you integrate them with your existing infrastructure. Even once they’re fully integrated, new unknowns could still appear as users provision additional services and configuration drift occurs. Regularly apply the techniques we’ve discussed across your entire cloud infrastructure to stay ahead of unexpected budget breaches.

A platform like Spacelift can help your organization manage cloud infrastructure more efficiently.
Spacelift is the infrastructure orchestration platform built for the AI-accelerated software era. It manages the full lifecycle for both traditional infrastructure as code and AI-provisioned infrastructure, supporting tools like OpenTofu, Terraform, Ansible, Pulumi, Kubernetes, and CloudFormation.

Security is one of Spacelift’s top priorities, with features such as policy as code, encryption, Single Sign-On (SSO), MFA, and private worker pools built into the product. Spacelift is SOC 2 Type II audited and provides compliance and security artifacts, including GDPR resources and its DPA, through the Spacelift Trust Center.

It is also the first IaC orchestration platform to receive FedRAMP authorization, delivering flexible, policy-driven automation to federal agencies and contractors seeking secure, compliant infrastructure workflows.
The power of Spacelift lies in its fully automated approach. Once you’ve created a Spacelift stack for your project, changes to the infrastructure as code files in your repository are automatically applied to your infrastructure.

For non-critical workloads like tests, POCs, and demos, Spacelift Intelligence adds an AI-powered layer that enables natural language provisioning, diagnostics, and operational insight, so developers can request infrastructure without writing configuration code while platform teams retain full governance and visibility.

Spacelift’s pull request integrations keep everyone informed of what will change by displaying which resources are going to be affected by new merges. Spacelift also allows you to enforce policies and automated compliance checks that prevent dangerous oversights from occurring.

Spacelift includes drift detection capabilities that periodically check your infrastructure for discrepancies compared to your repository’s state. It can then launch reconciliation jobs to restore the correct state, ensuring your infrastructure operates predictably and reliably.

With Spacelift, you get:

• Policies to control what kind of resources engineers can create, what parameters they can have, how many approvals you need for a run, what kind of task you execute, what happens when a pull request is open, and where to send your notifications
• Stack dependencies to build multi-infrastructure automation workflows with dependencies, having the ability to build a workflow that, for example, generates your EC2 instances using Terraform and combines it with Ansible to configure them
• Self-service infrastructure via Blueprints and Templates, enabling your developers to do what matters — developing application code while not sacrificing control
• Creature comforts such as contexts (reusable containers for your environment variables, files, and hooks), and the ability to run arbitrary code
• Drift detection and optional remediation

If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.

Auditing cloud spend within inherited environments is best handled using a data-first strategy. Being made responsible for environments without known cost baselines can feel overwhelming, but you’ll be able to take control if you systematically analyze billing data, infrastructure inventories, service ownership, and existing pricing commitments.

Once you’ve established what’s running and why it’s needed, you can then use the data you’ve collected to begin making optimizations. Rightsize instances, port services over to your existing platforms, and eliminate subscriptions that you no longer need. To avoid making misplaced assumptions about where your budget’s actually going, these tasks mustn’t begin until you fully understand the environment’s cost landscape.