Cloud Cost Audit: Where the Waste Usually Is, and the Order to Fix It

Direct answer: A cloud cost audit reviews your AWS, Azure or Google Cloud spend and produces a ranked list of specific changes, each with an estimated monthly saving, the effort and the risk. The waste is usually in six places: idle resources, oversized resources, missing or badly sized commitment discounts, storage and snapshots nobody cleans up, data transfer, and untagged spend that nobody owns. The order matters: right-size first, then buy commitments, or you lock in paying for capacity you were about to remove.

Why cloud bills grow faster than the product

Almost no cloud waste is a single bad decision. It accumulates from reasonable ones. An engineer sizes a database for a launch that never got that busy. A load test leaves a cluster running. A migration copies data into a new bucket and nobody deletes the old one. A logging default keeps everything forever. Each one is small. Together, a year later, they are a line on the board deck.

The reason it persists is ownership. The finance team sees the invoice but cannot tell which resource is which. Engineering knows the resources but never sees the invoice. Nobody's job is the space in between, which is exactly what an audit fills.

1. Idle resources

Resources that run and do nothing. The common ones:

• Development and staging environments running nights and weekends when nobody uses them.
• Instances, containers or clusters left over from tests, demos or departed engineers.
• Load balancers with no healthy targets behind them.
• Storage volumes no longer attached to anything, still billed every month.
• Public IP addresses held but unused. On AWS, public IPv4 addresses are now charged whether or not they are attached.
• Databases for features that were switched off.

Idle resources are the easiest saving and the riskiest to remove carelessly, because "nobody uses it" is sometimes wrong. A good audit identifies the owner before recommending deletion, and suggests stopping or snapshotting first, deleting later.

2. Oversized resources

Resources doing real work on far more capacity than the work needs. Look at actual CPU and memory use over a representative period, not at a single day. Typical findings:

• Instances sized for a peak that happens an hour a week, which could be smaller with autoscaling.
• Databases on large instance classes with low sustained use.
• Kubernetes nodes with low allocation because pod requests are inflated, so the cluster scales for capacity nobody consumes.
• Older instance generations where a newer one gives the same performance for less.
• Provisioned storage performance, such as IOPS, bought for a workload that no longer needs it.

Right-sizing carries production risk, so each recommendation should say how to test it and how to roll it back.

3. Commitments: savings plans and reservations

All three major clouds discount steady usage in exchange for a commitment: AWS Savings Plans and Reserved Instances, Azure reservations and savings plans, and Google Cloud committed use discounts. Terms are typically one or three years. The waste here runs both ways.

• No commitments at all. A company with years of steady baseline usage paying on-demand rates for all of it.
• Commitments bought before right-sizing. The discount is applied to capacity that should not exist, which turns a temporary waste into a contracted one.
• Commitments sized to a peak. Paying for committed capacity during troughs.
• Expired commitments nobody renewed, so the bill quietly went up.
• The wrong kind of commitment. A rigid reservation on an instance family the team is about to migrate away from.

The rule is to right-size, wait for usage to settle, then commit to the baseline you are confident of, leaving the variable part on demand. For a startup with uncertain growth, flexible commitments and shorter terms are often worth a smaller discount.

4. Storage, snapshots and logs

Storage is cheap per gigabyte and expensive in aggregate because it never shrinks on its own.

• Snapshots and machine images kept indefinitely, including for resources long deleted.
• Object storage with no lifecycle rules, so years of data sit in the most expensive tier.
• Old-generation volume types where a newer type costs less for the same performance.
• Backups duplicated across several tools that each keep their own copy.
• Log groups with no retention setting, which on several platforms means keep forever.
• Verbose application or debug logging left on in production, paid for at ingestion as well as storage.

One caution, because this is where cost and security meet. Some retention exists for a reason. Audit logs, backups and records you need for SOC 2, ISO 27001 or privacy law obligations should not be cut to save money. The fix is a written retention schedule that says what is kept, for how long and why, and lifecycle rules that enforce it.

5. Data transfer

Transfer charges are the least visible part of a cloud bill and often the most surprising. Common sources:

• Traffic leaving the cloud to the internet, especially serving large files without a content delivery network.
• Traffic between availability zones from chatty services split across zones without need.
• Traffic between regions from replication or services deployed in different regions by accident.
• NAT gateway processing charges for traffic to the cloud provider's own services that could use private endpoints instead.

Transfer findings often need an architecture change rather than a setting, so they rank lower on effort but can be large on saving.

6. Tagging and ownership

Untagged spend is not waste in itself. It is the reason waste survives. If a resource has no owner, environment or product tag, nobody can say whether it is needed, and nobody is accountable for its cost.

The audit should measure how much of the bill is untagged, propose a small tagging standard (owner, environment, product or cost centre), and identify how to enforce it at creation rather than by cleaning up afterwards. A readable bill is the change that keeps the other savings from growing back.

What not to cut

Some line items look like waste and are not. Before anything is removed, check it against what you are obliged to run:

• Security monitoring and logging that your SOC 2 or ISO 27001 controls rely on. Turning off a detection service saves money until the auditor samples the period it was off.
• Backups and their copies in a second region or account. A restore you cannot perform is the most expensive saving there is.
• Standby capacity that your continuity plan or customer commitments depend on. Idle by design is not idle by accident.
• Non-production environments that hold the only realistic test data for a release process your auditors have already reviewed.

The answer is rarely to keep everything at full price. It is usually a cheaper tier, a shorter retention with an archive, or a schedule, decided by someone who knows why the resource exists.

What a useful report looks like

• A baseline of spend by service, environment and team.
• Each change described specifically enough to act on, with the resource it applies to.
• An estimated monthly saving per change, calculated after the changes before it, so savings are not counted twice.
• Effort and production risk for each change, with how to test it first.
• The order to do them in, usually idle, then right-sizing, then storage and transfer, then commitments.

Access and security

A cost audit needs read-only access to billing and cost reports and to resource configuration. It never needs write access. Grant it through a dedicated role you can remove afterwards, not through a personal login.

Because the same read-only access shows how resources are configured, a cost audit and a cloud security review pair naturally. Public storage, unused admin credentials and unencrypted volumes tend to turn up in the same corners as forgotten spend.

Our cloud cost audit is from $2,500 per cloud account. If you are preparing for a raise, cloud cost against revenue is a question investors ask, which is why we cover it in technical due diligence too. Before any audit, you can rough out where your spend should be with the cloud cost estimator.

Frequently asked questions

Can the cloud provider's own recommendations do this?

They are a useful input and free. They do not know which resources matter to the business, which environments can be stopped, or what retention you are obliged to keep. The judgement in the middle is what an audit adds.

Should we buy savings plans or reservations now?

Right-size first. Commit only to the baseline you are confident will remain after the cleanup, and leave growth on demand until it settles.

Will cost cuts weaken our security or compliance?

They can if logs, backups or monitoring are cut without checking what you are obliged to keep. Each recommendation should be checked against your retention schedule and audit obligations before it is made.

How often should we do this?

Once properly, then a light review each year or after any major architecture change. Tagging and ownership keep the gap between reviews small.