I used to think AWS cost management was mostly a finance problem. Then I spent enough time actually digging through infrastructure on different projects, and realized almost every cost issue traces back to an engineering decision nobody revisited. Here are the five I run into constantly, and what actually fixed them.
- Nobody tagged anything
This one sounds boring, but it's the root of almost everything else. If resources don't have a team or owner tag at creation time, you can't answer "why does this cost what it costs" six months later. Not because the data doesn't exist, but because nobody can attribute it to a decision.
The fix isn't a dashboard. It's an IAM policy that denies resource creation without a required tag. Boring, but it's the one change that makes every other cost conversation possible.
- Staging environments running 24/7 at production size
I've lost count of how many times I've found a staging or QA environment sized identically to production, running around the clock, because "we might need to test something." In practice, almost nobody tests at 2am.
A scheduled shutdown outside working hours (or spinning environments up only when a PR needs testing) is one of the lowest-risk, highest-impact changes you can make. Zero code changes, zero downtime risk, real savings.
- Ignoring Compute Optimizer recommendations
AWS Compute Optimizer generates rightsizing suggestions automatically based on real utilization data, for free. Most teams have simply never opened it. I've seen EC2 instances sitting at under 10% average CPU utilization, sized months earlier for a load test that happened exactly once.
The information isn't missing. It's just not routed to anyone who'll act on it. Pulling these recommendations into a weekly ticket or Slack alert closes that gap.
- Cross-AZ data transfer nobody's checking
Compute and storage costs are easy to monitor because they're broken out clearly by service. Data transfer costs hide inside less distinct line items, so they get underweighted during reviews.
The recurring pattern: services split across availability zones early on "for redundancy," with nobody later checking if that redundancy still makes sense at current scale. Worth specifically asking "what's talking to what" instead of just "what costs the most."
- Storage that never moves tiers
Data written once tends to sit in the same storage class forever unless a lifecycle policy explicitly moves it. This is genuinely the easiest fix on this list. A lifecycle policy that transitions logs and backups to infrequent-access and archival tiers on a schedule requires zero application changes and keeps paying off every month without anyone remembering it exists.
The actual fix isn't technical
Every one of these is easy to fix once someone notices. The hard part is building a habit where cost gets reviewed on a schedule, broken down by team, instead of showing up as one big surprising number at the end of the month. Teams that keep this under control aren't the ones who did one great cleanup. They're the ones who made it routine.
If you want the more detailed, step-by-step version of the tagging and rightsizing tactics, I wrote a longer breakdown here: AWS cost optimization guide.
Curious what patterns other people keep running into — feel free to drop your own in the comments.
