Cloud bills grow every month because nobody is looking. The services are on-demand, the costs are hidden in the bill, and the team that set them up has moved on. By the time anyone notices the bill is large, the bill is very large.
Most teams can cut cloud costs by 30-50% with a methodical review. The savings come from boring fixes, not clever engineering.
The easy wins
Delete unused resources. An old database you forgot about. A storage bucket that was meant to be temporary. A load balancer for a service that no longer exists. These accumulate over months and years. A systematic review finds dozens of them.
Downsize over-provisioned resources. A server that is sized for peak load but averages 20% utilisation. Downsize it and let autoscaling handle peaks. This usually saves 50-70% without affecting performance.
Turn off development environments outside business hours. A development database or staging server running 24/7 costs the same as a production server. If it is only used during business hours, turn it off at night and weekends. Savings are 60-70% of development infrastructure cost.
Commit to reserved instances. If you have workloads that run 24/7, commit to a one-year or three-year reservation. This is 30-50% cheaper than on-demand. The catch is you pay upfront, but the payback is usually six months or less.
Consolidate databases. Ten single-purpose databases often cost more than one multi-tenant database with better capacity sharing. Consolidation saves 40-60% without architectural changes.
Change data storage. Moving data from DynamoDB to S3, or from expensive managed databases to cheaper open-source databases, often saves 70-90%. The trade-off is adding some application code.
The medium-effort wins
Review data transfer costs. Cross-region data transfer costs money. Cross-AWS region data transfer costs money. Consolidating regions or batching transfers can save 30-60%.
Optimize queries. A badly written query that scans a table instead of using an index might run 100x more expensive. Finding and fixing the worst queries often saves 20-30%.
Implement caching. A service that calls a database 1,000 times per day for the same data is wasteful. A cache reduces calls to 100. Caching saves 20-50% of database costs.
Right-size compute by metric. If you are choosing instance size based on gut feeling, you are probably oversized. Use actual CPU/memory metrics to choose the right size. Savings are usually 20-30%.
Consolidate monitoring tools. If you are running five different monitoring solutions, consolidate to one. Each monitoring tool costs money to ingest and store data. Consolidation saves 20-40% of monitoring costs.
The hard-effort wins
Architectural changes. Redesigning a service to use cheaper primitives (batch processing instead of real-time, caching instead of database, S3 instead of EBS) can save 40-70% but requires weeks of work.
Migrate to a different cloud. Sometimes another cloud is genuinely cheaper for your workload. Migration is expensive but can save 30-40% annually.
Build custom infrastructure. For huge workloads, custom infrastructure is cheaper than the cloud. This is rarely justified and requires significant engineering.
How to find the waste
Get the bill. Export your cloud bill to a spreadsheet. Understand what is costing what. Most teams do not actually look at their bill.
Group by service. Which services cost the most? Compute? Databases? Storage? Focus on the top three.
Check for patterns. Costs that spike on weekends or nights indicate something is running that shouldn’t. Costs that show up for every day indicate something is always on.
Ask teams about resources. Each team should know what they are running and roughly how much it should cost. If a team doesn’t know or the actual cost is 2x the estimate, investigate.
Use cloud cost analysis tools. CloudCheckr, Flexera, or the native tools in each cloud show waste. They cost money (usually £100-500 per month) but often find 2-3x their cost in savings.
The process
1. Review bill monthly and set a budget. 2. Alert the team when spending approaches the budget. 3. Assign someone to spend one hour per week on cost optimisation. 4. Every quarter, do a deeper analysis and find the largest cost drivers. 5. Target one easy win and one medium-effort win per quarter.
Most teams see 20-30% savings in the first quarter with this process. After a year, usually 40-50% savings.
What not to do
Do not kill features to cut costs. Removing functionality saves money but is the wrong trade-off.
Do not over-optimize for tiny savings. If a change saves £10 per month and takes 4 hours of work, it is not worth it.
Do not use the wrong tool for the job to save cost. If a managed service is right, use it even if it costs more. Operational burden outweighs the savings.
Do not surprise the team with constraints. Give advance warning and let teams plan around cost constraints.
The honest assessment
Cloud cost management is not glamorous but it is often the highest-leverage work available. An engineer who spends 20% of their time on cost optimisation often saves 20-30% of cloud spend.
The reason most teams don’t do this is that there is no career advancement in cost optimisation and cloud spend is usually someone’s problem but nobody’s job. Making it someone’s explicit job is often enough to cut costs dramatically.