What AWS Trusted Advisor checks, and what it structurally cannot
AWS Trusted Advisor gives every account 56 checks; Business Support+ unlocks a further 426 for a total of 482, at a $29/month minimum per account. Checks span six categories: cost optimization, performance, security, fault tolerance, service limits and operational excellence. They evaluate configuration state at a point in time, which means they cannot find defects that only exist in the relationship between a configuration and its live behaviour — where two individually valid settings contradict each other.
Trusted Advisor is the first thing most teams reach for, it is partly free, and it is genuinely good at what it does. It is also the thing TellHound gets compared to most often, so here is an honest account — including the part where you should keep using it.
What you actually get, and for what
Every AWS account gets 56 checks. AWS's own figure. Most of them are service limit checks, plus a short list in security and fault tolerance: EBS and RDS public snapshots, S3 bucket permissions, MFA on the root account, security groups with specific ports unrestricted, and STS global endpoint usage.
Business Support+ unlocks a further 426, for a total of 482, at a $29 per month minimum per account. That is a far lower price umbrella than most comparisons assume, and it is the number worth holding in your head when evaluating anything in this space, including us.
The checks cover six categories:
| Category | Examples |
|---|---|
| Cost optimization | Idle load balancers, underused instances, unassociated Elastic IPs |
| Performance | Over-utilised instances, high-latency configurations |
| Security | Open security groups, public snapshots, missing MFA |
| Fault tolerance | Single-AZ deployments, missing backups, no Multi-AZ |
| Service limits | Approaching an account or regional quota |
| Operational excellence | Practices that make an estate harder to run |
The 2027 change worth knowing about now
AWS has announced end-of-support dates that most write-ups have not caught up with:
- Developer Support is discontinued 1 January 2027
- Business Support is discontinued 1 January 2027
- Enterprise On-Ramp is discontinued 1 January 2027, with customers upgraded to Enterprise Support through 2026 — at a reduced $5,000 minimum, down from $15,000
Existing customers can stay on their plan until then or move to Business Support+ early. If your Trusted Advisor access depends on a Developer or Business plan, that access has a date on it, and it is worth planning for rather than discovering.
What it does well
Do not let anyone talk you out of it:
- Breadth. 482 checks is far more surface than any small vendor will cover, including this one. We have roughly thirty rules. That is not a rounding difference, it is a different kind of product.
- Service limits. Genuinely the best thing in it, and the category most likely to cause an outage you did not see coming. Nothing else watches quotas as an ongoing concern.
- It is already there. No onboarding, no third-party access, no procurement conversation.
If you are not looking at Trusted Advisor, start there before you evaluate anything else.
The one thing it structurally cannot do
Trusted Advisor evaluates configuration state. It reads how a resource is set up and compares that against a best-practice rule. That model finds an enormous amount, and it has a hard boundary: it cannot find a defect that exists only in the relationship between two settings, where each one is individually correct.
The clearest example we have found in production:
Capacity provider: managed scaling ENABLED ← valid configuration
Auto Scaling group: min 2, max 2 ← valid configuration
Both of those are normal, defensible settings. A capacity provider with managed scaling on is what you want. An Auto Scaling group with a fixed size is a perfectly ordinary thing to configure deliberately. No configuration checker will flag either one, because neither is wrong.
Together they describe a tier that makes scaling decisions it is not permitted to carry out. Under load, ECS decides more instances are needed, asks the group, the group has no headroom, and the request is silently discarded. Nothing fails. Nothing alarms. Every dashboard and runbook says the tier is protected by autoscaling. We wrote that one up in full: your ECS capacity provider says managed scaling is on, your ASG says otherwise.
The same shape appears elsewhere:
- A load balancer health check whose matcher accepts 4xx, so a target serving nothing but errors stays in rotation and counts as healthy
- A CDN caching by default with no minimum TTL, so a single origin header turns the whole distribution into a pass-through
- An instance that fell out of its Auto Scaling group and kept running — billing normally, no longer replaced when it fails, and reported by neither console
In each case the individual resources are valid. The defect is the join.
What to do about the gap
You do not need a vendor to check these. Every one is a Describe* call, and
the commands are in the posts linked above and in
what an AWS Well-Architected review actually
checks. Run them
quarterly and you will catch most of it.
The argument for a tool is repetition, not capability: doing that across every account, every day, and noticing when a resource that was fine last week is not any more.
If you are working out which categories of tool you already have and which you are missing, we mapped the whole landscape in AWS monitoring tools: what each kind actually tells you.
Our honest recommendation is to use both. Trusted Advisor for breadth and service limits, at $29/month, which is very hard to beat on value. Something that joins configuration to live behaviour for the class of problem above. Anyone telling you to replace a free-to-cheap, first-party, 482-check product with a thirty-rule one is selling rather than advising.
The short version
- 56 checks on every account; 482 with Business Support+ at $29/month minimum
- Six categories, strongest on service limits
- Developer, Business and Enterprise On-Ramp support plans all end 1 January 2027
- It evaluates configuration state, which means valid-but-contradictory settings are invisible to it by design
- Use it. Then check the joins separately