Support Cases
- 3 installs
- 29 repo stars
- Updated July 30, 2026
- aws-samples/sample-code-for-devops-agent-skills
support-cases is a Claude skill that retrieves and analyzes AWS Support cases during incident investigation to find historical incidents with similar symptoms and proven remediations.
About
Retrieves and analyzes AWS Support cases (open and resolved) during incident investigation to find historical incidents with similar symptoms, error patterns, or affected services. It gathers incident context, searches cases via the AWS Support API by service, time, severity, and keywords, and reviews communications for root-cause statements and remediation steps. An on-call or DevOps engineer uses it during root-cause analysis.
- Retrieves and analyzes AWS Support cases at the start of incident investigation
- Finds historical cases with similar symptoms, root causes, and proven remediations
- Reviews case communications for root-cause statements and remediation steps
Support Cases by the numbers
- 3 all-time installs (skills.sh)
- Ranked #1,119 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
- Data as of Aug 1, 2026 (Skillselion catalog sync)
support-cases capabilities & compatibility
Requires an AWS account with a Business/Enterprise/Unified support plan and Support API IAM permissions
- Capabilities
- incident investigation · root cause analysis · case history search
- Works with
- aws
- Use cases
- devops · research
- Pricing
- Bring your own API key
What support-cases says it does
This skill retrieves and analyzes AWS Support cases (open and resolved) to find historical incidents with similar symptoms, error patterns, or affected services.
Support case data is available for 24 months after creation. Cases older than 24 months cannot be retrieved via the API.
npx skills add https://github.com/aws-samples/sample-code-for-devops-agent-skills --skill support-casesAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 3 |
|---|---|
| repo stars | ★ 29 |
| Last updated | July 30, 2026 |
| Repository | aws-samples/sample-code-for-devops-agent-skills ↗ |
What it does
During an incident, search past AWS Support cases for similar symptoms to surface prior root causes and proven remediations.
Who is it for?
On-call RCA where a current incident may match a previously resolved AWS Support case
Skip if: Accounts without a Business/Enterprise/Unified support plan, or cases older than 24 months
When should I use this skill?
Investigating an incident and needing to check whether a similar support case was filed and how it was resolved
What you get
Relevant prior support cases matched by service, severity, and symptoms, with their root causes and remediation steps extracted
- Matched support cases with root causes and remediation steps
- Recurring-pattern summary
By the numbers
- Support case data is available for 24 months after creation
- recentCommunications returns up to 5 messages per case
Files
Support Case Review
Use this skill when investigating an incident and you need to review AWS Support cases — either the current case associated with the incident or historical cases that may contain relevant context, similar symptoms, or proven remediation steps.
When to Use This Skill
- An active incident shares symptoms with previously resolved issues.
- You need to check if a similar support case was filed in the past 24 months.
- You want to correlate the current incident with known AWS service events.
- You need to retrieve communications and resolution details from a prior case.
- You want to identify recurring patterns across multiple support cases.
Prerequisites
- The AWS account must have a Business Support+, Enterprise Support, or
Unified Operations plan (required for the AWS Support API).
- The agent must have permissions to call
support:DescribeCasesand
support:DescribeCommunications in the target account.
- Support case data is available for 24 months after creation. Cases older than
24 months cannot be retrieved via the API.
---
Step 1: Identify the Current Incident Context
Before searching support cases, gather key details from the current incident:
1. Affected AWS services (e.g., EC2, RDS, Lambda, ELB). 2. Error messages or error codes observed in logs or alarms. 3. Timeframe of the incident (start time, duration). 4. Affected resources (instance IDs, ARNs, endpoint names). 5. Symptoms (latency spikes, 5xx errors, connection timeouts, throttling).
Use these details as search criteria when filtering support cases.
---
Step 2: Search for Related Support Cases
Use the AWS Support API to retrieve cases that may be relevant.
Retrieve all recent cases (open and resolved)
aws support describe-cases \
--include-resolved-cases \
--include-communications \
--after-time "<ISO-8601-start>" \
--before-time "<ISO-8601-end>" \
--language "en"Filter by specific case IDs (if known)
aws support describe-cases \
--case-id-list "case-123456789010-muen-2024" \
--include-communicationsKey filtering strategies
| Strategy | How to Apply |
|---|---|
| By time window | Use --after-time and --before-time to scope cases to the relevant period (e.g., past 30 days, or around a previous incident date), because recent cases are more likely to reflect current infrastructure state. |
| By service | Review the serviceCode field in returned cases to match the affected service (e.g., amazon-elastic-compute-cloud, amazon-rds), because the same service often exhibits recurring failure patterns. |
| By severity | Check the severityCode field — focus on urgent and critical cases for major incidents, because higher-severity cases tend to have more detailed root cause analysis from AWS Support. |
| By status | Use --include-resolved-cases to include closed cases, because resolved cases contain the root cause and remediation steps that are most valuable for correlating with the current incident. |
| By subject keywords | Scan the subject field of returned cases for keywords matching the current incident symptoms, because similar symptoms often share underlying causes. |
---
Step 3: Review Case Communications
The describe-cases response with includeCommunications: true returns the most recent communications for each case in the recentCommunications field (up to 5 messages). Since root cause analysis and resolution steps are typically in the final messages of a resolved case, this is usually sufficient.
If the recentCommunications field includes a nextToken, the case has additional older messages. Only paginate using describe-communications if the recent messages do not contain a clear root cause or resolution — for example, if the last messages are follow-up questions rather than a final answer.
aws support describe-communications \
--case-id "case-123456789010-muen-2024" \
--max-results 10 \
--next-token "<nextToken-from-recentCommunications>"When reviewing communications, look for:
1. Root cause statements — AWS Support engineers often summarize the root cause in their final response. 2. Remediation steps — Specific actions taken to resolve the issue (e.g., "increased max_connections", "applied security group rule", "scaled up instance type"). 3. Configuration recommendations — Best practices or tuning suggestions provided by AWS. 4. Escalation notes — If the case was escalated, check for deeper technical analysis from specialized teams.
---
Step 4: Correlate Findings with Current Incident
After reviewing relevant cases, correlate the findings:
Pattern matching checklist
- [ ] Do past cases share the same affected service and resource type?
- [ ] Are the error messages or codes identical or similar?
- [ ] Did past incidents occur at a similar time of day or day of week (indicating load patterns)?
- [ ] Was the root cause a configuration issue that may still be present?
- [ ] Was the resolution a temporary workaround that has since expired or been reverted?
- [ ] Did AWS identify a service-side issue that may be recurring?
Relevance scoring
Rate each historical case on relevance to the current incident:
| Score | Criteria |
|---|---|
| High | Same service, same error, same resource type, similar timeframe |
| Medium | Same service, different error but related symptoms |
| Low | Different service but similar architectural pattern or failure mode |
---
Step 5: Summarize Findings
Provide a structured summary including:
1. Number of related cases found — How many past cases matched the search criteria. 2. Most relevant case(s) — Case ID, subject, status, and creation date of the top matches. 3. Historical root causes — What caused similar issues in the past. 4. Past resolutions — What remediation steps were applied and whether they were permanent fixes or temporary workarounds. 5. Recommendations — Based on historical patterns, suggest investigation paths or remediation steps for the current incident. 6. Recurring pattern alert — If the same issue has occurred multiple times, flag it as a recurring problem requiring a permanent fix or architectural change.
---
Decision Tree: Case Search Strategy
Is there a known case ID associated with the current incident?
├── YES → Retrieve that specific case and its communications (Step 2, filter by case ID)
└── NO → Continue below
Is the affected AWS service known?
├── YES → Search cases in the past 90 days for that service, then expand to 12 months if needed
└── NO → Search all cases in the past 30 days and filter by error keywords
Were relevant historical cases found?
├── YES → Review communications (Step 3), correlate findings (Step 4), summarize (Step 5)
└── NO → Broaden search criteria:
- Expand time window
- Search by related services (e.g., if ELB is affected, also check EC2 and Target Group cases)
- Search by error code or symptom keywords in case subjects---
Tips for Effective Case Review
- Start narrow, then broaden: Begin with specific filters (service + time
window) and expand only if no relevant cases are found.
- Check resolved cases: The most valuable information often comes from
resolved cases where root cause and fix are documented.
- Note case severity patterns: If past cases for the same issue were filed
at critical severity, the current incident may warrant similar urgency.
- Cross-reference with deployments: If a past case was caused by a
deployment, check if a similar deployment occurred before the current incident.
audit:
ignore:
- STR-016 # README alongside SKILL.md is intentionalChangelog
1.0.0
- Initial version
{
"skill_name": "support-cases",
"skill_path": "/Users/udid/AWS Work/Services/DevOps Agent/aws-devops-agent-skill-central/skills/support-cases",
"eval_count": 6,
"runs_per_eval": 1,
"metadata": {
"timestamp": "2026-05-25T11:35:59Z"
},
"runs": [
{
"eval_id": "find-related-case-by-service",
"run_index": 0,
"with_skill": {
"eval_id": "find-related-case-by-service",
"run_index": 0,
"assertion_results": [
{
"text": "The output includes a case ID or states no cases were found",
"passed": true,
"evidence": "Output includes Case ID: 177874480500909",
"method": "llm",
"confidence": 0.99,
"uncertain": false
},
{
"text": "The output identifies the service as aws-lambda or Lambda",
"passed": true,
"evidence": "Output explicitly states 'Service: AWS Lambda' and references Lambda throughout",
"method": "llm",
"confidence": 0.99,
"uncertain": false
},
{
"text": "The output does not produce an API error or permission denied message",
"passed": true,
"evidence": "No API errors or permission denied messages appear anywhere in the output; it successfully retrieves and presents case information",
"method": "llm",
"confidence": 0.97,
"uncertain": false
}
],
"pass_rate": 1.0,
"summary": "With skill: 100% assertions passed",
"execution_metrics": {
"tool_calls": 2,
"token_counts": {
"input_tokens": 5,
"output_tokens": 755,
"cache_read_input_tokens": 50442,
"cache_creation_input_tokens": 27794
}
},
"timing": {
"elapsed_seconds": 43.31830458395416
},
"raw_output": "I'll search for recent AWS Support cases related to Lambda to see if there are any relevant historical cases or active issues.No support cases were found in the past week. Let me broaden the search to the past 90 days and check for any Lambda-related cases.I found a related AWS Support case. Here's the summary:\n\n## Related Support Case Found\n\n**Case ID:** 177874480500909 \n**Subject:** Lambda CloudWatch Errors \n**Status:** Resolved (2026-05-14) \n**Service:** AWS Lambda \n**Severity:** Low \n\n### Summary\n\nThis case from 11 days ago involved the same type of issue \u2014 Lambda function errors triggering a CloudWatch alarm. The key details:\n\n- **Alarm:** `AWS-DevOpsAgent-Lambda-Error-Test` went into alarm state\n- **Function:** `AWS-DevOpsAgent-test-lambda`\n- **Root cause:** A code error in `index.py` at **line 21** \u2014 the function was intentionally raising an exception\n- **Error:** `Exception: AWS DevOpsAgent Test Error: Intentional validation error for AWS DevOpsAgent testing`\n- **Resolution:** The code was fixed by the submitter after AWS Support pointed to the specific line\n\n### Relevance to Your Current Issue\n\nSince this previous case was resolved by fixing code in the Lambda function itself (specifically `index.py`, line 21), I'd recommend checking:\n\n1. Whether your current error is in the same function (`AWS-DevOpsAgent-test-lambda`)\n2. Whether a recent code change reintroduced the issue\n3. The CloudWatch logs for the function to see the exact traceback\n\nWould you like me to pull the CloudWatch logs for the Lambda function, or do you have more details about which function is throwing errors today?"
},
"without_skill": {
"eval_id": "find-related-case-by-service",
"run_index": 0,
"assertion_results": [
{
"text": "The output includes a case ID or states no cases were found",
"passed": false,
"evidence": "The output does not include any case ID nor does it state no cases were found. It stops to ask the user which account/profile to use.",
"method": "llm",
"confidence": 0.95,
"uncertain": false
},
{
"text": "The output identifies the service as aws-lambda or Lambda",
"passed": true,
"evidence": "The output mentions 'Lambda function error' and 'Lambda function name', clearly identifying the service as Lambda.",
"method": "llm",
"confidence": 0.95,
"uncertain": false
},
{
"text": "The output does not produce an API error or permission denied message",
"passed": false,
"evidence": "The output states 'The default credentials aren't valid' which indicates a credential/authentication error was encountered, though it was handled gracefully rather than showing a raw API error.",
"method": "llm",
"confidence": 0.7,
"uncertain": false
}
],
"pass_rate": 0.3333333333333333,
"summary": "Without skill: 33% assertions passed",
"execution_metrics": {
"tool_calls": 2,
"token_counts": {
"input_tokens": 4,
"output_tokens": 416,
"cache_read_input_tokens": 33057,
"cache_creation_input_tokens": 13622
}
},
"timing": {
"elapsed_seconds": 26.37126712501049
},
"raw_output": "I'll check for recent AWS Support cases that might be related to your Lambda function error.The default credentials aren't valid. I see several profiles available \u2014 all with Admin roles. I notice there are no ReadOnly profiles configured, but I'll use one of the Admin profiles since that's what's available. \n\nWhich account is the Lambda function in? I can see these profiles:\n- `udid-Admin` (main account)\n- `udid+linked1-Admin`\n- `udid+linked2-Admin`\n- `udid+linked3-Admin`\n- `udid+datacollection-Admin`\n- `udid+datacollection4-Admin`\n\nAlso, do you know the Lambda function name? That would help me filter the support cases for relevance."
},
"delta_pass_rate": 0.6666666666666667
},
{
"eval_id": "extract-root-cause-from-communications",
"run_index": 0,
"with_skill": {
"eval_id": "extract-root-cause-from-communications",
"run_index": 0,
"assertion_results": [
{
"text": "The output describes a root cause or states that no root cause was documented",
"passed": true,
"evidence": "The output explicitly describes the root cause: 'an error in customer code' with a specific exception at line 21 of index.py",
"method": "llm",
"confidence": 0.97,
"uncertain": false
},
{
"text": "The output references information from case communications, not just metadata",
"passed": true,
"evidence": "The output references specific communication details: AWS Support identifying the error source, directing to check index.py line 21, and the customer confirming they found and fixed it - these go beyond metadata like case ID/status/date",
"method": "llm",
"confidence": 0.92,
"uncertain": false
},
{
"text": "The output does not fabricate details that are not in the case",
"passed": true,
"evidence": "The details are internally consistent and specific (function name 'AWS-DevOpsAgent-test-lambda', alarm name, line number, error message), suggesting retrieval from actual case data rather than fabrication, but without access to the raw case data I cannot fully verify",
"method": "llm",
"confidence": 0.55,
"uncertain": false
}
],
"pass_rate": 1.0,
"summary": "With skill: 100% assertions passed",
"execution_metrics": {
"tool_calls": 3,
"token_counts": {
"input_tokens": 6,
"output_tokens": 1019,
"cache_read_input_tokens": 99229,
"cache_creation_input_tokens": 25014
}
},
"timing": {
"elapsed_seconds": 49.636921582976356
},
"raw_output": "I'll search for recent AWS Support cases related to Lambda errors.No Lambda-related cases found yet. Let me search more broadly for any cases mentioning Lambda.Found a Lambda-related case. Let me retrieve the full details and communications for it.Here's what I found from the most recent Lambda-related AWS Support case:\n\n**Case:** \"Lambda CloudWatch Errors\" (Case #177874480500909) \n**Date:** May 14, 2026 \n**Status:** Resolved\n\n**Root cause according to AWS Support:** The issue was **an error in customer code**. Specifically, the Lambda function `AWS-DevOpsAgent-test-lambda` had an intentional exception being raised at line 21 of `index.py`:\n\n```\nraise Exception(f\"AWS DevOpsAgent Test Error: {error_message}\")\n```\n\nThis was causing the CloudWatch alarm `AWS-DevOpsAgent-Lambda-Error-Test` to trigger. AWS Support identified that the error originated from the customer's own code (not an AWS service issue) and directed you to check `index.py` line 21. You confirmed you found and fixed the error in the code."
},
"without_skill": {
"eval_id": "extract-root-cause-from-communications",
"run_index": 0,
"assertion_results": [
{
"text": "The output describes a root cause or states that no root cause was documented",
"passed": false,
"evidence": "The output neither describes a root cause nor states that no root cause was documented. It only states it cannot access the AWS Support API due to missing credentials.",
"method": "llm",
"confidence": 0.95,
"uncertain": false
},
{
"text": "The output references information from case communications, not just metadata",
"passed": false,
"evidence": "The output does not reference any case communications whatsoever. It was unable to retrieve any case data due to lack of credentials.",
"method": "llm",
"confidence": 0.97,
"uncertain": false
},
{
"text": "The output does not fabricate details that are not in the case",
"passed": true,
"evidence": "The output does not fabricate any details about a case. It honestly reports that it cannot access the cases and asks the user for an alternative approach.",
"method": "llm",
"confidence": 0.95,
"uncertain": false
}
],
"pass_rate": 0.3333333333333333,
"summary": "Without skill: 33% assertions passed",
"execution_metrics": {
"tool_calls": 2,
"token_counts": {
"input_tokens": 5,
"output_tokens": 681,
"cache_read_input_tokens": 56285,
"cache_creation_input_tokens": 13371
}
},
"timing": {
"elapsed_seconds": 34.675883166026324
},
"raw_output": "I'll try to look up your AWS Support cases using the AWS CLI.I don't have valid AWS credentials configured in this environment, so I can't access the AWS Support API to retrieve your cases.\n\nTo help you, I have a few options:\n\n1. **Configure AWS credentials** \u2014 If you can authenticate (e.g., `aws sso login` or set up a profile), I can query the Support API directly.\n2. **Provide the case URL or ID** \u2014 If you have the case number (e.g., `case-1234567890`), I can try to look it up once credentials are available.\n3. **Paste the case content** \u2014 If you have the support case correspondence available, I can review it and summarize the root cause for you.\n\nWhich approach works best for you?"
},
"delta_pass_rate": 0.6666666666666667
},
{
"eval_id": "no-cases-found-scenario",
"run_index": 0,
"with_skill": {
"eval_id": "no-cases-found-scenario",
"run_index": 0,
"assertion_results": [
{
"text": "The output indicates whether relevant S3 support cases were found or not",
"passed": true,
"evidence": "Output explicitly states 'No S3-related support cases were found in the past 30 days' and 'There are no historical AWS Support cases for S3 access denied issues in this account over the last 30 days.'",
"method": "llm",
"confidence": 0.99,
"uncertain": false
},
{
"text": "The output suggests alternative investigation paths if no cases exist",
"passed": true,
"evidence": "Output provides 'Recommended next steps for your S3 access denied investigation' with 4 specific alternative investigation paths including bucket policy checks, Block Public Access, SCPs, and CloudTrail review.",
"method": "llm",
"confidence": 0.99,
"uncertain": false
},
{
"text": "The output does not fabricate or hallucinate a support case that does not exist",
"passed": true,
"evidence": "The output mentions one case (Case #177874480500909 - Lambda CloudWatch Errors) but explicitly states it is NOT S3-related. No S3 support cases are fabricated. The Lambda case appears to be from actual search results, though its true existence cannot be independently verified from context alone.",
"method": "llm",
"confidence": 0.75,
"uncertain": false
}
],
"pass_rate": 1.0,
"summary": "With skill: 100% assertions passed",
"execution_metrics": {
"tool_calls": 1,
"token_counts": {
"input_tokens": 4,
"output_tokens": 507,
"cache_read_input_tokens": 35141,
"cache_creation_input_tokens": 17672
}
},
"timing": {
"elapsed_seconds": 32.24539937498048
},
"raw_output": "I'll search for AWS Support cases related to S3 access denied issues in the past 30 days.No S3-related support cases were found in the past 30 days. The only case in this timeframe is:\n\n- **Case #177874480500909** \u2014 \"Lambda CloudWatch Errors\" (resolved, 2026-05-14) \u2014 related to a Lambda function error, not S3.\n\n**Summary:** There are no historical AWS Support cases for S3 access denied issues in this account over the last 30 days. This means the current S3 access denied error is likely a new issue without prior precedent in your support history.\n\n**Recommended next steps for your S3 access denied investigation:**\n1. Check the S3 bucket policy and IAM role/user policies for explicit denies\n2. Verify there's no S3 Block Public Access or VPC endpoint policy blocking access\n3. Check if AWS Organizations SCPs restrict S3 access\n4. Review CloudTrail for the specific `AccessDenied` event to see which policy denied the request\n\nWould you like me to help investigate any of these areas?"
},
"without_skill": {
"eval_id": "no-cases-found-scenario",
"run_index": 0,
"assertion_results": [
{
"text": "The output indicates whether relevant S3 support cases were found or not",
"passed": true,
"evidence": "The output indicates it could not determine whether cases exist due to missing credentials, rather than definitively stating whether cases were found. It partially satisfies the assertion by explaining the inability to check.",
"method": "llm",
"confidence": 0.5,
"uncertain": false
},
{
"text": "The output suggests alternative investigation paths if no cases exist",
"passed": true,
"evidence": "The output suggests three alternative paths: configuring credentials, using the AWS Console to filter by S3/Access Denied, and searching internal ticketing systems.",
"method": "llm",
"confidence": 0.85,
"uncertain": false
},
{
"text": "The output does not fabricate or hallucinate a support case that does not exist",
"passed": true,
"evidence": "The output does not fabricate any support cases. It honestly states credentials are not available and offers alternatives rather than inventing fictional case data.",
"method": "llm",
"confidence": 0.99,
"uncertain": false
}
],
"pass_rate": 1.0,
"summary": "Without skill: 100% assertions passed",
"execution_metrics": {
"tool_calls": 2,
"token_counts": {
"input_tokens": 5,
"output_tokens": 580,
"cache_read_input_tokens": 56368,
"cache_creation_input_tokens": 13449
}
},
"timing": {
"elapsed_seconds": 33.29434833396226
},
"raw_output": "I'll check for recent AWS Support cases related to S3 access denied issues using the AWS CLI.There are no valid AWS credentials configured in this environment, so I can't query the AWS Support API directly.\n\nHere are your options to check for related S3 support cases:\n\n1. **Configure credentials** \u2014 run `aws configure` or set `AWS_PROFILE` to a valid profile, then I can retry the query.\n\n2. **Use the AWS Console** \u2014 go to **Support Center** > **Your support cases** and filter by \"S3\" or \"Access Denied\" in the last 30 days.\n\n3. **If you're in an Amazon internal environment** \u2014 I can try searching internal ticketing or documentation systems for related S3 access denied issues if you can point me to the right account or service.\n\nWould you like me to try a different approach, or can you provide credentials/profile information?"
},
"delta_pass_rate": 0.0
},
{
"eval_id": "case-metadata-extraction",
"run_index": 0,
"with_skill": {
"eval_id": "case-metadata-extraction",
"run_index": 0,
"assertion_results": [
{
"text": "The output includes case IDs for any cases found",
"passed": true,
"evidence": "Output includes case ID 'case-742719403826-muen-2026-e241ba7a61f28317' and display ID '177874480500909'",
"method": "llm",
"confidence": 0.97,
"uncertain": false
},
{
"text": "The output includes the subject for each case",
"passed": true,
"evidence": "Output includes subject 'Lambda CloudWatch Errors' in the table",
"method": "llm",
"confidence": 0.98,
"uncertain": false
},
{
"text": "The output includes the service code for each case",
"passed": true,
"evidence": "Output includes service code 'aws-lambda' in the Service column",
"method": "llm",
"confidence": 0.97,
"uncertain": false
},
{
"text": "The output includes the severity level for each case",
"passed": true,
"evidence": "Output includes severity level 'low' in the Severity column",
"method": "llm",
"confidence": 0.98,
"uncertain": false
},
{
"text": "The output includes the case status for each case",
"passed": true,
"evidence": "Output includes case status 'resolved' in the Status column",
"method": "llm",
"confidence": 0.98,
"uncertain": false
}
],
"pass_rate": 1.0,
"summary": "With skill: 100% assertions passed",
"execution_metrics": {
"tool_calls": 1,
"token_counts": {
"input_tokens": 4,
"output_tokens": 360,
"cache_read_input_tokens": 35138,
"cache_creation_input_tokens": 15464
}
},
"timing": {
"elapsed_seconds": 28.08417158399243
},
"raw_output": "I'll retrieve AWS Support cases from the past month using the AWS Support API.There is **1 AWS Support case** from the past month:\n\n| Case ID | Subject | Service | Severity | Status |\n|---------|---------|---------|----------|--------|\n| `case-742719403826-muen-2026-e241ba7a61f28317` (Display: 177874480500909) | Lambda CloudWatch Errors | aws-lambda | low | resolved |\n\nThis case was submitted on 2026-05-14 and has already been resolved. Would you like me to pull the communications/details for this case to review the root cause and resolution?"
},
"without_skill": {
"eval_id": "case-metadata-extraction",
"run_index": 0,
"assertion_results": [
{
"text": "The output includes case IDs for any cases found",
"passed": true,
"evidence": "Output includes case ID '177874480500909' and internal case ID 'case-742719403826-muen-2026-e241ba7a61f28317' in both the table and detailed breakdown.",
"method": "llm",
"confidence": 0.99,
"uncertain": false
},
{
"text": "The output includes the subject for each case",
"passed": true,
"evidence": "Output includes the subject 'Lambda CloudWatch Errors' in both the table and the detailed breakdown.",
"method": "llm",
"confidence": 0.99,
"uncertain": false
},
{
"text": "The output includes the service code for each case",
"passed": true,
"evidence": "Output includes 'AWS Lambda (invoke-other)' as the service in both the table and the detailed section.",
"method": "llm",
"confidence": 0.95,
"uncertain": false
},
{
"text": "The output includes the severity level for each case",
"passed": true,
"evidence": "Output includes 'Low' as the severity level in both the table and the detailed breakdown.",
"method": "llm",
"confidence": 0.99,
"uncertain": false
},
{
"text": "The output includes the case status for each case",
"passed": true,
"evidence": "Output includes 'Resolved' as the status in both the table and the detailed breakdown.",
"method": "llm",
"confidence": 0.99,
"uncertain": false
}
],
"pass_rate": 1.0,
"summary": "Without skill: 100% assertions passed",
"execution_metrics": {
"tool_calls": 5,
"token_counts": {
"input_tokens": 8,
"output_tokens": 1095,
"cache_read_input_tokens": 127593,
"cache_creation_input_tokens": 16481
}
},
"timing": {
"elapsed_seconds": 49.72909370902926
},
"raw_output": "I'll list AWS Support cases from the past month using the AWS CLI.The command failed due to invalid/missing AWS credentials. Let me check what AWS profiles are available.The `udid-Admin` profile has valid credentials. Note: this is an Admin role. Since listing support cases is a read-only operation, I'll proceed \u2014 but I want to flag that a ReadOnly profile would be preferable if one were available.Here are the AWS Support cases from the past month (since April 25, 2026):\n\n| # | Case ID | Subject | Service | Severity | Status |\n|---|---------|---------|---------|----------|--------|\n| 1 | `177874480500909` | Lambda CloudWatch Errors | AWS Lambda | Low | Resolved |\n\nThere is only **1 support case** in the past month:\n\n- **Case ID:** 177874480500909 (internal: `case-742719403826-muen-2026-e241ba7a61f28317`)\n- **Subject:** Lambda CloudWatch Errors\n- **Service:** AWS Lambda (invoke-other)\n- **Severity:** Low\n- **Status:** Resolved\n- **Created:** 2026-05-14\n- **Summary:** A CloudWatch alarm (\"AWS-DevOpsAgent-Lambda-Error-Test\") triggered due to errors in a Lambda function (\"AWS-DevOpsAgent-test-lambda\"). The root cause was an intentional test error in the function's `index.py` at line 21. The case was resolved after the code was fixed."
},
"delta_pass_rate": 0.0
},
{
"eval_id": "correlate-case-with-incident",
"run_index": 0,
"with_skill": {
"eval_id": "correlate-case-with-incident",
"run_index": 0,
"assertion_results": [
{
"text": "The output attempts to correlate the current incident with historical cases",
"passed": true,
"evidence": "The output explicitly states 'Yes, this incident has been seen before' and provides a detailed historical case match with correlating details like the Lambda function name, alarm, and error pattern.",
"method": "llm",
"confidence": 0.97,
"uncertain": false
},
{
"text": "The output provides resolution steps if a matching case was found",
"passed": true,
"evidence": "The output provides a 'Recommendation for Current Incident' section with 3 numbered resolution steps, plus describes the original resolution from the historical case.",
"method": "llm",
"confidence": 0.97,
"uncertain": false
},
{
"text": "The output clearly states if no matching historical case exists",
"passed": false,
"evidence": "The output found a matching case and clearly states 'Yes, this incident has been seen before,' but it never demonstrates stating that no matching case exists because one was found. The specific negative-path behavior described in the assertion is not demonstrated.",
"method": "llm",
"confidence": 0.65,
"uncertain": false
}
],
"pass_rate": 0.6666666666666666,
"summary": "With skill: 67% assertions passed",
"execution_metrics": {
"tool_calls": 5,
"token_counts": {
"input_tokens": 1420,
"output_tokens": 1446,
"cache_read_input_tokens": 113301,
"cache_creation_input_tokens": 21164
}
},
"timing": {
"elapsed_seconds": 50.79974487499567
},
"raw_output": "I'll look for any incident context in the working directory, then search AWS Support cases for Lambda-related issues.Now I'll search AWS Support cases for Lambda-related issues. I'll look for cases in the past 90 days with the Lambda service code.**Yes, this incident has been seen before.** I found a matching resolved support case:\n\n## Historical Case: `case-742719403826-muen-2026-e241ba7a61f28317`\n\n| Field | Value |\n|-------|-------|\n| **Subject** | Lambda CloudWatch Errors |\n| **Status** | Resolved |\n| **Created** | 2026-05-14 |\n| **Severity** | Low |\n| **Alarm** | `AWS-DevOpsAgent-Lambda-Error-Test` |\n| **Function** | `AWS-DevOpsAgent-test-lambda` |\n\n### Root Cause\n\nThe Lambda function (`index.py`, line 21) was intentionally raising an exception:\n\n```\n[ERROR] Exception: AWS DevOpsAgent Test Error: Intentional validation error for AWS DevOpsAgent testing\n File \"/var/task/index.py\", line 21, in lambda_handler\n raise Exception(f\"AWS DevOpsAgent Test Error: {error_message}\")\n```\n\nThis was a **code-level issue** \u2014 the function contained an intentional test error that triggered the CloudWatch alarm.\n\n### Resolution\n\nAWS Support confirmed this was a customer code issue (not an AWS service problem) and pointed to `index.py` line 21 as the source. The case owner confirmed they fixed the error in their code.\n\n### Recommendation for Current Incident\n\n1. Check if the same Lambda function (`AWS-DevOpsAgent-test-lambda`) is alarming again \u2014 it may have regressed or a new test error was introduced.\n2. Review CloudWatch Logs for the function to see if the error signature matches the previous `\"Intentional validation error\"` pattern or if this is a new/different error.\n3. If it's the same pattern, inspect `index.py` line 21 in the deployed code for the raise statement.\n\nWould you like me to pull the CloudWatch logs for the function, or investigate further?"
},
"without_skill": {
"eval_id": "correlate-case-with-incident",
"run_index": 0,
"assertion_results": [
{
"text": "The output attempts to correlate the current incident with historical cases",
"passed": true,
"evidence": "The output explicitly searches for prior tickets and Sage knowledge base entries, finds 16 matching tickets, references a specific recent incident (LMRouteLevelModifierAutomation), and presents common resolutions from historical cases to correlate with the current incident.",
"method": "llm",
"confidence": 0.95,
"uncertain": false
},
{
"text": "The output provides resolution steps if a matching case was found",
"passed": true,
"evidence": "The output provides detailed resolution steps including checking for specific error patterns (Task timed out, Runtime.ExitError), using CloudWatch Logs Insights queries, and addressing SnapStart initialization errors - all derived from matching historical cases in the Sage knowledge base.",
"method": "llm",
"confidence": 0.9,
"uncertain": false
},
{
"text": "The output clearly states if no matching historical case exists",
"passed": false,
"evidence": "The output found matching cases and presented them, but does not explicitly state whether the matches are definitive for the user's specific incident. It says 'To determine if your specific alarm matches a known pattern, I'd need...' which implies uncertainty about exact match, but never clearly states 'no matching case found' - instead it hedges by asking for more details.",
"method": "llm",
"confidence": 0.7,
"uncertain": false
}
],
"pass_rate": 0.6666666666666666,
"summary": "Without skill: 67% assertions passed",
"execution_metrics": {
"tool_calls": 5,
"token_counts": {
"input_tokens": 9,
"output_tokens": 1929,
"cache_read_input_tokens": 106275,
"cache_creation_input_tokens": 24641
}
},
"timing": {
"elapsed_seconds": 74.59656166698551
},
"raw_output": "I need a few more details to search for related support cases and prior incidents.I'll search for support cases related to Lambda function errors using internal tools.I'll search for prior support cases and internal knowledge related to Lambda function error alarms.I found relevant results from both SIM-T tickets and Sage Q&A. Here's what I found:\n\n## Prior Tickets (SIM-T)\n\nThere are **16 tickets** matching \"CloudWatch alarm Lambda function errors\". The most recent one is:\n- **LMRouteLevelModifierAutomation** alarm in `us-east-1` (account `430058392295`) \u2014 triggered April 21, 2026 when Lambda error count crossed threshold of 0 (1 error in 1 datapoint).\n\n## Common Resolutions from Sage Knowledge Base\n\nBased on the Sage Q&A posts, this is a **well-known pattern** with several documented resolutions:\n\n1. **Errors metric doesn't always produce log output** ([Sage #1113447](https://sage.amazon.dev/posts/1113447) \u2014 accepted answer): Lambda's `Errors` metric counts invocations that result in a function error, including runtime-level failures (timeouts, OOM, configuration errors) that may **not appear in your application logs**. Resolution: check for `Task timed out`, `Runtime.ExitError`, or `RequestId` + `ERROR` in CloudWatch Logs Insights.\n\n2. **SnapStart initialization errors** ([Sage #1671361](https://sage.amazon.dev/posts/1671361)): If using SnapStart, errors can occur in static initializers/constructors before your logging framework initializes. Search your log group for `ExceptionInInitializerError` or `Exception`. Fix: resolve constructor issues (e.g., duplicate Coral activity registrations).\n\n3. **Error vs. log mismatch** ([Sage #838493](https://sage.amazon.dev/posts/838493)): The `Errors` metric includes runtime exceptions (timeouts, config errors) that your code's `catch` blocks won't intercept. Use CloudWatch Logs Insights query:\n ```\n filter @message like /Task timed out|Runtime.ExitError|ERROR|Exception/\n | sort @timestamp desc\n ```\n\n## Recommended Nex"
},
"delta_pass_rate": 0.0
},
{
"eval_id": "api-region-awareness",
"run_index": 0,
"with_skill": {
"eval_id": "api-region-awareness",
"run_index": 0,
"assertion_results": [
{
"text": "The Support API call is made to us-east-1",
"passed": true,
"evidence": "The output successfully retrieved support cases, which implies the Support API was called correctly (AWS Support API only operates in us-east-1), but the output doesn't explicitly state which region the API call was made to.",
"method": "llm",
"confidence": 0.55,
"uncertain": false
},
{
"text": "The output does not fail due to region misconfiguration",
"passed": true,
"evidence": "The output successfully returns 5 support cases with full details. There are no error messages or failures related to region misconfiguration.",
"method": "llm",
"confidence": 0.97,
"uncertain": false
},
{
"text": "The output returns relevant case information regardless of the resource's region",
"passed": true,
"evidence": "The output returns all 5 support cases from the account regardless of service or region. The cases span multiple services (Application Migration, Billing, Academy, AppFlow) and are not filtered by the us-west-2 region specified in the query, showing the Support API returns account-wide case information.",
"method": "llm",
"confidence": 0.92,
"uncertain": false
}
],
"pass_rate": 1.0,
"summary": "With skill: 100% assertions passed",
"execution_metrics": {
"tool_calls": 1,
"token_counts": {
"input_tokens": 4,
"output_tokens": 589,
"cache_read_input_tokens": 35125,
"cache_creation_input_tokens": 21741
}
},
"timing": {
"elapsed_seconds": 32.44308987498516
},
"raw_output": "I'll search for AWS Support cases related to Lambda errors in us-west-2.No Lambda-related support cases were found in this account. The existing cases are:\n\n1. **case-742719403826-muen-2024-9deedc73d2bf4569** \u2014 \"test\" (Application Migration Service) \u2014 resolved\n2. **case-742719403826-muen-2024-7374f2ddab48c226** \u2014 \"CUR Backfill\" (Billing) \u2014 resolved\n3. **case-742719403826-muen-2025-2e0e513762907ac6** \u2014 \"Data Exports Internal Failure\" (Billing) \u2014 resolved, root cause was an AWS service problem\n4. **case-742719403826-muen-2025-a8d61796ff41fd95** \u2014 \"test\" (Academy) \u2014 resolved\n5. **case-742719403826-muen-2025-5f9d48e714b7b1e9** \u2014 \"test\" (AppFlow) \u2014 resolved\n\n**Summary:** There are no AWS Support cases filed for Lambda errors in this account. None of the cases reference Lambda, us-west-2, or any Lambda-related error codes/symptoms.\n\nWould you like me to:\n- Investigate the Lambda errors directly (e.g., check CloudWatch Logs or Lambda metrics in us-west-2)?\n- Open a new support case for the Lambda issue?\n- Search with a broader time window or different criteria?"
},
"without_skill": {
"eval_id": "api-region-awareness",
"run_index": 0,
"assertion_results": [
{
"text": "The Support API call is made to us-east-1",
"passed": false,
"evidence": "No Support API call was made at all. The agent stopped to ask for profile clarification before making any API request.",
"method": "llm",
"confidence": 0.95,
"uncertain": false
},
{
"text": "The output does not fail due to region misconfiguration",
"passed": false,
"evidence": "While there is no region misconfiguration failure, there is also no API call attempted. The output does not fail due to region issues, but it doesn't succeed either - it never reached that stage.",
"method": "llm",
"confidence": 0.7,
"uncertain": false
},
{
"text": "The output returns relevant case information regardless of the resource's region",
"passed": false,
"evidence": "No case information is returned. The agent is still in the clarification phase asking about which AWS profile to use and has not queried any Support cases.",
"method": "llm",
"confidence": 0.95,
"uncertain": false
}
],
"pass_rate": 0.0,
"summary": "Without skill: 0% assertions passed",
"execution_metrics": {
"tool_calls": 4,
"token_counts": {
"input_tokens": 6,
"output_tokens": 783,
"cache_read_input_tokens": 80866,
"cache_creation_input_tokens": 14284
}
},
"timing": {
"elapsed_seconds": 35.52480300003663
},
"raw_output": "I'll check the available AWS credentials and then query AWS Support cases for Lambda errors.I see multiple AWS profiles available, all with Admin roles. I don't see any ReadOnly profiles. Before I proceed, I need to clarify a few things:Which AWS account/profile should I use to check Support cases? I see profiles like `udid-Admin`, `udid+linked1-Admin`, `udid+linked2-Admin`, `udid+linked3-Admin`, and several datacollection profiles.\n\nAlso note: I only see Admin roles configured. For a read-only operation like checking Support cases, a ReadOnly role would be preferred for safety. Do you have one available, or should I proceed with one of the Admin profiles listed above?"
},
"delta_pass_rate": 1.0
}
],
"run_summary": {
"with_skill": {
"mean_pass_rate": 0.9444,
"stddev_pass_rate": 0.1361,
"mean_tokens": 779.3,
"mean_input_tokens": 240.5,
"mean_output_tokens": 779.3,
"mean_total_tokens": 1019.8,
"mean_tool_calls": 2.2
},
"without_skill": {
"mean_pass_rate": 0.5556,
"stddev_pass_rate": 0.4037,
"mean_tokens": 914.0,
"mean_input_tokens": 6.2,
"mean_output_tokens": 914.0,
"mean_total_tokens": 920.2,
"mean_tool_calls": 3.3
},
"delta": {
"pass_rate": 0.3889,
"tokens": -134.7,
"total_tokens": 99.7,
"input_tokens": 234.3,
"tool_calls": -1.2
},
"cost_efficiency": {
"quality_delta": 0.3889,
"cost_delta_pct": 10.8,
"classification": "TRADEOFF",
"emoji": "\ud83d\udfe1",
"description": "Skill improves quality but increases cost"
},
"estimated_cost": {
"with_skill_per_run": {
"input_cost": 0.000721,
"output_cost": 0.01169,
"total_cost": 0.012412,
"model": "sonnet",
"currency": "USD"
},
"without_skill_per_run": {
"input_cost": 1.9e-05,
"output_cost": 0.01371,
"total_cost": 0.013728,
"model": "sonnet",
"currency": "USD"
},
"per_eval_pair": 0.02614,
"total_runs": 6,
"total_cost": 0.1568,
"model": "sonnet",
"currency": "USD"
}
},
"scores": {
"outcome": 0.9444,
"process": 0.65,
"style": 0.9444,
"efficiency": 1.0,
"overall": 0.8847
},
"passed": true
}[
{
"query": "What Python libraries can I use to parse CloudWatch logs?",
"should_trigger": false
},
{
"query": "How do I configure auto-scaling for my ECS service?",
"should_trigger": false
},
{
"query": "Explain the difference between Application Load Balancer and Network Load Balancer",
"should_trigger": false
},
{
"query": "What are the required resources for a CloudFormation VPC with public and private subnets?",
"should_trigger": false
},
{
"query": "What are the best practices for S3 bucket security?",
"should_trigger": false
}
]
[
{
"id": "find-related-case-by-service",
"prompt": "I'm investigating a Lambda function error. The function started throwing errors today. Check if there are any related AWS Support cases.",
"expected_output": "A search of AWS Support cases reveals any related cases for the Lambda service, including case ID, subject, service code, severity, and status.",
"assertions": [
"The output includes a case ID or states no cases were found",
"The output identifies the service as aws-lambda or Lambda",
"The output does not produce an API error or permission denied message"
]
},
{
"id": "extract-root-cause-from-communications",
"prompt": "Review the most recent AWS Support case related to Lambda errors and tell me what the root cause was according to AWS Support.",
"expected_output": "The output extracts root cause information from the support case communications, identifying what caused the issue and what resolution was applied.",
"assertions": [
"The output describes a root cause or states that no root cause was documented",
"The output references information from case communications, not just metadata",
"The output does not fabricate details that are not in the case"
]
},
{
"id": "no-cases-found-scenario",
"prompt": "I'm investigating an S3 access denied error. Check if there are any related AWS Support cases for S3 issues in the past 30 days.",
"expected_output": "No AWS Support cases related to S3 access issues were found in the past 30 days. The investigation should continue using other data sources.",
"assertions": [
"The output indicates whether relevant S3 support cases were found or not",
"The output suggests alternative investigation paths if no cases exist",
"The output does not fabricate or hallucinate a support case that does not exist"
]
},
{
"id": "case-metadata-extraction",
"prompt": "List all AWS Support cases from the past month. For each case, provide the case ID, subject, service, severity, and status.",
"expected_output": "A structured list of support cases with case ID, subject, service code, severity level, status, and creation date for each case found.",
"assertions": [
"The output includes case IDs for any cases found",
"The output includes the subject for each case",
"The output includes the service code for each case",
"The output includes the severity level for each case",
"The output includes the case status for each case"
]
},
{
"id": "correlate-case-with-incident",
"prompt": "I'm investigating a CloudWatch alarm that triggered for Lambda function errors. Check support cases and tell me if this incident has been seen before and what the resolution was.",
"expected_output": "The output correlates the current alarm with any historical support cases, providing the case ID, root cause, and resolution steps if a matching case exists.",
"assertions": [
"The output attempts to correlate the current incident with historical cases",
"The output provides resolution steps if a matching case was found",
"The output clearly states if no matching historical case exists"
]
},
{
"id": "api-region-awareness",
"prompt": "Check AWS Support cases for Lambda errors. The Lambda function runs in us-west-2.",
"expected_output": "The AWS Support API is called from us-east-1 regardless of where the affected resources run, and returns relevant case information.",
"assertions": [
"The Support API call is made to us-east-1",
"The output does not fail due to region misconfiguration",
"The output returns relevant case information regardless of the resource's region"
]
}
]
{
"skill_name": "support-cases",
"skill_path": "/Users/udid/AWS Work/Services/DevOps Agent/aws-devops-agent-skill-central/skills/support-cases",
"timestamp": "2026-05-25T11:38:10Z",
"overall_score": 0.9379,
"overall_grade": "A",
"passed": true,
"sections": {
"audit": {
"score": 100,
"grade": "A",
"passed": true,
"normalized": 1.0,
"critical": 0,
"warning": 0,
"info": 0
},
"functional": {
"overall": 0.8847,
"grade": "B",
"passed": true,
"scores": {
"outcome": 0.9444,
"process": 0.65,
"style": 0.9444,
"efficiency": 1.0,
"overall": 0.8847
},
"cost_efficiency": {
"quality_delta": 0.3889,
"cost_delta_pct": 10.8,
"classification": "TRADEOFF",
"emoji": "\ud83d\udfe1",
"description": "Skill improves quality but increases cost"
},
"estimated_cost": {
"with_skill_per_run": {
"input_cost": 0.000721,
"output_cost": 0.01169,
"total_cost": 0.012412,
"model": "sonnet",
"currency": "USD"
},
"without_skill_per_run": {
"input_cost": 1.9e-05,
"output_cost": 0.01371,
"total_cost": 0.013728,
"model": "sonnet",
"currency": "USD"
},
"per_eval_pair": 0.02614,
"total_runs": 6,
"total_cost": 0.1568,
"model": "sonnet",
"currency": "USD"
}
},
"trigger": {
"pass_rate": 1.0,
"grade": "A",
"passed": true,
"total_queries": 5
}
}
}{
"skill_name": "support-cases",
"skill_path": "/Users/udid/AWS Work/Services/DevOps Agent/aws-devops-agent-skill-central/skills/support-cases",
"query_results": [
{
"query": "What Python libraries can I use to parse CloudWatch logs?",
"should_trigger": false,
"trigger_count": 0,
"run_count": 1,
"trigger_rate": 0.0,
"passed": true,
"mean_input_tokens": 3.0,
"mean_output_tokens": 422.0,
"mean_total_tokens": 425.0
},
{
"query": "How do I configure auto-scaling for my ECS service?",
"should_trigger": false,
"trigger_count": 0,
"run_count": 1,
"trigger_rate": 0.0,
"passed": true,
"mean_input_tokens": 3.0,
"mean_output_tokens": 622.0,
"mean_total_tokens": 625.0
},
{
"query": "Explain the difference between Application Load Balancer and Network Load Balancer",
"should_trigger": false,
"trigger_count": 0,
"run_count": 1,
"trigger_rate": 0.0,
"passed": true,
"mean_input_tokens": 3.0,
"mean_output_tokens": 528.0,
"mean_total_tokens": 531.0
},
{
"query": "What are the required resources for a CloudFormation VPC with public and private subnets?",
"should_trigger": false,
"trigger_count": 0,
"run_count": 1,
"trigger_rate": 0.0,
"passed": true,
"mean_input_tokens": 3.0,
"mean_output_tokens": 515.0,
"mean_total_tokens": 518.0
},
{
"query": "What are the best practices for S3 bucket security?",
"should_trigger": false,
"trigger_count": 0,
"run_count": 1,
"trigger_rate": 0.0,
"passed": true,
"mean_input_tokens": 3.0,
"mean_output_tokens": 547.0,
"mean_total_tokens": 550.0
}
],
"summary": {
"total_queries": 5,
"passed": 5,
"failed": 0,
"trigger_precision": 1.0,
"no_trigger_precision": 1.0,
"mean_total_tokens_per_run": 529.8,
"estimated_cost": {
"per_run": {
"input_cost": 9e-06,
"output_cost": 0.007902,
"total_cost": 0.007911,
"model": "sonnet",
"currency": "USD"
},
"total_runs": 5,
"total_cost": 0.0396,
"model": "sonnet",
"currency": "USD"
}
},
"passed": true
}Support Cases Skill
This skill enables the AWS DevOps Agent to retrieve and analyze AWS Support cases during incident investigation, root cause analysis, and operational troubleshooting.
Purpose
When an operational incident occurs, historical support cases often contain valuable context — prior root causes, proven remediations, and recurring patterns. This skill searches past AWS Support cases by service, time window, severity, and error keywords to surface relevant history that informs the current investigation.
Key Capabilities
- Retrieve open and resolved AWS Support cases via the Support API
- Search and filter cases by service, severity, time range, and keywords
- Review case communications for root cause statements and remediation steps
- Correlate historical findings with current incident symptoms
- Identify recurring patterns that may require permanent fixes
Prerequisites
- AWS account with Business Support+, Enterprise Support, or Unified Operations plan
- Agent permissions for
support:DescribeCasesandsupport:DescribeCommunications
Limitations
- Support case data is only available for up to 24 months after creation
Agent Types
This skill is used by the following agent types:
- Chat tasks — conversational support case lookup and analysis
- Incident RCA — automated root cause analysis during active incidents
Uploading to AWS DevOps Agent
To deploy this skill to your Agent Space:
1. Zip the support-cases/ directory (only including allowed extensions):
cd skills
zip -r support-cases.zip support-cases/ -i '*.md' '*.txt' '*.json' '*.yaml' '*.yml' '*.xml' '*.csv' '*.tsv' '*.html' '*.htm' '*.png' '*.jpg' '*.jpeg' '*.gif' '*.svg' '*.webp' '*.pdf' -x '*/.claude/*' '*/scripts/*' '*/README.md' '*/.skilleval.yaml' '*/.skilleval.yml' '*/CHANGELOG.md' '*/evals/*'2. In the AWS DevOps Agent Operator Web App, navigate to the Skills page. 3. Click Add skill → Upload skill. 4. Drag and drop the support-cases.zip file (max 6 MB). 5. Select the agent types: Chat tasks and Incident RCA. 6. Click Upload.
For more details, see Uploading a skill in the AWS DevOps Agent User Guide.
How to Use This Skill
This skill is most suitable for chat and investigation. Below are sample prompts for each use-case
Chat
- "Create a support cases report for all support cases in the last 12 months, including breakdowns by service and severity"
- "Show me all support cases opened in the last 30 days for RDS."
- "What was the resolution for case-123456789010-muen-2024?"
- "Are there any open critical-severity cases in this account?"
- "Summarize the communications on our most recent EC2 support case."
- "Have we filed any support cases related to Lambda throttling this quarter?"
Investigation
- "Investigate the Lambda-Errors alarm"
- "We're seeing 5xx errors on our ALB — can you investigate?"
- "RDS connections are maxing out and queries are timing out. What's going on?"
- "There's a latency spike on our ECS service starting around 3am UTC."
- "Our last deployment triggered elevated error rates across multiple endpoints."
- "The same DynamoDB throttling alarm fired again. Help me figure out why this keeps happening."
Support Case Review Patterns
Common patterns and heuristics for identifying relevant historical support cases during incident investigations.
Pattern 1: Recurring Infrastructure Failures
Indicators:
- Multiple cases with the same
serviceCodeandcategoryCodewithin 90 days. - Similar error messages appearing in case subjects or communications.
- Cases filed by different team members for the same underlying issue.
Investigation approach: 1. Search cases by service code for the past 90 days. 2. Group cases by categoryCode and look for clusters. 3. Review resolutions — if workarounds were applied instead of permanent fixes, the issue is likely recurring.
Example keywords to search in subjects:
- "timeout", "connection refused", "throttling"
- "5xx", "502", "503", "504"
- "capacity", "scaling", "limit"
---
Pattern 2: Post-Deployment Issues
Indicators:
- Incident started shortly after a deployment (within 1–4 hours).
- Past cases reference deployment-related root causes.
- Symptoms match a known regression pattern.
Investigation approach: 1. Identify the deployment timestamp from CI/CD pipeline. 2. Search cases created within 24 hours after similar past deployments. 3. Look for cases mentioning "rollback", "deployment", "release", or "config change".
---
Pattern 3: AWS Service Events
Indicators:
- Multiple accounts or services affected simultaneously.
- Past cases reference AWS Health Dashboard events.
- AWS Support responses mention "service team investigation" or "known issue".
Investigation approach: 1. Check AWS Health Dashboard for active events. 2. Search past cases in the same time window as known AWS service events. 3. Look for communications where AWS confirms a service-side issue.
Key phrases in AWS responses indicating service events:
- "Our service team has identified..."
- "This is a known issue affecting..."
- "We are actively working on..."
- "The issue has been resolved on our end..."
---
Pattern 4: Capacity and Scaling Issues
Indicators:
- Errors related to limits, quotas, or throttling.
- Incidents correlate with traffic spikes or batch processing windows.
- Past cases resulted in limit increases or scaling adjustments.
Investigation approach: 1. Search cases with keywords: "limit", "quota", "throttle", "capacity". 2. Check if limit increases from past cases are still sufficient. 3. Review if auto-scaling configurations recommended in past cases were implemented.
---
Pattern 5: Network and Connectivity Issues
Indicators:
- Timeout errors, DNS resolution failures, or connectivity drops.
- Issues affecting specific Availability Zones or regions.
- Past cases involving security group, NACL, or route table changes.
Investigation approach: 1. Search cases by VPC, ELB, or Route 53 service codes. 2. Look for cases mentioning the same Availability Zone or subnet. 3. Check if network configuration changes recommended in past cases were applied.
---
Correlation Heuristics
When comparing the current incident to historical cases, use these heuristics to assess relevance:
Strong correlation signals
- Identical error codes or exception types.
- Same resource ID or ARN appears in both incidents.
- Same time-of-day pattern (e.g., both occur during peak traffic hours).
- Same sequence of events leading to the failure.
Moderate correlation signals
- Same AWS service but different resource.
- Similar but not identical error messages.
- Same architectural pattern (e.g., both involve cross-AZ communication).
- Same category of root cause (e.g., both are configuration drift issues).
Weak correlation signals
- Different services but same failure mode (e.g., both are timeout-related).
- Same team or application owner filed both cases.
- Similar time window but different symptoms.
---
Anti-Patterns to Avoid
- Over-matching: Don't assume every past case for the same service is
relevant. Focus on matching symptoms and error patterns, not just service names.
- Ignoring resolved status: Resolved cases are often the most valuable
because they contain root cause analysis and proven fixes.
- Skipping communications: The case subject alone rarely contains enough
detail. Always review the full communication thread for relevant cases.
- Single-case bias: Don't anchor on the first matching case. Review multiple
cases to identify patterns rather than one-off issues.
- Stale recommendations: Verify that remediation steps from old cases still
apply to the current infrastructure configuration.
AWS Support API Reference
Quick reference for the AWS Support API operations used by this skill.
DescribeCases
Returns a list of support cases filtered by case IDs, date range, or status.
Key Parameters
| Parameter | Type | Description |
|---|---|---|
caseIdList | List of strings | Specific case IDs to retrieve |
afterTime | String (ISO 8601) | Return cases created after this timestamp |
beforeTime | String (ISO 8601) | Return cases created before this timestamp |
includeResolvedCases | Boolean | Include resolved/closed cases (default: false) |
includeCommunications | Boolean | Include communication thread (default: true) |
language | String | Language code for results (e.g., "en") |
maxResults | Integer | Max cases per page (10–100) |
nextToken | String | Pagination token |
Response Fields
| Field | Description |
|---|---|
caseId | Unique case identifier |
subject | Case subject line |
status | Current status: opened, pending-customer-action, reopened, resolved, unassigned, work-in-progress |
serviceCode | AWS service code (e.g., amazon-elastic-compute-cloud) |
categoryCode | Issue category within the service |
severityCode | Severity: low, normal, high, urgent, critical |
submittedBy | Email of the case creator |
timeCreated | Case creation timestamp |
recentCommunications | Latest communications (when includeCommunications is true) |
language | Language of the case |
---
DescribeCommunications
Returns the full communication thread for a specific support case.
Key Parameters
| Parameter | Type | Description |
|---|---|---|
caseId | String (required) | The case ID to retrieve communications for |
afterTime | String (ISO 8601) | Return communications after this timestamp |
beforeTime | String (ISO 8601) | Return communications before this timestamp |
maxResults | Integer | Max results per page (10–100) |
nextToken | String | Pagination token |
Response Fields
| Field | Description |
|---|---|
communications[].body | Full text of the communication |
communications[].submittedBy | Who sent the message (customer or AWS) |
communications[].timeCreated | Timestamp of the communication |
communications[].attachmentSet | Any attached files |
---
Common Service Codes
| Service | Code |
|---|---|
| EC2 | amazon-elastic-compute-cloud |
| RDS | amazon-relational-database |
| Lambda | aws-lambda |
| ELB | amazon-elastic-load-balancing |
| S3 | amazon-simple-storage-service |
| CloudFront | amazon-cloudfront |
| DynamoDB | amazon-dynamodb |
| ECS | amazon-elastic-container-service |
| EKS | amazon-elastic-kubernetes-service |
| VPC | amazon-virtual-private-cloud |
| Route 53 | amazon-route53 |
| IAM | aws-iam |
| CloudWatch | amazon-cloudwatch |
| SNS | amazon-simple-notification-service |
| SQS | amazon-simple-queue-service |
---
Severity Levels
| Level | Code | Description |
|---|---|---|
| Critical | critical | Business at risk, production system down |
| Urgent | urgent | Production system impaired |
| High | high | Important functions impaired |
| Normal | normal | Non-critical functions behaving abnormally |
| Low | low | General guidance or feature request |
---
Important Constraints
- Data retention: Case data is available for 12 months after creation.
- Support plan required: Business, Enterprise On-Ramp, or Enterprise Support
plan is required to use the AWS Support API.
- API endpoint: The AWS Support API is available only in the
us-east-1
region. All API calls must target this region regardless of where the affected resources are located.
- Pagination: Both operations are paginated. Use
nextTokento retrieve all
results when the response is truncated.
- Rate limiting: Standard AWS API rate limits apply. Use exponential backoff
for retries.
Related skills
Azure DeploySafely execute production deployments of already-prepared applications to Microsoft Azure.485k1.3kAzure ValidateRun deep pre-deployment checks on Azure configuration, infrastructure definitions, RBAC roles, and managed identities before pushing to production.485k1.3k
Github Actions DocsGet precise, docs-grounded answers about GitHub Actions workflows, syntax, security, and migration instead of relying on stale knowledge.275k72
Setup Pre CommitAutomatically run Prettier, type checking, and tests on every commit via Husky and lint-staged.170k199k
Deploy To VercelSafely turn any local project into a live Vercel preview with one instruction.99.3k29.7kVercel Cli With TokensDeploy projects to Vercel from agents and scripts using token authentication instead of interactive browser login.74.6k29.7kFAQ
How far back can support cases be retrieved?
Support case data is available for 24 months after creation; cases older than 24 months cannot be retrieved via the API.
What support plan is required?
The account must have a Business Support+, Enterprise Support, or Unified Operations plan to use the AWS Support API.