From Checks to Context: How AWS DevOps Agent and Trusted Advisor Work Together to Prevent Incidents
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
| Dimension | Trusted Advisor | DevOps Agent Proactive Prevention |
|---|---|---|
| Input signal | Current resource configuration | Historical incident investigations |
| Check type | Predefined best-practice catalog | Dynamic, learned from your incidents |
| Scope | AWS resources only | AWS, multicloud, on-premises |
| Personalization | Same checks for everyone | Unique to your incident patterns |
| Update frequency | Checks refresh periodically | Weekly evaluations (or on-demand) |
| Categories | 6 pillars | 4 categories |
| Actionability | Fix a specific resource | Prevent a class of incidents |
| Implementation guide | Links to documentation | Agent-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
| Scenario | Use |
|---|---|
| New account setup, establishing guardrails | Trusted Advisor |
| Post-incident, preventing recurrence | DevOps Agent |
| Compliance baseline checks | Trusted Advisor |
| Reducing repeat incidents across your team | DevOps Agent |
| Service quota approaching limits | Trusted Advisor |
| Identifying observability gaps from real failures | DevOps Agent |
| Broad infrastructure hygiene sweep | Both |
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
- Language
- English
Relevant content
- Accepted Answer
asked a month ago
AWS OFFICIALUpdated a month ago
AWS OFFICIALUpdated 2 years ago