Connecting AWS Bedrock to n8n: credentials, Claude models and RAG

For a team already running on AWS — infrastructure, committed spend, IAM governance already in place — routing AI calls through Amazon Bedrock instead of a standalone Anthropic or OpenAI API key changes the equation: one contract, one invoice, the same security rules as the rest of the infrastructure. Bedrock gives access to Claude, Amazon's Titan family, Llama and Mistral behind a single API, hosted in the AWS region of your choice. n8n integrates Bedrock natively through a dedicated LangChain sub-node. The part that catches most people off guard the first time: authentication goes through a full AWS credential (key, role to assume, region), and each model has to be explicitly authorized before it can be called. This guide walks through both, from the AWS console to your first AI agent in n8n.

Why Bedrock instead of a direct API key

If your workflows already use Claude or GPT through the standard nodes (see our Claude/GPT in n8n guide), Bedrock answers needs specifically tied to existing AWS infrastructure:

• Unified billing and commitment. Token consumption is added to your AWS bill and counts toward any spend commitment already negotiated (Savings Plan, EDP) — no separate credit card for each model provider.
• IAM instead of plain-text API keys. Access is governed with the same roles, policies and CloudTrail logs as the rest of your AWS infrastructure, including temporary access via an assumed role instead of a static key to rotate by hand.
• Data residency by region. A request sent to Bedrock from an AWS region is processed within that region; no data is used to retrain the underlying models, a point legal teams often require.
• A single access point for several model families. Switching a given use case from Claude to Titan or Llama changes neither the contract, the credential, nor the billing — only the model field on the node.

That pay-as-you-go billing logic, with no capacity reserved upfront, is exactly what a qualitative study by Muhammad Hamza, Muhammad Azeem Akbar and Rafael Capilla confirms ("Understanding Cost Dynamics of Serverless Computing: An Empirical Study", 2024 — see on Google Scholar), based on interviews with 15 experts from 8 companies that migrated to serverless architectures: teams gain budget flexibility (strictly pay-per-use) but need to actively monitor variable costs, or the bill can drift faster than with reserved infrastructure. A useful reminder for Bedrock, which is billed on exactly that model.

Step 1: enable model access in the Bedrock console

Unlike OpenAI or Anthropic direct, an AWS account has access to no Bedrock model by default: each model must be explicitly unlocked.

1. In the AWS console, open Amazon Bedrock → Model access.
2. Click Modify model access, check the models you want (say, Anthropic's Claude, or an Amazon Titan model) and confirm. Some third-party models get approved instantly, others ask for a use-case justification.
3. Make sure the activation was done in the region you plan to use in n8n: model access is managed region by region, and a model enabled in one region isn't automatically enabled in another.

Skip this step and every call from n8n fails with an access-denied error, even with a correctly configured credential and IAM permissions otherwise.

Step 2: the AWS credential in n8n

In n8n, Credentials → Add credential → AWS. Two ways to authenticate:

• Access Key ID / Secret Access Key: the most direct route, using a classic IAM key dedicated to n8n. Add the Region (the one where you enabled models in the previous step).
• Assume Role, for temporary multi-account access: an IAM user or role with permission to assume a target role supplies an STS Access Key ID / Secret Access Key, the target role's Role ARN (format arn:aws:iam::123456789012:role/MyRole), and optionally an External ID to avoid the "confused deputy" problem. An optional Session token rounds this out for temporary credentials.

On the AWS Bedrock Chat Model node, two extra endpoint fields appear: Bedrock Endpoint (used to list available models) and Bedrock Runtime Endpoint (used for actual inference). Leave both blank in standard use; only fill them in if Bedrock traffic routes through a VPC interface endpoint (PrivateLink) without private DNS.

As with any AI credential, apply least privilege: an IAM policy scoped to the ARNs of the models actually in use, never a blanket Bedrock access grant for convenience. Our guide to securing API credentials in n8n covers rotation and per-environment separation, directly applicable here.

Step 3: the AWS Bedrock Chat Model node

Like its Anthropic or Azure OpenAI counterparts, this is a LangChain sub-node: it doesn't run on its own, it plugs in as the language model of a parent node.

Chat Trigger ──▶ AI Agent ──▶ Response
                   │
                   ├── AWS Bedrock Chat Model  (AWS credential)
                   │     Model: anthropic.claude-3-5-sonnet-...
                   └── Tools (HTTP Request, Vector Store…)

1. Add an AI Agent (or a Basic LLM Chain for a simple call without tools) — see our complete guide to the AI Agent node for the general mechanics.
2. Attach an AWS Bedrock Chat Model with your AWS credential.
3. Pick the model from the list, or type its Bedrock identifier directly (format provider.model-name-version).
4. Set Maximum Number of Tokens, Sampling Temperature and Top P as on other n8n chat model nodes.

A common pitfall with the most recent Claude models: the raw model ID returns an "On-demand throughput isn't supported" error, because these models require an inference profile rather than direct on-demand access. The fix: switch the Model field to Expression mode and enter the inference profile ID for your region (typically prefixed with a region code) instead of the bare model ID.

Embeddings AWS Bedrock for RAG

The Embeddings AWS Bedrock node uses the same credential and generates vectors — via Titan Embeddings or another embeddings model available on Bedrock — to plug into n8n's vector store nodes, exactly like OpenAI or Azure embeddings. It's the key component for a RAG pipeline entirely hosted under an AWS contract: document ingestion, vector indexing and answer generation all go through the same access point and the same billing. Our RAG with Supabase pgvector guide still holds as-is on the storage side; only the embeddings node changes. That's exactly the architecture behind the RAG Assistant Pack, adaptable to Bedrock by simply swapping the embeddings and chat model sub-nodes.

Common errors and how to diagnose them

• AccessDeniedException: the model isn't enabled in Model access for the configured region, or the IAM policy behind the credential doesn't grant bedrock:InvokeModel (and bedrock:InvokeModelWithResponseStream for streaming) on the called model's ARN. Check both, in the same region.
• ValidationException — on-demand throughput isn't supported: use the inference profile ID rather than the raw model ID, in Expression mode on the Model field.
• Model missing from n8n's list: the credential points to a region where AWS simply doesn't offer that model; switch region on the credential or pick a model available locally.
• 429 / rate limiting: Bedrock applies rate quotas per model and per account, adjustable on request in the Service Quotas console. The same n8n patterns apply as for any other provider — our guide to AI API rate limits covers Loop Over Items, Wait and honoring the retry header.

Production best practices

• IAM scoped by use case. One role or policy per use case (support agent, document extraction, internal RAG) rather than broad Bedrock access: an incident on one workflow doesn't compromise the others.
• Tag and track costs. AWS Cost Explorer lets you tag Bedrock calls by project; combine it with tracking on the n8n side to attribute cost precisely to each workflow, as described in our method for tracking AI call costs.
• Have a fallback plan. A regional incident or a saturated quota on a Bedrock model is still possible; the multi-provider fallback pattern works as well between two Bedrock models as between Bedrock and an external provider — a particularly relevant safety net for the compliance and audit pipelines in the Compliance & Audit Pack, where a silent interruption is never an option.
• Assume Role instead of static keys as soon as several AWS accounts or environments (dev/prod) are involved: rotation becomes automatic and nothing sensitive sits in n8n beyond the session's lifetime.

Key takeaways

• AWS Bedrock gives access to Claude, Titan, Llama and Mistral under a single AWS contract, with IAM governance and data residency by region.
• Each model must be explicitly enabled in Model access (Bedrock console), region by region, before n8n can call it.
• n8n's AWS credential accepts either a classic key or an Assume Role setup (Role ARN, External ID, Session token) for temporary multi-account access.
• The AWS Bedrock Chat Model node plugs into an AI Agent or a Basic LLM Chain; recent Claude models often require an inference profile rather than a raw model ID.
• The Embeddings AWS Bedrock node covers RAG with the same credential, for a pipeline entirely hosted under an AWS contract.