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/iac-schema.md
IaC Schema Reference — Bedrock Knowledge Bases (CloudFormation + Terraform)
Schema facts for the Infrastructure-as-Code that describes a Bedrock Knowledge Base, in both supported formats: CloudFormation (
AWS::Bedrock::KnowledgeBase+AWS::Bedrock::DataSource) and Terraform (aws_bedrockagent_knowledge_base+aws_bedrockagent_data_source). The single source of truth for resource types, how to verify the live schema, the accepted Managed KB (MANAGED) vs self-managed KB (VECTOR; the host skill calls this a Customer-managed KB) shapes per format, and the public doc links. Both the KB path's discovery templates (the Discover phase emitssource-config.yaml+managed-target.yaml) and the IaC path's output (the Implement phase emitsmanaged-target.<ext>) are built from these facts.Use this file for schema/shape facts; use mapping for the substitution rules (what each setting becomes) and managed KB API for the camelCase API field names and accepted/rejected values that the IaC properties wrap.
Reading the public docs. Read every AWS/CloudFormation and Terraform doc read-only, per safety-and-iam. AWS/CloudFormation:
curlthe.mdendpoint. Terraform: the authoritative source of record is the HashiCorp Terraform Registry page for the AWS provider (links in §3–§4), but it is JS-rendered, socurlits plain-text twin — the provider's raw GitHub Markdown, identical content — instead. Do not download the Terraform provider to check it (§0); if the user runsterraform providers schema -jsonthemselves, its output wins on any conflict.
Contents
0. Verify the live schema before generating a template
1. CloudFormation — resource types and the source (
VECTOR) shape2. CloudFormation — the MANAGED target shape
3. Terraform — resource types and the source (
VECTOR) shape4. Terraform — the MANAGED target shape
5. Cross-format notes
Common mistakes
0. Verify the live schema before generating a template — don't trust memory
Both schemas evolve; do not rely on memory or a hardcoded enum. Before writing or updating any template, confirm the current schema with the format-appropriate read-only command, and take the accepted type/enum values and property/argument names from its output.
CloudFormation (aws cloudformation describe-type, read-only):
aws cloudformation describe-type --type RESOURCE \
--type-name AWS::Bedrock::KnowledgeBase --region <region> --query 'Schema' --output text
aws cloudformation describe-type --type RESOURCE \
--type-name AWS::Bedrock::DataSource --region <region> --query 'Schema' --output textTerraform: do not run a local schema check. terraform providers schema -json and
terraform validate need terraform init, which downloads the AWS provider (a large download) — too
heavy for a migration review, and it reads the user's global Terraform configuration. Take argument
names from the documented shapes in §3–§4 (the registry's raw GitHub Markdown, per the note above),
record schema_valid: unverified for the Terraform file, show the user a diff -u of the source file
against the migrated one, and give them the command to run before they deploy:
diff -u main.tf "$output_dir/managed-target.tf" # the review artifact; read-only
# for the user to run before deploy, not the agent:
terraform init -backend=false && terraform validateRecord the verification outcome — and never upgrade an unverified shape to a verified one. The
result of §0 is one of exactly three states, and it is what the Implement phase reports as
schema_valid:
| Outcome | schema_valid | What it means |
|---|---|---|
| The check ran and the emitted shapes match | verified | Safe to present as deployable |
| The check ran and found a violation | invalid | Report the offending resource/property, withhold from the deployable set |
| The check could not run (tool absent, no credentials, no provider, region unsupported) | unverified | Say which command was unavailable and why. The template is documented-shape only — present it as needing the user's own validation before deploy. It is not verified |
If terraform or the AWS CLI is not installed, the honest answer is unverified, not true. And if either
live schema disagrees with this file, trust the live schema, generate from it, and update this reference
with the new finding.
What the live schema cannot check. ConnectorParameters / connector_parameters is declared free-form
in both formats (proof in §2), so describe-type, cfn-lint, terraform validate and
--generate-cli-skeleton all accept any content inside it. That one block is validated only by the
service at create time, and managed KB API is its
authority — §0 verification tells you nothing about it.
1. CloudFormation — resource types and the source (VECTOR) shape
Both VECTOR and MANAGED knowledge bases use the same two resource types
(AWS::Bedrock::KnowledgeBase + AWS::Bedrock::DataSource) and are CloudFormation-deployable.
Build a source (VECTOR) template with KnowledgeBaseConfiguration.Type: VECTOR +
VectorKnowledgeBaseConfiguration, the discovered StorageConfiguration block, the matching
data-source connector block, and the chunking/parsing config — translating camelCase API fields to
PascalCase CFN properties (the CLI/JSON shapes in
managed KB API are camelCase).
AWS::Bedrock::KnowledgeBase — https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-bedrock-knowledgebase.html
AWS::Bedrock::DataSource — https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-bedrock-datasource.html
2. CloudFormation — the MANAGED target shape
Set KnowledgeBaseConfiguration.Type: MANAGED with a ManagedKnowledgeBaseConfiguration, and set the
data source's DataSourceConfiguration.Type: MANAGED_KNOWLEDGE_BASE_CONNECTOR with a
ManagedKnowledgeBaseConnectorConfiguration. Omit StorageConfiguration — the managed store is
auto-provisioned, and there is no StorageConfiguration on a Managed KB. Apply
mapping for the source-type substitutions and the managed
runtime limits a schema-valid template must still satisfy.
⚠️ The one place CloudFormation is NOT PascalCase
CloudFormation property names are PascalCase — except inside ConnectorParameters, which is a
free-form pass-through whose keys are the camelCase API names. The live schema is explicit that
nothing inside it is modelled:
"ManagedKnowledgeBaseConnectorConfiguration": {
"type": "object", "additionalProperties": false,
"properties": {
"DeletionProtectionConfiguration": { "$ref": "#/definitions/DeletionProtectionConfiguration" },
"MediaExtractionConfiguration": { "$ref": "#/definitions/MediaExtractionConfiguration" },
"ConnectorParameters": { "type": "object", "description": "Connector-specific parameters." }
}
}ConnectorParameters has no properties and no additionalProperties: false — CloudFormation
passes the object through to CreateDataSource verbatim. Consequences, all verified:
Type: S3/Version: "1"/ConnectionConfiguration/BucketName/InclusionPrefixesinside this block are wrong. The correct keys aretype,version,connectionConfiguration,bucketName,inclusionPrefixes— from managed KB API §2/§2b.No tool catches the mistake.
describe-type,cfn-lint,validate-templateand--generate-cli-skeleton(which returnsconnectorParameters: {}) all pass a PascalCased blob. It fails at deploy, against the live service.The wrappers around it are PascalCase and are schema-checked:
DeletionProtectionConfigurationandMediaExtractionConfigurationare siblings ofConnectorParameters, insideManagedKnowledgeBaseConnectorConfiguration. Putting either on the data source'sPropertiesis a hard schema error (additionalProperties: false).
Canonical managed CloudFormation shape — copy this structure
Resources:
MyKnowledgeBaseManaged:
Type: AWS::Bedrock::KnowledgeBase
Properties:
Name: my-kb-managed
RoleArn: !GetAtt KbExecutionRoleManaged.Arn
# Tags is a MAP (TagsMap), not a list of Key/Value pairs:
Tags: { Workload: docs }
KnowledgeBaseConfiguration:
Type: MANAGED
ManagedKnowledgeBaseConfiguration:
# EmbeddingModelType enum is exactly [MANAGED, CUSTOM]. "DEFAULT"/"MANAGED_DEFAULT" do not
# exist. MANAGED = service-managed model, no ARN, keeps the reranker. For CUSTOM, add
# EmbeddingModelArn + EmbeddingModelConfiguration.BedrockEmbeddingModelConfiguration
# { Dimensions: <MANAGED_DIMENSION>, EmbeddingDataType: FLOAT32 } — the only accepted values
# (the managed dimension is on the create page; see mapping Key findings).
EmbeddingModelType: MANAGED
ServerSideEncryptionConfiguration:
KmsKeyArn: !Ref CorpusKmsKeyArn # KB-level CMK; there is no per-data-source SSE
# NO StorageConfiguration.
MyDataSourceManaged:
Type: AWS::Bedrock::DataSource
Properties:
Name: my-corpus-managed
KnowledgeBaseId: !GetAtt MyKnowledgeBaseManaged.KnowledgeBaseId
DataSourceConfiguration:
Type: MANAGED_KNOWLEDGE_BASE_CONNECTOR
ManagedKnowledgeBaseConnectorConfiguration:
# >>> camelCase from here down — free-form pass-through to the API <<<
ConnectorParameters:
type: S3
version: "1"
connectionConfiguration:
bucketName: !Ref CorpusBucketName
bucketOwnerAccountId: !Ref AWS::AccountId
filterConfiguration:
inclusionPrefixes:
- published/en/
# <<< back to PascalCase: schema-checked siblings of ConnectorParameters >>>
DeletionProtectionConfiguration:
DeletionProtectionStatus: ENABLED # secure default; set DISABLED only on explicit customer opt-out
# DeletionProtectionThreshold: omitted = the service default (API reference has the range)
# MediaExtractionConfiguration: # the managed home for image/audio/video extraction
# ImageExtractionConfiguration: { ImageExtractionStatus: ENABLED }
# VectorIngestionConfiguration: omit it entirely on a managed-embedding KB — any
# ChunkingConfiguration (even FIXED_SIZE/NONE) is rejected with
# "A chunking strategy cannot be specified with a managed embedding model".
# ONLY with a CUSTOM embedding model may you carry FIXED_SIZE/NONE over, e.g.:
# VectorIngestionConfiguration:
# ChunkingConfiguration:
# ChunkingStrategy: FIXED_SIZE # custom-embedding KB only; SEMANTIC/HIERARCHICAL rejected
# FixedSizeChunkingConfiguration: { MaxTokens: <FROM_SOURCE>, OverlapPercentage: <FROM_SOURCE> }
# No ParsingConfiguration (managed forces SMART_PARSING), no DataDeletionPolicy, no
# ServerSideEncryptionConfiguration at this level.For a source whose original chunking was SEMANTIC or HIERARCHICAL, omit the whole
ChunkingConfiguration block — the managed default applies (see
mapping); do not translate an unsupported strategy.
The same omission is required whenever the KB uses the managed embedding model, whatever the
source strategy was: a chunking block is accepted only on a custom-embedding KB.
!GetAtt <kb>.KnowledgeBaseId and .KnowledgeBaseArn are the readable attributes. Name is not
a GetAtt attribute — the full read-only set is KnowledgeBaseId, KnowledgeBaseArn, CreatedAt,
UpdatedAt, FailureReasons, Status.
AWS::Bedrock::KnowledgeBase — https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-bedrock-knowledgebase.html
AWS::Bedrock::KnowledgeBase ManagedKnowledgeBaseConfiguration — https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-bedrock-knowledgebase-managedknowledgebaseconfiguration.html
AWS::Bedrock::DataSource — https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-bedrock-datasource.html
Create-only properties (from the live schema) — why this is a new resource, not an update
A VECTOR KB cannot be converted to MANAGED in place. AWS::Bedrock::KnowledgeBase declares
StorageConfiguration, KnowledgeBaseConfiguration/Type and
KnowledgeBaseConfiguration/ManagedKnowledgeBaseConfiguration as create-only, and
AWS::Bedrock::DataSource declares KnowledgeBaseId, DataSourceConfiguration/Type,
VectorIngestionConfiguration/ChunkingConfiguration and .../ParsingConfiguration as create-only.
Changing any of them replaces the resource. Two consequences to state in the plan rather than discover at deploy time: the managed KB is a new resource with a new ID (so every consumer holding the old KB ID must be repointed), and for a template consumers instantiate themselves — a Service Catalog product, a shared module, a nested stack — an in-place update is impossible, so existing instances must be re-launched, not updated.
3. Terraform — resource types and the source (VECTOR) shape
The AWS Terraform provider (hashicorp/aws) models a KB with aws_bedrockagent_knowledge_base
and each data source with aws_bedrockagent_data_source. Argument names are snake_case. A source (VECTOR) KB looks like:
resource "aws_bedrockagent_knowledge_base" "example" {
name = "example"
role_arn = aws_iam_role.example.arn
knowledge_base_configuration {
type = "VECTOR"
vector_knowledge_base_configuration {
embedding_model_arn = "arn:aws:bedrock:<region>::foundation-model/<model>"
}
}
storage_configuration {
type = "OPENSEARCH_SERVERLESS" # or aurora / pinecone / s3_vectors / opensearch_managed_cluster ...
opensearch_serverless_configuration { collection_arn = "..." vector_index_name = "..." field_mapping { ... } }
}
}A data source's chunking lives under vector_ingestion_configuration { chunking_configuration { chunking_strategy = "FIXED_SIZE" fixed_size_chunking_configuration { max_tokens overlap_percentage } } }.
There is no parsing_configuration to emit on managed (Smart Parsing is applied automatically). Emit a
chunking_configuration block only when the KB uses a custom embedding model; on a managed-embedding KB omit it entirely (any strategy is rejected —
see mapping).
Provider docs — trusted public source (Terraform Registry), plus the curl-able twin to fetch it:
aws_bedrockagent_knowledge_base— Terraform Registry (authoritative source of record): https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/bedrockagent_knowledge_baseaws_bedrockagent_data_source— Terraform Registry (authoritative source of record): https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/bedrockagent_data_sourcePlain-text twin to
curl(the Registry page is JS-rendered — this is the same content, fetchable):aws_bedrockagent_knowledge_base: https://raw.githubusercontent.com/hashicorp/terraform-provider-aws/main/website/docs/r/bedrockagent_knowledge_base.html.markdownaws_bedrockagent_data_source: https://raw.githubusercontent.com/hashicorp/terraform-provider-aws/main/website/docs/r/bedrockagent_data_source.html.markdown
4. Terraform — the MANAGED target shape
The provider supports the managed KB directly in recent hashicorp/aws versions: in the provider schema
aws_bedrockagent_knowledge_base.knowledge_base_configuration exposes
managed_knowledge_base_configuration and aws_bedrockagent_data_source.data_source_configuration
exposes managed_knowledge_base_connector_configuration. Read the first version that adds these blocks from the
provider's CHANGELOG (https://github.com/hashicorp/terraform-provider-aws/blob/main/CHANGELOG.md, search
managed_knowledge_base) and say that minimum version in the output — older provider versions lack it.
Suggest terraform fmt alongside terraform validate to the user. The agent does not
check the installed version (§0): the shape is unverified, and the user's own terraform validate
is what confirms it.
managed_knowledge_base_configuration accepts exactly: embedding_model_arn, embedding_model_type,
a nested embedding_model_configuration { bedrock_embedding_model_configuration { dimensions, embedding_data_type, audio { … }, video { … } } }, and
server_side_encryption_configuration { kms_key_arn }. There is no storage_configuration inside it.
Managed KB — type = "MANAGED" with a managed_knowledge_base_configuration block, and no
storage_configuration (auto-provisioned). embedding_model_type = "MANAGED" is the service-managed
model and keeps the managed reranker. Carry the source KB's CMK forward in
server_side_encryption_configuration.kms_key_arn (see
managed KB API "Encryption at rest"); omit that block
only when the customer accepts the AWS-owned default, and never silently drop a CMK the source KB was
using:
resource "aws_bedrockagent_knowledge_base" "example" {
name = "example-managed-kb"
role_arn = aws_iam_role.example.arn
knowledge_base_configuration {
type = "MANAGED"
managed_knowledge_base_configuration {
embedding_model_type = "MANAGED"
server_side_encryption_configuration {
kms_key_arn = var.kb_kms_key_arn
}
}
}
}Bring-your-own embedding uses embedding_model_type = "CUSTOM" with embedding_model_arn and
embedding_model_configuration { bedrock_embedding_model_configuration { dimensions = <MANAGED_DIMENSION> } }
(the managed dimension / FLOAT32 only, per the create page; CUSTOM disables the managed reranker — see
mapping).
Managed data source — type = "MANAGED_KNOWLEDGE_BASE_CONNECTOR" with a
managed_knowledge_base_connector_configuration block. In the provider schema
connector_parameters is typed "string", not a block or a map — so jsonencode({...}) is
mandatory, not a style choice, and its keys are the API camelCase names (type, version,
connectionConfiguration, aclEnabled, filterConfiguration, secretArn, siteUrls, …) exactly as
documented in managed KB API, embedded as JSON
inside the snake_case HCL.
The other two members of managed_knowledge_base_connector_configuration are nested HCL blocks,
siblings of connector_parameters — not keys inside the jsonencode:
| Member | Form | Contents |
|---|---|---|
connector_parameters | string argument (jsonencode({...})) | free-form camelCase connector body |
deletion_protection_configuration { } | HCL block | deletion_protection_status (required), deletion_protection_threshold (optional number) |
media_extraction_configuration { } | HCL block | image_extraction_configuration { image_extraction_status }, audio_extraction_configuration { … }, video_extraction_configuration { … } |
Putting deletionProtectionConfiguration inside the jsonencode blob is a silent failure: the
provider accepts the string, and the deletion-protection setting is never applied.
resource "aws_bedrockagent_data_source" "example" {
knowledge_base_id = aws_bedrockagent_knowledge_base.example.id
name = "example-s3-managed"
data_source_configuration {
type = "MANAGED_KNOWLEDGE_BASE_CONNECTOR"
managed_knowledge_base_connector_configuration {
# camelCase inside the jsonencode — this string is passed to the API verbatim.
connector_parameters = jsonencode({
type = "S3"
version = "1"
connectionConfiguration = { bucketName = "<bucket>", bucketOwnerAccountId = "<account-id>" }
aclEnabled = false
# filterConfiguration = { inclusionPrefixes = [...] } # carry the source's prefixes/patterns; omit maxFileSizeInMegaBytes to keep the service default
})
# snake_case HCL blocks — SIBLINGS of connector_parameters, never keys inside it.
deletion_protection_configuration {
deletion_protection_status = "ENABLED" # secure default; set "DISABLED" only on explicit customer opt-out
# deletion_protection_threshold omitted = the service default (API reference has the range)
}
# media_extraction_configuration {
# image_extraction_configuration { image_extraction_status = "ENABLED" }
# }
}
}
# Omit chunking on a managed-embedding KB — any chunking_configuration is rejected there.
# A chunking_configuration is valid only with a custom embedding model.
# No parsing_configuration on managed: Smart Parsing is applied automatically.
}Auth connectors (SharePoint/Confluence/OneDrive) set their fields inside the same jsonencode
connectionConfiguration / dataEntityConfiguration objects (secretArn, tenantId, authType,
siteUrls as a list, certificateS3Path, …) exactly as in
managed KB API §2b — the secret is referenced by
ARN only. name and knowledge_base_configuration force a new resource (create-only),
consistent with the CFN create-only note.
5. Cross-format notes
Same resources, two encodings. The field names differ (CFN PascalCase; Terraform snake_case HCL), but the values, enums, and managed rules are identical and come from managed KB API + mapping. Never hand-write a shape from memory in either format — verify with §0.
The connector body is the one part that is byte-identical in both formats, because both
ConnectorParametersandconnector_parametersare free-form pass-throughs carrying the same camelCase API object. The surrounding convention never applies inside it.MANAGED is create-only in both. A
VECTORKB is never converted in place; the managed KB is a new resource (a new logical ID / resource address).The managed store is never declared. Omit CFN
StorageConfiguration/ Terraformstorage_configurationon a managed KB.Scale limits are quotas, not schema. Data sources per KB and KBs per account per Region differ between self-managed and managed; read both live from Service Quotas (mapping §4) before execution. Preserve topology by default; consolidation is an optional improvement.
Common mistakes
PascalCasing the connector body. The most common translation error on this path: it looks correct, every offline validator (
describe-type,cfn-lint,terraform validate,--generate-cli-skeleton) accepts it, and only the live service rejects it at create time. InsideConnectorParameters/connector_parameters, keys are camelCase API names.Treating Terraform
connector_parametersas a block/map. It is typedstring;jsonencode({...})is mandatory.Putting
deletion_protection_configuration/media_extraction_configurationinside thejsonencodeblob. They are sibling HCL blocks (Terraform) / PascalCase siblings (CFN); nesting them in the connector body is a silent no-op.Declaring
StorageConfigurationon a managed KB; translating a SEMANTIC/HIERARCHICAL chunking strategy instead of omittingchunkingConfiguration; or emitting anychunkingConfiguration(evenFIXED_SIZE/NONE) on a managed-embedding KB — it is rejected with "A chunking strategy cannot be specified with a managed embedding model"; omit the block unless the KB uses a custom embedding model.Reporting an
unverifiedshape asverified. If §0 could not run, say which command was unavailable; the template is documented-shape only.Expecting an in-place
VECTOR→MANAGEDupdate. Create-only properties force resource replacement: a new KB ID and re-launched instances for consumer-instantiated templates.
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