Building a Cost Optimisation Strategy for AWS

The crawl-walk-run approach

Cost optimisation programs that try to do everything at once usually fail. There are too many levers, too many stakeholders, and too much change risk. The crawl-walk-run model sequences the work so each phase builds on the previous one.

Crawl: Visibility and waste elimination (Month 1–2) You cannot optimise what you cannot see. The first phase is purely about establishing visibility:

• Enable Cost Explorer and anomaly detection
• Set up AWS Budgets with alerts at 80% and 100% of expected monthly spend
• Establish a baseline of what you’re spending and on what
• Perform a first-pass cleanup of obvious waste (orphaned EBS volumes, idle Elastic IPs, old snapshots)
• Implement a tagging strategy

Expected outcome: 10–20% cost reduction just from eliminating obvious waste.

Walk: Rightsizing and architectural optimisation (Month 2–4) With a baseline established, move to efficiency improvements:

• Run AWS Compute Optimizer and rightsize over-provisioned instances
• Review and optimise top 5 cost drivers (usually EC2, RDS, data transfer, and one or two managed services)
• Implement storage lifecycle policies (S3, EBS, CloudWatch Logs)
• Evaluate architectural changes (Spot for batch, Lambda vs always-on containers, etc.)
• Stop dev/test environments at night

Expected outcome: additional 15–30% cost reduction.

Run: Purchase optimisation and cultural embedding (Month 4+) Now that you understand your stable baseline, make financial commitments:

• Purchase Savings Plans or Reserved Instances for stable workloads
• Implement automated cost controls (scheduled start/stop, AWS Config enforcement)
• Establish monthly cost review cadence
• Embed cost considerations into architecture reviews and deployment processes

Expected outcome: an additional 20–40% reduction from commitment pricing, plus a culture that sustains all of the above.

The critical order of operations

The sequence matters. A common mistake is buying Reserved Instances or Savings Plans early, before establishing a stable baseline.

Don’t buy commitment pricing until you know your stable baseline.

If you buy 1-year Savings Plans covering $10,000/month of EC2 and then rightsize to $6,000/month of EC2, you’re paying $4,000/month of committed spend on infrastructure that’s not running. The Savings Plan commitment still charges you.

The correct order:

1. Get visibility — know what you’re running and why
2. Eliminate waste — delete things that shouldn’t be running at all
3. Rightsize — match instance sizes to actual workloads
4. Establish a stable baseline — run the rightsized workload for 60–90 days
5. Buy commitment pricing — purchase Savings Plans based on the proven baseline
6. Optimise architecture — move to Spot, serverless, Graviton where appropriate

Each step reduces the baseline before the next step commits to it.

A 90-day cost optimisation plan

The monthly cost review habit

Sustainable cost management requires a regular review cadence. Without it, waste accumulates between fire-fighting episodes.

A monthly cost review should cover:

1. Trend — is total spend flat, growing, or shrinking? Is that expected given product changes?
2. Anomalies — did anything spike this month? Investigate if so.
3. Per-service analysis — which services grew most? Is that growth justified by usage?
4. Savings Plans coverage — is your commitment pricing being fully utilised?
5. Action items — 3–5 specific things to act on before the next review

The review should have an owner (not a committee — one person is accountable), a standard report format, and follow-up tracking. Reviews without follow-up are theater.

For the monthly report, pull data from Cost Explorer with this CLI command:

# Get last month's cost by service
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --output table

Automated cost controls

Manual processes don’t scale and don’t enforce themselves consistently. Automate the controls that should always be true:

Scheduled instance shutdown: EventBridge rule → Lambda → EC2/RDS stop/start. Tag instances with AutoStop: true and stop them at 7pm on weekdays:

{
  "source": ["aws.events"],
  "detail-type": ["Scheduled Event"],
  "resources": ["arn:aws:events:us-east-1:123456789012:rule/StopDevInstances"]
}

Tag enforcement: AWS Config rule required-tags flags resources missing required tags within 30 minutes of creation. CloudWatch alarm → SNS → Slack notifies the team when untagged resources are detected.

Budget Actions: For dev and test accounts, configure Budget Actions to apply an SCP that prevents new resource creation when the monthly budget is exceeded. This is a guardrail, not a punishment — it enforces conversation before overspend happens.

CloudWatch log retention: A weekly Lambda that scans all log groups and applies a 30-day retention policy to any log group with retentionInDays == null. This prevents log storage from growing unbounded.

See AWS Organizations for SCPs, and CloudWatch overview for log group management.

Getting engineering teams to care

Cost optimisation programs often stall because engineering teams don’t feel the impact of cloud costs in their day-to-day work. A few approaches that work:

Team cost dashboards — build or configure a per-team cost dashboard (CloudWatch or a third-party tool) that shows this week’s spend vs last week’s, and the biggest cost services. Make it visible in Slack or a team wiki.

Cost in architecture reviews — add “estimated monthly cost at production scale” as a required field in architecture review documents. Engineers who have to estimate cost before building tend to make more cost-efficient choices.

Efficient spending recognition — if a team reduces their monthly bill by 30% while maintaining reliability, that should be recognised. Cost efficiency is an engineering skill worth valuing.

Gamification — some organisations publish a leaderboard of cost efficiency metrics (cost per unit of work) per team. This works in competitive engineering cultures where teams want to rank well.

Cost in incident reviews — when a billing spike happens, include it in the incident review process the same way you’d review a reliability incident. What happened? Why wasn’t it caught? What changes prevent recurrence?

Quarterly rightsizing reviews

Rightsizing done once is not enough. Applications change, traffic patterns shift, and new features add load. An instance that was optimally sized six months ago may be over-provisioned today, or under-provisioned.

Schedule a quarterly rightsizing review:

1. Run aws compute-optimizer get-ec2-instance-recommendations for all accounts
2. Export findings and filter for OVER_PROVISIONED with low performance risk
3. Assign ownership of each recommendation to the team that owns the service
4. Track completion rate as a metric in the monthly review

Automate the data collection step so the review starts with current data, not stale recommendations.

Reviewing commitment pricing utilisation

Savings Plans and Reserved Instances need to be reviewed periodically. A Savings Plan purchased for a workload that was later decommissioned still charges until it expires.

In Cost Explorer, check the Savings Plans utilisation and coverage reports monthly:

• Utilisation — what percentage of your committed hourly spend is being used? Below 85% means you committed to more than you’re using.
• Coverage — what percentage of your eligible On-Demand spend is covered by Savings Plans? Below 70% means you have room to buy more commitments.

These two metrics together tell you whether your commitment pricing is calibrated correctly. Adjust at renewal time, not mid-term (you generally can’t modify a Savings Plan before expiry).