The question
The client’s AWS bill was higher than expected for the size of the website. The obvious assumption was that the servers were too big. Rather than start resizing instances, I audited everything that was running and where the money was actually going.
What the audit found
- The real cost driver was the database version, not server size. The managed database was running an end-of-life MySQL version, so AWS was charging extended-support fees on top of normal usage.
- A retired site was still running. A secondary website had no meaningful data activity for years and no live DNS pointing to it, but its infrastructure was still being paid for.
- Leftovers had accumulated: an orphaned database and a staging server larger than staging needs.
- A risk, not just a cost: one staging deployment was configured against the production database. Testing on staging could have changed live data.
Recommendations
- Separate staging from production data immediately.
- Remove the retired site and orphaned resources, after confirming nothing depends on them.
- Right-size staging to what testing actually needs.
- Upgrade the database to a supported MySQL version on a current instance class at a similar cost, removing the extended-support charge. The upgrade path was limited by the WordPress version, so it included regression testing on staging before touching production.
The lesson
Shrinking the servers would have been the quick answer, and it would have missed both the biggest cost and the biggest risk. Looking at the whole account, with evidence for each finding, produced a short list of changes that save money and make the platform safer.
