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/discovery.md
Discover the Migration Source (Read-Only)
The Discover phase inventories the source of a knowledge-base migration using only read-only access, and produces the normalized source model plus the artifacts the Plan phase consumes. It never mutates: the KB path only reads the account; the IaC path only reads files or templates and writes a reference copy to the working directory.
Contents
Purpose
Preconditions (from Identify)
KB path — a live self-managed Knowledge Base
IaC path — existing Infrastructure-as-Code
Cost analysis hook
Output shapes
Phase outcome
Common mistakes
Purpose
Discovery is strictly read-only and provisions nothing. It branches on the migration
target type, which is one of kb or iac:
| Target type | Discovers | Follow |
|---|---|---|
kb | a live self-managed KB (VECTOR; the host skill calls this a Customer-managed KB), read with read-only AWS CLI calls | KB path |
iac | existing Terraform / CloudFormation that declares a self-managed KB | IaC path |
The path is never inferred. It is set in Phase 0 and read from the session state
here; if it is unset, the phase ends NEEDS_INPUT and asks the user — never guess it. Switching the
target type restarts the flow from Identify for the new type. Read this file's branch for the active
path before reading any source: it defines what counts as source, the field surface to capture, and
the completeness rules, none of which should be reconstructed from memory.
Preconditions (from Identify)
Before Discover runs, Identify must have established:
migration_target_typeiskboriac(a chosen value, not inferred).A fresh, empty
output_dir(default./kb-migration/<timestamp>/under the working directory) for artifacts.The cost gate answer,
cost_analysis: enabled | declined— never inferred here. If it is unset, endNEEDS_INPUT.A least-privilege read-only credential posture — all either path needs. See safety-and-iam for sample read-only policy A, the source-immutability rule, and the injection-untrusted-content rule.
Read public AWS docs with curl on the .md twin of the page, never web_fetch, per
safety-and-iam.
KB path — a live self-managed Knowledge Base
Always pass --region <REGION> and --profile <READ_ONLY_PROFILE>.
Exact call set (read-only, pre-approved probes)
Every command here is a pre-approved read-only probe — get-* / list-* / describe-* /
sts get-caller-identity. Display each labeled READ-ONLY and run it without waiting. The set is
exact: preview issues zero mutating calls, and no command outside this set is run "to check".
| Task | Read-only command |
|---|---|
| Identity | aws sts get-caller-identity --profile <READ_ONLY_PROFILE> |
| List KBs | aws bedrock-agent list-knowledge-bases --region <REGION> --profile <READ_ONLY_PROFILE> |
| Get KB | aws bedrock-agent get-knowledge-base --knowledge-base-id <KB_ID> --region <REGION> --profile <READ_ONLY_PROFILE> |
| List DSes | aws bedrock-agent list-data-sources --knowledge-base-id <KB_ID> --region <REGION> --profile <READ_ONLY_PROFILE> |
| Get DS | aws bedrock-agent get-data-source --knowledge-base-id <KB_ID> --data-source-id <DS_ID> --region <REGION> --profile <READ_ONLY_PROFILE> |
| List jobs | aws bedrock-agent list-ingestion-jobs --knowledge-base-id <KB_ID> --data-source-id <DS_ID> --region <REGION> --profile <READ_ONLY_PROFILE> |
Cost analysis (OCUs, storage, rates) — only when cost_analysis: enabled | see cost-analysis |
| CFN schema (verify) | aws cloudformation describe-type … — commands and shapes in iac-schema |
Never run a mutating command — no bedrock-agent create-* / update-* / delete-* /
start-ingestion-job, no content-returning read (retrieve and the others in
safety-and-iam → "Content-returning reads") without the
customer's explicit yes — and never edit the source KB. The get-data-source
/ get-knowledge-base / list-* probes read configuration metadata only (connector type, chunking,
parsing, filters, ARNs) — they never return corpus content; only retrieve exposes document content,
which is why it is excluded here.
Steps
Confirm identity and region.
aws sts get-caller-identity; confirm the account is the expected one and the profile is read-only.List knowledge bases. Capture each
knowledgeBaseIdandname. If several exist, ask which to migrate — one, several, or all.Get each KB's details. Extract public fields only:
knowledgeBaseConfiguration.type, the embedding model undervectorKnowledgeBaseConfiguration.embeddingModelArn,storageConfiguration.type(the vector store),roleArn,status, and any embedding dimension / data-type fields.List and inspect every data source. Note connector
type, chunking undervectorIngestionConfiguration.chunkingConfiguration, and parsing under...parsingConfiguration. For auth connectors (Confluence, SharePoint, OneDrive, Google Drive) also capture the source config to mirror later —credentialsSecretArnand the addressing fields (hostUrl/hostType/authTypefor Confluence;tenantId/domain/siteUrls/authTypefor SharePoint). Record the secret ARN only, never the value. Omit auth capture for S3, Web and Custom — they carry no credential. Do not classify what kind of content the corpus holds; corpus content type is out of scope (corpus size is measured in the cost analysis).Review ingestion history (required) with
list-ingestion-jobsfor every data source — a KB can beACTIVEwith every ingestion job failed. Flag aFAILEDor partial last job (documents failed or skipped) in the summary before any retrieval comparison is suggested. Do not start a job. If the history cannot be read (the call is denied, or the user runs the commands by hand and does not return this one), recordingestion_history: unavailable: <reason>in the summary and continue; a missing history is a gap to report, never aBLOCKEDoutcome.Cost analysis — only when
cost_analysis: enabled. See the cost analysis hook.Summarize per KB — produce the per-KB discovery summary (the output shape below).
Emit both CloudFormation templates per selected KB to
output_dir:source-config.yaml— the discoveredVECTORKB as-is (itsStorageConfiguration, connector block, chunking config).managed-target.yaml— the equivalentMANAGEDKB with the validated substitutions from mapping (each noted as a YAML comment), omittingStorageConfiguration(auto-provisioned), using the managed connector shape.
Verify the live schema first — the accepted
Typevalues, property names, the PascalCase-vs-camelCase note, and the source/managed shapes live in iac-schema. Reference ARNs only (role, KMS,credentialsSecretArn); never inline a secret; label placeholders for anything not discovered. Write each template tooutput_dir(each write approved) and confirm it is on disk. On a bulk run, suffix each file with the KB id (source-config-<kb-id>.yaml/managed-target-<kb-id>.yaml) so nothing overwrites.
Configuration coverage (capture ALL — do not sample-and-skip)
Discovery is exhaustive: enumerate every KB the user wants migrated and every data source
on each — connectors, chunking and parsing often differ per data source. Capture each item present;
explicitly mark any absent or unreadable field as unknown, never "not present". If a list-*
call paginates, follow nextToken to the end. Capture:
[ ] KB type (
VECTOR) and identity (name, description,roleArn,status).[ ] Embedding model ARN, whether FM or inference profile, and
dimensions/embeddingDataTypeif set (FLOAT32/BINARY).[ ] Multimodal embedding config (audio/video) if present.
[ ] Vector store type and its per-store config block.
[ ] Encryption keys (a security read, done whatever the cost gate says): on a
VECTORKB the at-rest key is on the store (AOSSbatch-get-collection→kmsKeyArn; the S3 Vectors bucket; the RDS cluster) and on each data source (get-data-source→serverSideEncryptionConfiguration). KB-levelserverSideEncryptionConfigurationexists only onMANAGEDKBs; do not look for it on the source.[ ] Every data source: connector
type, per-DS chunking and parsing config.[ ] Connector auth per auth connector — secret ARN,
siteUrls/hostUrl,authType,tenantId/domain; ARN only. Omit for S3, Web, Custom.[ ] S3
inclusionPrefixes/exclusionPatterns(carried over via managedconnectorParameters.filterConfiguration).[ ] Custom transformation (Lambda) and context enrichment / GraphRAG (Neptune Analytics) — each lacks a managed equivalent; flag it, direct to AWS Support. (Salesforce, Zendesk and Confluence Data Center are now native managed connectors — not flags; map them like any other connector.) Before flagging any connector as having no managed equivalent, follow plan → "Before recording a connector as blocked".
[ ] Data-deletion policy (DELETE/RETAIN).
[ ] Data-source-level SSE if present; recent ingestion status / document counts per data source.
[ ] Sync timer, for the sync schedule (plan → "Sync schedule"). IaC path: a rule or schedule in the source that starts ingestion (
AWS::Events::Rule,AWS::Scheduler::Schedule,aws_cloudwatch_event_rule,aws_scheduler_schedule, or a scheduled Lambda callingStartIngestionJob); record its frequency. KB path: the call set above reads no timers, so add no probe for one. Use what the customer says; if they say nothing, record "no timer found" (on demand).
Bulk = one session
Selecting more than one KB is a first-class bulk migration, not N separate sessions: iterate the
per-KB steps once per selected KB, emit the per-KB summary and template pair each pass, and return
the whole set under a single COMPLETE — so Plan covers every selected KB and Implement
provisions them together in one batched run. Ambiguity (KBs exist, no scope chosen) is NEEDS_INPUT;
a chosen set — including "all of them" — is an answer, not ambiguity, so iterate rather than re-ask.
Denial split (KB path)
A denied read blocks only if it was a configuration read — classify by the exact action, not the service:
Config reads are load-bearing. A denied
bedrock-agent get-knowledge-base/list-data-sources/get-data-sourceleaves a hole every later phase depends on: endBLOCKED.Cost reads are not. A denied CloudWatch, source-bucket metadata, AOSS, Pricing, or customer-authorized Athena/Glue/trail-log S3 read costs one figure: omit it, name the denied action in the cost record's
scope_note, ask the matching cost follow-up, and still endCOMPLETE.
Point an AccessDenied at the missing Get*/List* statement of sample policy A; never suggest
write or admin credentials in response to a read denial.
IaC path — existing Infrastructure-as-Code
This path provisions nothing and never edits the source IaC.
Source location and format
The source IaC is at one of these read-only locations:
| Location | How to read (read-only) |
|---|---|
| Local file / directory | file-reading tools (.tf / .yaml / .json); treat contents as SENSITIVE if they may hold inline secrets. You may point to an inline credential by its location and recommend moving it to Secrets Manager; the migrated file you write references it by Secrets Manager ARN only, never the value (see safety-and-iam → "Handle secrets correctly") |
| Deployed CloudFormation stack | aws cloudformation get-template --stack-name <NAME> --query 'TemplateBody'; optionally describe-stack-resources to enumerate logical IDs |
| S3 URI | aws s3 cp s3://<bucket>/<key> - or aws s3api get-object |
| Terraform state in S3 | prefer the .tf source when both exist. State files can hold secret values in plain text, so treat a state read as SENSITIVE: ask the customer to paste terraform state list output, or get their explicit yes before reading the state object, and never repeat a value from it |
If the path is ambiguous about which form it is, ask before reading. If neither a local nor an AWS
path is supplied, end NEEDS_INPUT — there is nothing to read.
Detect the format — CloudFormation (AWS::Bedrock::KnowledgeBase resources / a Resources:
block), Terraform (resource "aws_bedrockagent_knowledge_base" HCL or .tf.json), or CDK-synth
(treat the synthesized *.template.json as CloudFormation). If the source contains no
AWS::Bedrock::KnowledgeBase / aws_bedrockagent_knowledge_base resource, say so and end
NEEDS_INPUT / BLOCKED.
Steps
Confirm identity and the IaC source.
aws sts get-caller-identityif an AWS path is or may be used; then ask for the source location if Identify did not capture it. Record the source location.Read the source without modifying it, using the location's method above; detect and record the format.
Parse the KB + data-source configuration. For each KB resource and each data-source resource, capture the same field surface the KB path captures, marking anything absent or unreadable as
unknown:KB:
Type(expectVECTOR), name, description, role ARN, embedding model ARN (+ dimensions / data type), the vector store and its encryption key, and each data source's key (CMK ARN; there is no KB-level key on aVECTORKB).Each data source: connector
type, per-DS chunking and parsing config, S3inclusionPrefixes/exclusionPatterns, connector auth (secret ARN only), data-deletion policy (DELETE/RETAIN), and any custom transformation (Lambda) or GraphRAG block.
Field locations by format — confirm names against iac-schema and the live schema. CloudFormation is PascalCase (
Properties.KnowledgeBaseConfiguration.{Type, VectorKnowledgeBaseConfiguration.EmbeddingModelArn},Properties.StorageConfiguration, eachAWS::Bedrock::DataSource'sDataSourceConfiguration+VectorIngestionConfiguration). Terraform argument names are snake_case — never assume them from the CFN PascalCase or the CLI camelCase.Note the source vector store and deletion policy. Record them; the managed target drops the store and maps the deletion policy — but that translation happens in Plan/Implement.
Produce the source-IaC reference copy. Write a reference copy to
output_dirassource-iac.<ext>: the source unchanged except that it starts with a comment line "SOURCE — DO NOT DEPLOY" (for a format with no comments, such as JSON, put the marker in the file name:source-iac.DO-NOT-DEPLOY.json), and any inline secret is redacted to an ARN/placeholder. It is a copy of what you read, never a modification of the user's file. 5a. Cost signal — only whencost_analysis: enabled. See the cost analysis hook. 5b. Classify the non-KB resources in the source (buckets, collections or indexes, vector buckets, roles, policies, keys): for each, whether it stays (still used, including a bucket the new data source will read), becomes obsolete after cutover, or is untouched. The plan's decommission checklist is built from this list.Summarize per KB — produce the per-KB IaC discovery summary (the output shape below).
Whether the IaC is deployed comes from the user or the source, not from a search.
The user says it was never deployed, or the source shows it: scope that KB out. Say why, and write no target file for it.
Unknown, and no matching KB in the account you can reach: that proves nothing. The file may deploy into another account or Region than your credentials reach. Say "no matching KB found in account
<id>,<region>", ask where it runs, and keep migrating the file. Never report it as undeployed on that basis.
Exhaustive enumeration and loops
Enumerate every KB resource and every data-source resource; do not stop at the first. Two things are most often undercounted:
Resources generated by a loop. A CloudFormation
Fn::ForEach/AWS::LanguageExtensionsblock or a Terraformfor_each/countexpands to many data sources though it appears once in the file — count the collection, not the literal blocks. The real count is what the data-sources-per-KB quota applies to.Values from a variable / parameter whose concrete value is not in the file are
unknown— a discovery result to report, not a value to invent (e.g. an embedding ARN supplied by a.tfvarsvariable or a stack parameter).
Flag every no-managed-path feature found (custom_transformation Lambda, GraphRAG / context
enrichment, any connector with no managed equivalent) in
no_managed_path_flags — these drive exclusions in planning. (Salesforce, Zendesk and Confluence
Data Center are native managed connectors and are not flagged.)
Denial split (IaC path)
Classify by the exact action, not the service:
Source reads block. A denied
cloudformation:GetTemplateors3:GetObjectmeans there is no source to parse: endBLOCKED.Cost reads degrade. A denied
cloudwatch:*,s3:ListBucket,aoss:*,pricing:GetProductsorce:GetCostAndUsagecosts one figure: record the denied action, omit that figure, and still endCOMPLETE.
Both sides involve S3, so note that s3:GetObject is a source read and blocks, while s3:ListBucket
is a cost probe and does not — reading "an S3 denial" as one category is how a corpus-sizing failure
gets mistaken for an unreadable template.
Cost analysis hook
The cost analysis runs only if the Identify cost gate was enabled (cost_analysis: enabled);
when the gate was declined, run no cost probe on either path. The full procedure — the input
checklist, the measurement commands (including vector count and embedding dimension), the plausibility
check of any stated OCU count against AWS's published guidance, the scripted comparison, the fixed output
table and the branch table for missing telemetry — lives in
cost-analysis as Steps 0-9; run them in order
before producing any cost figure and never reason from a remembered price. On the KB path it runs against the live collection
(KB Step 6); on the IaC path it is narrower (IaC Step 5a) — a template declares intent, not usage, so
if the stack is not deployed, do not estimate.
The two denial classes are not symmetric: a source-read denial BLOCKS (the source model is
load-bearing), while a cost-read denial degrades and the phase stays COMPLETE — the cost
figure is omitted, the denied IAM action is named, and nothing downstream depends on it. Neither an
unmeasurable figure, a denied permission, nor a declined gate ever blocks COMPLETE.
Output shapes
These are the outputs the Discover phase produces — the fields the Plan phase consumes, as plain
data per KB. Each unreadable field is the string unknown.
KB path — one discovery summary per KB:
source_kb_id: <id> # a live KB has an AWS id
kb_name: <name>
kb_type: VECTOR
kb_status: <status>
role_arn: <arn>
embedding_model_arn: <arn>
embedding_dimensions: <n or model default> # read the model's default from its Bedrock model page
embedding_data_type: <FLOAT32 | BINARY>
vector_store: <type>
encryption: <aws-owned | cmk-arn>
data_sources: # enumerate EVERY data source
- id: <ds-id>
name: <name>
type: <S3 | CONFLUENCE | SHAREPOINT | WEB | CUSTOM | …>
chunking: <strategy>
chunking_params: { … }
parsing: <strategy or DEFAULT>
inclusion_prefixes: [ … ] # S3 only; absent otherwise
connector_auth: # auth connectors only; omit for S3/Web/Custom; ARN only
secret_arn: <arn>
authType: <type>
hostUrl | siteUrls | tenantId | domain: <…>
custom_transformation: <true | false>
last_ingestion: { status: <…>, documents: <n> }
no_managed_path_flags: [ … ] # custom_transformation | graphrag; [] when none
migratable: <true | false>
notes: <string, "" when empty>
cfn_source_template: <path to source-config.yaml | source-config-<kb-id>.yaml | inline-only>
cfn_managed_template: <path to managed-target.yaml | managed-target-<kb-id>.yaml | inline-only>IaC path — one discovery summary per KB (identified by logical_id, never source_kb_id, since
a declared template resource has no AWS id):
logical_id: <template logical id>
kb_name: <name, may hold a template expression such as ${NameSuffix}>
kb_type: VECTOR
vector_store: <type or unknown>
encryption: <aws-owned | cmk-arn>
embedding_model_arn: <arn or unknown>
embedding_dimensions: <n or unknown>
embedding_data_type: <FLOAT32 | BINARY | unknown>
iac_format: <cloudformation | terraform | cdk-synth>
iac_source_location: <local path | stack:<name> | s3://…>
data_sources: # enumerate EVERY data source, expanding loops
- logical_id: <id>
type: <connector type>
chunking: <strategy>
parsing: <strategy or DEFAULT>
deletion_policy: <DELETE | RETAIN>
connector_auth: { secret_arn: <arn> } # auth connectors only
no_managed_path_flags: [ … ] # migratable is false exactly when this is non-empty
migratable: <true | false>
declared_cost_shape: { standby_replicas, kms_key_shared_with, embedding_model } # declared, not measured
source_iac_copy: <path to source-iac.<ext> | inline-only>
notes: <string, "" when empty>The cost figures (when the gate was enabled) are recorded per KB by
cost-analysis and keyed by the same source_kb_id
(KB path) or logical_id (IaC path); the two must agree.
Scale and quota
Read these limits live from Service Quotas before stating them, never from memory (mapping §4 has the command and codes):
Self-managed: data sources per KB (
L-679D8304) and KBs per account per Region (L-60DA3E0D).Managed: data sources per KB (
L-F02D918A) and KBs per account per Region (L-5C7643AC).
Preserve topology by default; consolidation is an optional improvement, not something Discover
decides. The exhaustive per-DS count from enumeration (loops expanded) is what a later phase checks
against the managed data-sources-per-KB limit (L-F02D918A, read live).
Phase outcome
The phase ends in one of COMPLETE | NEEDS_INPUT | BLOCKED | FAILED:
COMPLETE — the path's required artifacts exist and are non-empty on disk (KB path: both templates per selected KB; IaC path:
source-iac.<ext>), every coverage item is captured or markedunknown, and the user confirmed. A declined cost gate, an unmeasurable cost figure, and a denied cost read all still allow COMPLETE.NEEDS_INPUT — relayed to the user: the target type or cost gate is unset, the source was not supplied, or multiple KBs exist and no scope was chosen. A chosen set is not
NEEDS_INPUT.BLOCKED — a configuration/source read was denied, or the source has no KB. Stops here.
FAILED — an unexpected failure. (Teardown of owned resources applies only to the Implement phase, which is the only phase that creates resources.)
Named outputs the Plan phase needs: the per-KB discovery summary above, and (KB path) source_kb_id,
vector_store, embedding_model, the data-source list, cfn_source_template /
cfn_managed_template; (IaC path) logical_id, iac_format, iac_source_location,
no_managed_path_flags. Plan branches on the same target type.
Common mistakes
Guessing the path or the cost gate instead of reading the value —
unsetisNEEDS_INPUT, not an implied yes. Running cost analysis on a declined session spends budget the user turned down; skipping it on an enabled one drops the most-requested part of discovery.Running any mutating command (
start-ingestion-job,terraform apply,cloudformation deploy,create-*) or a content-exposingretrieve"to check" — discovery is strictly read-only.Sampling only the first KB / data source — discovery is exhaustive; enumerate every one. On the IaC path, counting a loop as one resource is the same error: a
Fn::ForEachorfor_each/countblock declares as many data sources as its collection has entries.Filling in a value the source does not contain — an embedding ARN supplied by a
.tfvarsvariable or a stack parameter isunknown; never substitute a plausible ARN.Reporting COMPLETE with a missing required artifact — it blocks the whole pipeline; finish it or end
NEEDS_INPUT/BLOCKED.Editing or
terraform import-ing the source, or copying an inline secret intosource-iac.<ext>— the source is read-only; redact secrets to an ARN/placeholder.Pasting camelCase into CloudFormation, adding
StorageConfiguration, or hand-writing shapes from memory — follow iac-schema: CFN is PascalCase, the managed store is auto-provisioned, and enums come from the live schema.Dumping full JSON with secrets — summarize; ARNs only. Forgetting
--region— KBs are regional; a missing region yields empty results.
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