Cloud Cost Assessment: What It Covers and What You Should Receive

A cloud cost assessment should end in a ranked list of changes you can make, each with its saving, its risk, its effort and a named owner. It reads your billing data and your architecture together, because the bill shows what you pay for and only the architecture explains why. If the output is a set of charts and general advice, you have bought a report, not an assessment.

What a cloud cost assessment is

An assessment is a bounded piece of work with a start, a scope and a set of deliverables. It is not a tool subscription and it is not a permanent role. The person doing it looks at three things in order: where the money goes, whether that spend matches real use, and what it would take to change it safely.

It differs from the preventive controls described in cloud cost optimization guardrails for data platforms. Guardrails stop spend from drifting. An assessment finds the drift that has already happened, and the guardrails are one of its outputs.

What the assessor needs from you

The quality of the findings depends on the inputs. Before the work starts, expect to provide:

1. Billing exports at line-item level, with resource identifiers, for a period long enough to show a full business cycle. A monthly invoice total is not enough.
2. A list of accounts, subscriptions or projects in scope, and who owns each.
3. Usage data: utilisation metrics for compute, databases and storage, and query history for any warehouse.
4. An architecture description, even a rough one, and the names of the workloads that are critical.
5. Existing commitments: reserved capacity, savings plans or committed use discounts, and when each ends.
6. Your tagging or labelling scheme, if one exists, and how well it is applied.

Access should be read-only. If an assessor asks for write access on day one, ask why.

What the analysis should cover

A thorough assessment works through the same set of questions on every provider. The table shows what to look for and what each check produces.

| Area | What the assessor checks | What you should get | | --- | --- | --- | | Idle resources | Stopped but billed disks, unattached addresses, forgotten environments, unused load balancers | A list of resources with owner and last-use evidence | | Oversized resources | Instances and databases whose peak use sits far below their size | A right-sizing proposal per workload with the risk noted | | Scheduling | Development and staging running overnight and at weekends | Which environments can scale to zero, and when | | Commitments | Share of steady usage covered by reserved capacity, savings plans or committed use | A coverage figure and a plan sized to measured use | | Storage | Data in the wrong tier, missing lifecycle rules, old snapshots and logs | Retention and tiering rules per bucket or volume | | Data transfer | Traffic between regions, zones and out to the internet | The flows that cost most and whether they can be moved or cached | | Managed services | Warehouses, clusters and serverless jobs that run more often than the business needs | A freshness tier for each pipeline | | Allocation | Share of spend that carries a usable tag or label | A tagging plan and a figure for unallocated spend |

Two of these deserve a closer look because they are where assessments most often go wrong.

Commitments

Commitment discounts reduce cost only when they cover usage that stays. Buying them before right-sizing locks in the waste. A sound assessment sizes commitments to the baseline that remains after the other changes, uses measured usage and not a forecast, and says what happens if a workload moves or shrinks. The names differ by provider (savings plans and reserved instances on AWS, committed use discounts on Google Cloud, reservations on Azure), but the logic is the same.

Unit cost

A total bill rising is not a problem by itself if the business grew with it. What matters is cost per unit of value: per customer, per pipeline run, per thousand requests, per report. Ask the assessor to express at least one product or workload this way.

Frequency is a good example. One of our pipelines, the real-time electricity market pipeline, reads like this in its case study: "A new AEMO dispatch report ingested every 5 minutes across 5 market regions". A schedule that tight is justified by the source, which publishes on that cadence. The same schedule on a source that changes daily would be a cost with no benefit, and the cost per run is what shows it. For the trade-off between freshness and effort, see choosing batch vs streaming for modern data pipelines.

What you should receive at the end

Ask for these deliverables in writing before the work starts.

1. A ranked findings list. Each finding has its estimated saving, the risk of making the change, the effort, the owner on your side and the evidence in your billing data.
2. A baseline. The spend per workload or team at the start, so a later saving can be measured against something.
3. A commitment plan, sized to measured steady usage, or a clear statement that you are not ready for one.
4. A tagging plan, with the required keys, who applies them and how untagged spend is reported.
5. Guardrails: budgets and anomaly alerts routed to the team that can act, and rules for new workloads.
6. A sequence. Which changes come first because they are safe and quick, and which need design or testing.
7. A review rhythm, so the list is revisited and the bill does not drift back.

A fixed scope with fixed deliverables is a good sign. So is a quote that is not tied to a share of your savings, because a percentage fee rewards the assessor for recommending cuts, not for recommending the right ones.

How to judge the findings

Findings fall apart in predictable ways. Check each one against four tests:

1. Is it traceable? You should be able to find the line items in your own export.
2. Is the assumption written down? "Move to a smaller instance" needs the utilisation figures that support it.
3. Is the risk named? A saving with no risk noted has not been thought through. Some changes affect latency, failover or a nightly job.
4. Does it have an owner? A finding nobody owns is a note, not a task.

Also ask what the assessor chose not to recommend and why. A short list of rejected options shows that the reasoning was applied, not assumed.

Questions to ask a consultant

• Which inputs do you need, and what access, exactly?
• How do you separate waste from capacity we need for peaks or failover?
• How do you size commitments, and what happens if we change architecture?
• Will you show every saving against our own billing lines?
• How do you treat shared costs and untagged spend?
• What do we receive at the end, and in what format?
• Who makes the changes, and do they go through our code review?
• What stops the bill drifting back after you leave?

Answers that are specific to your stack are a good sign. Answers that could apply to any customer are not.

Red flags

• The savings figure arrives before the access does. A number promised before anyone has seen your data is a sales number.
• Only the invoice is reviewed. Without architecture and utilisation data, the findings stay at "spend is high".
• Commitments are the first recommendation. That usually means the easy discount is being offered ahead of the harder work.
• No mention of risk. Every change has some.
• Fees tied to savings. The incentive points at cutting, not at fit.
• A tool the vendor runs and you cannot. If you cannot repeat the analysis next quarter, the capability stays with them.
• No handover of guardrails. Savings that are not protected tend to return.

When an assessment is enough

If you run one or two platforms and the bill drifts slowly, an assessment, the guardrails it sets and a short regular review are often all you need. If many teams launch workloads weekly and nobody owns allocation, you may need continuing FinOps effort. For a multi-cloud case, the data side matters: multi-cloud FinOps with a FOCUS data pipeline shows how billing exports from several providers become one model you can allocate from.

Our cloud architecture and cost optimization service starts with this kind of review and ends with a ranked list of changes and the controls to keep them.