AWS Bedrock Chat Model

The AWS Bedrock Chat Model node allows you use LLM models utilising AWS Bedrock platform.

On this page, you'll find the node parameters for the AWS Bedrock Chat Model node, and links to more resources.

Credentials

You can find authentication information for this node here.

Parameter resolution in sub-nodes

Sub-nodes behave differently to other nodes when processing multiple items using an expression.

Most nodes, including root nodes, take any number of items as input, process these items, and output the results. You can use expressions to refer to input items, and the node resolves the expression for each item in turn. For example, given an input of five name values, the expression {{ $json.name }} resolves to each name in turn.

In sub-nodes, the expression always resolves to the first item. For example, given an input of five name values, the expression {{ $json.name }} always resolves to the first name.

Node parameters

Authentication: Select the authentication method:
- AWS (IAM): Use an IAM access key. Select an AWS credential.
- AWS (Assume Role): Temporarily assume an IAM role. Select an AWS (Assume Role) credential.
Model: Select the model that generates the completion.

Learn more about available models in the Amazon Bedrock model documentation.

Node options

Maximum Number of Tokens: Enter the maximum number of tokens used, which sets the completion length.
Sampling Temperature: Use this option to control the randomness of the sampling process. A higher temperature creates more diverse sampling, but increases the risk of hallucinations.
Top P: Set the probability threshold for token selection. A lower value limits the pool to more probable tokens; a higher value allows more diverse options.
Max Retries: Enter the maximum number of times to retry a request.
Additional Model Request Fields: Enter model-family-specific inference parameters as JSON, for example Claude's top_k or Nova's inferenceConfig. Refer to the AWS model parameters documentation for the parameters each model family supports.
Latency Optimization: Choose whether requests use Standard or Optimized latency. Optimized mode can reduce response time for supported models and regions. Refer to the AWS latency-optimized inference documentation for availability.
Guardrail: Apply an Amazon Bedrock guardrail to requests. Refer to Using AWS Guardrails for details.

Using AWS Guardrails

Guardrails let your organization enforce content and safety policies on model invocations. The guardrail must exist in the same AWS region as the model. The Guardrail option has these fields:

Guardrail Identifier: The ID or full ARN of the guardrail to apply.
Guardrail Version: The guardrail version to use: a numeric version string (for example 1) or DRAFT for the working draft. Defaults to DRAFT.
Trace: Whether AWS includes diagnostic trace information about the guardrail's evaluation in the response: Disabled (default), Enabled, or Enabled (Full). Note: enabling trace makes AWS include guardrail assessment details (which can echo matched input content, e.g. PII findings) in responses; n8n doesn't currently surface these in the AI log.

When a guardrail intervenes, the node returns the guardrail's configured blocked message in place of the model output, as a normal response rather than an error. n8n doesn't expose the underlying stop reason: to detect an intervention downstream, match on your guardrail's blocked message text. An invalid guardrail identifier or version fails the node with the AWS validation error. Guardrails apply to both streaming and non-streaming requests.

IAM permissions

The credential needs the bedrock:ApplyGuardrail permission on the guardrail resource in addition to the invoke permissions. Without it, requests fail with an AccessDeniedException once a guardrail is set. If your organization requires guardrails on every invocation, enforce the bedrock:GuardrailIdentifier condition key on invoke permissions in IAM rather than relying on this optional node field.