What was being solved.
An ecommerce environment had rising AWS spend, incomplete allocation and performance pressure during demand peaks. Nobody inside the team could say which product or environment owned which part of the bill, so every proposed saving carried an unquantified reliability risk. The engagement ran inside the customer-owned AWS account under time-limited, least-privilege access. The public record does not name the client or publish its billing data.
How the engagement was structured.
Usage and ownership review
Mapped EC2, storage, data-transfer and service spend to products, environments and named owners before recommending anything. This step exists because a saving without an owner is a future incident: the review has to establish who is allowed to say yes to each change, not only what the change is.
Rightsizing and commitment candidates
Separated immediately reversible sizing changes from longer-term commitment decisions. Reversible changes were implemented first with rollback stated; commitment purchases were modelled only after the usage baseline had settled, so the customer never committed to yesterday’s waste.
Storage and delivery path
Reviewed unused volumes, snapshot growth, lifecycle policy, caching and CDN opportunities as separate implementation items, each with its own risk note. Storage cleanup touched recovery capability, so retention decisions were signed off against the backup scope rather than deleted for the bill.
Operating follow-through
Attached owners, budgets, anomaly routes and acceptance checks to the approved changes so a lower bill did not become the only success condition. The reliability requirements were written down first and every cost change was tested against them.
The questions this work answers for your environment.
Can you allocate the bill?
If spend cannot be mapped to products and owners, start there. Every later decision inherits that map.
Is the change reversible?
Sizing changes with rollback come before commitments. Commitments follow a settled baseline, never precede it.
What does the saving cost?
Each candidate carries a stated reliability, recovery or performance trade-off. A saving with no stated trade-off has not been analysed.
Who owns it afterwards?
Budgets, anomaly alerts and a review cadence keep the waste from returning after the project ends.
What this page can claim.
The current public evidence supports the work categories and the direction of the engagement. It does not support a public savings percentage, bill amount or customer name, so this page does not invent one.
A similar engagement starts with the fixed-price AWS review. The scope, access model and deliverables are stated before any account access is granted. See the AWS review