Amazon Bedrock LLM Processor (Beta)

This processor Micro-Integration consumes events from an event broker service, forwards them to an LLM, and then publishes the augmented events back to the event broker service.

At the Micro-Integration level, you must configure the connection parameters for your event broker service and LLM. For more information, see Micro-Integration Parameters.

You must also define one Micro-Integration Flow that specifies the endpoints where data is consumed from and published to. For more information, see Micro-Integration Flow Parameters.

This Micro-Integration supports only custom header mapping. Payload mapping is not supported.

Micro-Integration Parameters

For detailed information about connecting to your event broker service, see Event Broker Service Connection Parameters.

The following table describes the parameters for configuring an Amazon Bedrock LLM processor Micro-Integration.

   
Amazon Bedrock LLM Connection Details
AWS Region The AWS Region.

Authentication Scheme

The authentication scheme to use when connecting to Amazon Bedrock. One of:

  • AWS Access Key—Additional configuration is required. For more information, see Access Key.

  • AWS Chained IAM Role Assumption—Additional configuration is required. For more information, see Chained IAM Role Assumption.

Authentication using AWS Chained IAM Role Assumption is supported only for event brokers hosted on AWS.

Model ID The specific version or name of the LLM to use. For example: bedrock/anthropic.claude-3-5-sonnet-20240620-v1:0
Inference Profile ARN

The Bedrock application inference profile ARN. For example, arn:aws:bedrock:us-east-2:<account-id>:inference-profile/us.anthropic.claude-3-5-sonnet-20240620-v1:0

Refer to the AWS Console for Bedrock to find the inference profile ARN for your account and model.

User Prompt

A template for the user prompt to request a particular response from the model. Use the {{text://input.payload}} placeholder to include the message payload in the prompt.

For example:

  • You are a helpful AI assistant. Please summarize the information within the <content> tags: <content> {{text://input.payload}}</content>

  • You are a senior customer support specialist. Score the comments in the <content> tags on a scale of 1 (very negative) to 5 (very positive): <content> {{text://input.payload}}</content>

Max Tokens The max_tokens hyperparameter, which controls the maximum length of the LLM's response.
Temperature The temperature hyperparameter, which controls the randomness of the LLM's output. Valid values are between 0.0 and 1.0.

Access Key

Field Description
AWS Access Key An access key identifier.
AWS Secret Key The secret key associated with the AWS Access Key.

Chained IAM Role Assumption

Chained IAM role assumption allows Micro-Integrations to securely access AWS resources across different AWS accounts without requiring direct credential exchange. Chained IAM role assumption works through a trust relationship between AWS accounts:

  • The resource owner creates an IAM role (solace-mi-workload-role) in their AWS account, and configures it with the specific permissions required.

  • This role is configured to trust the Solace AWS account's role (single-pod-identity-role in account 718462147973).

  • When a Micro-Integration needs to access the resource, it uses the trust chain to temporarily assume the necessary permissions, as follows:

    [Assume single-pod-identity-role] → [Get credentials to assume solace-mi-workload-role] → 
[Assume solace-mi-workload-role] → [Get credentials to access the target vendor resource] → 
[Access the resource]

The resource owner must do the following:

  1. Create a role called solace-mi-workload-role in the resource owner's AWS account and attach the following trust policy:

    {
  "Version":"2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Principal":{
      "AWS":"arn:aws:iam::718462147973:role/single-pod-identity-role"
     },
    "Action":[
     "sts:TagSession",
     "sts:AssumeRole"
     ]
  }]
}

  2. Attach the required resource permissions to the solace-mi-workload-role. The minimum required permissions are:

    • bedrock:InvokeModel

    • bedrock:InvokeModelWithResponseStream

The following table describes the parameters for configuring authentication using chained IAM role assumption.

Field Description
AWS Account ID  The 12-digit AWS Account ID to be used for IAM role assumption. This is the account where the solace-mi-workload-role exists.
Session Name

The session name to use for the assumed role session (defaults to solace-mi-workload-session if not provided).
External ID

An optional external ID to use if the resource owner's trust policy requires it.

To configure it, the resource owner must separate the sts:TagSession and sts:AssumeRole into different statements in the solace-mi-workload-role trust policy and add the following condition to the sts:AssumeRole statement:

"Condition":{
  "StringEquals":{
    "sts:ExternalId":"<your_external_id_string>"
   }
 }

Micro-Integration Flow Parameters

You must configure the endpoint parameters for the Micro-Integration Flow.

Source Endpoint

Field Description
Endpoint Type

Select TOPIC_ENDPOINT or QUEUE to specify the type of endpoint to receive from.
Queue Name

The name of the queue to receive from. Endpoint Type must be QUEUE.
Topic Name

The name of the topic endpoint to consume from. Endpoint Type must be TOPIC_ENDPOINT.
Message Selector For the event broker service as the source, enables message filtering per endpoint.

Target Endpoint

Field Description
Destination Type

The destination type to send AI responses to. Select TOPIC or QUEUE.

Create the required queue on your event broker service if you haven't done so already. For more information, see Creating Event Broker Services.
Destination Name The name of the queue or topic to publish AI responses to.