Free · AWS cost review

Make more of your AWS spend.Read-only. Ranked. Yours to keep.

Read-only analysis of your agreed AWS scope. Each savings opportunity comes with its effort and risk, so you choose what to change.

Read-only access · No changes to your account
What you get

Spend, explained. Changes, ranked.

Read-only access. No changes made to your account. Estimates are not guaranteed savings.

01 /
Spend analysis

Usage and cost patterns in the agreed scope.

02 /
A ranked savings plan

Estimated opportunities, effort and risks.

03 /
An engineer walkthrough

Make sense of the recommendations together.

An illustrative AWS savings plan
Example opportunities; actual savings depend on usage and approved changes.
The service in practice

Understand the bill. Choose the change.

A free review of agreed AWS spend and usage, with opportunities explained in terms of evidence, estimated impact, effort and risk. You keep the plan and decide whether any implementation goes ahead.

AGREE

Define the review boundary

Confirm the account or workload, available billing information and a technical owner. Discuss known changes in demand and any commitments or constraints that affect interpretation.

ACCESS

Set up read-only visibility

Agree the billing, usage and configuration information needed. Your team controls access and can revoke it after the review. No changes are made to the environment.

ANALYSE

Connect cost to use

Review the agreed data and identify candidates for improvement. Separate observed facts, estimates and the assumptions that need a conversation with the workload owner.

DECIDE

Walk through the findings

Discuss the ranked plan and the checks needed before implementation. A typical review is planned over about a week, subject to access, data availability and engineering capacity.

Scope & capability

Follow spend back to the workload.

A lower line item is only useful if the workload can still do its job. We look for the relationship between resource use, service requirements and ownership before recommending changes. These are example areas to investigate, not promises of savings.

COMPUTE

Match capacity to real demand.

Review available utilisation and workload patterns before discussing resource sizing or architecture changes. Consider peaks, memory, throughput and recovery needs alongside average demand. Record what needs validation before a smaller resource or different configuration is safe.

COMMITMENTS

Understand the obligation.

Review existing commitments and eligible usage before discussing additional purchases. Stable demand, coverage, utilisation and future plans matter. A lower eligible rate should be considered alongside the risk of paying for a commitment the workload no longer needs.

STORAGE

Connect retention to a purpose.

Inspect storage ownership, access patterns and lifecycle requirements. Discuss storage classes, retention and backup needs with the responsible team. Include retrieval, access and transition implications in the decision rather than assuming every archived object is an immediate saving.

NETWORK

Explain the traffic path.

Review data transfer patterns and the services involved. Investigate routing and endpoint options where relevant, checking their own costs and operational implications. Any proposed change needs to preserve the availability and security boundaries the workload relies on.

IDLE RESOURCES

Check before removing.

Identify resources with little or no observed use and confirm their purpose. A quiet database, snapshot or volume may still have a recovery or retention role. Ownership and dependencies must be understood before recommending removal.

SCHEDULING

Separate working hours from always on.

Discuss whether non-production or intermittent workloads need to run continuously. Review start-up dependencies, automation and the people who rely on the environment. Scheduling opportunities depend on the workload tolerating the proposed availability window.

Illustrative opportunity record

Make each recommendation reviewable.

Each item follows the same four steps, from evidence to a decision. This is an illustrative structure; real findings depend on the agreed scope.

BASELINE

Observed spend & usage

Define the period, resources and information used for the analysis.

OPPORTUNITY

A proposed change

Explain the resource or configuration decision and why it may reduce spend.

TRADE-OFF

Effort, risk & dependency

Record validation work, reliability considerations and any new obligation.

DECISION

Owner & next step

Identify who can approve the change and what evidence is needed before implementation.

Illustrative structure, not customer findings or a completed engagement.

What you take away

Deliverables your team can work with.

Your team keeps the baseline, the ranked plan and the context to decide what happens next.

BASELINE

A view of the agreed spend

Understand the services, resources and usage patterns included in the review. The analysis records its scope and available evidence so the conclusions can be interpreted in context.

OPPORTUNITIES

A prioritised improvement list

Receive recommendations with the reasoning, estimated opportunity where supportable and the assumptions behind it. Unknowns and validation needs remain visible rather than being hidden in a headline percentage.

TRADE-OFFS

Effort and risk alongside the estimate

Discuss implementation effort, dependencies, commitment exposure and service impact. The plan helps distinguish a candidate for investigation from a change your team is ready to approve.

WALKTHROUGH

An engineer to discuss the plan

Work through the findings and choose the next step. Your team can implement internally or request a separate quote. The review does not require you to purchase implementation services.

The important detail

An estimate needs a baseline.

Spend can change because of usage, pricing arrangements, architecture or business demand. The review explains its assumptions so an estimated opportunity is not mistaken for a guaranteed result.

Use a representative period

Discuss whether the available period reflects normal operation, a seasonal peak or a temporary event. Recent migrations and changes in customer demand can make a short period misleading.

Account for the consequences

Include relevant operating constraints, commitments and dependencies in the recommendation. A cost change that creates recovery work or a new obligation needs to be understood before approval.

Validate after implementation

If your team proceeds, define how to compare the result with the baseline and check service behaviour. Realised savings depend on approved changes and subsequent usage; they cannot be guaranteed by the review.

Preparing for the engagement

Know who owns the spend.

The review is most useful when billing visibility and workload context come together. Bring someone who understands the resources and can explain the business or technical reasons behind them.

Relevant information

Agree access to billing, usage and supporting configuration for the selected scope. Share known commitments, planned migrations and material changes in demand.

Operational context

Identify resources with recovery, retention or regulatory requirements. Explain maintenance windows, performance constraints and services that must remain available.

A clear commercial boundary

tMinus1 funds the free review. Availability is confirmed when you enquire. Implementation is separate and optional, with scope and price agreed before any changes are made.

AI runs on infrastructure

AI workloads add new lines to the bill.

Model calls, GPU instances and vector stores sit beside the compute, storage and data transfer you already pay for. The method stays the same: connect each line to its workload and its owner before anything changes.

See AI delivery
Engineering experience

Built by a team that operates software.

tMinus1 built Automatum, a multi-tenant platform with marketplace integrations and metered billing. That platform work informs how we approach identity, integration, deployment and operational ownership.

Platform engineering experience. The case study is not a claimed result from this service.

PLATFORM CASE STUDYAutomatumExplore the engineering and operations ↗
Further reading

Explore the engineering behind the service.

Understanding review limitations

The review uses the agreed billing, usage and configuration information. Incomplete history or missing ownership can limit an estimate. We record assumptions and the checks needed before a recommendation becomes an approved change.

Implementation, commitment purchases and resource removal require a separate decision by your team. Savings depend on the changes made and future usage.

Useful answers

Before we start.

Discuss anything specific to your team or environment.

What is the catch?

We spend an hour or two in your account and learn whether we could be useful to each other. If the findings turn up implementation work you want done, we will quote it. If not, you keep everything and we part on good terms. No fee, no follow-up sequence.

What does read-only access mean exactly?

You create an IAM role with read-only permissions on billing, Cost Explorer, and resource metadata. We cannot create, modify or delete anything. No agents are installed. We agree what billing, resource metadata and findings information is needed before starting; application records are outside the review scope. You revoke the role when the review is done.

We already have a Savings Plan. Will this still find anything?

Often, yes. Savings Plans cover eligible compute spend, but they do not address idle resources, storage classes, data transfer patterns or NAT gateway use. The review looks at those areas too, and it tells you plainly if it finds little to change.

Who needs to be on the walkthrough call?

Your technical lead and whoever owns the AWS budget. The findings are specific enough that the budget owner can act on them without translating the technical side. Sixty minutes is typically enough.

Who sees the findings?

You and us. We do not publish your account data, we do not use your name in marketing without written permission, and we will sign your NDA before we start if you need one.

Can you review multiple accounts or a full AWS organisation?

The free review covers one account. Pick the one with the highest spend. A full-organisation review is real work and we quote it as such.

The next step

Request your free cost review.

We’ll confirm fit and arrange the review. Implementation is separate and optional.

Request your free cost review
Free AWS Cost Review — we find the waste, you keep the findings
Request your free cost review