Cloud infrastructure
Mendral + AWS
Investigate CloudWatch, ECS, EKS, Lambda, and RDS without leaving your CI run.
Or book a 15-min demo and we'll wire AWS into a live investigation.
When a deploy fails or a CI job blows up touching AWS infrastructure, Mendral connects to your AWS account and pulls the data the agent needs to root-cause it. CloudWatch logs filtered by request ID, alarm history around the deploy window, ECS task exit codes, Lambda error logs, RDS slow-query stats — all read into the same investigation thread that started with the failing CI job. The triage that used to mean three terminals and five browser tabs happens inline.
What the agent can investigate
The AWS skill adds these surfaces to every Mendral investigation that touches AWS.
Query log groups by time range, filter pattern, request ID, or trace ID. The agent retrieves only the lines needed to support its current hypothesis.
Read alarm state history around an investigation window and pull metric samples to test whether a regression is correlated with a deploy.
Inspect task definitions, exit codes, container last-state reasons, and service events. Common path for diagnosing canary failures and rollbacks.
Instance status checks and security-group context for EC2; function metadata, error logs, and Dead Letter Queue messages for Lambda.
Instance events, parameter group context, and slow-query log excerpts when a deploy correlates with a database regression.
Resolves the principal that hit a permission error so the agent can name the missing policy in its proposed fix.
How it works
The agent receives an AWS skill that wraps the AWS SDK with read-only API access by default. Investigations triggered by CI failures, Sentry webhooks, or a connected monitor can pull AWS state without an engineer pivoting to the console. Every API call the agent makes is recorded against the investigation ID for audit.
Connect via cross-account IAM role with an external ID (recommended), or scoped access keys. Permissions are read-only at install time; you choose which accounts, regions, and resource ARN prefixes Mendral can see.
Example investigation
A canary deploy to ECS fails in CI. The build job times out waiting for the new task to become healthy.
- 1
Identifies the failing ECS service from the deploy script.
- 2
Pulls the most recent task's stoppedReason: OutOfMemoryError, container killed due to memory usage.
- 3
Diffs the task definition's memory limit before and after the latest commit. Finds it was lowered from 2048 MB to 1024 MB three days ago in PR #4192.
- 4
Pulls 30 days of CloudWatch container memory metrics. Typical RSS: ~1.4 GB.
- 5
Opens a PR reverting the memory change with the metric data attached as evidence.
PR ready before the on-call engineer finished reading the Slack alert.
Frequently asked
Does Mendral need write access to my AWS account?
No. The default permission set is read-only. The agent never modifies AWS resources — fixes are proposed as pull requests in your repo.
Which AWS services are covered?
CloudWatch (Logs, Alarms, Metrics), ECS, EKS, EC2, Lambda, RDS, and the IAM context required to interpret permission errors. We add new services as the agent encounters investigations that need them.
How is authentication handled?
Cross-account IAM role with an external ID is the recommended setup. Access keys are supported and rotated through your existing secret store.
Is data exfiltrated from AWS?
No. Logs and metrics are read into the agent's working context for the duration of the investigation and discarded afterward. Nothing is persisted in long-term storage outside your AWS account.
Can I scope which AWS accounts Mendral can read?
Yes. Permissions can be narrowed to specific accounts, regions, and resource ARN prefixes per workspace.
Put AWS context
in every investigation.
Five-minute install. AWS connects from the workspace settings. First enriched investigation runs on the next CI failure.
Or book a 15-min demo with the founders.