Traversal Now Sees Your AWS Stack: Introducing CloudWatch and AWS Account Integrations

Blog

Table of Contents

Written By

Traversal

Traversal is an AI SRE platform that helps engineering teams investigate incidents and keep production running reliably at some of the world’s leading enterprises. To do that, it needs the same view of production your engineers have, and for most of our customers, much of that view lives in AWS.

Today we’re launching new integrations that give Traversal a direct view into your AWS environment: Amazon CloudWatch and AWS Account. It’s the latest in a series of enterprise readiness launches rolling out over the next few weeks.

See Traversal in action today.

‍

Why AWS context matters

Traversal’s investigations are only as good as the context behind them. Traversal already reasons over telemetry (metrics, events, logs, and traces); the code and deploys that change your systems; and tribal knowledge: tickets and team-specific docs your org keeps in tools like Linear, Notion, and Slack.

Direct AWS access adds another layer of depth. For systems running on AWS, the cause of an incident sometimes sits in the infrastructure itself, even when the symptoms show up somewhere else. Application telemetry can show you a timeout, but the explanation might live in a security group rule, a route table, or a load balancer’s target group. With direct AWS access, Traversal can go straight to that configuration and confirm the root cause.

These integrations also enrich Traversal’s Production World Model™, a living map of your entire production environment and how everything within it connects. AWS Account brings your infrastructure into the Production World Model™, down to the resources in each account and how they’re configured and connected. Every investigation, every question about your environment, and every deploy checked against production starts from a fuller picture of your stack.

What’s launching

Amazon CloudWatch. For many AWS managed services, such as databases, load balancers, and serverless functions, CloudWatch is often the only place their metrics and logs live. The CloudWatch integration brings that telemetry into Traversal natively, so Traversal can reason over it alongside everything else it sees, from application logs to recent deploys. Managed services stop being a blind spot, and CloudWatch stops being a separate console to check.

AWS Account. Through the AWS CLI, Traversal can inventory resources and inspect their configuration across AWS services. It’s built for broad, account-level investigation: what exists, how it’s configured, and how it all connects.

CloudWatch and AWS Account are designed to work together. CloudWatch gives Traversal region-specific telemetry, and AWS Account gives it the wider resource and configuration context around that telemetry. Configure both, and Traversal sees the signal and the system behind it. And because Traversal can already inspect EKS and other Kubernetes clusters directly, it can follow an issue from a pod all the way out to the AWS infrastructure around it.

Built for how you already secure AWS

Both AWS integrations connect through a cross-account IAM role, the standard pattern for giving partners access to AWS data. Traversal assumes that role through AWS STS and mints short-lived credentials for each command, so there are no long-lived access keys to create, store, or rotate. Access is read-only: Traversal observes your environment and never changes it.

That means your security team decides exactly what Traversal can reach, using the same IAM controls they already apply across AWS. Nothing new to learn, and nothing outside the guardrails you’ve already built.

What this looks like in an investigation

Say checkout requests start failing intermittently on a random afternoon.

Without AWS context, the investigation starts and ends in the application layer. The checkout service logs show connection timeouts to the payments service. But the payments service looks healthy: CPU is normal, error rates are flat, and nothing has been deployed in days. The trail goes cold, and an engineer starts clicking through the AWS console by hand, hoping to spot what changed.

With the new integrations, Traversal keeps going. CloudWatch shows rejected connections climbing on the load balancer in front of the payments service. AWS Account lets Traversal inspect that load balancer’s configuration and the security groups around it, where it finds a rule change from earlier that day that narrowed the allowed source range. Looking inside the cluster, Traversal sees the checkout pods were recently rescheduled onto nodes in a subnet that now falls outside that range.

The root cause was never in either service. It was in the network between them, and Traversal can now see it, isolate it, and show the evidence that led there.

The same holds when the problem sits inside a managed service itself. When a database, load balancer, or serverless function is part of the failure, Traversal can investigate it directly, alongside the applications that depend on it.

Traversal and AWS

AWS runs much of the world’s production. Traversal helps teams understand it: what’s running, how it behaves, and what’s going wrong when it doesn’t. And that visibility reaches beyond incidents. The same access that lets Traversal investigate a failure also lets it answer the questions leaders ask about their AWS footprint, like how usage and spend are changing over time.

The relationship works in both directions. Traversal gets the deep system context it needs to investigate faster and more accurately. AWS customers get a clearer picture of the services they rely on, which makes it easier to build on more of the platform with confidence.