Amazon Bedrock
AWSOfficialPublished by AWS
- Skill
- Tool integration
- Cloud and DevOps
- Apache-2.0
- Medium risk
- Has scripts
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
Download the skill as a ZIP:
https://autogineer.com/agent-skills/aws/amazon-bedrock/downloadUnzip 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_skilltool: The skill is not installed on the local filesystem. You MUST fetch each reference or script viaretrieve_skillwith thefileparameter (e.g.file="references/managed-knowledge-bases-setup.md"orfile="scripts/fetch_bedrock_agent.py"), and run the script from the returned content. Do NOTfile_readthese 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.
| Endpoint | Client | Use For |
|---|---|---|
bedrock | Control plane | List models, manage access, provisioned throughput |
bedrock-runtime | Data plane | Invoke 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-mantle | Data plane | OpenAI-compatible APIs: Responses API, Chat Completions (recommended), Messages API. Supports server-side tool use with built-in tools. Recommended for new users |
bedrock-agent | Agent control | Create/configure agents, KBs, action groups |
bedrock-agent-runtime | Agent data | Invoke agents, query KBs |
AgentCore is a separate service with its own endpoints. Refer to AgentCore endpoints and quotas for the latest.
| Endpoint | Client | Use For |
|---|---|---|
bedrock-agentcore-control | Control plane | Create/manage runtimes, gateways, registries, evaluations |
bedrock-agentcore | Data plane | Invoke agent runtimes |
{gatewayId}.gateway.bedrock-agentcore | Gateway data plane | Invoke 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:*orAmazonBedrockFullAccessStore API keys and OAuth secrets in AWS Secrets Manager with automatic rotation enabled
Include confused deputy protection (
aws:SourceAccount,aws:SourceArnconditions) in all resource-based policies for Bedrock servicesTreat 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?
| Goal | Use | Reference |
|---|---|---|
| Call a model (text, image, video) | Converse API | See above + model invocation |
| Build a RAG application (RAG on Bedrock) | Knowledge Bases — Managed KB (MKB) by default; Customer-managed only if the user explicitly asks | managed KB setup (see KB decision guide) |
| Create an agent that takes actions | Bedrock Agents | agent creation |
| Filter harmful/sensitive content | Guardrails | guardrails |
| Run a config-based managed agent loop on AgentCore (no code, no container) | AgentCore Harness | harness |
| Migrate an existing Bedrock Agent (classic) to an AgentCore Harness | Bedrock Agents to AgentCore harness Migration | migration guide |
| Migrate an existing Customer-managed Knowledge Base to a Managed KB | KB migration | migrate KB to Managed |
| Deploy and scale an agent loop you wrote yourself | AgentCore Runtime | runtime |
| Expose REST APIs as MCP tools | AgentCore Gateway | gateway |
| Choose the right model | Model Selection | model guide |
| Set up or debug prompt caching | Prompt Caching | prompt caching |
| Diagnose throttling or audit quotas | Quota Health | quota health |
| Track costs by team, model, or tag | Cost Tracking | cost tracking |
| Migrate between Claude generations | Model Migration | migration 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 --versionYou 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,ConverseStreamCommandin JS SDK).
Mode When to use Converse Batch/backend pipelines — single complete response, no stream handling required ConverseStream Chat 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) orAgenticRetrieveStream(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
maxTokensand quota reservationYou MUST guide the user through comparing limits vs peak usage using
aws service-quotasandaws 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
| Retry | Do NOT retry |
|---|---|
| ThrottlingException | ValidationException |
| ModelTimeoutException | AccessDeniedException |
| ServiceUnavailableException | ResourceNotFoundException |
| 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.
| Service | Use For | Reference |
|---|---|---|
| Harness | Managed config-based agent loop — no orchestration code; fastest path from config to a running agent | harness procedure |
| Gateway | Expose APIs, Lambda functions, or existing MCP servers as tools for agents | gateway procedure |
| Runtime | Deploy and scale agents and tools (serverless, any framework) | runtime procedure |
| Runtime Container | Build ARM64 containers for Runtime | container build procedure |
| Memory | Short-term (multi-turn) and long-term (cross-session) agent memory; share memory across agents | memory & observability |
| Identity | Agent authentication with external IdPs (Okta, Entra ID, Cognito); act on behalf of users | credentials & security |
| Policy | Enforce agent boundaries with natural language or Cedar rules; intercepts Gateway tool calls | Refer to the AWS documentation on AgentCore Policy |
| Payments | Enable agents to pay for x402-protected APIs, MCP tools, and content via microtransactions (Coinbase CDP, Stripe Privy) | payments procedure |
| Observability | Trace, debug, and monitor agent execution (OTEL, CloudWatch) | memory & observability |
| Registry | Catalog and discover agents, MCP servers, tools, and skills across your org | registry & evaluations |
| Evaluations | Automated agent quality assessment (LLM-as-a-Judge) | registry & evaluations |
| Code Interpreter | Secure sandbox code execution for agents | Refer to the AWS documentation on AgentCore Code Interpreter |
| Browser | Web 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
- ATTRIBUTION.mdAdded by AutoGineer893 B
- LICENSELicence file added by AutoGineer9.9 KiB
- NOTICELicence file added by AutoGineer67 B
- SKILL.md35.7 KiB
- assets/kb_shim.py.tmpl3.4 KiB
- assets/lambda_shim.py.tmpl8.0 KiB
- assets/tool_schema.json.tmpl389 B
- references/agentcore-credentials-and-security.md6.5 KiB
- references/agentcore-gateway.md7.0 KiB
- references/agentcore-harness.md22.0 KiB
- references/agentcore-memory-observability.md5.6 KiB
- references/agentcore-payments-setup-script.md12.3 KiB
- references/agentcore-payments-wiring.md12.1 KiB
- references/agentcore-payments.md19.5 KiB
- references/agentcore-registry-evaluations.md6.9 KiB
- references/agentcore-runtime-container-build.md10.5 KiB
- references/agentcore-runtime.md7.7 KiB
- references/agents-and-action-groups.md16.5 KiB
- references/bedrock-agents-to-agentcore-harness/cli.md2.0 KiB
- references/bedrock-agents-to-agentcore-harness/deploy.md12.1 KiB
- references/bedrock-agents-to-agentcore-harness/discovery.md3.9 KiB
- references/bedrock-agents-to-agentcore-harness/eligibility.md3.3 KiB
- references/bedrock-agents-to-agentcore-harness/mapping.md8.9 KiB
- references/bedrock-kb-migration/cost-analysis.md52.9 KiB
- references/bedrock-kb-migration/discovery.md26.1 KiB
- references/bedrock-kb-migration/iac-schema.md24.7 KiB
- references/bedrock-kb-migration/implement-iac.md19.0 KiB
- references/bedrock-kb-migration/implement-kb.md29.7 KiB
- references/bedrock-kb-migration/managed-kb-api.md76.0 KiB
- references/bedrock-kb-migration/mapping.md59.9 KiB
- references/bedrock-kb-migration/plan.md18.5 KiB
- references/bedrock-kb-migration/safety-and-iam.md27.8 KiB
- references/cost-tracking.md4.5 KiB
- references/guardrails.md14.7 KiB
- references/knowledge-bases-decision-guide.md2.8 KiB
- references/knowledge-bases-retrieval.md9.2 KiB
- references/knowledge-bases-setup.md17.9 KiB
- references/managed-knowledge-bases-retrieval.md9.0 KiB
- references/managed-knowledge-bases-setup.md12.7 KiB
- references/migrate-bedrock-agents-to-agentcore-harness.md11.5 KiB
- references/migrate-knowledge-base-to-managed.md32.4 KiB
- references/model-invocation.md11.0 KiB
- references/model-migration.md4.3 KiB
- references/model-selection-guide.md7.4 KiB
- references/prompt-caching.md5.5 KiB
- references/prompt-engineering-by-model.md8.0 KiB
- references/quota-health.md4.3 KiB
- references/sdk-converse-api-python.md6.3 KiB
- references/sdk-converse-api-typescript.md6.5 KiB
- scripts/fetch_bedrock_agent.pyScript14.1 KiB
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 store | Comparison | Formula block used in Step 6 |
|---|---|---|
OPENSEARCH_SERVERLESS | two-sided | self-managed on OpenSearch Serverless + Managed |
S3_VECTORS | two-sided | self-managed on S3 Vectors + Managed |
| any other store (Pinecone, Redis, Aurora pgvector, MongoDB, Neptune, provisioned OpenSearch) | one-sided | Managed 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:
how the two pricing models differ (A), each point from the page named there, fetched in this conversation, with its link;
the Step 2 list of inputs still missing, asked for in one message;
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.
| # | Input | Side | Needed for | Where it comes from |
|---|---|---|---|---|
| 1 | Collection architecture (Classic, or a NextGen collection group), its capacity settings, standbyReplicas, KMS key, how many collections share its OCU pool | self-managed | REQUIRED (every self-managed figure is read against it) | Step 3.1 |
| 2 | Search OCU, 30-day Average and Maximum | self-managed | REQUIRED for the self-managed total | Step 3.2, or the bill line (3.5) |
| 3 | Indexing OCU, 30-day Average and Maximum | self-managed | REQUIRED for the self-managed total | Step 3.2, or the bill line (3.5) |
| 4 | Vector-acceleration OCU | self-managed | when the metric reports | Step 3.2 |
| 5 | Indexed storage GB (and hot storage GB on NextGen) | self-managed | REQUIRED for the self-managed total | Step 3.3 |
| 6 | Raw corpus GB | Managed | REQUIRED for the Managed total | Step 3.3, or the customer |
| 7 | Vector count of the KB's index | self-managed sizing | REQUIRED for Step 4 | Step 3.4 |
| 8 | Embedding model and dimension | self-managed sizing | REQUIRED for Step 4 | Step 3.4 |
| 9 | Retrieval calls per month, and the source of the number | Managed | REQUIRED for the Managed total | Step 3.6, app telemetry, or the customer |
| 10 | Whether agentic retrieval is wanted; expected agentic calls per month | Managed | when wanted | the customer |
| 11 | Embedding token volume per ingest, and how often the corpus is re-ingested | self-managed (Managed only with a custom model) | when known; omitted from both sides when unknown | ingest bill, Cost Explorer model line, or the customer |
| 12 | Parser in use (default, foundation-model, or Bedrock Data Automation) and its volume (tokens or pages) | self-managed | when not the default parser | GetDataSource parsing configuration; the customer |
| 13 | Reranker in use and queries per month | self-managed | when implemented | the customer, app telemetry |
| 14 | Whether a foundation model generates answers, which, and its token volume | both, symmetric | when known; omitted from both sides when unknown | the customer |
| 15 | Corpus growth per month and the horizon to compare over | both | optional | the 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: DISABLEDis 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/AOSSnever 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.
Averageis the billed figure;Maximumshows whether capacity sits flat or bursts. NeverSumat 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
SearchOCUagain over the same 30 days at--period 3600(AverageandMaximum) 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
dimensionsis absent, the model's default applies; read it from the model's page in this conversation and record the source.S3_VECTORSsource: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>-StorageUsedInHotByteHouron 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 anS3_VECTORSstore 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:
The vended metric. Bedrock publishes
InvocationsunderAWS/Bedrock/KnowledgeBaseswhen the KB's service role may callcloudwatch:PutMetricDataon 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 lackscloudwatch:PutMetricDataonAWS/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. DocumentedOperationvalues areRetrieveandAgenticRetrieveStream; ask aboutRetrieveAndGenerateseparately.Application telemetry: the calling service's request metrics or logs.
The customer's own count (a legitimate, common outcome). Record it as customer-supplied with their source; a forecast is labeled a forecast.
Existing CloudTrail data events, only if already captured.
Retrieveis abedrock-agent-runtimedata event;lookup-eventssearches 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.
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.
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
standbyReplicasisENABLED, 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.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.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
SearchOCUandSearchRequestRateseries under their own traffic; offer to read them.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.
S3_VECTORSsource. There are no OCUs; the check is whether the stated logical vector storage is consistent withvector_count × dimension × bytes_per_dimensionas 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.
| Component | Price List --service-code → what to match | Page |
|---|---|---|
| Managed KB storage (raw GB-month) | AmazonBedrockAgentCore → usagetype ending Knowledge-Base:Consumption-based:Storage | Bedrock pricing, Managed Knowledge Bases |
| Managed KB retrieval (per call unit) | AmazonBedrockAgentCore → ...Knowledge-Base:Consumption-based:Retrieval | same |
| Managed KB agentic retrieval | AmazonBedrockAgentCore → ...Knowledge-Base:Consumption-based:AgenticRetrieval | same; note it is charged plus the underlying Retrieve calls |
| OpenSearch Serverless OCU-hours | AmazonES → usagetype ending -SearchOCU / -IndexingOCU | OpenSearch Service pricing, Serverless |
| OpenSearch Serverless storage | AmazonES → 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 data | AmazonS3 → the S3 Vectors usage types the bill shows (3.5) | S3 pricing, Vectors |
| Embedding, reranking, parsing and FM models | AmazonBedrockFoundationModels → match servicename client-side; embedding meter is the usagetype ending _InputTokenCount-Units; BDA parsing per page under its own section | Bedrock pricing, model sections |
The pricing pages render their rate tables in JavaScript. A
curlof 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.
| Component | Self-managed | source | Managed | source |
|---|---|---|---|---|
| Compute (search OCU / indexing OCU / acceleration; or S3 Vectors query charges) | none to size or pay for | source 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 rate | source read (Step 5) | ||
| Parsing | included with the managed parser | source read (Step 5) | ||
| Reranking | included with the managed reranker | source read (Step 5) | ||
| Retrieval calls | none per call | |||
| Agentic retrieval (plus underlying Retrieve calls) | not offered | |||
| Answer generation | symmetric | symmetric | ||
| Data transfer | state it; not priced | state it; not priced | ||
| Operating the store (patching, scaling, capacity, index maintenance) | customer | qualitative | AWS | qualitative |
| Monthly total |
Then, in this order:
Dominant line item on each side.
What the figures rest on: each input with its tag, the window, the dimension set, the fetched rate sources and timestamps.
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.The Step 4 result whenever a capacity figure was supplied: fits or does not, with the fetched figure and link.
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.
| Situation | Attempts | Then | Record 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 customer | unavailable: <reason> |
Retrieval Invocations series empty (3.6) | 1 | say missing, not zero; name the likely cause and that adding the permission starts the count (3.6); ask the customer for their count | unavailable: no Invocations series; KB service role likely lacks cloudwatch:PutMetricData |
Query refused (AccessDenied, AccessDeniedException, UnauthorizedOperation) | 1 | record the denied IAM action, continue with everything else | denied: <iam action> on the read-only profile |
pricing:GetProducts denied | 1 | credential-free offer file first (C), pricing page last | source offer-file or pricing-page |
| Customer cannot or will not supply a figure | ask once | record it; the total that needs it is omitted | unavailable: not supplied |
| Figure failed Step 4 | — | record as capacity_setting; ask for the series or the bill | capacity_setting |
Which missing input removes which total:
| Missing | Effect |
|---|---|
| search OCU average, or indexing OCU average | self-managed total omitted (quote rates and the figures you have) |
| indexed GB | self-managed storage line omitted; total omitted |
| raw GB | Managed total omitted |
| retrieval calls per month, everything else in hand | Managed total omitted; the threshold (Step 6, Step 8) replaces the verdict |
| retrieval calls per month and another input | Managed total omitted (quote the storage line and the retrieval rate) |
| vector count or dimension | Step 4 cannot run; every stated OCU count is a floor |
S3_VECTORS logical storage (with keys and metadata), write volume, or query volume | S3 Vectors total omitted (quote the lines you can price from supplied figures) |
| embedding or generation volume | that line omitted on both sides, said in one sentence |
| either total | the 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 KB | Where to read it live | |
|---|---|---|---|
| What you pay for | Capacity: search OCU-hours and indexing OCU-hours, plus indexed storage | Consumption: raw data stored, plus retrieval calls (and agentic retrieval calls if used) | OpenSearch Service pricing (Serverless); Bedrock pricing (Managed Knowledge Bases) |
| Vector store compute | You size it and pay for it; OCUs scale with vectors, dimension and traffic | None to size or pay for | OpenSearch Serverless scaling |
| Parsing, embedding, reranking | You pay the models you call, on every ingest and re-ingest, and per query for reranking | Included with the managed parser, embedding model and reranker (a model of your choice is charged) | Bedrock pricing, Managed Knowledge Bases and model sections |
| Storage basis | Indexed GB | Raw GB | both pricing pages |
| When idle | Down to the configured minimum; a NextGen group with a zero minimum can scale compute to zero | Storage only | Scale to zero; collection groups |
| As traffic grows | OCUs grow (replicas for throughput, memory for data) | Retrieval charges grow per call | both pricing pages |
| S3 Vectors as the self-managed store | Logical vector storage, PUT volume, per-query request and data charges; no compute to size | as above | S3 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
Retrievecalls.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: DISABLEDconfiguration.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, notAmazonBedrock; an empty result underAmazonBedrockis expected.OpenSearch Serverless rates are under
AmazonES, the legacy code. Guessed codes return an emptyPriceList, not an error, so an empty result proves nothing. Filter onregionCodeor the exactusagetype(for exampleUSW2-SearchOCU); page withNextToken. Matchusagetypeby exact suffix: the Region also publishesSemanticSearchOCU,DirectQueryOCUandIngestionOCU, and the indexed-storage meter is-StorageUsedInS3ByteHour(-StorageUsedInHotByteHourfor NextGen hot storage).Model rates: there is no
modelIdattribute; matchservicenameclient-side. The on-demand embedding meter is theusagetypeending_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
| Task | Command |
|---|---|
| Collection config / redundancy / KMS key / group | aws opensearchserverless batch-get-collection --ids <ID> (3.1) |
| Collection group capacity settings | aws opensearchserverless batch-get-collection-group --names <GROUP_NAME> (3.1) |
| List collections (sharing scope) | aws opensearchserverless list-collections |
| Which OCU scope carries the collection | aws cloudwatch list-metrics --namespace AWS/AOSS --metric-name SearchOCU (3.2) |
| Search / indexing OCUs, 30-day Average and Maximum | aws 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 storage | list-metrics --metric-name StorageUsedInS3 --dimensions Name=CollectionId,Value=<ID>, then get-metric-statistics with the full set at --period 60 (3.3) |
| Raw corpus size | aws s3api list-objects-v2 --bucket <B> --prefix <P> --query 'sum(Contents[].Size)' |
| Vector count | get-metric-statistics --namespace AWS/AOSS --metric-name SearchableDocuments for the KB's index (3.4) |
| Embedding model and dimension, and the KB's index name | aws bedrock-agent get-knowledge-base --knowledge-base-id <ID> (3.4) |
| S3 Vectors index dimension | aws s3vectors get-index --vector-bucket-name <B> --index-name <I> (3.4) |
| The bill | aws ce get-cost-and-usage ... --group-by Type=DIMENSION,Key=USAGE_TYPE --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon OpenSearch Service"]}}' (3.5) |
| Retrieval volume | get-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 |
| Rates | aws pricing get-products --service-code <AmazonBedrockAgentCore | AmazonES | AmazonS3 | AmazonBedrockFoundationModels> --region us-east-1 --filters "Type=TERM_MATCH,Field=regionCode,Value=<REGION>" (C) |
| Rates without IAM | curl -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.pyinoutput_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 aClientId-onlyStorageUsedInS3query 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