# skill-eval audit configuration
# See: https://github.com/aws-samples/sample-agent-skill-eval
audit:
  ignore:
    # README.md alongside SKILL.md is intentional and required by this repo's
    # contribution guide (README carries the non-production disclaimer,
    # prerequisites, and upload steps). Matches the convention used by the
    # other skills in this repository.
    - STR-016

# Changelog

## [1.0.1] - 2026-09-16

### Changed
- Clarified the data-boundary documentation: `bedrock-agentcore:ListMemoryRecords` is a data-plane call and its response can include PII-bearing memory `content`. The skill uses it **only** to count records (AC-MEM-2) and never reads, stores, or reproduces `content`. Updated SKILL.md, README (new "Memory record data handling" section), references, sample IAM policies, and the CloudFormation block to state this accurately, and separated the action into its own clearly-labeled IAM statement so it can be omitted for zero data-plane access.

## [1.0.0] - 2026-09-10

### Added
- Initial release of the `agentcore-ops-review` skill for AWS DevOps Agent.
- Runtime Resilience checks (AC-RUN-1..4): failed/stuck runtime and endpoint states, single-AZ VPC placement, endpoint version drift, and DEFAULT-endpoint-only deployments.
- Gateway Health check (GW-01): gateway status, target redundancy and health, policy engine attachment, and target synchronization freshness.
- Memory & Knowledge Effectiveness checks (AC-MEM-1..4): strategy-aware extraction-error, empty long-term memory, high ingestion error rate, and provisioned-but-never-populated detection.
- Resource Utilization & Operational Hygiene checks (AC-UTIL-1..3): idle resources, consolidation opportunities, and low overall utilization. Estate discovery covers runtimes, memories, gateways, browsers, code interpreters, and workload identities.
- Cross-pillar runtime observability from the `AWS/Bedrock-AgentCore` CloudWatch namespace (`SessionCount`, `Invocations`, `Throttles`, `CPUUsed-vCPUHours`, `MemoryUsed-GBHours`), with `ActiveSessionCount` preferred for the idle-resource signal where available.
- Two IAM modes: runtime-observability-only (CloudWatch only) and full control-plane (read-only `bedrock-agentcore:` set + `ec2:DescribeSubnets`). Missing permissions degrade affected checks to visibility limits rather than failing the review.
- Structured report artifact with executive summary, prioritized findings, KPI summary, per-pillar detail, visibility limits, and methodology (`references/report-template.md`).
- Sample IAM policies for observability-only, linked, and management accounts.

# Bedrock AgentCore Operational Review — AWS DevOps Agent Skill

A comprehensive Amazon Bedrock AgentCore operational review skill for [AWS DevOps Agent](https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent.html). Conducts best-practices assessments aligned with the [Amazon Bedrock AgentCore Developer Guide](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html) and the [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html). Generates a shareable report artifact for the review.

## What It Does

When activated via Chat, this skill instructs the DevOps Agent to:

1. Discover AgentCore resources in the configured account/regions — agent runtimes, endpoints, versions, memories (and their strategies), gateways and gateway targets, browsers, code interpreters, and workload identities.
2. Collect CloudWatch metrics from the `AWS/Bedrock-AgentCore` namespace for session counts, invocations, throttles, vCPU-hours, GB-hours, and memory ingestion errors.
3. Resolve VPC subnet placement to availability zones (via `ec2:DescribeSubnets`) to assess runtime AZ fault tolerance.
4. Analyze against four check areas mapped to the Well-Architected Framework — **Runtime Resilience** (Reliability), **Gateway Health** (Reliability), **Memory & Knowledge Effectiveness** (Performance Efficiency), and **Resource Utilization & Operational Hygiene** (Operational Excellence) — plus cross-pillar runtime observability signals.
5. Generate a shareable report artifact, titled `Bedrock AgentCore Operational Review — <account-id> — <YYYY-MM-DD>`.

All data is gathered through native AWS APIs (`bedrock-agentcore`, `cloudwatch`, `ec2`, `ce`, `health`). The skill never invokes an agent (`InvokeAgentRuntime`) and reads no prompts or responses. It makes **one** data-plane call — `bedrock-agentcore:ListMemoryRecords` — solely to count long-term memory records; that response can include potentially PII-bearing `content`, which the skill never reads, stores, or reproduces (see [Memory record data handling](#memory-record-data-handling)). It does not depend on any internal tooling.

## Agent Types

This skill is intended for the following agent types (selected in the Operator Web App at upload time):

- **On-demand** — conversational invocation in Chat ("review my AgentCore runtimes", "AgentCore health check").
- **Evaluation** — proactive operational improvement recommendations.

Select **Generic** instead if you want the skill available to all agent types.

## Prerequisites

### 1. An AWS DevOps Agent Space with the target AWS account

You need an existing [Agent Space](https://docs.aws.amazon.com/devopsagent/latest/userguide/getting-started-with-aws-devops-agent-creating-an-agent-space.html) with the target AWS account configured as a cloud source.

### 2. IAM permissions — two modes

The standard `AIDevOpsAgentAccessPolicy` covers `bedrock:*` read actions but does **NOT** include the `bedrock-agentcore:*` namespace. (Note: `bedrock-agentcore-control` is the SDK client name, not an IAM prefix — every control-plane action such as `ListAgentRuntimes`, `GetMemory`, and `ListGateways` authorizes under the single service prefix `bedrock-agentcore:`.) The skill supports two modes:

**Runtime-observability-only mode** — relies exclusively on CloudWatch metrics against namespace `AWS/Bedrock-AgentCore`. Requires no `bedrock-agentcore:` additions. See `references/iam-policy-observability-only.json`:

- `cloudwatch:ListMetrics`, `cloudwatch:GetMetricData`
- `health:DescribeEvents`, `health:DescribeEventDetails`
- `sts:GetCallerIdentity`
- `ce:GetCostAndUsage`, `ce:GetDimensionValues` (region discovery)

**Full control-plane mode** — adds the read-only `bedrock-agentcore:` set plus `ec2:DescribeSubnets` to enable the runtime/gateway/memory/utilization checks. See `references/iam-policy-linked-account.json` (and `references/iam-policy-management-account.json` for the payer/management account):

- `bedrock-agentcore:ListAgentRuntimes`, `GetAgentRuntime`, `ListAgentRuntimeEndpoints`, `ListAgentRuntimeVersions`
- `bedrock-agentcore:ListMemories`, `GetMemory` (control-plane), `ListMemoryRecords` (data-plane; record count only — see [Memory record data handling](#memory-record-data-handling))
- `bedrock-agentcore:ListGateways`, `GetGateway`, `ListGatewayTargets`, `GetGatewayTarget`
- `bedrock-agentcore:ListBrowsers`, `ListCodeInterpreters`, `ListWorkloadIdentities`
- `ec2:DescribeSubnets` (AC-RUN-2 multi-AZ check)

The skill operates in **read-only** mode: it never calls `Create*`, `Update*`, `Delete*`, or `InvokeAgentRuntime`. Its only data-plane call is `bedrock-agentcore:ListMemoryRecords`, used for a record count and nothing else (see [Memory record data handling](#memory-record-data-handling)). If a required permission is missing, the affected check degrades to a **visibility limit** ("signal unavailable — check skipped") rather than failing the review or producing a false finding.

### 3. AgentCore workloads with activity (recommended)

Most checks rely on `AWS/Bedrock-AgentCore` CloudWatch metrics and control-plane inventory, which only exist for accounts actively using AgentCore. Reviewing an account with no AgentCore activity produces "No AgentCore usage detected" rather than false findings.

### 4. Relationship to `agentcore-observability-setup`

This skill assesses operational posture from *existing* telemetry; it does not configure or validate observability wiring. Where telemetry is absent, it reports a visibility limit and defers the configuration gap to the `agentcore-observability-setup` skill, which owns the observability-wiring finding.

## Uploading to AWS DevOps Agent

> Reference: [Uploading a skill](https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-skills.html#uploading-a-skill)

### 1. Package the skill

From the `skills/` directory in this repo, build the archive from **inside** the
skill directory so `SKILL.md` sits at the archive root (nesting it under a
subdirectory causes `Failed to get skill resource` errors at load time):

```bash
cd skills/agentcore-ops-review
zip -qrD ../agentcore-ops-review.zip . \
  -x 'README.md' 'CHANGELOG.md' '.skilleval.yaml' 'evals/*'
```

The resulting `agentcore-ops-review.zip` contains `SKILL.md` at the root plus the
`references/` files:

```
SKILL.md               # frontmatter + skill instructions (required, at root)
references/
├── pillar-checks.md
├── report-template.md
├── iam-policy.json
├── iam-policy-observability-only.json
├── iam-policy-linked-account.json
└── iam-policy-management-account.json
```

`README.md`, `CHANGELOG.md`, `.skilleval.yaml`, and `evals/` are excluded from the
upload — they are repo/offline-evaluation artifacts, not part of the runtime skill.

Constraints (enforced at upload time):

- Total zip size ≤ **6 MB**.
- `SKILL.md` is required and must include `name` and `description` frontmatter.
- A `scripts/` directory is **not** allowed — uploads containing scripts are rejected.

### 2. Upload via the Operator Web App

1. Navigate to the **Skills** page in your Agent Space Operator Web App.
2. Click **Add skill** → **Upload skill**.
3. Drag and drop `agentcore-ops-review.zip` (or browse to it).
4. Select agent types: **On-demand** and **Evaluation** (or leave **Generic** to make it available to all agent types).
5. Review the validation results.
6. Click **Upload**.

## Usage

In the DevOps Agent Chat, use natural language:

- *"Run an AgentCore operational review for all regions."*
- *"Review my AgentCore runtimes in `us-east-1` for resilience."*
- *"Audit my agent memory pipelines for extraction errors."*
- *"Check my AgentCore gateway health and target redundancy."*
- *"ORR for our AgentCore workloads."*

The agent will:

- Collect all data automatically (no prompts for confirmation).
- Use only AWS read APIs — no agent invocation, no prompts/responses read; the sole data-plane call (`ListMemoryRecords`) is used for a record count only, never for `content`.
- Generate a report artifact titled `Bedrock AgentCore Operational Review — <account-id> — <YYYY-MM-DD>`.

## Skill Contents

```
agentcore-ops-review/
├── SKILL.md                            # main skill instructions (with frontmatter)
├── README.md                           # this file
├── CHANGELOG.md                        # version history
├── references/
│   ├── pillar-checks.md                # detailed check definitions, rules, thresholds
│   ├── report-template.md              # artifact report structure
│   ├── iam-policy.json                 # policy index / notes
│   ├── iam-policy-observability-only.json
│   ├── iam-policy-linked-account.json
│   └── iam-policy-management-account.json
└── evals/                              # evaluation data (not included in upload zip)
```

## Check Areas Covered

| Pillar (WA) | Check Area | Rule IDs | Reference |
|-------------|-----------|----------|-----------|
| Reliability | Runtime Resilience & Production Readiness | AC-RUN-1..4 | [AgentCore runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime.html) |
| Reliability | Gateway Health & Target Redundancy | GW-01 | [AgentCore gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) |
| Performance Efficiency | Memory & Knowledge Effectiveness | AC-MEM-1..4 | [AgentCore memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html) |
| Operational Excellence | Resource Utilization & Operational Hygiene | AC-UTIL-1..3 | [AgentCore observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html) |
| Cross-pillar | Runtime Observability (session count, invocations, throttles, vCPU/GB-hours) | — | [AgentCore observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html) |

## Severity Definitions

| Severity | Definition | SLA |
|----------|------------|-----|
| CRITICAL | Immediate risk to availability, security, or data integrity | 24–48 hours |
| HIGH | Significant gap that could lead to incidents | 1 week |
| MEDIUM | Notable improvement opportunity | 30 days |
| LOW | Minor optimization or hardening | When convenient |
| INFO | Observation, no action required | N/A |

## Memory record data handling

The skill's only data-plane call is `bedrock-agentcore:ListMemoryRecords`, used to count records for long-term memories (check AC-MEM-2). Each `MemoryRecordSummary` in that response includes a required `content` field — the extracted facts, preferences, and summaries a long-term memory has stored, which can contain end-user PII.

This skill uses **only the record count**. It does not read, parse, log, store, transform, transmit, or reproduce the `content` field anywhere — not in findings, artifacts, recommendations, or logs.

If you prefer the skill make **zero** data-plane calls, omit `bedrock-agentcore:ListMemoryRecords` from the IAM policy. AC-MEM-2 (empty/near-empty long-term memory) then degrades to a documented visibility limit, while all other memory checks — which rely on CloudWatch ingestion metrics (`Errors`, `Invocations`, `NumberOfMemoryRecords`) — continue to work.

## Non-production disclaimer

> ⚠️ This skill is sample code, not intended for production use without additional review and testing. Users should validate it in a non-production environment first. It performs read-only operational analysis and makes no changes to your AWS resources, but you are responsible for reviewing the IAM permissions you grant and the findings it produces before acting on them.

---
name: agentcore-ops-review
description: Comprehensive operational review procedures for Amazon Bedrock
  AgentCore resources aligned with the AWS Well-Architected Framework. Covers four
  check areas — Runtime Resilience, Gateway Health, Memory & Knowledge
  Effectiveness, and Resource Utilization & Operational Hygiene — plus runtime
  observability signals from CloudWatch. Use this skill when a user asks to review,
  audit, or assess Amazon Bedrock AgentCore workloads, perform an AgentCore
  operational readiness review, investigate agent runtime failures, audit
  memory/knowledge pipeline health, or review gateway resilience and resource
  hygiene. Triggers on requests like "AgentCore review", "AgentCore best practices
  audit", "review my AgentCore runtimes", "AgentCore health check", "audit my agent
  memory pipelines", or "ORR for AgentCore".
metadata:
  author: pamvas
  version: "1.0.1"
  aws-devops-agent-skills.agent-types: "Chat tasks, Evaluation"
  aws-devops-agent-skills.aws-services: "Amazon Bedrock AgentCore"
  aws-devops-agent-skills.technical-domains: "Machine Learning, GenAI"
---

# Bedrock AgentCore Operational Review

Use this skill when performing an operational review of Amazon Bedrock AgentCore resources, investigating agent runtime failures, auditing memory/knowledge pipeline health, or reviewing gateway resilience and resource hygiene.

## Overview

This skill provides procedures for a review of AgentCore resources across four check areas mapped to the AWS Well-Architected Framework:

- **Runtime Resilience** (Reliability) — Failed/stuck runtimes and endpoints, single-AZ VPC placement, endpoint version drift, DEFAULT-endpoint-only deployments
- **Gateway Health** (Reliability) — Gateway status, target redundancy and health, policy engine attachment, target synchronization freshness
- **Memory & Knowledge Effectiveness** (Performance Efficiency) — Extraction pipeline errors, empty long-term memory, high ingestion error rate, provisioned-but-never-populated memories
- **Resource Utilization & Operational Hygiene** (Operational Excellence) — Idle resources, consolidation opportunities, low overall utilization
- **Runtime Observability** (cross-pillar) — Session counts, invocations, throttles, vCPU-hours, GB-hours per runtime

This is a **READ-ONLY** review. No modifications are made to any resource, and it never invokes an agent (`InvokeAgentRuntime`), reads no prompts or responses, and makes no other data-plane calls. **One exception:** for long-term memories the skill calls `bedrock-agentcore:ListMemoryRecords` (a data-plane API) solely to obtain a **record count**. That response can include a `content` field carrying extracted, potentially PII-bearing memory content; the skill uses **only the count** and never parses, logs, stores, or reproduces `content`. See "Memory record data handling" below.

## Data Source Boundaries (IMPORTANT — IAM footprint)

The standard `AIDevOpsAgentAccessPolicy` covers `bedrock:*` read actions but does **NOT** include the `bedrock-agentcore:*` namespace. (Note: `bedrock-agentcore-control` is the SDK client name, not an IAM prefix — all control-plane actions such as `ListAgentRuntimes`, `GetMemory`, and `ListGateways` authorize under the single service prefix `bedrock-agentcore:`.) Two modes:

1. **Runtime-observability-only mode** — relies exclusively on CloudWatch metrics (`cloudwatch:GetMetricData`, `cloudwatch:ListMetrics`) against namespace `AWS/Bedrock-AgentCore`. Requires no `bedrock-agentcore:` additions. When an account isn't using AgentCore, the namespace is simply empty ("no activity detected") — this is not a failure.
2. **Full control-plane mode** — adds read-only `bedrock-agentcore:` control-plane List/Get actions and `ec2:DescribeSubnets` to enable the runtime/gateway/memory/utilization checks. It also uses one **data-plane** action, `bedrock-agentcore:ListMemoryRecords`, for the long-term-memory record count only (see "Memory record data handling" below). See `references/iam-policy-linked-account.json`.

If a required permission is missing, the affected check degrades to a **visibility limit** (reported as "signal unavailable / check skipped") rather than failing the review or producing a false finding.

**Memory record data handling:** `bedrock-agentcore:ListMemoryRecords` is a data-plane API whose `MemoryRecordSummary` entries include a required `content` field — the extracted facts/preferences/summaries a long-term memory has stored, which can contain end-user PII. This skill calls it **only** to count records for AC-MEM-2 and never reads, parses, logs, stores, transforms, or reproduces the `content` field. If you prefer zero data-plane access, omit this action from the IAM policy: AC-MEM-2 then degrades to a visibility limit while all other memory checks (which use CloudWatch ingestion metrics) continue to work.

**Seam with `agentcore-observability-setup`:** This skill assesses operational posture from *existing* telemetry; it does not configure or validate observability wiring. Where telemetry is absent, this skill reports a visibility limit and defers the configuration gap to `agentcore-observability-setup` — that skill owns the observability-wiring finding (Transaction Search, OTEL/ADOT, log delivery, X-Ray resource policy), while this skill reports only the posture consequence. A customer running both should not see two overlapping findings on the same resource.

## Step 1: Discover Account and Regions

1. Call `sts:GetCallerIdentity` to determine the account.
2. Discover AgentCore-active regions:
   - Query Cost Explorer: `ce:GetDimensionValues` (dimension SERVICE, last 30 days), match "Amazon Bedrock AgentCore".
   - Then `ce:GetCostAndUsage` for that service grouped by REGION; select top regions by UnblendedCost.
   - If no AgentCore spend is found, fall back to probing `cloudwatch:ListMetrics` (namespace `AWS/Bedrock-AgentCore`) in the customer's primary regions to detect activity.
3. If no AgentCore activity is detected in any region, stop: "No AgentCore usage detected in the last 30 days."

## Step 2: Runtime Resilience Pillar (Reliability)

Discover runtimes and enrich each with endpoints and versions:
- `bedrock-agentcore:ListAgentRuntimes` → `GetAgentRuntime` (status, `failureReason`, `networkConfiguration`)
- `bedrock-agentcore:ListAgentRuntimeEndpoints` (status, `liveVersion`, `targetVersion`, name)
- `bedrock-agentcore:ListAgentRuntimeVersions` (to compute latest version + drift)
- `ec2:DescribeSubnets` (resolve VPC subnet IDs to AZs — endpoints carry NO AZ data)

| Check | Rule | Severity |
|-------|------|----------|
| AC-RUN-1 | Runtime/endpoint in `CREATE_FAILED`/`UPDATE_FAILED`, or stuck in `CREATING`/`UPDATING` > 1 hour | **Critical** |
| AC-RUN-2 | VPC-mode runtime whose subnets all resolve to a single AZ (PUBLIC mode exempt) | **High** |
| AC-RUN-3 | Live endpoint ≥ 3 versions behind latest runtime version | **Medium** |
| AC-RUN-4 | Actively-updated runtime (2+ versions) served only by the auto-updating DEFAULT endpoint | **Low** |

**Key fact:** Endpoints are a versioning/traffic-routing construct, not a redundancy mechanism. AZ fault tolerance is derived exclusively from the runtime's VPC subnet configuration. If `ec2:DescribeSubnets` is unavailable, AC-RUN-2 degrades to "AZ distribution unknown".

## Step 3: Gateway Health (Reliability)

Discover gateways and their targets:
- `bedrock-agentcore:ListGateways` → `GetGateway` (status, protocolType, authorizerType, `policyEngineConfiguration`)
- `bedrock-agentcore:ListGatewayTargets` → `GetGatewayTarget` (status, `targetConfiguration`, `lastSynchronizedAt`, credential providers)

Target type derived from `targetConfiguration.mcp`: Lambda, MCP Server, API Gateway, OpenAPI Schema, Smithy Model.

| Risk Level | Condition |
|------------|-----------|
| **Critical** | Gateway not `READY`, zero targets, OR all targets unhealthy |
| **Warning** | Single target (no redundancy), no policy engine attached, some unhealthy targets, OR stale sync (> 7 days) |
| **Healthy** | Multiple READY targets, policy engine attached, recent synchronization |

Unhealthy target statuses: `FAILED`, `UPDATE_UNSUCCESSFUL`, `SYNCHRONIZE_UNSUCCESSFUL`. Stale sync threshold: `lastSynchronizedAt` older than 7 days.

## Step 4: Memory & Knowledge Effectiveness (Performance Efficiency)

Discover memories and their strategies, then query CloudWatch ingestion metrics:
- `bedrock-agentcore:ListMemories` → `GetMemory` (status, createdAt, **configured strategies**)
- `bedrock-agentcore:ListMemoryRecords` — **data-plane call, count only** (long-term-strategy memories). Read the returned record *count*; do not read the `content` field (see "Memory record data handling")
- `cloudwatch:GetMetricData` (namespace `AWS/Bedrock-AgentCore`): per-memory `Invocations`/`Errors` for the `Ingestion` operation, and `Invocations` for the `CreateEvent` operation (30-day window)

**All rules are strategy-aware** — read `GetMemory` strategies first. Record-count rules apply ONLY to memories with a long-term strategy; short-term-only memories are never flagged as empty.

| Check | Rule | Severity |
|-------|------|----------|
| AC-MEM-1 | Long-term memory with CloudWatch ingestion `Errors > 0` | **High** |
| AC-MEM-2 | Long-term memory with < 10 records (escalates to High if 0 records AND > 7 days old) | **Medium→High** |
| AC-MEM-3 | Ingestion error rate > 20% (`Errors / Invocations`) | **High** |
| AC-MEM-4 | Provisioned but never populated: zero `CreateEvent` activity AND > 7 days old | **Medium** |

**Safety rule:** `CreateEvent` activity is queried for EVERY memory (short-term memories receive events too). When the CloudWatch signal is unreadable, event count is `None` (not 0), so AC-MEM-4 is skipped rather than firing a false "never populated" finding.

## Step 5: Resource Utilization & Operational Hygiene (Operational Excellence)

Enumerate all provisionable resource types and collect a 30-day activity signal:
- Inventory: `ListAgentRuntimes`, `ListMemories`, `ListGateways`, `ListBrowsers`, `ListCodeInterpreters`, `ListWorkloadIdentities`
- Activity: `cloudwatch:GetMetricData` (`Invocations`, `AWS/Bedrock-AgentCore`) keyed by per-type dimension (`AgentRuntimeId`, `MemoryId`, `GatewayId`)

| Check | Rule | Severity |
|-------|------|----------|
| AC-UTIL-1 | Idle resource: zero activity over 30-day window, > 7 days old | **Medium** |
| AC-UTIL-2 | Consolidation: duplicate configs in a region, OR regions holding resources with < 5% of total activity (3+ regions) | **Informational→Medium** |
| AC-UTIL-3 | Overall utilization < 60% (active / assessable, excluding recently-created) | **Informational** |

For the AC-UTIL-1 idle signal, prefer the real-time `ActiveSessionCount` gauge (a currently-running-sessions gauge, filterable by the `Service` dimension) where available; fall back to the cumulative `SessionCount` / `Invocations` counters over the 30-day window when `ActiveSessionCount` is not present.

**Framing:** AgentCore runtime billing is consumption-based — idle time is free. Frame findings as operational hygiene and security surface (unmanaged IAM roles, stale config), NOT wasted spend. Exception: memories holding stored long-term records DO accrue storage cost — call this out in the finding.

**Classification safety:** A resource is only classified **Idle** when its activity signal is complete for the full window. Types with no queryable per-resource metric (Browser, CodeInterpreter, WorkloadIdentity), and every resource when the CloudWatch call fails, are classified **Active (partial)** — never Idle. Resources younger than 7 days are **RecentlyCreated** and excluded from both idle flagging and the utilization ratio.

## Step 6: Runtime Observability (cross-pillar signals)

For each runtime, collect CloudWatch metrics from namespace `AWS/Bedrock-AgentCore`:

| Metric | Dimensions | Period | Statistic |
|--------|-----------|--------|-----------|
| CPUUsed-vCPUHours | Resource (ARN), Service=`AgentCore.Runtime`, Name | 3600s | Sum |
| MemoryUsed-GBHours | Resource (ARN), Service=`AgentCore.Runtime`, Name | 3600s | Sum |
| SessionCount | Resource (ARN), Operation=`InvokeAgentRuntime`, Name | 300s | Sum |
| Invocations | Resource (ARN), Operation=`InvokeAgentRuntime`, Name | 300s | Sum |
| Throttles | Resource (ARN), Operation=`InvokeAgentRuntime`, Name | 300s | Sum |

`SessionCount` is a cumulative counter of new sessions per period. Where a real-time view is needed, `ActiveSessionCount` is a gauge of currently-running sessions (filterable by the `Service` dimension).

Discover resources first via `cloudwatch:ListMetrics` (namespace `AWS/Bedrock-AgentCore`), extract unique `Resource` ARN + `Name` dimensions, then batch `GetMetricData` per resource.

Derived signals:
- **Throttle rate** = `Throttles / Invocations × 100`
- **Health status** = "Throttling Detected" when `Throttles > 0`, else "Healthy"
- Only report runtimes with any activity (CPU-hours, GB-hours, invocations, or session count > 0).

## Step 7: Additional Context

1. **Health Events**: `health:DescribeEvents` filtered for Bedrock/AgentCore service, last 14 days.
2. **Documentation**: Cross-reference findings against AgentCore best-practices docs for remediation links.

## Step 8: Produce Report and Recommendations

Produce an artifact with the structure defined in `references/report-template.md`.

For each finding with severity Warning/Medium or higher, create a recommendation with:
- Title: `[Check ID] [Check name] — [Resource identifier]`
- Summary: Current state, expected state, business/operational impact, remediation steps, and a TAM conversation starter.

## Related Skills / Boundaries

Boundaries are deliberate and non-overlapping:
- **`agentcore-observability-setup`** — sets up/validates observability *wiring*. This skill consumes that telemetry for posture assessment and defers observability-*configuration* gaps to it (see the seam described in Data Source Boundaries).
- **`agentcore-runtime-diag`** (queued submission — referenced for scope, not yet published) — reactive triage of a *single failing invocation*. This skill is proactive, estate-wide posture; it does not diagnose individual call failures or evaluate authorizer/credential correctness. Gateway checks here are redundancy/staleness/health only, not auth evaluation.
- **`aiml-access-diagnostics`** (published) — generic AI/ML AccessDenied chain via `iam:SimulatePrincipalPolicy`. Not overlapping — this skill makes no IAM-simulation calls.
- **`bedrock-adoption-readiness`** (published) — foundation-model workload readiness (IAM governance, ZDR, quotas, observability). Different resource surface — this skill reviews the AgentCore agent runtime / memory / gateway layer, not foundation-model inference.

## Error Handling

| Error | Action |
|-------|--------|
| AccessDenied on `bedrock-agentcore:*` | Log as visibility limit "signal unavailable — check skipped", continue in observability-only mode |
| AccessDenied on `ec2:DescribeSubnets` | AC-RUN-2 degrades to "AZ distribution unknown" |
| CloudWatch returns no data | Report "no activity detected" for that resource; classify utilization as Active (partial), never Idle |
| No AgentCore usage anywhere | Stop early: "No AgentCore usage detected" |
| Throttled by AWS API | Retry with exponential backoff (3 attempts) |
| Check raises an exception | Isolate the failure — degrade that check to a visibility limit and continue the others |

## Important Notes

- ALL API calls with pagination (NextToken) MUST be paginated to completion.
- Cost Explorer queries run against us-east-1 (global endpoint).
- Findings are only produced when the underlying signal is complete — incomplete signals become visibility limits, never false positives.
- Batch CloudWatch `GetMetricData` requests where possible.
- This is a READ-ONLY review — no modifications, and no data-plane calls other than `ListMemoryRecords` for record count (count only; `content` is never read).