AWS Backup Coverage Review

AWS Backup Coverage Review

Perform a structured, read-only coverage and posture review of AWS Backup in one account across all enabled Regions. The review answers one question precisely — which backup-eligible resources are actually recoverable, and which are not — then explains why each gap exists and how to close it.

Output Contract — read this before doing anything else

The only acceptable output of this skill is the full report defined in the Final Delivery Contract below. A conversational prose summary of the findings — however accurate, however well organised — is a failed run.

Every response must contain, in order: Scope (including Regions swept and not swept), Coverage Rating with a coverage percentage, Executive Summary, Coverage Matrix, Findings & Recommendations, a Check Coverage Matrix with all 23 rows, and Next Steps.

Three failure modes to avoid specifically, because all three feel natural in a chat:

• Do not compress the report into narrative bullets because the question was phrased casually. "What isn't being backed up?" requires the same full report as "run an AWS Backup coverage review".
• Do not substitute a direct lookup when the question is narrow. "Are my EBS volumes protected in us-east-1?" narrows the scope of the review; it does not authorise a different output. Narrow the sweep, then render the full report for that scope. See Scoped requests under the Final Delivery Contract — and Follow-up questions in the same conversation for the single exception, which applies only after a qualifying report has already been delivered in this conversation.
• Do not end with an offer to investigate further or to fix anything ("want me to dig into any of these?", "which gap would you like to tackle first?"). The report is the deliverable, complete on first response. Findings the review surfaces are already in it, each with a recommendation and an SLA bucket. In particular, never offer to "run the full coverage review" as a follow-up — if this skill loaded, the full review for the requested scope is the current response.

If you cannot complete a section, render it with the explicit status values defined below (AccessDenied, ToolingFailure, NotEnumerated) — never drop it.

Self-check before responding. Count the rows in your Check Coverage Matrix. If the count is not exactly 23, or if the response contains no ## Coverage Rating heading and no coverage percentage, the response is incomplete — fix it before sending. Then verify the protected count and the coverage percentage are identical everywhere they appear — Coverage Rating, headline, and the by-type table. A report that states two different coverage figures is wrong regardless of which is correct.

When to Use

Activate this skill when the user asks to:

• Find out what is not being backed up, or which resources are unprotected
• Review, audit, or assess AWS Backup coverage, posture, or configuration
• Review backup plans, backup selections, or backup vaults
• Assess data protection gaps or backup compliance without AWS Config or AWS Backup Audit Manager already being set up
• Check whether specific resources (volumes, databases, file systems, tables) are protected by AWS Backup

Do NOT activate for restoring data or recovery execution, backup/restore job failure triage, backup storage cost optimization, or RDS-native automated backups and manual snapshots taken outside AWS Backup. For Amazon S3 bucket versioning, replication, and Object Lock posture, storage-s3-resiliency-expertise is the correct skill.

Why This Skill Exists

AWS Backup Audit Manager's BACKUP_RESOURCES_PROTECTED_BY_BACKUP_PLAN control requires AWS Config recording, a framework, and a report plan that has already run. Many accounts have none of that, so this skill computes the answer on demand from read-only APIs, treating AWS Config as an optimization rather than a prerequisite.

Architecture

• This skill (orchestrator/analyzer): scope resolution, routing, coverage model application, rating, report rendering.
• Data collection: data collection reference — the read-only API allowlist, hard denials, the per-Region and per-resource-type call plan, and error classification. Load it at Step 2, before issuing any API call. Data is acquired with the agent's native use_aws tool under the assumed role in the target account. No credentials or profile are requested from the user.
• Coverage logic: coverage logic reference — all 23 checks, thresholds, verdict rules, finding templates, and the rating roll-up. Load it at Step 6, before evaluating the checks.
• Report template: report template — report structure, the coverage matrix, the check coverage matrix, severity map, pre-render validation. Load it at Step 8, before rendering the report.
• Operational depth: backup best practices reference — reasoning behind the thresholds, remediation guidance, and the canonical AWS documentation URLs. Load it when a finding needs remediation guidance or a documentation citation.

The Coverage Model

Coverage is not binary. Every eligible resource resolves to exactly one of six states. Getting this distinction right is the whole value of the review — a resource can sit inside a backup plan and still be unrecoverable.

OrphanedRecoveryPoint is resolved from the opposite direction to the other five. ListProtectedResources keeps returning a resource long after it is deleted, so every entry it returns must be cross-checked against the live inventory. An entry with no matching live resource is an orphaned recovery point: it is a retention and cost issue, not a coverage gap. Never count it as Protected, never count it as Stale, and never include it in the coverage numerator or denominator — a deleted resource needs no protection. Report it, with the age of its newest recovery point, so long-abandoned recovery points in unused Regions become visible.

OptInBlocked is the most commonly missed real finding, because the AWS Backup console shows the plan and selection as correctly configured.

Scope Resolution

Never ask the user for the account or the Region list. Resolve silently:

1. Account — sts:GetCallerIdentity.
2. Regions — ec2:DescribeRegions with AllRegions=false (enabled Regions only).
3. If the user named specific Regions, resource types, or resource ARNs, narrow to those and say so in the report header. Otherwise review everything.

Region sweep discipline. Sweep every enabled Region unless the user narrowed the scope. Do not shortcut to a handful of "likely" Regions — an unprotected resource in an unswept Region is the exact thing this review exists to find, and a Region looks empty only after it has been queried. A cheap probe (ListProtectedResources plus one or two inventory calls) is enough to eliminate a Region; drop it from further work once it returns nothing.

If any enabled Region was not swept, the report's Scope table must list it under "Regions not swept", and the Coverage Rating must be capped at Medium, because the denominator is incomplete. Never present a coverage percentage as account-wide when Regions were skipped.

If the user names a resource type AWS Backup does not support, state that plainly and continue with the supported types rather than aborting.

Execution Flow

Work through these in order; each step depends on the one before it.

• Step 1 — Resolve scope: apply the scope rules above.
• Step 2 — Determine the inventory strategy once, loading the data collection reference first:
  • Call config:DescribeConfigurationRecorderStatus. If a recorder exists and recording is true → Config fast path (one config:SelectResourceConfig query per Region).
  • Otherwise → direct enumeration (per-service Describe/List calls).
  • Record which strategy was used; the report must disclose it, because it determines how complete the denominator is.
• Step 3 — Collect AWS Backup configuration per Region: region settings, plans, selections, vaults, protected resources, restore testing plans.
• Step 4 — Collect the eligible-resource inventory per Region using the chosen strategy.
• Step 5 — Resolve coverage states: assign every eligible resource exactly one of the six coverage states. Persist the per-resource rows as you resolve them — write each resource's Region, type, ARN or identifier, coverage state, last backup, and matched selection to a working file (e.g. fs_write to a scratch path). This is the account-wide inventory; on a large sweep it will not survive in context to Step 8, so it must exist on disk. Render the Coverage Matrix from this file, not from memory.
• Step 6 — Evaluate the checks: load the coverage logic reference and evaluate all 23 checks. Persist all 23 verdicts (check ID, verdict, finding text, severity, status) to the working file alongside the inventory, for the same reason. Render the Check Coverage Matrix and Findings from this file.
• Step 7 — Evaluate pre-flight: inspect every status field in the collected data.
  • Any AccessDenied → present the permissions audit below.
  • Any ToolingFailure → present the tooling notice below.
  • Otherwise proceed.
• Step 8 — Render the report: load the report template again now, immediately before rendering. A read from earlier in the run does not count — on a long sweep the template falls out of context, and rendering from a remembered outline drops required sections and collapses headings. Re-read it, then render every section it defines, drawing the Coverage Matrix, Check Coverage Matrix and Findings from the working file written in Steps 5 and 6.
• Step 9 — Validate: run the pre-render validation checks.
• Step 10 — Deliver per the Final Delivery Contract below.

Pre-flight: Permissions audit

If any check returned AccessDenied, present:

⚠️ The role is missing read permissions for some checks.

Check	Missing action	Status
<check id and name>	<iam:Action>	AccessDenied

Coverage cannot be stated accurately without these — an unreadable resource type is not the same as an unprotected one.

How would you like to proceed?

1. Stop here (recommended). Add the missing permissions and re-run.
2. Continue with reduced accuracy. Affected resource types will be reported as Unknown, excluded from the coverage percentage, and the Coverage Rating will be capped at Medium.

Wait for the user's response. Do NOT proceed by default.

Pre-flight: Tooling notice

If any check returned ToolingFailure, present:

⚠️ Tooling infrastructure failure — some checks could not reach the AWS API.

Check	Status
<check id and name>	ToolingFailure

How would you like to proceed?

1. Stop here and retry later (recommended).
2. Continue with partial data. Report will note the gaps; rating capped at Medium.

Wait for the user's response. Do NOT proceed by default.

Coverage Rating

One rating for the account, from the roll-up rules in the coverage logic reference:

AccessDenied and ToolingFailure never lower the score. They cap the rating at Medium. A permissions gap is not a coverage gap.

Severity Definitions

Emoji map: CRITICAL → ❌ · HIGH → ⚠️ · MEDIUM → ⚠️ · LOW → ℹ️ · INFO → ℹ️ · pass → ✅ · unverifiable → 🚫

Final Delivery Contract (Required)

This defines how to deliver the full report the Output Contract already mandates; it does not restate that the report is the only acceptable output.

If you delegate any part of this review to a subagent

Delegating the account sweep to a research subagent is allowed, but the subagent returns data, never the final answer. A subagent may not receive this skill's references/ or assets/ files, so it cannot be trusted to render the report.

• The agent that owns this skill renders the report itself, from the data the subagent returned.
• Never relay a subagent's summary as the final response.
• If the subagent's data is missing anything the report requires, ask it for that specific data or collect it directly. Do not omit a section because the data came back thin.
• Bound each subagent to a compact, structured return. Give it a fixed schema — per-resource inventory rows (Region, type, ARN, coverage state, last backup, matched selection) plus the raw AWS Backup configuration, as data only, no prose narration and no rendered report. A subagent that returns a long free-text answer forces a distillation pass that silently drops the per-resource detail the Coverage Matrix needs. Have it write its findings to the shared working file (Steps 5–6) rather than returning them inline where possible.
• Split the sweep into non-overlapping Region groups, one group per subagent. Overlapping groups re-collect the same Regions, multiplying tool calls and the volume that must later be distilled.
• A subagent that returns nothing — a refusal, an empty result, a cancelled operation — is a ToolingFailure for every resource type it was asked to cover, not evidence those types are absent. Record it as ToolingFailure, name what failed, and either re-collect that group directly or disclose it in the tooling notice. Never treat a missing subagent return as "zero resources."