Cloud cost control: 18% off a donation platform's AWS bill in three months
A donation platform's AWS bill dropped 18% in three months after a compute, storage, and data-transfer audit, without touching uptime or response times.
On this page5 sections
A donation platform processing recurring gifts for hundreds of nonprofits was watching its AWS bill climb faster than its transaction volume. Three months later, the same traffic cost 18% less every month, with no change to uptime or response times.
The ask
The client's CTO didn't want a rewrite or a re-platform. Donation processing has to stay reliable during end-of-year giving season, the platform's highest-stakes traffic window, and any change that risked downtime or a slower checkout was off the table. The ask was narrow and specific: bring the AWS bill down without touching what visitors and donors actually experience.
The audit
A cloud engineer and a backend engineer spent the first two weeks instrumenting cost, not cutting it. Every service's spend was tagged and attributed, then lined up against actual usage, not provisioned capacity. The audit surfaced four categories of waste that account for most cloud overspend on platforms this size:
- Over-provisioned compute: EC2 instances sized for a traffic spike that happened once, running at 12% average utilization the rest of the year.
- Orphaned storage: snapshots and old database backups nobody was deleting, some from a migration two years prior.
- Unoptimized data transfer: cross-AZ traffic between services that could have shared a subnet, and images served without a CDN in front of them.
- No reserved capacity: 100% on-demand pricing for workloads that had been running continuously for years.
What we changed
Right-sized compute
Moved from statically over-provisioned EC2 instances to auto-scaling groups sized against real traffic patterns, with a scheduled floor during the December giving season and a lower one the rest of the year.
Cleared storage debt
Deleted or archived to cold storage every snapshot and backup past its actual retention requirement, cutting S3 and EBS snapshot spend by more than half.
Fixed data-transfer routing
Re-architected cross-service traffic to stay within the same availability zone where possible, and put a CDN in front of static assets and donation-receipt PDFs.
Bought reserved capacity
Committed to 1-year reserved instances for the baseline compute that had been running on-demand for years with no meaningful variation.
Shipped a cost dashboard
Left the client with a per-service cost dashboard and monthly budget alerts, so the next spend creep gets caught in weeks, not a year.
The outcome
18%
Lower monthly AWS bill
3 months
From kickoff to the new baseline
0
Minutes of downtime during the change
The bill dropped every month of the engagement as each change landed, with the full 18% reduction realized by the third month once reserved capacity kicked in. Response times and uptime were unaffected; the December giving-season traffic spike that follows was handled without incident on the new auto-scaling configuration.
We expected to trade cost for risk. Instead we got a lower bill and a dashboard that tells us when something's about to get expensive again, before it shows up on an invoice.
VP of Engineering, donation platform (anonymised at client's request)
What we learned
- Most cloud overspend isn't one big mistake. It's four or five small ones compounding for years without an owner.
- Cost work doesn't require a rewrite. Every change here shipped behind the existing architecture, not instead of it.
- A dashboard is the real deliverable. The 18% is a one-time win; the visibility is what keeps the bill from creeping back up.
