skip to content

What does AWS Trusted Advisor check, how does your AWS Support plan change what you see, and why is it not a substitute for a Well-Architected Review?

level: middleimportance: should knowfreq 42%

answer

  1. It reads account configuration, not design
  2. Categories include cost, security, fault tolerance, limits
  3. What you see depends on your Support plan
  4. Full catalogue needs a paid plan
  5. A rules engine cannot judge requirements

basics

~20 s

AWS Trusted Advisor runs curated checks over an account's configuration and usage across categories including cost optimization, performance, security, fault tolerance, service limits and operational excellence. Basic and Developer Support see only a subset; the full catalogue needs Business, Enterprise On-Ramp or Enterprise Support.

solid answer

~50 s

Trusted Advisor inspects what is actually configured in your account and flags it against a fixed catalogue of checks, grouped into categories such as cost optimization, performance, security, fault tolerance, service limits and operational excellence. Typical findings are under-utilised instances, idle load balancers, security groups open to the world, missing MFA on the root user, and quotas you are close to. Access is gated by Support plan: Basic and Developer accounts see only a limited subset, mostly service quota and a few security checks, while Business, Enterprise On-Ramp and Enterprise Support unlock the whole catalogue plus programmatic access; Trusted Advisor Priority, the curated feed your account team drives, is Enterprise Support only. It is not a substitute for a review because it evaluates *resources against generic rules* and knows nothing about your requirements. It cannot tell you that a single-Region design is wrong for a workload with a cross-Region recovery objective — only a design conversation does that.

code

bash · 10 lines
bash
aws support describe-trusted-advisor-checks \
  --language en \
  --region us-east-1 \
  --query "checks[?category=='fault_tolerance'].[id,name]" \
  --output table

aws support describe-trusted-advisor-check-result \
  --check-id CHECK_ID_FROM_ABOVE \
  --language en \
  --region us-east-1

go deeper

for a junior

Know that Trusted Advisor inspects your account against AWS's own checks across categories such as cost, security, fault tolerance and service limits, and that it reports findings rather than fixing anything.

for a middle

Be ready to explain the Support-plan gating precisely, and to say why a green result is a narrow statement about configuration rather than a claim about the workload's design.

for a senior

Show how you operationalise it: EventBridge rules or CloudWatch metrics so red checks reach a team instead of sitting in a console, and a clear position on which findings you actually act on.

for a principal

Own the question of what an account-level rules engine can and cannot govern. Decide where Trusted Advisor, Config rules, Security Hub and a Well-Architected Review each belong, and avoid paying three times for the same finding.

## What it is Trusted Advisor is a rules engine AWS runs over your account. It periodically inspects resource configuration and usage, compares it against a curated catalogue of checks, and colours each one green, yellow or red with the offending resources listed. There is no agent, no instrumentation and nothing to configure — it reads what your account already exposes through service APIs. ## The check categories Checks are grouped into categories: **cost optimization** (under-utilised EC2 instances, idle load balancers, unassociated Elastic IP addresses, idle database instances), **performance**, **security** (security groups allowing unrestricted access, permissive S3 bucket permissions, missing MFA on the root user, ageing access keys), **fault tolerance** (missing backups, single-AZ deployments of things that support more), **service limits**, and **operational excellence**, which was added later than the original five. The catalogue is AWS's, not yours. You cannot add a check, and the exact set moves over time as AWS adds and retires them — which is a reason to describe the categories in an interview rather than reciting check names. ## Support-plan gating This is the part interviewers probe, because it decides whether Trusted Advisor is useful to you at all. - **Basic and Developer Support**: a limited subset only — service quota checks and a small number of security checks. - **Business, Enterprise On-Ramp and Enterprise Support**: the full check catalogue, plus programmatic access through the AWS Support API (`DescribeTrustedAdvisorChecks`, `DescribeTrustedAdvisorCheckResult`) and the Trusted Advisor API, and organisational views across accounts. - **Enterprise Support only**: Trusted Advisor Priority, where your AWS account team curates and prioritises recommendations for you rather than handing you a flat list. The AWS Support API is only available in `us-east-1`, so a script that queries it from another Region fails for reasons that look nothing like a permissions problem. ## Getting the findings out of the console Trusted Advisor publishes metrics to CloudWatch in the `AWS/TrustedAdvisor` namespace — including counts of red, yellow and green checks and a `ServiceLimitUsage` metric — and emits EventBridge events when a check's status changes. That is how you turn it from a page somebody remembers to open into something that reaches a team channel. Checks refresh on their own schedule and can be refreshed manually, but not continuously, so a finding can be stale by hours; never treat a green check as a real-time assertion. ## Why it is not a review Trusted Advisor answers "is anything in this account configured in a way AWS knows is usually wrong?" A Well-Architected Review answers "is this workload the right design for what the business needs?" The gap between those is the whole point. Trusted Advisor has no idea what your workload does. It cannot know that the single-AZ database it flagged is a scratch environment where that is correct, or that the multi-AZ database it approved still fails your recovery objective because the failover has never been tested. It cannot see that your service has no runbook, that deployments are manual, or that one engineer is the only person who understands the queue topology. None of that is a resource attribute, so no rules engine will find it. The honest framing: Trusted Advisor is evidence, and a good review *uses* it. The Well-Architected Tool surfaces relevant Trusted Advisor checks next to design questions for exactly that reason — when you claim you follow a best practice, the account-level evidence is right there. But the claim is a design decision, and only people can make it. ## Where it genuinely earns its keep Three places. First, **service limits** — an always-on view of quotas you are approaching, though Service Quotas is the authoritative and more complete source. Second, **cheap security hygiene** — root MFA, wide-open security groups and public buckets are findings you want the moment they appear, wired to EventBridge rather than checked quarterly. Third, **first-pass cost waste** — idle load balancers and unattached volumes are money you are burning for nothing, and the check finds them without any analysis effort. What it will not do is tell you your architecture is wrong.

  • You want a Slack alert the moment a Trusted Advisor security check goes red. How would you wire that?
    Trusted Advisor emits check status change events to EventBridge, so you write a rule matching those events and target a Lambda function or an SNS topic that posts to Slack. It also publishes red, yellow and green check counts to CloudWatch in the `AWS/TrustedAdvisor` namespace if you would rather alarm on aggregate counts. Both need a Support plan that exposes the checks.
  • Trusted Advisor shows all green across the security category. What have you actually learned?
    That the account passes the specific configuration rules in AWS's catalogue — no wide-open security groups, root MFA present, and so on. It says nothing about your application's authorization logic, your secrets handling, your dependency risk, or whether the design is right. Green is the absence of a small set of known-bad configurations, not the presence of security.
  • How does Trusted Advisor relate to a Well-Architected Review in practice?
    It is evidence feeding the review. The Well-Architected Tool surfaces relevant Trusted Advisor checks next to design questions, so when a team claims it follows a best practice the account-level facts sit alongside the claim. The review still has to make the judgment — Trusted Advisor supplies observations, not requirements.

Trusted Advisor is a smoke detector: cheap, always on, and it only tells you about the specific things it was built to smell. A Well-Architected Review is the building inspection that asks whether the fire exits are in the right place at all.

saying these in an interview costs you the question

  • Assumes every account sees the full check catalogue
  • Treats a green Trusted Advisor as proof the workload is secure
  • Thinks Trusted Advisor remediates findings automatically
  • Uses it as the authoritative source for every service quota
  • Believes its checks are evaluated in real time

context

resolving links…