Insights26 January 2025Updated 25 October 20265 min read

Taming the Cloud: Controlling Infrastructure Costs

Taming the cloud controlling infrastructure costs with key takeaways on auditing and cost allocation strategies.

Cloud cost optimisation needs a distinction between seeing a charge and changing the activity behind it. AWS makes that distinction explicit: its Budgets service separates notifications from configured actions, which can run automatically or require approval. We recommend starting with an owner for each workload and a specific decision that owner can take when spending changes.

Treat the approach as a review of your own infrastructure, not a forecast of a particular saving. Ask what each resource does, what demand it serves and what evidence would justify changing it. Keep security and recovery requirements in that discussion rather than treating every unused-looking resource as disposable.

Give each charge an owner

AWS's cost allocation announcement describes billing data grouped by resource tags, with department and application as possible reporting dimensions. It also shows an important limitation: where a resource has no value for a selected tag key, that resource's entry in the corresponding report column is blank.

Choose a small set of names that your engineering and finance teams understand. We suggest an application owner and an environment, with an explicit category for shared infrastructure. Agree how shared costs should be divided before presenting a departmental total as someone's responsibility.

Include unallocated spending in the review rather than hiding it in a miscellaneous line. Ask the team to identify its owner or record why it remains shared. Our recommendation is to make the reporting useful for decisions before adding a detailed internal charging process.

Review capacity against observed demand

AWS introduced EC2 resource optimisation recommendations to identify idle and underused instances using historical usage, CloudWatch metrics and existing reservations. Its suggested actions include terminating idle instances or moving active instances to smaller options.

Use those recommendations as a review queue, not permission to delete. Ask the owner whether the observation period includes the workload's important peaks. For a field application, we would check periods when devices reconnect and submit accumulated work. For a reporting service, include its scheduled processing window.

Before changing capacity, record the response time and failure rate you intend to preserve. Agree a rollback condition, make the change and repeat the relevant workload test. Do not call a recommendation a realised saving until the billing evidence supports that conclusion. Keep the before-and-after record alongside the change.

Scale to a meaningful signal

AWS's target tracking announcement describes choosing a load metric and target, then letting Auto Scaling adjust the number of EC2 instances to maintain it. The examples include average CPU utilisation and requests per load balancer target.

Choose a signal that represents the work you need to complete. We recommend testing the scaling policy against an increase in demand and the subsequent quiet period. Watch the service outcome as well as the number of running instances.

Set an explicit capacity boundary for the test, name the person who can change it and decide what should happen when demand exceeds it. Do not make cost the only acceptance criterion. Keep a record of whether the application met its response-time target while the policy added and removed capacity.

Decide what a budget should trigger

The AWS Budgets Actions launch distinguishes budget notifications from actions tied to actual or forecast spending. Its actions include applying access policies and targeting running EC2 or RDS resources, with automatic execution or an approval workflow.

We recommend beginning with approval for any action that could affect a production service. Give the alert recipient a written response: inspect the named workload, identify the change in usage and decide whether to approve the proposed action. Test that response before relying on it.

For a disposable development environment, you might choose a different policy. State its scope explicitly. An alert that asks someone to investigate and an action authorised to stop a resource are different controls. Check which one you have configured rather than treating a budget amount as a universal spending cap.

Match cheaper capacity to interruption tolerance

AWS describes Spot Instances as discounted spare compute capacity that EC2 can interrupt. Its interruption-handling examples include saving job state, removing a server from a load balancer and draining containers.

Before putting work on that capacity, require a demonstration of recovery. Interrupt a worker during a representative job and check what happens to incomplete output. Ask whether the job can resume, whether repeating it changes the result and who sees a failure.

We would consider a restartable batch job before a service with untested recovery behaviour. Compare the completed work and operational effort, not only the advertised capacity price. Keep interruption handling in the acceptance tests for any workload you decide to move.

Review commitments after the workload

AWS's Savings Plans announcement exchanges discounted compute rates for a commitment to a consistent monetary amount of compute usage per hour over one or three years. It distinguishes usage covered by that commitment from additional usage billed at On-Demand rates.

Our recommendation is to review the workload before choosing the commitment. List planned removals, likely migrations and demand you cannot yet predict. Ask finance and engineering to agree which part of usage they are prepared to commit to, rather than using the current bill as the purchasing target.

For the next review, choose one owned workload and one proposed change. Write down its current cost, required service behaviour and rollback condition. Check the outcome before extending the change elsewhere. If you want to discuss that first workload, let's have a chat.

Update, October 2026

For teams applying the same cost discipline to agentic delivery, our July 2026 engineering article, The Cheapest Model That Can Safely Do the Job, describes routing work by complexity with a separate risk check. It adds a concrete design for choosing a cheaper execution route without making low cost the sole decision rule.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →