Performance Tuning and Cost Optimisation: Right-Size Everything, Waste Nothing

Somewhere in your cloud environment, there is a compute instance running at 12% average CPU utilisation on an instance class designed for heavy workloads. It was provisioned eighteen months ago by an engineer who chose the size based on a reasonable principle: better too much capacity than too little. Nobody questioned it at the time. Nobody has reviewed it since. It runs around the clock, billing at full rate, doing a fraction of the work it was built to handle. Multiply that by every service, every environment, every team — and you start to understand why the cloud bill feels disconnected from the value it delivers.

The instinct to over-provision is rational. Under-provisioned infrastructure creates outages, and outages create conversations nobody wants to have. But over-provisioned infrastructure creates a different problem: a cost base that grows with every deployment, every new service, every environment that gets created and never decommissioned. The cost of being cautious compounds quietly until someone in finance asks why infrastructure spend has doubled while traffic has grown by a third.

Performance tuning and cost optimisation™ is the engineering discipline of matching every cloud resource to the workload it actually serves — not the workload someone imagined when they provisioned it. Across 900+ projects delivered for 1400+ businesses, we have seen the same pattern: organisations that optimise based on real usage data reduce infrastructure costs meaningfully without touching performance. Organisations that optimise based on assumptions trade one set of problems for another. The data comes first.

Why Theoretical Capacity Planning Fails

Capacity planning before launch is an educated guess. Engineers estimate peak traffic, add a safety margin, and provision accordingly. The problem is not that the estimate is wrong — it almost always is — but that nobody revisits it once real data is available. The launch-day estimate becomes the permanent baseline, and the infrastructure runs at that baseline whether the application needs it or not.

Three patterns make this worse over time.

Traffic assumptions ossify. An application provisioned for 10,000 concurrent users at launch may serve 2,000 on an average day and 6,000 on the busiest. The infrastructure is sized for the 10,000 that was estimated, not the 6,000 that actually occurs. The gap between provisioned capacity and peak demand is waste. The gap between peak demand and average demand is the auto-scaling opportunity that was never implemented.

Environment costs replicate production. Development and staging environments are often provisioned at or near production scale because it is easier than calculating appropriate smaller sizes. A staging database running on the same instance class as production, serving a test workload at single-digit utilisation, costs the same per hour. Multiply that across three or four non-production environments and the infrastructure spend for workloads that serve no users rivals the spend for the production workload that serves all of them.

Nobody owns the bill. Engineering provisions resources. Finance pays the invoice. Neither has complete visibility into the relationship between spend and utilisation. According to the FinOps Foundation's State of FinOps report, aligning engineering actions with financial accountability remains one of the top challenges for organisations practising cloud financial management. Without that alignment, optimisation depends on someone voluntarily reviewing resources they provisioned months ago — and that rarely happens without a structured process.

The result is infrastructure that works but wastes. Everything runs. Nothing is sized correctly. The bill grows, and the conversation about whether it should be growing never has enough data to reach a conclusion.

What Right-Sizing Actually Involves

Right-sizing is the practice of adjusting compute, database, and storage resources to match the workload they serve, based on observed utilisation data rather than provisioning assumptions. It is the single highest-impact cost optimisation practice because it addresses the most common form of cloud waste: resources that are larger than they need to be.

The process requires at least two weeks of utilisation data — ideally four — to capture normal traffic patterns, weekly cycles, and any periodic spikes. Shorter observation windows miss patterns that matter: the batch job that runs every Sunday night, the traffic spike every Monday morning, the monthly reporting cycle that doubles database connections for two hours.

Compute Right-Sizing

For compute instances, right-sizing means analysing CPU utilisation, memory usage, and network throughput to identify the smallest instance type that comfortably handles the observed workload, including peak periods. An instance averaging 15% CPU with peaks at 45% can typically move down one or two instance sizes without any performance impact. The savings compound because compute is usually the largest line item in a cloud bill.

The key discipline is testing after resizing. Right-sizing is not a spreadsheet exercise — it requires deploying the smaller instance, running the production workload against it, and validating that latency, throughput, and error rates remain within acceptable bounds. When this is built into a broader delivery framework, the resize-test-validate cycle becomes routine rather than exceptional.

Database Right-Sizing

Databases are frequently the most over-provisioned resource class because the consequences of an undersized database — slow queries, connection exhaustion, replication lag — are immediately visible and painful. Engineers provision conservatively, and the conservative choice persists long after the workload data proves a smaller instance would suffice.

Database right-sizing requires analysing connection counts, query throughput, storage I/O, and memory utilisation. A database instance handling 200 concurrent connections on an instance class designed for 5,000 is a candidate for downsizing. The savings are often substantial because database instance pricing scales steeply with size.

Storage Tiering

Storage costs accumulate silently. Data written to high-performance storage tiers at creation time remains on those tiers indefinitely, even when access patterns change. Application logs, historical records, and infrequently accessed data sitting on provisioned IOPS storage cost multiples of what they would cost on standard or infrequent-access tiers. Implementing lifecycle policies that automatically transition data to appropriate storage tiers based on access patterns is one of the simplest optimisation practices — and one of the most neglected.

Caching, CDN, and Auto-Scaling: The Performance-Cost Multipliers

Right-sizing reduces cost by removing excess capacity. Caching, CDN optimisation, and auto-scaling reduce cost by making existing capacity serve more requests — or by matching capacity to demand in real time. These are the practices that improve performance and reduce cost simultaneously.

Caching layers reduce redundant computation. Every database query that returns the same result to the same request is wasted compute. A caching layer — whether application-level, in-memory, or at the API gateway — serves repeated requests from memory instead of reprocessing them. For read-heavy applications, which most production workloads are, an effective caching strategy can reduce database load dramatically, deferring or eliminating the need for database scaling. The engineering investment is modest. The compounding return on reduced database and compute load is significant.

CDN optimisation moves data closer to users. A content delivery network caches static assets and, increasingly, dynamic content at edge locations geographically close to users. This reduces origin server load (cost benefit) and reduces latency for users (performance benefit). Misconfigured CDNs — low cache hit ratios, overly aggressive cache invalidation, static assets served from the origin — negate both benefits. Optimising CDN configuration to maximise cache hit ratios is low-effort, high-impact work that many teams overlook as part of ongoing development and scaling.

Auto-scaling matches capacity to demand. Instead of provisioning for peak and paying for that capacity around the clock, auto-scaling adds instances when demand increases and removes them when it subsides. The savings are proportional to the variance between peak and average load. An application that peaks at three times its average load and runs on fixed infrastructure pays for that peak capacity during every off-peak hour. Auto-scaling eliminates the off-peak waste.

The discipline in auto-scaling is tuning the scaling policies. Scale too aggressively and you pay for instances that spin up and terminate before serving meaningful traffic. Scale too conservatively and users experience degraded performance during demand spikes. The policies should be informed by the same utilisation data used for right-sizing: observed traffic patterns, response time thresholds, and the time each instance requires to become ready to serve traffic.

Reserved Instances, Savings Plans, and Spot: The Purchasing Layer

Once workloads are right-sized and auto-scaling is tuned, the purchasing layer provides the next tier of savings. This is where organisations commit to usage patterns in exchange for lower rates — but only after they understand those patterns from real data.

Reserved instances and savings plans offer discounts — typically ranging from 20% to over 60% compared to on-demand pricing, according to AWS pricing documentation — in exchange for a one- or three-year commitment to a specific instance type or compute spend level. The savings are substantial, but the commitment is real. Reserving capacity for a workload that gets decommissioned in six months is worse than paying on-demand for a workload that runs for three years. This is why right-sizing must precede purchasing decisions: you need to know the steady-state workload before committing to a reservation.

Spot instances offer the deepest discounts — often 60% to 90% below on-demand rates — for workloads that can tolerate interruption. Batch processing, data pipelines, CI/CD build environments, and stateless processing tiers are strong candidates. Production web servers that need continuous availability are not. The architectural pattern is straightforward: run the base load on reserved capacity, handle predictable scaling with on-demand, and use spot for fault-tolerant overflow and batch work.

The purchasing strategy should layer these options based on workload characteristics. Stable, predictable workloads get reserved pricing. Variable but critical workloads get auto-scaled on-demand. Fault-tolerant, interruptible workloads get spot. The mix is specific to each organisation's workload portfolio and cannot be determined without the utilisation data that right-sizing produces.

What Happened When the Data Replaced the Assumptions

A production workload had been running on oversized instances since its initial deployment. The original provisioning was reasonable — the team sized for anticipated growth and added headroom for safety. Twelve months later, the growth had materialised at roughly half the projected rate, but the infrastructure had never been revisited. The compute instances ran at low average utilisation with moderate peaks during business hours. The database was provisioned for connection volumes it had never approached. The staging environment mirrored production sizing despite serving only internal testing traffic.

The optimisation began with four weeks of utilisation data collection across all environments. The data revealed what the team suspected but had not quantified: compute instances were running well above the capacity the workload required, the database could serve its peak load on a smaller instance class, and the staging environment could operate on instances a fraction of the production size.

The team implemented changes in three phases. First, right-sizing: compute instances were moved down two instance classes across production and staging, and the database was moved to an appropriately sized instance after load testing confirmed no performance degradation. Second, auto-scaling was implemented for the application tier, replacing the fixed fleet with a scaling group that matched capacity to the observed daily traffic curve. Third, with the right-sized workload now stable and predictable, the team committed to reserved instances for the base compute and database capacity.

The combined effect reduced compute costs by roughly 40% with no measurable impact on application performance. Response times remained within their established baselines. The staging environment, right-sized and scheduled to shut down outside business hours, cost a fraction of its previous monthly rate. No architectural changes were required. No features were removed. The application served the same traffic, at the same performance, on infrastructure that matched the workload instead of exceeding it.

When to Optimise — and What to Optimise First

Start with right-sizing if your workloads have been running for more than a month and you have never reviewed instance utilisation. Right-sizing delivers the fastest, most visible savings with the lowest risk, because you are changing resource sizes, not architecture. Any organisation spending meaningful amounts on cloud compute that has not reviewed utilisation data in the past quarter has right-sizing opportunities.

Add auto-scaling if your workload has predictable demand variation — daily cycles, weekly patterns, seasonal peaks. The greater the ratio between peak and average load, the greater the auto-scaling savings. Applications with flat demand profiles benefit less. Applications that spike to three or four times their baseline benefit substantially, particularly as they scale and evolve over time.

Consider reserved instances and savings plans if you have right-sized your workloads and observed stable utilisation over at least two to three months. Committing before right-sizing locks in pricing for potentially oversized resources. Committing before observing stable patterns risks reserving capacity you won't use. The sequence matters: right-size first, observe the stable state, then commit.

Invest in caching and CDN optimisation if your application is read-heavy and your database or origin server is handling repetitive queries. The performance improvement often defers or eliminates infrastructure scaling that would otherwise be required to handle growing traffic.

Our ISO 9001 and ISO 27001-certified processes ensure that every optimisation is documented, tested, and validated before deployment — because a cost reduction that introduces performance degradation is not an optimisation.

What to Do Next

Pull the utilisation metrics for your five most expensive compute resources. Check the average CPU and memory utilisation over the past month. If any of them are consistently below 30%, those are your first right-sizing candidates. Calculate the monthly cost difference between the current instance class and the next size down. That number, multiplied across every oversized resource in your environment, is the starting point.

When you are ready to move from observation to action, talk to our DevOps team. We bring the same data-driven approach — informed by current infrastructure and delivery practices — to every optimisation engagement, so every change is grounded in your actual workload, not industry averages.

Frequently Asked Questions