How to Use AWS Trusted Advisor in 2026: Pricing & Checks

Every AWS account ships with Trusted Advisor already on, and most engineers only ever see six checks before assuming that's the whole tool. It isn't. What you get, how current the data stays, and whether you can automate any of it depends on which support plan sits behind the account, and AWS restructured that lineup at the end of 2025.

Knowing how to use AWS Trusted Advisor past those six defaults is where it earns its keep: what your plan unlocks, how to read the console without mistaking stale-but-defensible data for a bug, how to automate findings with the right IAM setup, how to roll it out across an Organization, and when the cost tab shows the whole picture. For the full check-by-check list, keep the AWS Trusted Advisor Cheat Sheet open alongside this guide.

What Trusted Advisor Checks (and What It Doesn't Fix)

Trusted Advisor evaluates your account against six categories: Cost optimization, Performance, Security, Fault tolerance, Service limits, and Operational Excellence. Operational Excellence is the newest addition, added October 26, 2023, alongside 64 new checks powered by an AWS Config integration. AWS's marketing pages now also describe the categories using the word "resilience," but the console navigation and the official check-reference page still label the category Fault tolerance. Treat "resilience" as descriptive language layered on top of the existing category, not a formal rename.

The current technology page puts the total check count at approximately 480 (56 available to every account, roughly 426 more unlocked by a paid plan). Treat that as a marketing snapshot, not a number to cite in a compliance document; it has grown before and will grow again.

The distinction that matters more than any check count: Trusted Advisor finds, it doesn't fix. AWS's own guidance is direct about this: review findings regularly and remediate issues yourself. Every red flag is a recommendation, not an automated action. If you're expecting Trusted Advisor to close an open security group or delete an idle volume on its own, it won't; you build that automation yourself, typically off an EventBridge event (covered below).

That boundary also means Trusted Advisor isn't trying to replace AWS Config, Security Hub, or Inspector. Each of those does continuous, deeper evaluation in its own lane. Trusted Advisor's value is breadth across cost, security, performance, and quotas in one dashboard, not depth in any single one; the FAQ below draws that line more precisely.

What Your AWS Support Plan Actually Gets You

This is the section most existing guides get wrong, because AWS restructured its support plans in a December 2025 transformation. If you're picturing Developer, Business, Enterprise, or Enterprise On-Ramp, those plan names are already on a retirement clock.

The current commercial-region lineup is four plans: Basic (free), AWS Business Support+, AWS Enterprise Support, and AWS Unified Operations. Developer Support, the old Business Support tier, and Enterprise On-Ramp are all being discontinued on January 1, 2027. Existing customers can stay until then or upgrade early, and all three remain available indefinitely in AWS GovCloud (US), which the restructuring didn't touch. If you're budgeting for 2027, check this line item now.

All three paid tiers charge whichever is greater: the flat minimum, or the tiered percentage of your monthly AWS bill before credits and discounts. Business Support+ bills per account; Enterprise Support and Unified Operations bill on aggregate spend across every subscribed account. AWS's own worked example: an account spending $20K/month on Business Support+ pays $10K × 9% + $10K × 7% = $1,600/month, well above the $29 floor once your bill has any real size. Enterprise Support carries a 30-day minimum commitment; Unified Operations requires 90 days.

The free tier isn't nothing. Basic Support gets every Service Limits check, regardless of plan, plus six named Security and Fault Tolerance checks. Which six checks those actually are depends on which AWS page you read (more in the FAQ). The real catch on Basic Support is refresh behavior: there's no automatic refresh at all. You click the per-check refresh icon yourself, so a Basic-tier account's data is only ever as current as the last manual click.

Cross into Business Support+ or higher and two things change together: the full check set replaces the free six-plus-quotas, and checks refresh automatically on a weekly cycle in addition to manual and API-triggered refresh. That's also where the Trusted Advisor API and CLI open up. A Basic-tier account calling either gets a SubscriptionRequiredException or an access-denied response, full stop.

How to Use the Trusted Advisor Console: Reading and Acting on Recommendations

Open the console at console.aws.amazon.com/trustedadvisor/home and you land on the Recommendations page, organized by category with color-coded status: red (action recommended), yellow (investigation recommended), and gray (checks with excluded items). Drill into a category and green appears too, for checks with no problems detected. Each check shows its alert criteria, a recommended action, and a table of affected resources.

Read the "Checks with excluded items" count cautiously. It isn't a severity signal, just a count of checks with resources you've deliberately suppressed from evaluation. A check can show zero problems and still carry a nonzero excluded-items count.

Excluding and re-including resources

Suppressing a known-acceptable finding, a public S3 bucket that's intentionally a static site, say, follows a repeatable pattern:

1. Open the check, select the resource, click Exclude & Refresh.
2. Review everything suppressed under the Excluded items tab.
3. To restore a resource: Excluded items, select it, Include & Refresh.

Programmatically, this runs through the Trusted Advisor API's BatchUpdateRecommendationResourceExclusion operation, with one documented exception: Trusted Advisor Priority recommendation resources cannot be excluded this way. Standard checks can; Priority findings can't be silenced through this API.

Filtering, downloading, and reading stale data correctly

Category pages support keyword search, a status filter, and tag filtering if your resources carry tags, useful for scoping a review to one team or one environment without wading through the whole account. Every check has a download button that exports an .xls file, plus a top-level "Download all checks" option for a full export.

Before flagging a check as stale, check which of four defensible reasons applies: Basic Support checks never auto-refresh; paid-plan checks refresh weekly by default, so a week-old flag is expected, not a bug; Compute Optimizer- and Cost Optimization Hub-powered checks reject manual and API refresh requests entirely and can take a few hours (up to 48 right after opt-in) to update on their own schedule; and Security Hub CSPM-sourced controls refresh from Security Hub itself, not from Trusted Advisor. A per-check cooldown also exists on top of all this (the API's millisUntilNextRefreshable field proves it), but AWS doesn't document the exact cooldown length, so don't build automation that assumes a specific number of minutes between refreshes.

Automating Trusted Advisor: IAM Permissions, the API, and EventBridge Alerts

Clicking through the console every week doesn't scale past a handful of accounts. This is also where most first automation attempts break. Trusted Advisor's IAM permissions split across two separate namespaces, and neither grants access to the other.

The two-namespace trap

The trustedadvisor namespace controls the Trusted Advisor console and the newer Trusted Advisor API (DescribeChecks, RefreshCheck, ExcludeCheckItems). The support namespace controls the older AWS Support API, including its Trusted Advisor operations (DescribeTrustedAdvisorChecks, RefreshTrustedAdvisorCheck). Granting trustedadvisor:* does not grant Support API access, and granting support:* does not grant full Trusted Advisor console access; AWS's own docs call this out explicitly. It's the most common cause of "my script works but the console shows nothing" tickets.

A read-only console policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["trustedadvisor:Describe*", "trustedadvisor:Get*", "trustedadvisor:List*"],
      "Resource": "*"
    }
  ]
}

An API-only policy that denies the case-management side of the Support API, so a service account can pull Trusted Advisor data without also opening support cases:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "support:DescribeTrustedAdvisorCheckRefreshStatuses",
        "support:DescribeTrustedAdvisorCheckResult",
        "support:DescribeTrustedAdvisorChecks",
        "support:DescribeTrustedAdvisorCheckSummaries",
        "support:RefreshTrustedAdvisorCheck",
        "trustedadvisor:Describe*",
        "trustedadvisor:Get*",
        "trustedadvisor:List*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "support:AddAttachmentsToSet", "support:AddCommunicationToCase", "support:CreateCase",
        "support:DescribeAttachment", "support:DescribeCases", "support:DescribeCommunications",
        "support:DescribeServices", "support:DescribeSeverityLevels", "support:ResolveCase"
      ],
      "Resource": "*"
    }
  ]
}

Describe* alone is the trap worth calling out here. The newer Trusted Advisor API's read operations are ListChecks, ListRecommendations, and GetRecommendation, which are separate IAM actions that no amount of trustedadvisor:Describe* covers, so a policy stopping at Describe* denies the very aws trustedadvisor list-checks call in the next section.

Run either policy through the AWS IAM Policy Validator before attaching it to catch malformed JSON and grants broader than you meant. Don't expect it to catch a namespace mismatch: support:* and trustedadvisor:* are both valid IAM syntax, so a policy granting one while your code calls the other validates cleanly and still fails at runtime. For that, match the namespace to the API you're actually calling and confirm with aws iam simulate-principal-policy against the exact action name.

Which API to actually build against

Two programmatic surfaces exist. The AWS Support API (support namespace) is the original one, dating back to roughly 2013, bundling Trusted Advisor operations alongside support-case management. The newer AWS Trusted Advisor API (trustedadvisor-2022-09-15) is Trusted-Advisor-only, with richer per-check metadata and operations like ListChecks and ListRecommendations. AWS's docs point new integrations toward this newer API without saying the Support API is deprecated, so an existing integration keeps working, but new builds should default to the Trusted Advisor API.

Both APIs require a paid support plan and are throttled: 5 requests/second per supported Region for the Support API, 100 for the Trusted Advisor API. Exceeding either returns a ThrottlingException. Polling dozens of accounts from a scheduled Lambda? Batch and back off; the Support API's limit disappears fast at scale.

Read "per supported Region" carefully on the Support API, because it implies more Regions than you get. Support publishes three regional endpoints (us-east-1, us-west-2, eu-west-1) and case operations sync across all of them, but its Trusted Advisor operations run only through US East (N. Virginia). A legacy client pointed at Oregon or Ireland manages cases perfectly well and fails the moment it calls DescribeTrustedAdvisorChecks. Pin those clients to us-east-1.

aws trustedadvisor list-checks

{ "checkSummaries": [{ "name": "Security Groups - Unrestricted Access", "pillars": ["security"], "checkGranularity": "resource" }] }

EventBridge over polling

Trusted Advisor sends events to your account's default EventBridge bus under source aws.trustedadvisor, with three event types: check-item refresh notifications, and weekly or daily Pursuit digests. Match every event with { "source": ["aws.trustedadvisor"] }. A refresh payload carries the check name, resource details, and a status to branch on:

{
  "detail-type": "Trusted Advisor Check Item Refresh Notification",
  "detail": { "check-name": "Exposed Access Keys", "status": "ERROR" }
}

The base pattern, a rule triggering Step Functions that invokes Lambda to remediate or notify, is well covered elsewhere. What's worth getting right in production is routing: send high-severity events (exposed keys, public snapshots) to paging with dedupe logic, and route low-severity findings (an idle load balancer) to a weekly digest instead. Skip that split and every refresh becomes an alert, and alerts people learn to ignore stop being alerts.

Trusted Advisor also publishes metrics to CloudWatch under AWS/TrustedAdvisor: RedChecks, YellowChecks, RedResources, YellowResources per check, plus ServiceLimitUsage for quotas. These land in US East (N. Virginia) only, so build the alarm in us-east-1 no matter where the rest of the stack lives; from any other Region the namespace isn't there to alarm on. Confirm what you have with aws cloudwatch list-metrics --namespace AWS/TrustedAdvisor --region us-east-1. An alarm on RedResources for IAM Access Key Rotation, threshold >= 1, gives a CloudWatch-native alternative to EventBridge. Paid customers can also subscribe to a weekly findings email, though it excludes Priority results, which use their own notification configuration.

Rolling Trusted Advisor Out Across an AWS Organization

A single account's Trusted Advisor view doesn't scale to twenty accounts logged into separately. Organizational view solves that, with one real prerequisite and one caveat that catches teams off guard.

Prerequisites: your AWS Organization needs all features enabled (not just consolidated billing), and the management account needs Business Support+, Enterprise Support, or Unified Operations. From the management account, go to Trusted Advisor's Preferences, then Your organization, and toggle on trusted access. That registers Trusted Advisor as a trusted service and creates the AWSServiceRoleForTrustedAdvisorReporting role.

The CLI for registering a delegated administrator (a distinct mechanism from Priority's own delegated-admin registration, using a different service principal):

aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal reporting.trustedadvisor.amazonaws.com

That branch point matters before you build a leadership dashboard on an org report: enabling organizational view does not upgrade what any member account contributes. An account still on Basic Support only ever contributes Basic-tier data, and nobody can force-refresh it remotely; someone has to sign into that specific account and click refresh. An org-wide report across mixed support tiers can understate real risk, since it silently omits checks lower-tier accounts were never entitled to run. Presenting one as coverage evidence? Confirm every account in scope is on a paid plan first.

Reports generate from Organizational View, then Create report, filterable by Region, category, specific checks, resource status, and OUs/accounts. You can store up to 50 reports (the 51st deletes the oldest, unrecoverably), only one generates at a time, and downloads come as a .zip with a summary, a schema file, and per-resource CSV or JSON data; large reports split into multiple files past 5 MB.

Trusted Advisor Priority: When Your Account Team Gets Involved

Priority is a different tier of feature entirely, and it isn't self-service the way the rest of Trusted Advisor is. It surfaces prioritized, context-aware recommendations, some machine-generated from Trusted Advisor checks, Security Hub, the Well-Architected Tool, and Compute Optimizer signals, and some manually curated by your AWS account team based on things only they know about your environment, like a planned migration or an upcoming launch.

Eligibility is narrower than the rest of the full check set: Priority requires Enterprise Support or Unified Operations specifically. Business Support+ does not qualify, even though it gets the same full check set otherwise. Priority also isn't a toggle you flip yourself: you have to contact your AWS account team to request activation. Your organization needs all-features Organizations plus trusted access enabled, same as standard organizational view.

Once active, recommendations move through an acknowledge, resolve or dismiss, reopen lifecycle, and the management account can register up to 5 delegated administrator accounts to review and act on Priority recommendations without needing management-account access for every review. If you're weighing whether Priority matters at your incident volume, that 5-account cap is worth knowing before you assume it maps onto however many regional or business-unit admins you'd want.

Trusted Advisor vs. AWS Compute Optimizer: When to Use Each

If you've wondered why Trusted Advisor's cost tab shows exactly one recommendation for an oversized EC2 instance instead of several ranked options, you're looking at the tail end of a pipeline, not an independent analysis.

Compute Optimizer's resource coverage is broader than most engineers assume. Beyond EC2, EBS, and Lambda, it now covers EC2 Auto Scaling groups, ECS on Fargate, RDS and Aurora, NAT Gateway, DynamoDB, ElastiCache, MemoryDB, DocumentDB, WorkSpaces, SageMaker endpoints, and Microsoft SQL Server licenses on EC2. It works by analyzing historical CloudWatch utilization metrics with machine learning instead of static thresholds. For EC2 instances, Auto Scaling groups, and RDS DB instances specifically, you can choose a 14-day lookback (default, free), 32 days (free, added to catch monthly patching and maintenance cycles a 14-day window misses), or 93 days (paid, requires Enhanced Infrastructure Metrics). AWS's FAQ doesn't extend those 32/93-day options to newer idle-detection resource types like NAT Gateway or DynamoDB; those stay on the fixed 14-day window.

Compute Optimizer itself has no separate service charge; you pay only for the resources it analyzes and standard CloudWatch fees. The one paid add-on, Enhanced Infrastructure Metrics for the 93-day lookback, runs roughly $0.25 per resource per month for continuous usage.

The dependency chain nobody draws

Opt in to Compute Optimizer, and four specific Trusted Advisor checks (EBS over- and under-provisioned volumes, Lambda over- and under-provisioned memory; check IDs COr6dfpM03 through COr6dfpM06) start pulling their data directly from it instead of Trusted Advisor's older independent logic. AWS explicitly recommends migrating off the older EBS checks once opted in, and as of February 2026 an unused-NAT-Gateway check joined this Compute-Optimizer-powered group too. These checks auto-refresh at least once daily and reject manual refresh requests entirely; expect up to 12 hours for findings to generate after opt-in and up to 48 hours before they surface in Trusted Advisor.

Go up one more level and the chain becomes clear. AWS Cost Optimization Hub is a free feature of AWS Billing and Cost Management that consolidates and deduplicates cost recommendations from multiple sources, including Compute Optimizer's rightsizing data, and applies your account's actual discounts so the savings estimate is real rather than list-price. To get the newer, Cost-Optimization-Hub-powered checks (AWS's framed replacement for "legacy" TA cost logic), opt in to both Compute Optimizer and Cost Optimization Hub; the Hub itself depends on Compute Optimizer for its rightsizing data. Expect up to 24 hours before new checks populate. Already opted into both on Business Support+ or higher? They apply automatically.

That answers the "why only one recommendation" question: the cost tab isn't hiding options, it's built to surface just the top action per resource. For the full picture, go to Cost Optimization Hub directly rather than treating the cost tab as your primary FinOps source.

The practical rule: run Trusted Advisor continuously as your governance tripwire, since it's the only one of the two that touches security posture and quotas at all. Opt in to Compute Optimizer and Cost Optimization Hub for accurate rightsizing, and treat the cost tab as a pointer into that richer data. Whichever tool generates a recommendation, validate it against actual traffic before shipping the change.

Should You Upgrade Your Support Plan for Trusted Advisor?

The honest answer depends on three concrete triggers, not a vague "it depends."

Account count and automation need. Past a couple of accounts, manually refreshing Basic-tier checks in each one stops being viable, and Basic Support has no API access to fall back on. Business Support+'s $29/month-per-account floor is a low bar for what it unlocks: the full check set, weekly auto-refresh, both APIs. For most teams past a single account, this is the easiest upgrade decision in the lineup.

Whether the free six checks are already surfacing real findings. If Basic Support's named checks and your Service Limits checks keep flagging things you can't act on without the other roughly 426 checks (fault-tolerance gaps, performance recommendations, operational excellence findings), that's a signal the free tier is undersizing your actual risk, not that Trusted Advisor has nothing more to offer.

Whether Priority's account-team involvement is worth $5,000/month. Enterprise Support's minimum buys Priority, a designated TAM, and faster response times, a real jump from Business Support+. It pays off where a dismissed finding is genuinely expensive: regulated workloads, high-incident-volume environments, teams that want an AWS engineer's judgment on a curated recommendation rather than a dashboard alone. Without that risk profile, Business Support+ covers the operational need without the five-figure commitment.

None of this requires guessing. Count your accounts, look at what your free-tier checks already tell you, and be honest about how expensive a missed finding is at your scale. A cost optimization checklist helps frame the decision if you're weighing this against other FinOps maturity work.

Frequently Asked Questions

Key Takeaways: How to Use AWS Trusted Advisor Going Forward

Five things to carry forward: confirm what your plan unlocks before assuming a check is missing; treat the free six checks and the roughly 480-check paid set as a floor, not a ceiling; remember the cost tab's "one recommendation" is Cost Optimization Hub's top pick, not the full analysis; automate refresh and alerting through the Trusted Advisor API and EventBridge past a handful of accounts, using the two-namespace IAM split correctly the first time; and put January 1, 2027 on a calendar if you're still on a legacy plan.

Haven't opened the console past the default six checks? Start there, then work through the pricing table above. Already know your plan well? Decide what to do with what it's telling you, and keep the AWS Trusted Advisor Cheat Sheet open alongside this guide for the full check-by-check reference.