TL
The short answer

The first AWS cost optimization sprint should take two weeks and proceed in a fixed order: eliminate pure waste, then rightsize, then tier storage, then set commitment coverage last. The order matters more than the effort. Buying Savings Plans or Reserved Instances before you cut waste locks a discount onto resources you are about to delete, which is the most common way a first pass leaves money on the table. Done in order, a first sprint routinely contributes to the 31 percent median reduction we see in the first 90 days, and almost none of the early work touches production.

This is an AWS cost fundamentals exercise. You do not need new tooling to start, only the Cost and Usage Report, a couple of native advisors, and the discipline to act on what they surface. Here is the two week plan.

Before the sprint: turn on the source of truth

Every decision in the sprint reconciles against the Cost and Usage Report, the CUR. Cost Explorer is fine for a first glance, but the CUR is the granular, line item record you trust for allocation and for measuring the before and after. Enable it on day zero, confirm tags are flowing, and pull a clean baseline of the last full month by service, by account, and by team. If tagging is thin, the sprint still works, it just spends more time attributing cost to owners.

One more setup step: switch on AWS Compute Optimizer and Cost Anomaly Detection. Both are free, both recommend rather than decide, and both feed the sprint.

Week one: cut the waste that carries no risk

The first week targets spend you can remove without an architecture conversation. Nothing here changes how an application runs, so engineering sign off is fast.

  • Orphaned storage. Unattached EBS volumes, old snapshots no policy will ever restore, and buckets nobody owns. These accrue quietly and delete cleanly.
  • Idle resources. Stopped instances still paying for attached volumes and elastic IPs, load balancers with no targets, and NAT gateways routing almost nothing. Data transfer and NAT charges are classic quiet budget eaters.
  • Untagged and unknown spend. Anything the CUR cannot attribute to a team. Tag it or flag it for an owner before it becomes a permanent mystery line.
  • Non production left running. Dev and test environments that run nights and weekends for no reason. A schedule that stops them outside working hours is one of the highest return changes in the whole sprint.

Week one is where the visible number moves first and trust is earned, because none of it risks a customer facing system.

Week two: rightsize, then tier, then commit

The second week works through the changes that need a human to confirm them against real workload behaviour.

  • Rightsizing. Compute Optimizer flags oversized instances; you confirm each against actual CPU, memory, and burst patterns before resizing. Fold in the standing structural wins while you are here: Graviton for workloads that can move architecture, and gp3 in place of gp2 for EBS. Both are savings that do not expire at a renewal.
  • Storage tiering. Move infrequently accessed S3 data to the right class with lifecycle policies, and consider Intelligent Tiering where access patterns are unpredictable.
  • Commitment coverage, last. Now that waste is gone and instances are right sized, the steady state floor is finally visible. Size Savings Plans and Reserved Instances to that floor on a defensible forecast, not to the inflated usage you started the sprint with. Commitment strategy is risk adjusted, not discount maximised.
Worked example

A scaling fintech started its first sprint at a baseline nobody had reviewed in a year. Week one removed unattached volumes, idle load balancers, and a non production fleet that had been running around the clock. Week two confirmed a round of rightsizing, moved cold S3 data down a tier, and only then placed a Savings Plan sized to the reduced steady state. The estate finished the program 41 percent lighter. Figures are verified against billing data and anonymised.

How to make the savings stick

A sprint that is not followed by a rhythm leaks back. The day the sprint closes, stand up the review cadence that holds the gains: a weekly anomaly and commitment utilization check and a monthly cost by team review. The full rhythm is laid out in the AWS spend review cadence, and the recurring surprises a cadence catches are in common AWS billing surprises. Treat the sprint as the step change and the cadence as how you keep it.

Frequently asked questions

How long does a first AWS cost optimization sprint take?
Two weeks. Week one is discovery and the quick wins that carry no risk. Week two confirms rightsizing and sets commitment coverage to a defensible forecast.
What should you cut first in AWS?
Pure waste first: stopped instances still attached to disks, unattached EBS volumes, idle load balancers, and old snapshots. Then rightsizing, storage tiering, and commitment coverage last.
Should you buy Savings Plans in the first sprint?
Only after rightsizing. Buying commitment before you cut waste locks in a discount on resources you are about to delete. Size coverage to the steady state floor that remains.

Run your first sprint with us

We run the two week sprint with your team, then hand you the cadence that keeps the savings. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk to you.

Independent · buyer-side

Put a defensible number on your cloud spend.

No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.

Buyer-side intelligence, monthly.

The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.