AWS accounts rarely break in a way that gets your attention. They drift. A little more spend each month, a permission that was meant to be temporary, a region nobody remembers turning on. None of it is an emergency on any given day, which is exactly why it accumulates for years.
After enough reviews, the same five signals keep telling me an account is overdue for one. None of them require access to your environment to recognize. If two or more sound familiar, it’s worth a closer look.
1. Your bill goes up every month and nobody can fully explain why
Not a spike — a steady climb. The kind where each month is 3–5% higher than the last and the answer is always “we shipped some stuff.” Real growth shows up in your bill, but so does waste, and from the invoice they look identical.
The tell: nobody on the team can point at a line item and say that one is bigger because of X. When the bill is a black box, it’s almost always carrying cost you’d cut in a heartbeat if you could see it.
2. You’ve never mapped your setup against the Well-Architected pillars
AWS publishes six pillars — operational excellence, security, reliability, performance, cost, and sustainability — and almost nobody outside of an AWS-led review has actually gone pillar by pillar against their own account. That’s not negligence. It’s that the day job never leaves room for it.
The tell: if you can’t remember the last time someone deliberately asked “where are we weak on reliability?” rather than waiting for an incident to answer it, you’re running on luck you haven’t measured.
3. The person who built it is gone — or about to be
So much of an AWS environment lives in one engineer’s head: why this subnet, why that instance type, which alarms actually matter. When that person leaves, the account doesn’t break. It just becomes un-editable, because nobody else dares touch it.
The tell: a change you’d like to make — right-size that fleet, retire that old service — keeps not happening because the only person who understood it is no longer the person who has to live with the consequences.
4. “Temporary” is doing a lot of work
The instance spun up for a one-week load test. The wide-open security group added to
unblock a launch. The IAM role with * permissions created on a Friday. Temporary things
in AWS have a way of becoming permanent the moment they stop causing pain.
The tell: you have at least one resource you’d describe, a little sheepishly, as “technically still on.” Each one is small. Together they’re your attack surface and a chunk of your bill.
5. You’re about to do something that raises the stakes
A funding round and the diligence that comes with it. A SOC 2 push. A big new customer who wants to know how their data is handled. A migration. Each one turns “we’ll get to it” into “we need an answer this quarter.”
The tell: someone outside the team is about to ask hard questions about your infrastructure, and you’d rather know the answers before they do.
What a review actually changes
The point of looking isn’t to produce a scary list. It’s to convert a black box into a ranked, finite set of decisions: here’s what’s costing you, here’s what’s risky, here’s what to fix first, and here’s roughly what each fix is worth. Most of what I find is cheap to fix and was simply invisible. The expensive part was not knowing.
If two or more of these signs landed, that’s usually the moment a fixed-price, read-only Well-Architected & Cost Review pays for itself — an expert second opinion across all six pillars, with a deliberate emphasis on cost, and no open-ended retainer. You get the ranked list and the dollar figures; what you do with them is up to you.