An AWS bill is a list of charges, not a list of things you can safely remove. An apparently quiet server may run the overnight import. An old backup may be the only copy from before a damaging update. The useful result of a review is a short set of decisions with evidence behind them.
Start by agreeing what the website must keep doing: its important customer journeys, acceptable interruption and recovery needs. That makes cost a constraint you can manage alongside service quality. The AWS Cost Optimization Pillar is a useful starting point for that wider view.
1. Choose a complete month and name the cost measure
Use a finished calendar month for the baseline. Keep the current month and forecast in separate columns. A month-to-date figure has fewer days in it; a forecast is a prediction. Neither is a substitute for the amount attributed to a complete period.
Write down whether you are using unblended, net unblended or amortised costs. Amortised views spread commitment fees across the relevant period; they answer a different question from when cash leaves the account. AWS explains these choices in Cost Explorer’s advanced options. Use the same measure on both sides of a comparison.
Keep tax, credits and currency conversion visible. Reconcile differences between your working total and the invoice before attributing them to infrastructure. Choose a second complete month if the first included an unusual campaign or migration.
2. Give each material charge a purpose and an owner
Group spend by service, region and usage type, then work towards the application role. A line labelled storage might support the live database, recovery copies or a forgotten development environment. Those have different owners and different consequences if changed.
Make an explicit “not yet mapped” list. Missing tags do not prove that something is unused. Ask who can explain its purpose and record the next check. If nobody owns it, assign the investigation before assigning a deletion date.
For shared services, write down how you allocate the cost. A rough but explicit method is easier to improve than a precise-looking allocation that nobody can explain. Do not force every bill line into a resource if the charging dimension does not support that mapping.
3. Separate cleanup, redesign and commitments
A resource with no remaining purpose is a cleanup candidate. Moving media or replacing a server is a project with migration and overlap costs. Buying a commitment changes the commercial terms. Keep these in different rows so a quick saving does not conceal a larger dependency.
| Candidate | Evidence still needed | Decision |
|---|---|---|
| Retained address | Owner confirms DNS, allowlists and rollback use | Investigate; price alone does not authorise release |
| Old snapshot | Retention owner and a recorded recovery test | Keep until evidence exists |
| Smaller web server | Peak memory, busy journeys and background jobs | Test a replacement |
| Hourly commitment | Stable eligible usage after resizing | Defer purchase until the new baseline is known |
This fictional inventory has no customer data or price estimate. Its point is the approval evidence: each row ends with a decision someone can act on. Add the estimated recurring change, implementation effort and recovery cost only when you have enough information.
Cost Optimization Hub can help consolidate recommendations and account for overlapping opportunities. Treat recommendations as candidates for your workload review. They do not establish whether a website’s particular checkout, import or recovery process will still work.
4. Calculate the net change once
Compare the same workload before and after. Subtract all new recurring costs from the avoided charge, and show one-off work separately. A smaller server plus object storage and delivery has several cost lines; counting only the server makes the estimate look better than it is.
Sequence dependent actions. If you resize first and then buy a commitment, price the commitment against the smaller eligible workload. Do not add a full saving from each recommendation against the original bill. Where traffic is variable, give a low and high usage scenario with the assumptions written beside it.
5. Decide how you will verify the result
Before changing anything, record the expected outcome, who approves it, what must be tested and when you will review billing. Keep a dated change log. Compare the next complete period using the same cost measure and explain differences in traffic, duration and configuration.
Track useful business outcomes too. A cheaper hosting month with slower checkout or a failed restore is not a successful optimisation. Use labels such as estimated saving, conditional migration and realised saving so a proposal never becomes a claimed result by accident.
What can go wrong?
A lower bill can come from credits, fewer visitors or a shorter month. A supposedly unused resource can be waiting for a monthly task. A large recommendation can overlap another one. These are reasons to improve the evidence, rather than to abandon the review.
Proceed, investigate or keep?
- Proceed: an owner has approved the smallest useful change, tests and recovery are defined, and the net estimate is clear.
- Investigate: the charge is understood but its dependencies, peak demand or replacement cost are not.
- Keep: the resource meets an agreed service or recovery need that has no acceptable replacement.
For the next technical check, read what to measure before resizing EC2 or how to approach a media move.
Continue the AWS review
- Why disabled AWS services can still cost money
- What to check before deleting old Lightsail backups
- Move WordPress media off your server safely, then review its size
- Review AWS WAF costs without weakening protection
If you are reviewing your website’s hosting, tell AceMedia Host what you need.