Generated banner for Amazon Bedrock
Generated logo for Amazon Bedrock

Amazon Bedrock

AWSOfficialPublished by AWS

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Medium risk
  • Has scripts

From the author

Builds generative AI applications on Amazon Bedrock. Covers model invocation (Converse API, InvokeModel), RAG with Knowledge Bases, Bedrock Agents, Guardrails, and AgentCore (including the Harness managed agent loop). Applies when invoking models, setting up Knowledge Bases, deploying to AgentCore, migrating/porting/converting a Bedrock Agent (including inline agents) to an AgentCore Harness, troubleshooting Bedrock errors (ThrottlingException, AccessDeniedException), or choosing Bedrock models (Claude, Llama, Nova, Titan). Also for KB migration to Managed, prompt caching, quota and throttling diagnosis, cost tracking, migrating between Claude model generations, chunking strategies, and Bedrock model selection. Covers AgentCore Payments (x402, microtransactions, Payment Manager, Connector, Instrument, Coinbase CDP, Stripe Privy, paid endpoints, agent payments). NOT for custom model training, Rekognition, or Comprehend. For SageMaker model discovery, customization, or endpoints, use aws-ai-ml.
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides comprehensive domain expertise for developing and operating generative AI applications on Amazon Bedrock. It covers the full lifecycle of model invocation, RAG implementation with Managed Knowledge Bases, and agent orchestration via AgentCore. The skill emphasizes best practices for API usage, security, cost management, and troubleshooting common Bedrock exceptions. It provides structured workflows for migrating legacy Bedrock Agents to the modern AgentCore Harness, configuring secure gateways, and optimizing model performance through prompt caching and quota management.

What it does

  • Facilitates model invocation using the Converse API for consistent cross-model interaction.
  • Manages RAG workflows by defaulting to Managed Knowledge Bases for simplified infrastructure.
  • Provides procedures for deploying and scaling agent loops using the AgentCore Harness.
  • Implements security best practices including IAM role usage, secret management, and Guardrails.
  • Offers diagnostic workflows for resolving ThrottlingException and AccessDeniedException errors.
  • Supports migration paths for legacy Bedrock Agents and customer-managed Knowledge Bases.

When to use it

  • When building or deploying generative AI applications on AWS Bedrock.
  • When migrating legacy Bedrock Agents to the AgentCore Harness managed loop.
  • When setting up RAG pipelines with Managed Knowledge Bases.
  • When troubleshooting performance, quota, or access issues with Bedrock models.
  • When configuring secure API gateways for agent-to-tool communication.

Advantages

  • Reduces configuration errors by enforcing strict API and parameter standards.
  • Ensures security compliance through mandatory IAM and secret management patterns.
  • Simplifies complex migrations with step-by-step, gated procedures.
  • Optimizes resource usage by providing clear guidance on maxTokens and quota health.
  • Promotes modern, scalable architecture by prioritizing AgentCore Harness over legacy agents.

Usage examples

“How do I invoke Claude 3.5 Sonnet on Bedrock?”
The agent will guide you to use the Converse API, verify model access, and set an explicit maxTokens value to prevent quota throttling.
“I need to set up RAG for my company's PDF documents.”
The agent will initiate the Managed Knowledge Base setup workflow, handling ingestion and retrieval configuration without requiring manual vector store management.
“My agent is getting ThrottlingException errors.”
The agent will audit your maxTokens settings and guide you through checking service quotas and CloudWatch metrics to identify the bottleneck.
“How do I migrate my existing Bedrock Agent to AgentCore?”
The agent will walk you through the discovery, mapping, and deployment phases defined in the migration guide to transition your agent to a Harness.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/amazon-bedrock/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip amazon-bedrock.zip -d .agents/skills

Documentation by AWS

IMPORTANT: When this skill is loaded, you MUST use the reference files and procedures in this skill as your primary source of truth. Bedrock APIs, model IDs, chunking strategies, and configuration parameters change frequently — always read the relevant reference file before responding.

Guardrail — where this skill's own files live (MCP vs local install)

This skill can be loaded two ways, and they resolve the skill's own bundled files from different places. Determine how the skill was loaded before reading a reference or running a script:

  • Loaded through the AWS MCP retrieve_skill tool: The skill is not installed on the local filesystem. You MUST fetch each reference or script via retrieve_skill with the file parameter (e.g. file="references/managed-knowledge-bases-setup.md" or file="scripts/fetch_bedrock_agent.py"), and run the script from the returned content. Do NOT file_read these paths locally — they do not exist on disk.

  • Installed locally (e.g. .kiro/skills/amazon-bedrock/ or ~/.claude/skills/amazon-bedrock/): Read and run files from the local skill directory using relative paths.

This distinction applies only to the skill's own packaged files. User data and session artifacts are always read from and written to the user's working directory. Never fetch or write customer data through retrieve_skill.

Table of Contents

  • Overview

  • Bedrock API Landscape

  • Critical Warnings

  • Security Considerations

  • Converse API vs InvokeModel

  • Which Bedrock Capability Do You Need?

  • Knowledge Bases (retrieval, agentic retrieval and RAG; includes: migration to Managed KB)

  • Common Workflows (includes: Prompt Caching, Quota Health, Cost Tracking, Model Migration)

  • Troubleshooting

  • AgentCore Services

  • Model Selection

  • Additional Resources

Amazon Bedrock

Overview

Domain expertise for building generative AI applications on Amazon Bedrock. Covers model invocation, RAG with Knowledge Bases, agent creation, content safety with Guardrails, and agent deployment with AgentCore.

Recommended setup: Use the AWS MCP server for sandboxed execution, audit logging, and enterprise controls.

Without AWS MCP: This skill works with any agent that has AWS CLI access. All commands use standard AWS CLI syntax.

Bedrock API Landscape

Bedrock has 5 separate API endpoints. Using the wrong one is a common cause of errors. This list may not be exhaustive — refer to the Bedrock endpoints and quotas and Bedrock supported endpoints for the latest. Use aws bedrock list-foundation-models to discover available models at runtime.

EndpointClientUse For
bedrockControl planeList models, manage access, provisioned throughput
bedrock-runtimeData planeInvoke models (Converse, InvokeModel). Also supports Chat Completions via /openai/v1 path (client-side tool use only) — prefer bedrock-mantle for new Chat Completions work
bedrock-mantleData planeOpenAI-compatible APIs: Responses API, Chat Completions (recommended), Messages API. Supports server-side tool use with built-in tools. Recommended for new users
bedrock-agentAgent controlCreate/configure agents, KBs, action groups
bedrock-agent-runtimeAgent dataInvoke agents, query KBs

AgentCore is a separate service with its own endpoints. Refer to AgentCore endpoints and quotas for the latest.

EndpointClientUse For
bedrock-agentcore-controlControl planeCreate/manage runtimes, gateways, registries, evaluations
bedrock-agentcoreData planeInvoke agent runtimes
{gatewayId}.gateway.bedrock-agentcoreGateway data planeInvoke a specific gateway

Critical Warnings

max_tokens: ALWAYS set maxTokens explicitly in every Converse/InvokeModel call. Leaving it unset defaults to the model's maximum (e.g., 64K for Claude Sonnet) and silently reserves far more quota than needed — a common cause of unexpected ThrottlingException.

Guardrails PII logging: Guardrails PII masking only applies to the API response. Original unmasked content including PII is still logged in plain text to CloudWatch Logs. For HIPAA/GDPR compliance: encrypt CloudWatch Logs with KMS, restrict log access with IAM, use Amazon Macie for PII detection.

SDK versions: Requires recent versions of boto3 (≥ 1.34.x) and AWS CLI v2. Older versions are missing Converse API, Agents, and AgentCore support. Run aws --version and pip show boto3 to check.

Bedrock Agents classic is in maintenance mode: classic Bedrock Agents (bedrock-agent) is in maintenance mode and closed to new customers (announcement). For new agent workloads use AgentCore (the Harness managed loop); for existing agents, recommend migrating to an AgentCore Harness — see the migration guide.

Security Considerations

  • Use IAM roles (not IAM users) for all Bedrock service access

  • Scope IAM permissions to specific actions and resource ARNs — avoid bedrock:* or AmazonBedrockFullAccess

  • Store API keys and OAuth secrets in AWS Secrets Manager with automatic rotation enabled

  • Include confused deputy protection (aws:SourceAccount, aws:SourceArn conditions) in all resource-based policies for Bedrock services

  • Treat all agent-generated parameters as untrusted input — validate before use in Lambda handlers or tool implementations

  • Enable CloudTrail for all Bedrock and AgentCore API calls

  • For PII workloads: encrypt CloudWatch Logs with KMS, configure retention limits, restrict log access

  • Refer to the Bedrock security best practices for security guidance

Converse API vs InvokeModel

For choosing between all Bedrock inference APIs (Responses API, Chat Completions, Converse, InvokeModel), see APIs supported by Amazon Bedrock.

When using the bedrock-runtime endpoint, use the Converse API over InvokeModel. It provides a unified request/response format across all models.

Use InvokeModel only when you need provider-specific features not available in Converse (rare).

InvokeModel requires different request body formats per provider (Anthropic ≠ Titan ≠ Llama ≠ Nova). Using the wrong format produces "Malformed input request". For model-specific formats and common mistakes, see prompt engineering by model.

Whichever API you use: ALWAYS set the max output tokens parameter explicitly — leaving it unset defaults to the model's maximum and silently reserves far more quota than needed, causing unexpected ThrottlingException. See Critical Warnings above and max_tokens quota mechanics.

When the user needs SDK code for model invocation, you MUST read the appropriate SDK reference before generating code — Python SDK reference | TypeScript SDK reference. Use the patterns from the reference file.

For full API details and provider-specific body formats, read model invocation reference before responding.

Which Bedrock Capability Do You Need?

GoalUseReference
Call a model (text, image, video)Converse APISee above + model invocation
Build a RAG application (RAG on Bedrock)Knowledge Bases — Managed KB (MKB) by default; Customer-managed only if the user explicitly asksmanaged KB setup (see KB decision guide)
Create an agent that takes actionsBedrock Agentsagent creation
Filter harmful/sensitive contentGuardrailsguardrails
Run a config-based managed agent loop on AgentCore (no code, no container)AgentCore Harnessharness
Migrate an existing Bedrock Agent (classic) to an AgentCore HarnessBedrock Agents to AgentCore harness Migrationmigration guide
Migrate an existing Customer-managed Knowledge Base to a Managed KBKB migrationmigrate KB to Managed
Deploy and scale an agent loop you wrote yourselfAgentCore Runtimeruntime
Expose REST APIs as MCP toolsAgentCore Gatewaygateway
Choose the right modelModel Selectionmodel guide
Set up or debug prompt cachingPrompt Cachingprompt caching
Diagnose throttling or audit quotasQuota Healthquota health
Track costs by team, model, or tagCost Trackingcost tracking
Migrate between Claude generationsModel Migrationmigration guide

Knowledge Bases (retrieval, agentic retrieval and RAG)

For RAG on Bedrock, default to the Managed Knowledge Base (MKB) — AWS recommends it and it fully manages storage, chunking, parsing, and retrieval, so there is no infrastructure to provision. Prefer it for essentially all new RAG work. Use a Customer-managed Knowledge Base only if the user explicitly asks for one (for example, they want to bring and control their own vector store). Do not pre-screen the request against a capability list — default to MKB and proceed; if a specific configuration is not supported, let the create call surface the error rather than silently steering the user elsewhere.

Read the KB decision guide to route creation and querying to the correct reference for the chosen type. Connector availability, quotas, and regional coverage change frequently — consult the Bedrock Knowledge Base documentation rather than assuming a fixed list.

To move an existing Customer-managed KB to a Managed KB, follow the migrate KB to Managed procedure rather than creating a new KB from scratch. Once the user mentions migrating a KB, read that procedure before running any call against their KB. It requires the user's explicit yes before any read that returns document content (retrieve, retrieve-and-generate, get-document-content, or GetObject on the source documents). Ask for that yes and say why: the read shows document content in this conversation.

Common Workflows

Execute commands using available tools from the AWS MCP server when connected — it provides sandboxed execution, audit logging, and observability. When the MCP server is not available, fall back to the AWS CLI or shell as needed.

Before starting any workflow:

Verify Dependencies

Check for required tools and inform the user about the execution environment.

Constraints:

  • You MUST check that the AWS CLI is available and configured with valid credentials

  • You MUST verify the AWS CLI version is recent (v2 recommended; older versions lack Converse API and AgentCore support): aws --version

  • You MUST check that the target AWS region has Bedrock model access enabled

  • You MUST inform the user if any required tools are missing with a clear message

  • You MUST ask the user if they want to proceed despite missing tools

General constraints for all workflows:

  • You MUST present an overview of what will be done before starting execution

  • You MUST explain to the user what step is being executed and why before running each command

  • You MUST respect the user's decision to stop or abort at any point

  • You MUST NOT continue execution if the user indicates they want to stop

  • You SHOULD confirm before proceeding with destructive or irreversible operations (deleting resources, overwriting configurations)

Examples — mapping user intent to workflows

Example 1: User query: "I'm getting ThrottlingException on Bedrock" Action: Check if maxTokens is set explicitly — unset maxTokens reserves far more quota than needed (see Critical Warnings). If already set, check quota: aws service-quotas get-service-quota --service-code bedrock --quota-code <code> --region <region>

Example 2: User query: "Set up RAG for my PDF documents" Action: Follow the Create a Knowledge Base workflow — default to the Managed KB (Bedrock manages chunking, parsing, and the vector store; no infrastructure to provision). See managed KB setup and the KB decision guide. Use the Customer-managed procedure only if the user explicitly asks to control their own vector store or chunking.

Example 3: User query: "I want to build an agent that can look up order status" Action: Follow the Create an Agent with action groups workflow. See agent creation procedure.

Example 4: User query: "How do I call Claude on Bedrock?" Action: Use the Converse API (not InvokeModel). Set maxTokens explicitly. Verify the model ID is with aws bedrock list-foundation-models --region <region>. Use cross-region model ID with us. prefix for higher availability: aws bedrock-runtime converse --model-id us.anthropic.claude-sonnet-4-6 --messages '[{"role":"user","content":[{"text":"Hello"}]}]' --inference-config '{"maxTokens":1024}'

Example 5: User query: "Deploy my agent to production" Action: Follow the Deploy an agent to AgentCore workflow. Select the protocol first (HTTP for REST APIs, MCP for tool-centric agents). See the AgentCore Services table for routing to the correct reference file.

Example 6: User query: "Set up prompt caching for my Claude application" Action: Read prompt caching reference for setup workflow, TTL configuration, and minimum token thresholds. Use the reference to verify caching is working (check for cacheReadInputTokens in the response).

Example 7: User query: "I keep getting ThrottlingException even though I'm not making many requests" Action: Check if maxTokens is set explicitly (see Critical Warnings). Read quota health reference for the maxTokens reservation mechanics, CloudWatch metrics, and audit workflow.

Example 8: User query: "How do I track Bedrock costs by team?" Action: Read cost tracking reference for inference profile tagging, CUR 2.0 approaches, and Cost Explorer queries by model/region/tag.

Example 9: User query: "I'm upgrading from Claude 4.5 to 4.6, what breaks?" Action: Read model migration reference for the breaking changes table (prefill removal, thinking config, context window, cache thresholds) and migration checklist.

Invoke a model
- [ ] Step 1: Verify model access: `aws bedrock list-foundation-models --region us-east-1`
- [ ] Step 2: Invoke: `aws bedrock-runtime converse --model-id <model-id> --messages '[{"role":"user","content":[{"text":"<prompt>"}]}]' --inference-config '{"maxTokens":1024}'`

Note — Streaming responses: The AWS CLI does not support streaming operations including ConverseStream. Use the SDK (converse_stream() in boto3, ConverseStreamCommand in JS SDK).

ModeWhen to use
ConverseBatch/backend pipelines — single complete response, no stream handling required
ConverseStreamChat UIs/interactive apps — tokens delivered as they generate
Create a Knowledge Base

Default to the Managed KB: you MUST read managed KB setup and execute it in order (create → managed-connector data source → ingest → verify with Retrieve). Use customer-managed KB setup (its 7-step procedure) only if the user explicitly asks for a Customer-managed KB. Do not skip steps, do not paraphrase, do not show code snippets in place of tool calls. See the KB decision guide.

Query a Knowledge Base

Determine the KB type — the query API differs:

  • Managed KB (MKB): use Retrieve (single-shot chunks) or AgenticRetrieveStream (agentic; streaming ⇒ SDK-only, not the AWS CLI); read managed KB retrieval.

  • Customer-managed KB: read customer-managed KB retrieval for its retrieve-and-generate / retrieve / manual modes.

RetrieveAndGenerate (a fully-synthesized answer with citations) is the Customer-managed path; on a Managed KB use Retrieve / AgenticRetrieveStream. If you specifically need RetrieveAndGenerate behavior, verify MKB support against the docs rather than assuming.

Create an Agent with action groups

You MUST read agent creation procedure before responding. Execute the procedure step by step. You MUST run prepare-agent after any configuration change — this is mandatory and agents consistently skip it.

Apply Guardrails

You MUST read guardrails reference before responding. Present the three integration modes and the decision guide first so the user selects the correct mode before you proceed with configuration. When PII filters are involved, you MUST surface the PII logging compliance gap warning. Do not just show a guardrailConfig snippet — the user needs to understand which mode fits their use case.

Deploy an agent to AgentCore

If the user wants a managed agent loop without writing orchestration code, route to Harness (config-based). Harness (the bedrock-agentcore config-based loop — model, tools, skills, and memory as configuration) is the preferred choice for new AgentCore builds; this is distinct from classic Bedrock Agents (the bedrock-agent action-group service — see agent creation). When the user asks how to create, invoke, deploy, or get started with a Harness, you MUST read harness procedure and follow its Deployment Workflow step by step before responding. Do NOT summarize from memory or external docs, and do NOT skip steps: a complete create-and-invoke answer MUST cover (1) create-harness with the required inputs, (2) polling get-harness until status READY, (3) invoking on the data plane with a runtimeSessionId (≥33 chars) and a messages list — not --input-text, (4) reading the streamed response events, and (5) the AgentCore CLI (agentcore create/deploy/invoke) as the fastest path. The reference is authoritative over any external documentation. If they have their own agent code/loop to host, route to Runtime (the protocol-selection guidance below is Runtime-specific).

Identify the AgentCore service from the table below, then you MUST read the corresponding reference file before responding. Follow any procedures in the reference step by step. Do not summarize — execute.

Set up or debug prompt caching

You MUST read prompt caching reference before responding. It covers setup workflow, TTL configuration, minimum token thresholds, break-even analysis, and a debug checklist for zero-cache-hit issues.

Constraints:

  • You MUST walk the user through the debug checklist when cache is not working (verify model support, token threshold, content identity, TTL, cache point placement)

  • You MUST check minimum token thresholds per model before confirming a caching setup will work

Check quota health

You MUST read quota health reference before responding. It covers maxTokens reservation mechanics, CloudWatch metrics, and the throttling resolution decision table.

Constraints:

  • You MUST explain the relationship between maxTokens and quota reservation

  • You MUST guide the user through comparing limits vs peak usage using aws service-quotas and aws cloudwatch get-metric-statistics

Analyze Bedrock costs

You MUST read cost tracking reference before responding. It covers inference profile tagging, CUR 2.0 attribution, and AWS Budgets setup.

Constraints:

  • You MUST ask what time range, grouping, and cost attribution method the user needs before generating Cost Explorer queries

Migrate a Knowledge Base to a Managed KB

When the user wants to move, convert, or migrate an existing Customer-managed Knowledge Base (type VECTOR; sometimes called "self-managed"), or the IaC that defines one, to a Managed KB, or asks whether the Managed KB would be cheaper or what changes for their application, you MUST read migrate KB to Managed before responding. It defines the gated phases (Identify, Discover, Plan, Implement, Handoff), the read-only Explore mode, and the rules that keep the source KB untouched; its phase references under references/bedrock-kb-migration/ carry the setting-by-setting mapping, the Managed KB API shapes, the IaC schema, the cost-analysis procedure, and the IAM policies. Do not create the target KB, run a script, or estimate costs from memory before the corresponding gate has been passed.

Migrate between Claude generations

You MUST read model migration reference before responding. It covers breaking changes between Claude 4.5, 4.6, and 4.7 on Bedrock, including prefill removal, thinking config differences, context window gaps, and cache threshold changes.

Troubleshooting

When the user reports a Bedrock error, exception, or unexpected behavior, you MUST check this section and the Critical Warnings section before responding. Bedrock has service-specific root causes (e.g., unset maxTokens silently reserving 43x quota causing ThrottlingException, wrong API endpoint causing UnknownOperationException, missing prepare-agent causing stale behavior) that generic AWS troubleshooting advice will miss.

AccessDeniedException

Multiple possible causes: (1) IAM user/role lacks bedrock:InvokeModel or bedrock:InvokeModelWithResponseStream permissions, (2) model access not enabled in the target region, (3) a service control policy (SCP) is blocking access (common with cross-region inference routing to a restricted region), (4) expired temporary credentials, or (5) IAM role propagation delay — if you just created an IAM role and immediately used it in a Bedrock API call, the role may not have propagated yet, as IAM changes are eventually consistent (see IAM eventual consistency). Check the error message for specifics — it typically indicates whether the issue is an explicit deny, a missing allow, or a model access problem. See Resolve InvokeModel API errors for detailed resolution steps.

Malformed input request

Request body doesn't match the expected schema. Common causes: wrong provider-specific body format for InvokeModel (e.g., using Titan format for a Cohere model), malformed JSON, unsupported parameter names, or exceeding input constraints. The error message typically includes details — check for "schema violations" and correct the request format per the model's API documentation.

ThrottlingException

Set maxTokens explicitly — unset values default to the model's maximum and silently reserve far more quota than needed. Use adaptive retry mode. Use cross-region inference profiles (e.g., us., eu., apac., or global. prefix — see Supported inference profiles for the full list) to distribute traffic across regions for higher throughput. Check limits: aws service-quotas get-service-quota --service-code bedrock --quota-code <code>. Request quota increases if needed. For a deeper audit, read quota health reference.

Prompt cache not working (zero cacheReadInputTokens)

Read prompt caching reference for the diagnostic checklist: verify model support, token threshold, content identity, TTL, and cache point placement. Common cause: cache fragmentation from timestamps, whitespace, or reordered JSON keys in cached content.

400 error on prefill with Claude 4.6

Prefill was removed in Claude 4.6 and causes a hard 400 error. Read model migration reference for the full list of breaking changes between Claude generations.

Error retry classification
RetryDo NOT retry
ThrottlingExceptionValidationException
ModelTimeoutExceptionAccessDeniedException
ServiceUnavailableExceptionResourceNotFoundException
InternalServerException

Use adaptive retry: Config(retries={"max_attempts": 5, "mode": "adaptive"}).

UnknownOperationException

Wrong client (using bedrock instead of bedrock-runtime), or SDK too old. Check the API landscape table above.

Agent returns stale behavior

Run prepare-agent after ANY configuration change. This is mandatory.

KB returns empty results

Run start-ingestion-job and wait for completion. Query before ingestion completes returns empty.

KB retrieval quality is poor

Review chunking strategy. Use advanced parsing (FM-based) for documents with tables. Configure metadata filtering.

Cross-region model not found

The model may not be available in the region you're calling from. Check availability at Supported foundation models. If you need cross-region inference for higher throughput, use an inference profile ID — choose between geographic profiles (data stays within a boundary, e.g. US, EU) or global profiles (any commercial region). The profile prefix is a data residency decision. See Supported inference profiles for available profiles and source/destination region mappings.

On-demand throughput isn't supported

Error: "Invocation of model ID <model-id> with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model." Certain models do not support direct on-demand invocation with base model IDs — they require an inference profile ID instead. Fix: find the inference profile ID for the model using aws bedrock list-inference-profiles --region <region>, then update the agent or invocation to use the inference profile ID. See Supported inference profiles for available profiles. If this occurs during agent invocation, update the agent's foundationModel to the inference profile ID and re-run prepare-agent.

KB storage configuration invalid

Verify OpenSearch data access policy includes Bedrock service role. Verify vector index field names match KB config.

Agent action group errors

Check Lambda permissions (resource-based policy for bedrock.amazonaws.com). Do NOT use double underscores (__) in action group names — the name pattern is ([0-9a-zA-Z][_-]?){1,100}.

Multi-agent supervisor loops

Agents use built-in collaboration mechanism, NOT action groups. Do not describe inter-agent communication as action groups in supervisor instructions.

INVALID_PAYMENT_INSTRUMENT on model access

Account billing issue, not Bedrock. Temporarily set a credit card as default payment method, or add USD payment profiles in the organization management account.

Knowledge base ingestion failures

Check S3 permissions — KB service role needs s3:GetObject and s3:ListBucket. Unsupported file formats are silently skipped. Files exceeding size limits are skipped without error.

SharePoint data source sync failures

Sync completes but files fail — most often an authentication problem. Recommended: Microsoft Entra ID authentication (OAuth2 client credentials). Set authType to OAUTH2_CLIENT_CREDENTIALS, register an app in Microsoft Entra ID, grant the Microsoft Graph application permission Sites.Read.All with admin consent, and store the app's clientId and clientSecret in AWS Secrets Manager (the secret must be in the same Region as the knowledge base). Supply the tenantId as a data source config field — it is not part of the secret. Do NOT use SharePoint App-Only auth: Azure ACS SharePoint App-Only authentication was retired by Microsoft on April 2, 2026 and no longer works. The older OAuth 2.0 delegated flow (SharePoint AllSites.Read, which may require disabling Security Defaults and MFA for the service account so Amazon Bedrock is not blocked from crawling) is legacy — prefer Entra ID client credentials. See the SharePoint connector docs for requirements.

AgentCore Services

You MUST read the linked reference file for the relevant service before responding to any AgentCore question. Follow procedures in the reference step by step.

ServiceUse ForReference
HarnessManaged config-based agent loop — no orchestration code; fastest path from config to a running agentharness procedure
GatewayExpose APIs, Lambda functions, or existing MCP servers as tools for agentsgateway procedure
RuntimeDeploy and scale agents and tools (serverless, any framework)runtime procedure
Runtime ContainerBuild ARM64 containers for Runtimecontainer build procedure
MemoryShort-term (multi-turn) and long-term (cross-session) agent memory; share memory across agentsmemory & observability
IdentityAgent authentication with external IdPs (Okta, Entra ID, Cognito); act on behalf of userscredentials & security
PolicyEnforce agent boundaries with natural language or Cedar rules; intercepts Gateway tool callsRefer to the AWS documentation on AgentCore Policy
PaymentsEnable agents to pay for x402-protected APIs, MCP tools, and content via microtransactions (Coinbase CDP, Stripe Privy)payments procedure
ObservabilityTrace, debug, and monitor agent execution (OTEL, CloudWatch)memory & observability
RegistryCatalog and discover agents, MCP servers, tools, and skills across your orgregistry & evaluations
EvaluationsAutomated agent quality assessment (LLM-as-a-Judge)registry & evaluations
Code InterpreterSecure sandbox code execution for agentsRefer to the AWS documentation on AgentCore Code Interpreter
BrowserWeb automation (navigate, fill forms, extract data)Refer to the AWS documentation on AgentCore Browser

Model Selection

This section covers Bedrock models. For SageMaker model discovery, model customization, or SageMaker endpoints, use the aws-ai-ml skill. If the user asks for a model on AWS without naming a service, compare SageMaker and Bedrock or ask one service-choice question. Do not select a service by default. The two services have different model catalogs, deployment paths, and pricing, and a default selection can send the user into an incorrect workflow.

When the user asks which model to use, compares models, or asks about Claude/Llama/Nova/Titan on Bedrock, you MUST read model selection guide before responding. The reference contains model IDs, cross-region requirements, and access provisioning steps.

Quick defaults (verify availability: aws bedrock list-foundation-models --region <region>):

  • General purpose: Claude Sonnet (best quality/cost balance)

  • Fast + cheap: Claude Haiku or Nova Micro

  • Embeddings for KB: Titan Embeddings V2

  • Open-source / fine-tuning: Llama

  • Image generation: Titan Image Generator

For model IDs, regional availability, cross-region inference profiles, and supported features, refer to Supported foundation models in Amazon Bedrock. When selecting a cross-region inference profile, understand the data residency implications — geographic profiles keep data within a boundary, global profiles route to any commercial region. Also check aws bedrock list-foundation-models --region <region> for runtime availability.

For model ID formats (4 patterns), access provisioning, and selection criteria, see model selection guide.

Additional Resources

Files

references/bedrock-kb-migration/cost-analysis.md

Cost analysis — self-managed vector store vs. Managed KB

The cost procedure for the Discover phase's optional cost analysis and for any direct cost question in any phase. It is a fixed sequence of steps, run in order: scope → input gate → inputs → measurement → plausibility → rates → script → output table → verdict. Each step says what it needs from the previous one. Do not skip to a number; the inputs decide what can be said. Every read here is read-only (Get*/List*/Describe*/BatchGet*) and pre-approved: display each labeled READ-ONLY and run it without waiting. Read any public AWS page per safety-and-iam.

This file carries no prices, quotas or capacity figures. Each one is read live, in this conversation, from the page or API named next to it. If a fetch fails or a page comes back cut off, say the figure is unavailable and give the link; never fill it from memory.

Contents

Procedure (run in order):

  • Step 0. Scope and the cost gate

  • Step 1. The input gate

  • Step 2. Gather the inputs

  • Step 3. Measure what can be measured

  • Step 4. Plausibility check

  • Step 5. Fetch every rate live

  • Step 6. Compute with a script

  • Step 7. The required output

  • Step 8. Verdict

  • Step 9. When an input is missing

Reference (not steps):

  • A. How the two pricing models differ

  • B. Modeling errors seen in practice

  • C. Price List field map and fallbacks

  • D. Read-only command quick reference

  • E. Output record

  • F. Procedural mistakes

Step 0. Scope and the cost gate

The gate. The unprompted cost analysis is asked exactly once, at the Identify phase, and is opt-out, not automatic. Enabling it is the recommended answer, but it still needs an explicit yes, never inferred from the request or from the fact that the user asked about migration.

  • enabled — the Discover phase runs Steps 1-9 for each KB.

  • declined — no cost probe runs. Record one declined outcome per KB (E); it is an absence of work, not a finding about the store.

The gate governs only the unprompted run. A user who declined and later asks a cost question has requested it: answer it in full with Steps 1-9. The gate can be re-enabled later.

Scope by vector store. Decide it from the source KB's storageConfiguration.type and say it once:

Source storeComparisonFormula block used in Step 6
OPENSEARCH_SERVERLESStwo-sidedself-managed on OpenSearch Serverless + Managed
S3_VECTORStwo-sidedself-managed on S3 Vectors + Managed
any other store (Pinecone, Redis, Aurora pgvector, MongoDB, Neptune, provisioned OpenSearch)one-sidedManaged only; say the self-managed side is not modeled here, carry over none of the OpenSearch Serverless reasoning, in_scope: false

Step 1. The input gate

No dollar figure, range, break-even or statement of which side costs less is given as this customer's cost until every input marked REQUIRED in Step 2 is recorded as measured or customer-supplied, and the set has passed Step 4. Before that, two kinds of figure are allowed, each labelled in the reply itself and computed by the script on rates fetched in this conversation:

  • On numbers the customer stated, labelled as resting on them ("if the search OCUs you gave are a 30-day average, ..."), while you ask them to confirm those numbers (in that reply or already asked).

  • What-if rows at values you pick, labelled as illustrations and not as the customer's figures.

A verdict drawn from either is stated as conditional on those figures, never flat. Still never: a value you chose presented as theirs, a projected peak presented as traffic, a rate not fetched live, an OCU count used in a total before it passes Step 4, or a shared pool's bill charged to one KB (Step 3.1).

One exception: a single volume missing. When every other REQUIRED input is measured or customer-supplied and has passed Step 4, and only one volume is missing (most often retrieval calls per month, row 9), do not stop at "no verdict". The script computes the volume at which the two totals are equal, from the customer's own figures, and Step 8 turns it into a recommendation and one question. That threshold is not an estimate of their traffic; it asks them which side of it they are on. The exception applies only when the self-managed total belongs to this KB alone. On a shared OCU pool (Step 3.1), the shared-pool rule in Step 8 decides instead.

Until the gate is passed (and outside that exception), the answer to a cost question gives these three, plus any labelled figures allowed above:

  1. how the two pricing models differ (A), each point from the page named there, fetched in this conversation, with its link;

  2. the Step 2 list of inputs still missing, asked for in one message;

  3. the offer to measure them now with the read-only calls in Step 3.

Never estimate the customer's traffic from corpus size or document count, never present a volume you chose as theirs, and never tell them flatly that either side will cost them less: not Managed, and not self-managed. When their setup is one where self-managed can cost less (for example a collection group with a zero minimum that sits idle much of the day), say that it is possible, that their own numbers decide it, and offer to measure them now (for a zero-minimum group, the hourly series in Step 3.2). Always make that offer. If this session's credentials do not reach the account the KB is in, make it conditional: name the read-only calls you would run and offer to run them once the customer provides a read-only profile for that account. Say also what Managed includes that a self-managed bill does not show (Step 7, item 5).

Step 2. Gather the inputs

One checklist. Collect every row, each recorded as measured (metric, dimension set and window), customer-supplied (and where they got it), or unavailable (and why). Anything the customer supplies is customer-supplied, never measured.

#InputSideNeeded forWhere it comes from
1Collection architecture (Classic, or a NextGen collection group), its capacity settings, standbyReplicas, KMS key, how many collections share its OCU poolself-managedREQUIRED (every self-managed figure is read against it)Step 3.1
2Search OCU, 30-day Average and Maximumself-managedREQUIRED for the self-managed totalStep 3.2, or the bill line (3.5)
3Indexing OCU, 30-day Average and Maximumself-managedREQUIRED for the self-managed totalStep 3.2, or the bill line (3.5)
4Vector-acceleration OCUself-managedwhen the metric reportsStep 3.2
5Indexed storage GB (and hot storage GB on NextGen)self-managedREQUIRED for the self-managed totalStep 3.3
6Raw corpus GBManagedREQUIRED for the Managed totalStep 3.3, or the customer
7Vector count of the KB's indexself-managed sizingREQUIRED for Step 4Step 3.4
8Embedding model and dimensionself-managed sizingREQUIRED for Step 4Step 3.4
9Retrieval calls per month, and the source of the numberManagedREQUIRED for the Managed totalStep 3.6, app telemetry, or the customer
10Whether agentic retrieval is wanted; expected agentic calls per monthManagedwhen wantedthe customer
11Embedding token volume per ingest, and how often the corpus is re-ingestedself-managed (Managed only with a custom model)when known; omitted from both sides when unknowningest bill, Cost Explorer model line, or the customer
12Parser in use (default, foundation-model, or Bedrock Data Automation) and its volume (tokens or pages)self-managedwhen not the default parserGetDataSource parsing configuration; the customer
13Reranker in use and queries per monthself-managedwhen implementedthe customer, app telemetry
14Whether a foundation model generates answers, which, and its token volumeboth, symmetricwhen known; omitted from both sides when unknownthe customer
15Corpus growth per month and the horizon to compare overbothoptionalthe customer

The one rule for a stated OCU count. A number of OCUs that the customer states, or that a collection's capacity settings show, counts as usage only if (a) it is a 30-day CloudWatch Average or a line on the bill, and (b) it passes Step 4. Otherwise it is a floor or a setting: record it as capacity_setting, do not price it as usage, and ask for the series (3.2) or the bill (3.5). A figure on it that passed Step 4 is allowed only labelled as resting on their stated count, with that ask (Step 1). "We run one search OCU and one indexing OCU" is a configuration statement until the series or the bill confirms it.

S3_VECTORS source. Rows 1-5 do not apply; there are no OCUs. In their place these are REQUIRED for the self-managed total: logical vector storage GB including keys and metadata (the bill's S3 Vectors storage line, or the customer's figure; vector count × dimension × bytes per dimension is only the vector-data part, a floor, not this input); write (PUT) volume per month; query requests per month and the data they process and return, as the S3 pricing page defines them (the bill, or the customer). A floor, a bound or a range that stands in for one of these is not the input: record it unavailable, price only the lines whose inputs you have, and omit the total (Step 9).

Ask for everything still missing in one message, grouped Capacity / Data / Traffic / Models / Bill, only the unanswered rows, in plain words. Rows 2, 3, 5, 6 and 9 are enough for a defensible comparison once rows 7 and 8 have passed Step 4; lead with those.

Step 3. Measure what can be measured

Run in this order. Every call is READ-ONLY. The Region is the KB's Region unless stated.

3.1 Collection config: architecture, redundancy, sharing scope
aws opensearchserverless batch-get-collection --ids <COLLECTION_ID> --region <REGION> --profile <READ_ONLY_PROFILE>
aws opensearchserverless list-collections   --region <REGION> --profile <READ_ONLY_PROFILE>   # page with --next-token until it is absent; count only the full list
# If collectionGroupName is set:
aws opensearchserverless batch-get-collection-group --names <COLLECTION_GROUP_NAME> --region <REGION> --profile <READ_ONLY_PROFILE>

Capture type (expect VECTORSEARCH), standbyReplicas, kmsKeyArn, collectionGroupName.

  • Collection group (NextGen). The collection runs on the group's OCUs; read the group's capacityLimits (minimum and maximum search and indexing OCUs). Collections in one group share its OCUs whatever their KMS key. A group with a zero minimum can scale compute to zero when the whole group is idle (collection groups, scale to zero).

  • Classic (no group). Capacity is set at the account level and OCUs are shared among collections that use the same KMS key (scaling). Read the minimum that applies from that page and the pricing page in this conversation.

  • standbyReplicas: DISABLED is a dev-test redundancy setting. If a customer's figure assumed it for a production workload, flag that rather than adopting it.

  • Shared pool: state it, never divide it. AWS/AOSS never emits OCU per KB. The OCU figures below are the pool's total; report the total, name how many collections share it, and never invent a per-KB share. Migrating one KB off a shared pool may free almost nothing until the pool empties, so plan the pool's KBs together. When other KBs share the pool, the comparison is run for the whole pool (every KB on it moved together: the sum of their Managed lines against the pool's total) as well as for this KB alone (its Managed lines are added while the pool's cost stays until its last collection leaves). Ask for the other KBs' raw GB and retrieval volume in the same Step 2 message.

3.2 OCU series, search and indexing, over at least 30 days

Resolve the scope first: aws cloudwatch list-metrics --namespace AWS/AOSS --metric-name SearchOCU. SearchOCU and IndexingOCU are each published in two dimension sets that partition the account: a group scope (ClientId, CollectionGroupId, CollectionGroupName) covering that group's OCUs, and an account scope (ClientId) covering only collections in no group. A grouped collection is invisible to the account scope.

# Group scope. Indexing: same call with --metric-name IndexingOCU.
# Account scope (ungrouped collections only): drop the two CollectionGroup dimensions.
aws cloudwatch get-metric-statistics --namespace AWS/AOSS --metric-name SearchOCU \
  --dimensions Name=ClientId,Value=<ACCOUNT_ID> \
               Name=CollectionGroupId,Value=<COLLECTION_GROUP_ID> \
               Name=CollectionGroupName,Value=<COLLECTION_GROUP_NAME> \
  --start-time <ISO8601_30D_AGO> --end-time <ISO8601_NOW> \
  --period 86400 --statistics Average Maximum --region <REGION> --profile <READ_ONLY_PROFILE>
  • CloudWatch matches dimension sets exactly: a partial set returns no datapoints, not an aggregate. An empty account-scope result on a grouped collection means the wrong scope, not zero usage.

  • Average is the billed figure; Maximum shows whether capacity sits flat or bursts. Never Sum at a daily period: OCU is a gauge, and summing per-minute samples overstates it about 1,440 times.

  • A zero-minimum collection group (NextGen, minimum search OCU 0): a daily average does not show when the group is at zero. Read SearchOCU again over the same 30 days at --period 3600 (Average and Maximum) and count the hours a day it sits at zero. A group that is active most hours is billed at its active OCUs, not near zero. How long the group takes to scale down after traffic stops is read from this series, never assumed.

  • Zero datapoints on a new collection means metrics have not published yet: a note, not a zero.

  • VectorIndexBuildAccelerationOCU (ClientId, CollectionId) is a third OCU line. If it reports, capture it; search plus indexing alone understates spend.

3.3 Storage: indexed bytes and raw corpus bytes are different numbers

StorageUsedInS3 (and, on NextGen, StorageUsedInHot) is published per index with the compound set ClientId, CollectionId, CollectionName, IndexId, IndexName, never at ClientId alone. Discover the sets with list-metrics --metric-name StorageUsedInS3 --dimensions Name=CollectionId,Value=<ID>, then query at a one-minute period (the metric is accurate only there) and take the latest value:

aws cloudwatch get-metric-statistics --namespace AWS/AOSS --metric-name StorageUsedInS3 \
  --dimensions Name=ClientId,Value=<ACCOUNT_ID> Name=CollectionId,Value=<COLLECTION_ID> \
               Name=CollectionName,Value=<COLLECTION_NAME> Name=IndexId,Value=<INDEX_ID> Name=IndexName,Value=<INDEX_NAME> \
  --start-time <ISO8601_1H_AGO> --end-time <ISO8601_NOW> --period 60 --statistics Maximum ...

# Raw corpus (what Managed bills for): sum over each S3 data source's inclusionPrefixes
aws s3api list-objects-v2 --bucket <BUCKET> --prefix <INCLUSION_PREFIX> --query 'sum(Contents[].Size)'

Record both and label which is which. Report the expansion ratio (indexed ÷ raw) on its own: vectors, the graph, filterable metadata and any lexical index multiply raw bytes. Non-S3 connectors have no bucket to sum; raw size comes from the customer. If indexed storage is unavailable, say so; raw size does not stand in for it.

3.4 Vector count and embedding dimension

These two inputs size the self-managed side; raw GB does not. A Bedrock KB writes one document per chunk into its index, so the index's document count is its vector count.

# Which index the KB writes to, and the embedding model and dimension it uses
aws bedrock-agent get-knowledge-base --knowledge-base-id <SOURCE_KB_ID> --region <REGION> --profile <READ_ONLY_PROFILE> \
  --query 'knowledgeBase.{index: storageConfiguration.opensearchServerlessConfiguration.vectorIndexName,
                          model: knowledgeBaseConfiguration.vectorKnowledgeBaseConfiguration.embeddingModelArn,
                          dims:  knowledgeBaseConfiguration.vectorKnowledgeBaseConfiguration.embeddingModelConfiguration.bedrockEmbeddingModelConfiguration.dimensions}'

# Vector count: SearchableDocuments for that index (same compound dimension set as 3.3; one-minute period, latest value)
aws cloudwatch list-metrics --namespace AWS/AOSS --metric-name SearchableDocuments --dimensions Name=CollectionId,Value=<COLLECTION_ID> ...
aws cloudwatch get-metric-statistics --namespace AWS/AOSS --metric-name SearchableDocuments \
  --dimensions <the full set returned for the KB's IndexName> --period 60 --statistics Maximum \
  --start-time <ISO8601_1H_AGO> --end-time <ISO8601_NOW> ...
  • Use the KB's index only; other indexes in the collection are not this KB.

  • If dimensions is absent, the model's default applies; read it from the model's page in this conversation and record the source.

  • S3_VECTORS source: aws s3vectors get-index --vector-bucket-name <B> --index-name <I> gives the dimension; the vector count comes from the customer or their ingestion records.

3.5 The bill

Read the actual spend from Cost Explorer (READ-ONLY; endpoint us-east-1 whatever the KB's Region; one call per account, the API is charged and not real-time):

aws ce get-cost-and-usage --region us-east-1 --profile <READ_ONLY_PROFILE> \
  --time-period Start=<YYYY-MM-DD_30D_AGO>,End=<YYYY-MM-DD_TODAY> --granularity MONTHLY \
  --metrics UnblendedCost --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon OpenSearch Service"]}}'
  • OpenSearch Serverless bills as Amazon OpenSearch Service. Keep only the KB Region's Serverless usage types (<REGION_PREFIX>-SearchOCU, <REGION_PREFIX>-IndexingOCU, <REGION_PREFIX>-StorageUsedInS3ByteHour, and <REGION_PREFIX>-StorageUsedInHotByteHour on NextGen); exclude provisioned-domain types (ESInstance:*, ES:*-Storage) and data transfer (*-Bytes).

  • The figure is account-level, never per KB; report it with the collection count from 3.1.

  • For the model lines (embedding, reranking, FM) repeat with "Values":["Amazon Bedrock"]; for an S3_VECTORS store repeat with "Values":["Amazon Simple Storage Service"] and keep the usage types that name vectors.

The bill is the real number. Prefer it over the derived OCU × rate figure and reconcile any large gap rather than presenting both without comment.

3.6 Retrieval volume

Managed retrieval cost is set entirely by monthly call count. Prefer the source that exists; never stand up new telemetry (a trail, a workgroup, a log pipeline) to size a migration. In order:

  1. The vended metric. Bedrock publishes Invocations under AWS/Bedrock/KnowledgeBases when the KB's service role may call cloudwatch:PutMetricData on that namespace. Check first whether this KB publishes: list-metrics --namespace AWS/Bedrock/KnowledgeBases. Then:

    aws cloudwatch get-metric-statistics --namespace AWS/Bedrock/KnowledgeBases --metric-name Invocations \
      --dimensions Name=KnowledgeBaseId,Value=knowledge-base/<SOURCE_KB_ID> Name=Operation,Value=Retrieve \
      --start-time <ISO8601_30D_AGO> --end-time <ISO8601_NOW> --period 2592000 --statistics Sum \
      --region <REGION> --profile <READ_ONLY_PROFILE>

    The dimension value carries the knowledge-base/ prefix. A KB with no series is either unqueried or not publishing, and the metric cannot tell you which. When the series is empty, the reply must say all three, in so many words: the count is missing, not zero; the likely cause is that the KB's service role lacks cloudwatch:PutMetricData on AWS/Bedrock/KnowledgeBases; and if the customer adds that permission, counting starts from then on (calls made before it are not counted). Saying only "missing, not zero" is not enough. Never add the permission yourself. Documented Operation values are Retrieve and AgenticRetrieveStream; ask about RetrieveAndGenerate separately.

  2. Application telemetry: the calling service's request metrics or logs.

  3. The customer's own count (a legitimate, common outcome). Record it as customer-supplied with their source; a forecast is labeled a forecast.

  4. Existing CloudTrail data events, only if already captured. Retrieve is a bedrock-agent-runtime data event; lookup-events searches management events only and returns zero regardless of traffic (CloudTrail for Bedrock). Count in the customer's existing event data store or query engine over 30 days; ask them to run it if the read-only profile cannot reach it.

Convert only what you were given: monthly_calls = sustained_qps × 86,400 × 30. Never substitute a projected peak for measured volume.

Step 4. Plausibility check

Run before any figure from Step 2 is used. Inputs: vector count (row 7), embedding dimension (row 8), every OCU count that was stated or configured (row 1, and any customer statement), standbyReplicas.

  1. Fetch AWS's own capacity guidance in this conversation and give the links: the OpenSearch Serverless scaling page (what one OCU provides and how OCUs scale with data and traffic), the vector search page, and the AWS post that gives the number of vectors one OCU handles at stated dimensions (vector engine GA). If a page fails to load or the figure is not on it, say the check could not be completed and treat every stated OCU count as a floor.

  2. Read the vectors-per-OCU figure for the dimension nearest the KB's. When AWS gives it only at a different dimension, scale it to the KB's dimension by the ratio of the two (vector memory grows with dimension), feed both the fetched figure and the ratio to the script, and say the result is an estimate. A different dimension is not a reason to skip the check. Read from the scaling page how OCUs divide between active and standby capacity when standbyReplicas is ENABLED, and compare against the active share. Then let the Step 6 script evaluate, with the fetched figure as an input: stated_search_ocu_active × vectors_per_ocu_at_dimension ≥ vector_count. Report the result as fits or does not fit, never as a price. If you still cannot complete the check, say why.

  3. Does not fit → the stated capacity cannot hold this index. Say which three figures conflict (vector count, dimension, stated OCUs) and the fetched figure they conflict with, with its link. Drop the stated OCU count as a cost input, record it as capacity_setting, and ask for the 30-day series (3.2) or the bill (3.5). Fits → the stated count is a plausible floor; it is still usage only under the Step 2 rule.

  4. Throughput. AWS publishes no figure for retrievals per second per OCU, nor documents per second per indexing OCU. Say exactly that when asked. The only evidence is this customer's own SearchOCU and SearchRequestRate series under their own traffic; offer to read them.

  5. Internal consistency. Indexed GB below raw GB, a vector count far below a document count, or a dimension that does not match the model's page each mean a figure is wrong; name it and ask, do not average.

  6. S3_VECTORS source. There are no OCUs; the check is whether the stated logical vector storage is consistent with vector_count × dimension × bytes_per_dimension as the S3 pricing page (Vectors tab) states it in this conversation.

A capacity figure that fails this step is never priced, and a "but if it did hold" table is never built.

Step 5. Fetch every rate live

Fetch each rate in this conversation, with its unit, source and timestamp. Field map and fallbacks are in C.

ComponentPrice List --service-code → what to matchPage
Managed KB storage (raw GB-month)AmazonBedrockAgentCore → usagetype ending Knowledge-Base:Consumption-based:StorageBedrock pricing, Managed Knowledge Bases
Managed KB retrieval (per call unit)AmazonBedrockAgentCore → ...Knowledge-Base:Consumption-based:Retrievalsame
Managed KB agentic retrievalAmazonBedrockAgentCore → ...Knowledge-Base:Consumption-based:AgenticRetrievalsame; note it is charged plus the underlying Retrieve calls
OpenSearch Serverless OCU-hoursAmazonES → usagetype ending -SearchOCU / -IndexingOCUOpenSearch Service pricing, Serverless
OpenSearch Serverless storageAmazonES → usagetype ending -StorageUsedInS3ByteHour (plus -StorageUsedInHotByteHour for NextGen hot storage); not ES:*-Storage (provisioned domains) and not OpenSearch-Vectors-TimedStorage-ByteHrs (a different product)same
S3 Vectors storage, PUT, query request, query dataAmazonS3 → the S3 Vectors usage types the bill shows (3.5)S3 pricing, Vectors
Embedding, reranking, parsing and FM modelsAmazonBedrockFoundationModels → match servicename client-side; embedding meter is the usagetype ending _InputTokenCount-Units; BDA parsing per page under its own sectionBedrock pricing, model sections
  • The pricing pages render their rate tables in JavaScript. A curl of the page returns the worked examples at best and no model rates at all. For every rate the path is the Price List API, then the credential-free offer file (C); the page is a last resort for a figure that is literally in its text.

  • Bedrock model IDs are not in the pricing catalog; match servicename. Check the token unit the record states and convert before use.

  • The Managed Knowledge Bases section also lists what is included (parser, embedding model, reranker, agentic planning model). Record that list from the page in this conversation; Step 7 uses it.

  • Credit an inclusion only to a source you read in this conversation that states it. A Price List API result lists meters, not inclusions: never credit it, or a page you did not fetch or that came back without that section, for what Managed includes. If the page did not show the list, give the mapping reference as the source and say the pricing page was not read.

Step 6. Compute with a script

Arithmetic is done by a script, never by reasoning in prose. Write cost_compare.py to output_dir, feed it every input with its source tag and every rate with its unit, run it, and copy its output into the reply. Every number the customer sees comes from the script's output. A row whose input is missing prints not included: <reason> and the total that depends on it is omitted (Step 9).

hours_in_month = 730

Self-managed on OpenSearch Serverless (monthly):
  search_ocu_avg        × ocu_rate_per_hour × hours_in_month
+ indexing_ocu_avg      × ocu_rate_per_hour × hours_in_month
+ acceleration_ocu_avg  × ocu_rate_per_hour × hours_in_month        # only if the metric reports
+ indexed_gb            × aoss_storage_rate_per_gb_month
+ embedding_tokens_per_ingest × embedding_rate × ingests_per_month   # omitted from both sides when unknown
+ parsing_units         × parsing_rate                                # FM tokens or BDA pages; default parser = 0
+ rerank_queries        × rerank_rate                                 # only if implemented
+ generation_tokens     × fm_rate                                     # only if counted; symmetric with Managed

Self-managed on S3 Vectors (monthly):
  logical_vector_gb     × s3v_storage_rate_per_gb_month
+ put_gb_per_month      × s3v_put_rate_per_gb
+ queries_per_month     × s3v_query_request_rate
+ query_data_processed  × s3v_processed_rate (tier chosen by vector count, as the page states)
+ query_data_returned   × s3v_returned_rate (above the free allowance the page states)
+ embedding, parsing, reranking, generation as above

Managed KB (monthly):
  raw_gb                × managed_storage_rate_per_gb_month
+ retrieve_calls        × retrieve_rate
+ agentic_calls         × agentic_rate
+ agentic_underlying_retrieve_calls × retrieve_rate                   # agentic retrieval is charged plus its Retrieve calls
+ custom_embedding_tokens × model_rate                                # only with a custom embedding model; the managed model is included
+ generation_tokens     × fm_rate                                     # only if counted; symmetric

vectors_per_ocu_at_dimension = fetched_vectors_per_ocu × (fetched_dimension ÷ kb_dimension)   # Step 4; an estimate when the dimensions differ
plausibility: stated_search_ocu_active × vectors_per_ocu_at_dimension ≥ vector_count   # Step 4, when a capacity figure was supplied
delta  = managed_total − self_managed_total          # negative ⇒ Managed costs less
ratio  = managed_total ÷ self_managed_total

One volume missing (Step 1 exception, Step 8; not on a shared pool, where self_managed_total is the pool's):
threshold_retrieve_calls = (self_managed_total − managed_total_without_retrieval) ÷ retrieve_rate_per_call
threshold_qps            = threshold_retrieve_calls ÷ (86,400 × 30)       # the same volume, sustained around the clock
# Any other single missing volume: solve the same equality for that line, every other line as measured.

Rules the script enforces: the storage basis is raw GB on Managed and indexed GB on self-managed; the OCU lines are the pool's when ocu_pool_shared_collections > 1 and are labeled so, and the script then also prints the whole-pool comparison (pool_managed_total = Σ managed_total over every KB on the pool, against the pool's self-managed total); a line that is unknown on one side is omitted on both (embedding, generation); redundancy is whatever the collection runs, never a dev-test setting standing in for production; a break-even is computed only across the range the inputs cover.

Step 7. The required output

Every component appears on its side with a value and a source tag, or not included: <reason>. Nothing is silently absent.

ComponentSelf-managedsourceManagedsource
Compute (search OCU / indexing OCU / acceleration; or S3 Vectors query charges)none to size or pay forsource read (Step 5)
Storage (indexed GB on self-managed; raw GB on Managed)
Embedding (ingest and re-ingest)included with the managed model, or custom-model ratesource read (Step 5)
Parsingincluded with the managed parsersource read (Step 5)
Rerankingincluded with the managed rerankersource read (Step 5)
Retrieval callsnone per call
Agentic retrieval (plus underlying Retrieve calls)not offered
Answer generationsymmetricsymmetric
Data transferstate it; not pricedstate it; not priced
Operating the store (patching, scaling, capacity, index maintenance)customerqualitativeAWSqualitative
Monthly total

Then, in this order:

  1. Dominant line item on each side.

  2. What the figures rest on: each input with its tag, the window, the dimension set, the fetched rate sources and timestamps.

  3. What the self-managed figure reflects: Classic or NextGen, standbyReplicas, the configured minimum and whether the series sits at it, how many collections share the pool.

  4. The Step 4 result whenever a capacity figure was supplied: fits or does not, with the fetched figure and link.

  5. What Managed includes that the self-managed total does not, read from the pricing page's Managed Knowledge Bases section in this conversation (the items it lists as included) and from mapping for limits: stated as facts with links, not as a recommendation, each credited only to a source you read (Step 5).

Step 8. Verdict

Only from the Step 6 output, and only after Step 7 is on the screen.

  • Both totals present: lead with the recommendation in one sentence (which side costs this customer less), then the delta and ratio, the line item that drives each side, and what would change it (Managed grows per call as traffic grows; self-managed OCUs grow with data and traffic and fall with idleness only as far as the configured minimum or, on a zero-minimum group, to zero). Close with what Managed includes that the self-managed total does not (Step 7, item 5).

  • One volume missing (Step 1 exception; on a shared pool use the shared-pool bullet instead): lead with a one-sentence recommendation built on the Step 6 threshold, for example "Managed costs you less unless you average more than N Retrieve calls a month (about X per second around the clock)", then ask one yes/no question: "Is your traffic above or below that?" Say that N is a floor: self-managed capacity only grows with traffic, so above N it may need more OCUs too and the real crossover can only be higher. When the missing volume is on the self-managed side (for example S3 Vectors writes or queries), say how large the unpriced lines would have to be to change the answer. A threshold of zero or below means Managed costs more at any traffic: say so plainly, as the self-managed rule below says. Either way, offer to measure the missing volume.

  • The result favours self-managed: say so plainly, as a finding about the bill. Then name what the total leaves out (item 5 of Step 7: operations work, re-ingestion, OCU growth under load, the parsing, embedding and reranking that Managed includes) and offer to measure what could change the result. Do not soften the number and do not argue with it.

  • The result favours Managed: report the delta and the dominant line items the same way.

  • Shared pool (Step 3.1): lead with the whole-pool result and recommend planning the pool's KBs together. For this KB alone, say that moving it adds its Managed lines while the pool's cost stays until the pool empties, and what the pool would cost with this KB gone, if the series shows it. This rule wins over the one-volume threshold: give no break-even or verdict that charges the pool's bill to this KB, labelled or not, including "if this KB were the pool's only tenant". A labelled what-if that prices this KB on capacity of its own, at a size you state and read from the docs in this conversation, is allowed (Step 1).

  • Either total missing for any other reason (more than one volume, or a capacity or storage input): no flat verdict, no "likely", no "typically". Say which input removed which total (Step 9) and offer to measure. There is no typical crossover to quote. A verdict conditional on Step 1's labelled figures is allowed.

  • A break-even is a result of the script over the range the inputs cover, never a starting point, and never computed on a capacity figure that failed Step 4. Apart from Step 1's labelled figures, the one-volume threshold above is the only one computed on a missing input, and only because every other input is the customer's own.

Step 9. When an input is missing

An unreadable or denied figure is an expected outcome, never a blocker; the analysis is part of the summary and does not gate the migration.

SituationAttemptsThenRecord as
Query succeeded, nothing usable (new collection, wrong scope tried, no series)up to 3 varied (widen window, other dimension set, other service code)omit the field, name the gap, ask the customerunavailable: <reason>
Retrieval Invocations series empty (3.6)1say missing, not zero; name the likely cause and that adding the permission starts the count (3.6); ask the customer for their countunavailable: no Invocations series; KB service role likely lacks cloudwatch:PutMetricData
Query refused (AccessDenied, AccessDeniedException, UnauthorizedOperation)1record the denied IAM action, continue with everything elsedenied: <iam action> on the read-only profile
pricing:GetProducts denied1credential-free offer file first (C), pricing page lastsource offer-file or pricing-page
Customer cannot or will not supply a figureask oncerecord it; the total that needs it is omittedunavailable: not supplied
Figure failed Step 4—record as capacity_setting; ask for the series or the billcapacity_setting

Which missing input removes which total:

MissingEffect
search OCU average, or indexing OCU averageself-managed total omitted (quote rates and the figures you have)
indexed GBself-managed storage line omitted; total omitted
raw GBManaged total omitted
retrieval calls per month, everything else in handManaged total omitted; the threshold (Step 6, Step 8) replaces the verdict
retrieval calls per month and another inputManaged total omitted (quote the storage line and the retrieval rate)
vector count or dimensionStep 4 cannot run; every stated OCU count is a floor
S3_VECTORS logical storage (with keys and metadata), write volume, or query volumeS3 Vectors total omitted (quote the lines you can price from supplied figures)
embedding or generation volumethat line omitted on both sides, said in one sentence
either totalthe delta, ratio, break-even and verdict go with it; never a partial comparison, except the one-volume threshold

Denial wording. A read-only profile that excludes the cost probes is a normal, supported posture. Name the action, not the symptom (cloudwatch:GetMetricStatistics denied on the read-only profile; OCU figures omitted), attribute it to the profile, report all denials once together at the end, never ask for write or admin access, and point at the optional read-only statement with the Step 2 questions as the by-hand equivalent. The analysis still counts as performed; only a no at the gate is declined.

A denial still gets a comparison. After a denied read, still give the Step 7 table with everything that can be priced: every per-unit rate you fetched, with its source, and every line whose quantity you have (for example Managed storage on the raw bytes you measured). Omit only the lines and totals the denied figure fed, each marked not included: denied <iam action>. Never call the comparison blocked, not possible, or on hold.


A. How the two pricing models differ

Use this whenever cost comes up and Step 1's gate is not passed. Take each point from the page named, fetched in this conversation, and give its link.

Self-managed (OpenSearch Serverless VECTOR KB)Managed KBWhere to read it live
What you pay forCapacity: search OCU-hours and indexing OCU-hours, plus indexed storageConsumption: raw data stored, plus retrieval calls (and agentic retrieval calls if used)OpenSearch Service pricing (Serverless); Bedrock pricing (Managed Knowledge Bases)
Vector store computeYou size it and pay for it; OCUs scale with vectors, dimension and trafficNone to size or pay forOpenSearch Serverless scaling
Parsing, embedding, rerankingYou pay the models you call, on every ingest and re-ingest, and per query for rerankingIncluded with the managed parser, embedding model and reranker (a model of your choice is charged)Bedrock pricing, Managed Knowledge Bases and model sections
Storage basisIndexed GBRaw GBboth pricing pages
When idleDown to the configured minimum; a NextGen group with a zero minimum can scale compute to zeroStorage onlyScale to zero; collection groups
As traffic growsOCUs grow (replicas for throughput, memory for data)Retrieval charges grow per callboth pricing pages
S3 Vectors as the self-managed storeLogical vector storage, PUT volume, per-query request and data charges; no compute to sizeas aboveS3 pricing, Vectors

Two consequences: neither side is flat (never hold one side constant across traffic the inputs do not cover), and the configured minimum is not the bill (the bill is the OCU series or the Cost Explorer line; a minimum says only the lowest it can go).

B. Modeling errors seen in practice

  • Pricing a stated OCU count as usage ("we run one search and one indexing OCU", then OCUs × rate × 730). A stated or configured count is a floor until the series or the bill confirms it (Step 2 rule) and it passes Step 4.

  • Sizing OCUs from GB. Vector count and dimension set the memory an index needs; raw GB does not. A configuration that cannot hold the index is not costed (Step 4).

  • Counting only retrieval. Self-managed has no per-call charge, so a retrieval-only comparison always favours it; the OCU-hours, storage, embedding, parsing and reranking lines are the comparison.

  • Counting search OCUs but not indexing OCUs, or omitting the acceleration metric when it reports.

  • Applying the Managed per-GB rate to indexed GB inflates Managed by the whole expansion ratio.

  • Scoring embedding, reranking and parsing as free on both sides. They are included on Managed and real charges or missing capabilities on self-managed.

  • Pricing agentic retrieval without its underlying Retrieve calls.

  • Holding one side flat across traffic levels.

  • A projected peak presented as traffic, or volumes the agent chose presented as the customer's.

  • Comparing production Managed against a standbyReplicas: DISABLED configuration.

  • Attributing a shared OCU pool to one KB, or promising the pool's cost disappears when one KB leaves, including a break-even worked out as if this KB were the pool's only tenant.

  • Arithmetic in prose: a total that was never computed by the script in output_dir.

  • Accepting a generated cost model without the bill: anchor on CloudWatch and Cost Explorer (3.5).

C. Price List field map and fallbacks

aws pricing get-products --service-code AmazonBedrockAgentCore --region us-east-1 \
  --filters "Type=TERM_MATCH,Field=regionCode,Value=<REGION>" --profile <READ_ONLY_PROFILE>
aws pricing get-products --service-code AmazonES --region us-east-1 \
  --filters "Type=TERM_MATCH,Field=regionCode,Value=<REGION>" --profile <READ_ONLY_PROFILE>
aws pricing get-products --service-code AmazonBedrockFoundationModels --region us-east-1 \
  --filters "Type=TERM_MATCH,Field=regionCode,Value=<REGION>" --profile <READ_ONLY_PROFILE>
  • Managed KB rates are under AmazonBedrockAgentCore, not AmazonBedrock; an empty result under AmazonBedrock is expected.

  • OpenSearch Serverless rates are under AmazonES, the legacy code. Guessed codes return an empty PriceList, not an error, so an empty result proves nothing. Filter on regionCode or the exact usagetype (for example USW2-SearchOCU); page with NextToken. Match usagetype by exact suffix: the Region also publishes SemanticSearchOCU, DirectQueryOCU and IngestionOCU, and the indexed-storage meter is -StorageUsedInS3ByteHour (-StorageUsedInHotByteHour for NextGen hot storage).

  • Model rates: there is no modelId attribute; match servicename client-side. The on-demand embedding meter is the usagetype ending _InputTokenCount-Units. Convert the unit the record states.

  • If pricing:* is denied, the credential-free bulk offer file serves the same data: curl -sSL "https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/<SERVICE_CODE>/current/<REGION>/index.json".

  • Pricing-page sections are rendered by JavaScript. A fetched page with the heading but not the number is not a source; use the API or the offer file.

  • Quote every rate with its unit, its source and the time you fetched it.

D. Read-only command quick reference

TaskCommand
Collection config / redundancy / KMS key / groupaws opensearchserverless batch-get-collection --ids <ID> (3.1)
Collection group capacity settingsaws opensearchserverless batch-get-collection-group --names <GROUP_NAME> (3.1)
List collections (sharing scope)aws opensearchserverless list-collections
Which OCU scope carries the collectionaws cloudwatch list-metrics --namespace AWS/AOSS --metric-name SearchOCU (3.2)
Search / indexing OCUs, 30-day Average and Maximumaws cloudwatch get-metric-statistics --namespace AWS/AOSS --metric-name SearchOCU ... with the dimension set from 3.2; --metric-name IndexingOCU for the other half
Indexed storagelist-metrics --metric-name StorageUsedInS3 --dimensions Name=CollectionId,Value=<ID>, then get-metric-statistics with the full set at --period 60 (3.3)
Raw corpus sizeaws s3api list-objects-v2 --bucket <B> --prefix <P> --query 'sum(Contents[].Size)'
Vector countget-metric-statistics --namespace AWS/AOSS --metric-name SearchableDocuments for the KB's index (3.4)
Embedding model and dimension, and the KB's index nameaws bedrock-agent get-knowledge-base --knowledge-base-id <ID> (3.4)
S3 Vectors index dimensionaws s3vectors get-index --vector-bucket-name <B> --index-name <I> (3.4)
The billaws ce get-cost-and-usage ... --group-by Type=DIMENSION,Key=USAGE_TYPE --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon OpenSearch Service"]}}' (3.5)
Retrieval volumeget-metric-statistics --namespace AWS/Bedrock/KnowledgeBases --metric-name Invocations --dimensions Name=KnowledgeBaseId,Value=knowledge-base/<ID> Name=Operation,Value=Retrieve, 30-day Sum (3.6); then app telemetry, then the customer
Ratesaws pricing get-products --service-code <AmazonBedrockAgentCore | AmazonES | AmazonS3 | AmazonBedrockFoundationModels> --region us-east-1 --filters "Type=TERM_MATCH,Field=regionCode,Value=<REGION>" (C)
Rates without IAMcurl -sSL "https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/<SERVICE_CODE>/current/<REGION>/index.json"

E. Output record

One record per KB. Read analysis_status first. Every value is a placeholder naming where the real value comes from. Omit, never null: a field a bounded search cannot resolve is dropped and the gap named in scope_note. On declined, keep only source_kb_id, vector_store, analysis_status and scope_note. USD throughout; identifiers and ARNs only, never a secret value.

source_kb_id: <live KB id>      # an IaC-only KB uses logical_id instead — exactly one
vector_store: <OPENSEARCH_SERVERLESS | S3_VECTORS | other>
analysis_status: performed      # performed | declined  (declined = the user said no at the gate; never means AWS said no)
in_scope: true                  # true for OPENSEARCH_SERVERLESS and S3_VECTORS; false ⇒ omit current_self_managed, name why in scope_note
pricing_source: { method: pricing:GetProducts, service_codes: [<AmazonES | AmazonBedrockAgentCore | AmazonS3 | AmazonBedrockFoundationModels>], region_endpoint: us-east-1, retrieved_at: <ts> }
corpus:
  total_size_bytes: <measured: s3:ListObjectsV2 sum(Size)>
  object_count: <measured>
  measured_via: s3:ListObjectsV2 sum(Size) over inclusionPrefixes
index:
  vector_count: <measured: SearchableDocuments for the KB's index, or customer-supplied>
  embedding_model_arn: <GetKnowledgeBase>
  embedding_dimension: <GetKnowledgeBase, or the model's page>
  plausibility: { checked: <true|false>, stated_search_ocu: <n or none>, fits: <true|false>, guidance_source: <url>, note: <text> }   # omit when no capacity figure was supplied
current_self_managed:           # omit the whole block when not in_scope
  architecture: <CLASSIC | NEXTGEN_GROUP | S3_VECTORS>
  collection_arn: <arn>
  standby_replicas: <ENABLED | DISABLED>
  collection_group: <name, or none>
  capacity_limits: <the group's capacityLimits as returned; omit for Classic>
  ocu_pool_shared_collections: <count>   # > 1 ⇒ OCU figures are the pool's, not this KB's
  search_ocu_avg: <measured: AWS/AOSS SearchOCU 30d Average>
  search_ocu_max: <measured: 30d Maximum>
  indexing_ocu_avg: <measured>
  indexing_ocu_max: <measured>
  acceleration_ocu_avg: <measured: VectorIndexBuildAccelerationOCU>   # omit with reason when no series
  indexed_storage_gb: <measured: StorageUsedInS3 (+ StorageUsedInHot on NextGen)>
  expansion_ratio: <derived: indexed ÷ raw>
  capacity_setting: <a stated or configured OCU count that is a floor, not usage>   # omit when none was stated
  usage_source: <how the OCU and storage figures were obtained, incl. dimension set and window>
  bill_line_usd: <measured: Cost Explorer, account-level, Region and usage types kept>
  rates: { ocu_per_hour: <fetched>, storage_per_gb_month: <fetched>, embedding: <fetched + unit>, rerank: <fetched + unit>, parsing: <fetched + unit> }
  line_items_usd: { compute: <script>, storage: <script>, embedding: <script | not included: reason>, parsing: <...>, reranking: <...>, generation: <...> }
  estimated_monthly_usd: <script>    # omit if any REQUIRED input is absent
retrieval:                      # omit when no volume was established
  calls_monthly: <measured or customer-supplied>
  effective_qps: <derived>
  source: <measured | customer_supplied | forecast>
  measured_via: <metric and window, app telemetry, or the existing data-event store>
  agentic_calls_monthly: <customer-supplied>   # omit unless agentic retrieval is wanted
estimated_managed:
  embedding_model_type: <MANAGED | CUSTOM>   # MANAGED ⇒ embedding, parsing, reranking included
  raw_corpus_gb: <measured>
  rates: { storage_per_gb_month: <fetched>, retrieve: <fetched + unit>, agentic: <fetched + unit> }
  line_items_usd: { storage: <script>, retrieval: <script>, agentic: <script | not included: reason>, generation: <...> }
  included: [<items the pricing page lists as included, read in this conversation>]
  estimated_monthly_usd: <script>    # omit when raw GB or retrieval volume is absent
  managed_pricing_source: { method: <pricing:GetProducts | offer-file | pricing-page>, url: <url>, retrieved_at: <ts> }
comparison:                     # omit unless BOTH totals are present
  delta_monthly_usd: <script: managed − self-managed; negative ⇒ Managed costs less>
  ratio: <script>
  cheaper: <MANAGED | SELF_MANAGED | COMPARABLE>
  self_managed_dominant_line_item: <e.g. search OCUs>
  managed_dominant_line_item: <e.g. retrieval calls>
  rests_on: <the inputs, each measured or customer-supplied>
  script_path: <output_dir>/cost_compare.py
scope_note: <specific reason>   # required on in_scope:false, declined, any omitted field, or a denied permission (name the IAM action)

F. Procedural mistakes

  • Giving a figure before the Step 1 gate is passed that Step 1 does not allow: a total on a guessed rate, an assumed input presented as theirs, or a table at volumes you chose presented as their usage.

  • Quoting a rate without fetching it in this conversation, or naming a page you did not fetch.

  • Skipping Step 4 when the customer stated an OCU count, or pricing a count that failed it.

  • Computing in prose instead of in cost_compare.py in output_dir.

  • An output table with a row missing rather than marked not included: <reason>.

  • Concluding OpenSearch Serverless pricing "isn't published": it is, under AmazonES (C). Empty results from guessed codes, an unfiltered single page, or a ClientId-only StorageUsedInS3 query prove nothing.

  • Blocking the migration because a figure was unavailable or denied: Step 9, then move on.

  • Mishandling a denial: spending the 3-attempt ladder on it, writing "OCUs unavailable" instead of the IAM action, recording it as declined, or asking for broader or write credentials.

  • Running the analysis on a declined session, or offering a "rough idea" instead.

  • Writing cost or price files outside output_dir.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs an API key, Needs Python

Security

What our scanner noticed· Medium risk

  • References to credential files
  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · skills/core-skills/amazon-bedrock · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
aws/agent-toolkit-for-aws

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download amazon-bedrock.zip