Skip to content

From Checks to Context: How AWS DevOps Agent and Trusted Advisor Work Together to Prevent Incidents

6 minute read
Content level: Intermediate
0

Explains how TA (static best-practice checks) and DevOps Agent (incident-pattern analysis) complement each other for layered incident prevention.

From Checks to Context: How AWS DevOps Agent and Trusted Advisor Work Together to Prevent Incidents

Introduction

AWS Trusted Advisor and AWS DevOps Agent both aim to improve your operational posture, but they approach the problem from fundamentally different angles. Trusted Advisor evaluates your environment against a catalog of predefined best-practice checks. DevOps Agent analyzes patterns across your actual incident history to generate recommendations specific to your workloads.

Used together, they create a layered prevention strategy: Trusted Advisor catches configuration drift against established rules, while DevOps Agent identifies emergent patterns that no predefined check could anticipate.

Important: There is no native integration between Trusted Advisor and DevOps Agent today. The complementary value comes from using both services independently as part of your operational workflow.

This article explains how each service generates recommendations, where they complement each other, and how to use both effectively.

How Trusted Advisor Generates Recommendations

Trusted Advisor continuously evaluates your AWS environment against predefined checks across six pillars:

  • Cost Optimization — Idle resources, underutilized instances, unassociated Elastic IPs
  • Performance — Over-provisioned resources, CloudFront configuration, EBS throughput
  • Security — Open security groups, IAM best practices, MFA on root
  • Fault Tolerance — Multi-AZ deployments, backup configurations, health check gaps
  • Service Limits — Resources approaching quota limits
  • Operational Excellence — Logging, monitoring, deletion protection

These checks apply universally regardless of your application's specific behavior or incident history. This makes them reliable for catching known anti-patterns but unable to detect novel risk patterns unique to your workloads.

You can retrieve Trusted Advisor findings programmatically to establish your operational baseline:

# List available Trusted Advisor checks in the fault_tolerance category
aws support describe-trusted-advisor-checks --language en \
  --query 'checks[?category==`fault_tolerance`].[id,name]' \
  --output table

# Get results for a specific check
aws support describe-trusted-advisor-check-result \
  --check-id "your-check-id" \
  --query 'result.flaggedResources[*].[metadata]' \
  --output table

This gives you a snapshot of where your environment deviates from established best practices — your starting point before layering in incident-driven insights.

How DevOps Agent Generates Recommendations

DevOps Agent's proactive prevention feature takes a fundamentally different approach. It analyzes your actual incident investigations — correlating telemetry, code changes, deployment history, and root causes — to identify improvements that would prevent entire classes of incidents.

Evaluations run automatically on a weekly cadence (or on-demand), and recommendations are categorized into four areas:

  • Observability — Monitoring gaps, missing alerts, insufficient logging that delayed detection
  • Infrastructure — Resource configuration issues, capacity gaps, architectural weaknesses
  • Governance — Deployment pipeline gaps, missing tests, inadequate operational controls
  • Code Optimization — Error handling deficiencies, resilience gaps in application code

Each recommendation is informed by real incidents your team experienced. The system prioritizes using AI-powered ranking combined with incident frequency, severity, and recency.

For recommendations that involve code or configuration changes, DevOps Agent generates agent-ready specifications. These structured documents include the problem statement, solution summary, target repositories, specific file paths, test requirements, and a phased implementation plan. You can hand these directly to a coding agent for implementation.

Side-by-Side Comparison

DimensionTrusted AdvisorDevOps Agent Proactive Prevention
Input signalCurrent resource configurationHistorical incident investigations
Check typePredefined best-practice catalogDynamic, learned from your incidents
ScopeAWS resources onlyAWS, multicloud, on-premises
PersonalizationSame checks for everyoneUnique to your incident patterns
Update frequencyChecks refresh periodicallyWeekly evaluations (or on-demand)
Categories6 pillars4 categories
ActionabilityFix a specific resourcePrevent a class of incidents
Implementation guideLinks to documentationAgent-ready specs for coding agents

Where They Complement Each Other

Trusted Advisor catches what you missed in configuration.

Example: An RDS instance without Multi-AZ enabled. Trusted Advisor flags this regardless of whether you have ever had a database incident. It is a known best practice.

DevOps Agent catches what predefined checks cannot see.

Example: The agent might identify that your last three incidents all stemmed from deployment rollouts lacking canary analysis. No predefined check would detect this because it requires correlating incident patterns with your deployment pipeline.

Together, they form a prevention funnel:

+---------------------------------------------+
|  Trusted Advisor                            |
|  "You have resources that don't follow      |
|   established best practices"               |
|  -> Fix known configuration anti-patterns   |
+----------------------+----------------------+
                       |
                       v
+---------------------------------------------+
|  DevOps Agent Proactive Prevention          |
|  "Based on your last 12 incidents, these    |
|   3 changes would prevent 8 of them"        |
|  -> Eliminate your specific failure modes   |
+---------------------------------------------+

Practical Workflow: Using Both Services

Step 1: Establish your baseline with Trusted Advisor

Review Trusted Advisor findings across all pillars. Address critical and warning items, particularly in Security and Fault Tolerance. This eliminates known risks before looking for novel ones.

Step 2: Onboard your application into DevOps Agent

Connect your AWS accounts, observability tools (CloudWatch, Datadog, Splunk, Dynatrace, New Relic), code repositories, and CI/CD pipelines. The more context DevOps Agent has, the more accurate its incident correlations become.

Step 3: Let incident history accumulate

DevOps Agent's proactive prevention becomes more valuable as it processes more investigations. After several incidents, the weekly evaluation cycle begins surfacing patterns.

Step 4: Triage recommendations from both sources

  • Trusted Advisor findings: address as configuration hygiene (often quick fixes)
  • DevOps Agent recommendations: address as architectural or process improvements (use agent-ready specifications to accelerate implementation)

Step 5: Measure impact

Mark DevOps Agent recommendations as "Implemented" to track effectiveness. Compare incident frequency before and after addressing both Trusted Advisor findings and DevOps Agent recommendations.

When to Use Which

ScenarioUse
New account setup, establishing guardrailsTrusted Advisor
Post-incident, preventing recurrenceDevOps Agent
Compliance baseline checksTrusted Advisor
Reducing repeat incidents across your teamDevOps Agent
Service quota approaching limitsTrusted Advisor
Identifying observability gaps from real failuresDevOps Agent
Broad infrastructure hygiene sweepBoth

Conclusion

Trusted Advisor and DevOps Agent proactive prevention are not competing services. They address different layers of operational risk. Trusted Advisor provides universal guardrails based on AWS collective experience. DevOps Agent provides personalized recommendations based on your team's specific incident history.

The most effective operational teams use both: Trusted Advisor to maintain a strong baseline, and DevOps Agent to continuously close gaps that only manifest through real-world failures.

Related Resources