support-cases

Files (11)

• .skilleval.yaml
• CHANGELOG.md
• README.md
• SKILL.md
• benchmark.json · evals/
• eval_queries.json · evals/
• evals.json · evals/
• report.json · evals/
• trigger_report.json · evals/
• case-review-patterns.md · references/
• support-api-reference.md · references/

SKILL.md (first lines)

# 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:DescribeCases` and
  `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-communications
```

### Key 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?

From aws/tools-for-devops-agent, Apache-2.0.

More from aws/tools-for-devops-agent