$npx -y skills add aws-samples/sample-devops-agent-tools --skill support-casesALWAYS use this skill in the beginning of any incident investigation, root cause
| 1 | # Support Case Review |
| 2 | |
| 3 | Use this skill when investigating an incident and you need to review AWS Support |
| 4 | cases — either the current case associated with the incident or historical cases |
| 5 | that may contain relevant context, similar symptoms, or proven remediation steps. |
| 6 | |
| 7 | ## When to Use This Skill |
| 8 | |
| 9 | - An active incident shares symptoms with previously resolved issues. |
| 10 | - You need to check if a similar support case was filed in the past 24 months. |
| 11 | - You want to correlate the current incident with known AWS service events. |
| 12 | - You need to retrieve communications and resolution details from a prior case. |
| 13 | - You want to identify recurring patterns across multiple support cases. |
| 14 | |
| 15 | ## Prerequisites |
| 16 | |
| 17 | - The AWS account must have a Business Support+, Enterprise Support, or |
| 18 | Unified Operations plan (required for the AWS Support API). |
| 19 | - The agent must have permissions to call `support:DescribeCases` and |
| 20 | `support:DescribeCommunications` in the target account. |
| 21 | - Support case data is available for 24 months after creation. Cases older than |
| 22 | 24 months cannot be retrieved via the API. |
| 23 | |
| 24 | --- |
| 25 | |
| 26 | ## Step 1: Identify the Current Incident Context |
| 27 | |
| 28 | Before searching support cases, gather key details from the current incident: |
| 29 | |
| 30 | 1. **Affected AWS services** (e.g., EC2, RDS, Lambda, ELB). |
| 31 | 2. **Error messages or error codes** observed in logs or alarms. |
| 32 | 3. **Timeframe** of the incident (start time, duration). |
| 33 | 4. **Affected resources** (instance IDs, ARNs, endpoint names). |
| 34 | 5. **Symptoms** (latency spikes, 5xx errors, connection timeouts, throttling). |
| 35 | |
| 36 | Use these details as search criteria when filtering support cases. |
| 37 | |
| 38 | --- |
| 39 | |
| 40 | ## Step 2: Search for Related Support Cases |
| 41 | |
| 42 | Use the AWS Support API to retrieve cases that may be relevant. |
| 43 | |
| 44 | ### Retrieve all recent cases (open and resolved) |
| 45 | |
| 46 | ``` |
| 47 | aws support describe-cases \ |
| 48 | --include-resolved-cases \ |
| 49 | --include-communications \ |
| 50 | --after-time "<ISO-8601-start>" \ |
| 51 | --before-time "<ISO-8601-end>" \ |
| 52 | --language "en" |
| 53 | ``` |
| 54 | |
| 55 | ### Filter by specific case IDs (if known) |
| 56 | |
| 57 | ``` |
| 58 | aws support describe-cases \ |
| 59 | --case-id-list "case-123456789010-muen-2024" \ |
| 60 | --include-communications |
| 61 | ``` |
| 62 | |
| 63 | ### Key filtering strategies |
| 64 | |
| 65 | | Strategy | How to Apply | |
| 66 | |----------|-------------| |
| 67 | | 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. | |
| 68 | | 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. | |
| 69 | | 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. | |
| 70 | | 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. | |
| 71 | | By subject keywords | Scan the `subject` field of returned cases for keywords matching the current incident symptoms, because similar symptoms often share underlying causes. | |
| 72 | |
| 73 | --- |
| 74 | |
| 75 | ## Step 3: Review Case Communications |
| 76 | |
| 77 | The `describe-cases` response with `includeCommunications: true` returns the |
| 78 | most recent communications for each case in the `recentCommunications` field |
| 79 | (up to 5 messages). Since root cause analysis and resolution steps are |
| 80 | typically in the final messages of a resolved case, this is usually sufficient. |
| 81 | |
| 82 | If the `recentCommunications` field includes a `nextToken`, the case has |
| 83 | additional older messages. Only paginate using `describe-communications` if the |
| 84 | recent messages do not contain a clear root cause or resolution — for example, |
| 85 | if the last messages are follow-up questions rather than a final answer. |
| 86 | |
| 87 | ``` |
| 88 | aws support describe-communications \ |
| 89 | --case-id "case-123456789010-muen |