cloudcostdown.euAWS Cost Management · Cost Drift
AWS Cost Drift: Why Your Bill Keeps Growing After Optimisation
You optimised your AWS costs 6 months ago. The bill is creeping up again. This isn't unusual - it's cost drift, and it affects every startup that treats cloud optimisation as a one-time project rather than an ongoing practice.
The Typical Cost Drift Pattern
This pattern repeats at almost every startup that does a one-time optimisation:
Optimisation completed. Bill reduced 30–40%. Team celebrates.
New engineers join. Infrastructure added with default settings. No alerts triggered.
Traffic grows. Instances upsized. Nobody reviews the new sizes against actual utilisation.
A Savings Plan expires without renewal. On-demand rates quietly kick back in.
Bill is back to 70–80% of its pre-optimisation level. No single change caused it - drift did.
Bill exceeds original pre-optimisation level due to compounded drift. Leadership asks why costs are rising again.
The 6 Causes of AWS Cost Drift
Drift isn't one thing - it's six independent processes all running in parallel, each adding a small amount every month.
New engineers with default settings
Every new hire provisions infrastructure using the defaults they learned or the sizes that feel safe. Without a standard infrastructure baseline enforced via IaC modules or policies, new resources gradually add up to significant over-provisioning.
+5–15% over 6 months per 5 new engineersTraffic growth without right-sizing reviews
When traffic grows, teams upsize instances - which is correct. When traffic plateaus or drops (post-launch, seasonal), nobody downsizes. Infrastructure stays at peak capacity indefinitely.
+10–25% after each scaling event without cleanupInstance type staleness
AWS releases newer, more cost-efficient instance families regularly (Graviton, latest generation). Instances from 2–3 years ago are often 20–40% more expensive per unit of compute than current equivalents. Nothing forces a migration review.
+20–40% cost penalty vs. current generation for aged computeCommitted discount expiry
Reserved Instances and Savings Plans expire. If nobody is tracking expiry dates, on-demand rates kick back in silently. A $5,000/month Savings Plan expiring without renewal is an instant $2,500–3,500/month increase.
30–72% price increase when commitments expire unrenewedNew services with no cost awareness
Teams adopt new AWS services - a new RDS instance for a project, a new EKS cluster for a team - provisioned at convenient sizes without cost review. Each addition is individually defensible but collectively adds up.
Cumulative: €200–2,000/month per quarter at fast-growing teamsStorage lifecycle policy gaps
S3 buckets grow indefinitely. Log groups accumulate. Backups retain beyond policy. Nobody revisits storage lifecycle policies after they're set, and data in Standard tier continues growing regardless of access frequency.
+5–10% on storage costs annually without lifecycle managementReactive vs. Proactive Cost Management
Most startups manage cloud costs reactively - they notice the bill went up and then investigate. Proactive management catches drift before it compounds.
Reactive (what most startups do)
- Check the bill when it arrives each month
- Investigate after a spike that's already happened
- No budget alerts until spend is 50%+ over target
- Savings Plan renewals missed until on-demand kicks in
- Engineering investigates after the fact - time wasted on diagnosis
Proactive (with managed FinOps)
- Monthly cost review against optimised baseline
- AWS Cost Anomaly Detection alerts within 24h of spikes
- Savings Plan and RI renewal calendar managed proactively
- Compute Optimizer recommendations reviewed monthly
- New resource provisioning audited against cost standards
The Managed FinOps Retainer (€3K/month) covers proactive monitoring, monthly reviews, commitment management, and drift detection - preventing the pattern above from repeating. Most clients see the retainer cost covered within the first month of drift that's caught early.
What to Do Right Now
Whether you're dealing with active drift or want to prevent it after an upcoming optimisation, these are the highest-leverage actions.
Set up AWS Cost Anomaly Detection
Creates a monitor that alerts when any service spend is unusually high. Free to set up. Catches the most obvious drift signals - a new resource type, an unexpected traffic pattern - within 24 hours.
AWS Cost Anomaly Detection guide →Create monthly budget alerts
Set an AWS Budget for your current monthly spend + 15%. Alert at 80% and 100% of threshold. This doesn't prevent drift but ensures you're aware of it within the month it happens, not the following quarter.
Audit Savings Plan and RI expiry dates
In AWS Cost Management > Savings Plans, check the expiry dates of all active commitments. Add calendar reminders 60 days before expiry for analysis and 30 days for renewal. A missed renewal is an instant 30–70% price increase on those resources.
Savings Plans vs Reserved Instances →Run Compute Optimizer monthly
Compute Optimizer continuously monitors instance utilisation and surfaces rightsizing recommendations. Reviewing and acting on these monthly catches the 'upsized and never reviewed' drift pattern before it compounds.
AWS Compute Optimizer guide →Common questions
How long does it take for costs to drift back after optimisation?
Typically 3–6 months for savings to erode noticeably, and 12–18 months to fully return to pre-optimisation levels. The speed depends on team size, growth rate, and whether any proactive monitoring is in place.
Is drift inevitable or can it be prevented?
Drift is inevitable without active management - that's the nature of a dynamic cloud environment. But the rate of drift can be controlled. Tagging standards, IaC module guardrails, monthly Compute Optimizer reviews, and budget alerts together reduce drift speed significantly.
Should I do another full audit, or just a targeted review?
If it's been 12+ months since your last audit and costs have grown significantly, a full audit is more cost-effective than a targeted review - you'll miss the cross-service patterns that targeted reviews can't see. If it's been 3–6 months and you've kept monitoring in place, a targeted review of the areas that changed is sufficient.