AWS cost optimisation and reliability

AWS cost optimisation is the work of reducing the cost of a workload while still meeting its performance, security and availability requirements. Start with the bill, the resource owner and the business outcome. An idle-looking resource is a candidate for investigation, not automatic permission to delete it.

For an IT leader, the useful result is a lower and more predictable cost per order, customer or other relevant unit of work. A lower total bill caused by fewer customers is not an efficiency improvement. Neither is a saving that shifts an unacceptable outage risk onto the business.

AWS's Cost Optimization Pillar puts cost alongside functional requirements. The sequence below applies that principle to a review you can run with finance and engineering. It does not promise a percentage saving before the estate has been assessed.

Build a baseline that finance can reconcile

Choose a representative period and separate recurring consumption from credits, taxes, refunds and one-off charges. Record the currency and the billing basis you use. Commitments and upfront payments can make a single month's cash bill misleading.

Group spend by account, service, region and environment. Then investigate the largest changes. Cost allocation tags can help assign spend to teams and projects, but tagging coverage and activation matter. Keep unallocated costs visible rather than forcing them into a convenient category.

For important workloads, record both cost and activity. A shop might use cost per completed order; a reporting service might use cost per successful job. Keep the calculation stable so changes remain comparable.

The FinOps guide covers ongoing ownership. For this review, name one technical owner and one finance owner who can agree what counts as a realised saving.

Inspect unused resources before changing them

Review unattached volumes, old snapshots, inactive load balancers, unused addresses and test environments. An unattached volume may contain the only recoverable copy of data. An apparently idle service may run a monthly or seasonal process.

For each candidate, ask:

• Who owns it and which service depends on it?
• What evidence shows it is no longer needed?
• Does retention, legal hold or recovery policy require it?
• Is there a tested recovery route if the decision is wrong?
• What approval and change window are appropriate?

Create a removal list with evidence and dates. Where possible, first stop or isolate a resource through a reversible step. Do not delete snapshots by age alone or remove redundancy because CPU use looks low.

Schedule non-production around actual demand

Development and test systems are candidates for scheduling when their users and automated processes do not need continuous access. Include overnight builds, overseas teams, integrations and maintenance jobs in the decision.

Here is a hypothetical calculation, using deliberately simple assumptions:

That is about 70% of this example's instance running hours, not 70% of its entire environment bill. Storage, backups, networking, licences and other resources may continue to cost money. Database stopping limits and automatic restart behaviour also depend on the service.

Test start-up time, dependencies and failure notification. Give users a documented way to request an exception. Review the schedule when the team's working pattern changes.

Right-size against representative performance

Review recommendations from AWS tooling together with workload telemetry. CPU alone is insufficient. Memory, storage latency, throughput, network limits, burst credits and peak concurrency can determine the right size.

Use a period that includes business peaks. Test the candidate in a representative non-production environment, then make a controlled production change with monitoring and rollback. Record the before-and-after configuration and compare error rate and response time as well as cost.

Database changes need particular care. Reducing capacity or changing availability configuration are different decisions. Removing a standby may reduce cost while weakening recovery capability. Obtain the service owner's acceptance of that trade-off rather than presenting it as a harmless sizing adjustment.

A recommendation is an input to a decision, not a guarantee that a smaller resource will perform equally well.

Buy commitments after understanding the baseline

Savings Plans and Reserved Instances can reduce eligible usage charges in exchange for commitments. Their coverage, flexibility and discounts depend on the product and terms. Review the exact offer for the relevant service, region and workload rather than relying on a headline percentage.

First remove avoidable usage and right-size. Then estimate the demand you expect to retain through the commitment period. Model lower-demand and migration scenarios as well as your central forecast.

Suppose, hypothetically, a commitment costs £100 a week and eligible usage falls to £60. The unused commitment is still a cost. A discount on the covered usage does not erase that exposure. Compare the full commitment with the likely alternative spend, including uncertainty.

Track utilisation and coverage separately. High coverage can coexist with an oversized commitment. Assign someone to review expiry and changes in demand, and treat a new commitment as a commercial decision requiring the normal authority to spend.

Use Spot only where interruption is acceptable

Spot capacity can fit work that can stop, retry or checkpoint without corrupting data or missing an unacceptable deadline. A batch job or build runner is a candidate only after you verify those properties. Build jobs are not inherently idempotent; deployment or publication steps may have external effects.

AWS documents interruption notices as best effort. Stop and termination notices normally give two minutes; hibernation begins immediately. Design recovery so correctness does not depend on receiving the warning.

Test lost workers, duplicate work, partial output and retry limits. Keep durable state outside the disposable worker. Consider capacity diversity and a fallback for work that must finish by a deadline. Include retries and operational support in the cost comparison.

Review storage lifecycle and retrieval costs together

A lower storage rate can come with retrieval charges, minimum storage durations, transition costs or slower access. Classify objects by how often they are read, how quickly they must be restored and how long they must be retained.

For a backup, test a representative restore before changing its storage class. For logs, agree retention with the people responsible for investigations and compliance. A lifecycle policy should implement that decision, not invent it.

Model a normal month and an incident month with unusually heavy retrieval. Review object size and request patterns as well as total bytes. A storage-class headline discount is not a reliable estimate of the total bill.

Trace networking costs without weakening resilience

Inspect data processing, internet egress, cross-zone traffic, endpoints and content delivery charges. Map the costly route to the application that uses it before changing the architecture.

A gateway endpoint for a supported service may avoid a NAT path. An interface endpoint has its own pricing and operational requirements. A content delivery network may reduce origin traffic but changes the overall billing model. Compare the complete route at your volume and in your regions.

Do not concentrate a resilient service in one availability zone just to remove cross-zone charges. Evaluate latency, failure behaviour and recovery alongside cost. An architectural change with a lower bill can still be poor value.

Measure savings without double counting

Use a change register with the baseline, intervention, expected saving, actual billing evidence and performance result. A resource that was both scheduled and resized cannot contribute two independent full savings estimates.

Adjust for changes in usage, credits and price. For example, if demand rises, total spend may increase while unit cost improves. State both so leadership can distinguish business growth from waste.

Give each item one disposition: implemented and measured, implemented awaiting billing evidence, rejected for business reasons, or awaiting a dependency. Do not label a recommendation as a saving before it has affected the bill.

Keep the review active

A monthly review should cover major cost changes, new resources without owners, expiring commitments, unallocated spend and the results of recent changes. Budget alerts need an owner and an agreed response; they do not by themselves cap every service's spend.

Build sensible defaults into the developer platform, such as required ownership information and expiry dates for temporary environments. Keep exceptions visible so teams can meet unusual requirements without abandoning the process.

Get an independent cost review

If your AWS bill is rising and ownership is unclear, book a consultation. My technical consulting services can help identify the largest cost drivers, separate safe changes from architectural trade-offs and build a measurement plan. Bring a representative billing period and the business requirements for your important services. The first decision is where to investigate, not a promised savings percentage.