Cloud Cost Optimisation: How to Cut Your AWS Bill by 40%

Cloud infrastructure gives engineering teams the freedom to provision resources in seconds. That freedom has a cost — literally. Without deliberate guardrails, AWS bills compound quietly in the background until someone opens the console and has a bad morning. This article covers the strategies we apply on every engagement to bring cloud spend back under control without compromising reliability or performance.

1. Right-Sizing Instances — The Fastest Win

Over-provisioned instances are the single biggest source of wasted cloud spend. Teams provision large instances during initial setup "just in case" and never revisit them. AWS Compute Optimizer analyses your actual utilisation and recommends downgrades with projected savings.

How to identify candidates

• Pull 2 weeks of CloudWatch CPU and memory utilisation metrics
• Any instance averaging below 20% CPU utilisation is a right-sizing candidate
• Check memory with the CloudWatch agent — EC2 does not report memory by default
• Test the downgraded instance under synthetic load before promoting to production

Right-sizing alone typically reduces EC2 spend by 20–35% on accounts that have been running for more than a year without review.

2. Reserved Instances vs Spot Instances — Choosing the Right Model

On-demand pricing is convenient but expensive. For predictable workloads, the choice between Reserved Instances and Spot Instances determines how much you save:

• Reserved Instances (1-year): 40% discount vs on-demand. Use for your baseline capacity — databases, core application servers, anything that must stay running.
• Reserved Instances (3-year): up to 60% discount. Only commit if you're confident in the instance type — Savings Plans are often more flexible.
• Spot Instances: up to 90% discount. Use for stateless, interruptible workloads — batch jobs, data processing pipelines, CI/CD runners, ML training.

The optimal strategy is a layered fleet: Reserved Instances for your baseline, auto-scaling with Spot for burst capacity, and on-demand only as a last resort fallback.

3. S3 Storage Tiers — Stop Paying Standard Rates for Cold Data

S3 Standard is priced for frequently accessed data. Most teams store everything there by default and pay accordingly. S3 Intelligent-Tiering and storage class transitions fix this automatically.

Storage class hierarchy

• S3 Standard: $0.023/GB — for data accessed daily
• S3 Standard-IA: $0.0125/GB — for data accessed monthly
• S3 Glacier Instant Retrieval: $0.004/GB — for archives accessed a few times a year
• S3 Glacier Deep Archive: $0.00099/GB — for compliance archives accessed rarely

Set up S3 Lifecycle rules to transition objects automatically based on age. Logs older than 30 days rarely need instant access — moving them to Standard-IA or Glacier cuts storage costs by 60–95%.

4. CloudWatch Cost Anomaly Detection — Catch Spikes Before They Become Bills

AWS Cost Anomaly Detection uses machine learning to identify unusual spend patterns and alert you before they compound. Setup takes 10 minutes and has saved multiple clients from four-figure surprise bills caused by misconfigured auto-scaling or forgotten load tests.

Configuration checklist

• Enable Cost Anomaly Detection at the account level
• Set an absolute threshold alert (e.g., alert if daily spend increases by more than $50)
• Set a percentage threshold alert (e.g., alert on 20%+ day-over-day increase)
• Route alerts to a Slack channel via SNS — email gets ignored, Slack does not

5. Tagging Strategy for Cost Allocation

You cannot optimise what you cannot measure. Without a consistent tagging strategy, your Cost Explorer shows a single number with no breakdown by team, product, or environment. Implement mandatory tags enforced via AWS Config rules:

• Environment: production | staging | development
• Team: backend | frontend | data | devops
• Product: your product or service name
• CostCentre: billing code for chargeback

Once tags are consistent across all resources, you can generate per-team cost reports and hold each team accountable for their own AWS spend. This cultural shift is often more impactful than any technical optimisation.

6. Auto-Scaling Policies — Scale Down as Aggressively as You Scale Up

Most teams configure scale-out policies carefully and leave scale-in policies at their defaults. The result: your fleet scales up during a traffic spike and stays there for hours after the spike ends.

Scale-in best practices

• Set a scale-in cooldown of 5–10 minutes — short enough to respond but long enough to avoid thrashing
• Use target tracking on CPU utilisation (target: 60%) rather than simple scaling rules
• For ECS services, enable scale-in protection only during active request processing — not statically
• Review your scaling history monthly in CloudWatch — look for instances that stayed alive long after load dropped

Combining all six strategies — right-sizing, reserved capacity, storage tiering, anomaly detection, tagging, and aggressive scale-in — consistently delivers 35–50% reductions in monthly AWS spend for accounts that have not been actively optimised. The work pays for itself within the first billing cycle.