AWS Investigation
AWSOfficialPublished by AWS
- Skill
- Guidelines
- Cloud and DevOps
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
AWS Investigation provides a rigorous framework for troubleshooting and auditing AWS environments. It emphasizes evidence-based reasoning, requiring that all conclusions be derived directly from verifiable sources such as service logs, deployment artifacts, and query results. The skill mandates strict practices for data completeness, including exhaustive pagination, regional scope verification, and precise aggregate counting, while explicitly separating factual evidence from unverified hypotheses.
What it does
- Traces requests across multiple AWS services to identify failure boundaries.
- Analyzes deployment records to determine the actual state of running configurations.
- Performs exact data investigations, including counts, breakdowns, and joins.
- Verifies the scope of incidents to distinguish between entity-specific and fleet-wide issues.
- Ensures search completeness by checking all relevant regions and data partitions.
- Provides a checklist for validating root causes against collected evidence.
When to use it
- When triaging an active alarm, error spike, or failed request.
- When you need to determine the exact configuration or version of a deployed system.
- When investigating why specific records are failing or unmatched in a data pipeline.
- When you need to confirm the scope of an incident across an entire AWS account.
Advantages
- Reduces reliance on assumptions by enforcing strict evidence provenance.
- Ensures high accuracy in reporting through mandatory pagination and aggregate queries.
- Provides a clear, repeatable process for complex multi-service troubleshooting.
- Prevents common errors like partial data reporting or incomplete regional searches.
Usage examples
- “Why are requests failing for user ID 123 in the us-west-2 region?”
- The agent will list relevant log groups, perform an aggregate query to check if the error is isolated to this user or widespread, and provide a root cause based on the logs.
- “Which version of the application is currently running in production?”
- The agent will inspect the actual deployment artifacts and configuration parameters rather than relying on the latest stored version, confirming the exact version in use.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/aws/aws-investigation/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip aws-investigation.zip -d .agents/skills
Documentation by AWS
AWS Investigation
An investigation answers a question about what an AWS account is doing, and every claim in the answer must come from something you read: a deployed artifact, a service's own log record, or a query result. Inference from names, descriptions, the newest stored version or one service's view of another is a lead, never evidence.
Pick the reference
Read the reference that matches the question before you start; most investigations need more than one.
| The question is about | Read |
|---|---|
| What a deployed system currently does, serves or executes: live configuration, feature flags, parameters, which code runs, reproducing a code path's query, or a first data route that is blocked | references/deployed-artifacts.md |
| A request, alarm or incident that spans several services: tracing one request, counting failed requests, deciding where an event was lost | references/multi-service-logs.md |
| Facts in the account's data: finding where data lives, exact counts and breakdowns, filtering, joining or exporting records, the rules behind failed or unmatched records | references/data-investigation.md |
| Whether a finding is complete and a root cause holds: searching every region and scope, paginating before counting, coverage of a date range, one entity vs the whole affected population, consistency of the root cause, whether a runbook fixes the cause, answering the user's own question | references/completeness-and-root-cause.md |
Rules for every investigation
Explore before you give up. Assume the credentials are the intended environment. Treat unfamiliar or internal terms (service nicknames, airport-code regions such as PDX = us-west-2, IAD = us-east-1) as search hints: list resources, log groups and data stores in the likely regions and search for the identifiers in the request before saying something cannot be done.
Separate evidence from inference. Keep a short provenance note per claim (
claim <- artifact, record or query). Label anything you did not read as a hypothesis or UNVERIFIED, with the routes you tried.Count exactly. Use aggregate queries run in the engine, scoped to exactly what was asked, and report unique entities separately from raw records.
Quote, don't paraphrase. Give identifiers, field values, error codes and messages exactly as the source produced them, including
nulland empty values.Finish the task. Produce every requested artifact (files, tables, plans), and state the assumptions you made in the final answer.
Closing checklist
Before submitting your analysis:
Have you searched all relevant regions and scopes?
Have you paginated through all results, and said which part of the requested range has data?
Have you verified the scope of failures (entity-specific vs fleet-wide, the whole affected population)?
Does your root cause fit all the facts you found?
Have you labelled every mechanism you could not confirm as unverified, and reported a missing component as a defect only if it was meant to exist?
Did your claims about live configuration come from the deployed artifact, not the latest stored version (deployed-artifacts.md)?
For a request that crosses services, did you read each service's own logs and place the failure boundary per event (multi-service-logs.md)?
Have you answered the user's specific question directly?
Before you finish, have you reread your conclusion against each piece of evidence you collected and removed any statement that contradicts it?
Have you removed any contradictions between your findings and recommendations, and checked each runbook option against the confirmed cause?
Files
- ATTRIBUTION.mdAdded by AutoGineer899 B
- LICENSELicence file added by AutoGineer9.9 KiB
- NOTICELicence file added by AutoGineer67 B
- SKILL.md4.9 KiB
- references/completeness-and-root-cause.md8.8 KiB
- references/data-investigation.md5.1 KiB
- references/deployed-artifacts.md7.9 KiB
- references/multi-service-logs.md1.8 KiB
NOTICE
Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- AWS
- Publisher
- AWS (Official)
- Source
- aws/agent-toolkit-for-aws · skills/core-skills/aws-investigation · commit 0a218f8
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- NOTICE (added by AutoGineer from NOTICE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Also distributed in
- aws/agent-toolkit-for-aws
AutoGineer is not affiliated with or endorsed by AWS.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-investigation.zip