Configuring Connection Details

This section provides instructions for configuring the connection details required to establish communication between the connector and your third-party system.

For information about configuring the connection to the event broker, see Connecting to Your Event Broker.

The name of the binder for Amazon SQS is sqs.

Amazon SQS Connection Details

We assume that you are familiar with the Spring Cloud AWS Credentials. However, the steps that follow help you to connect to AWS services without in-depth knowledge.

In addition to authentication credentials, the AWS client libraries also require setting a property for the AWS cloud region using "spring.cloud.aws.region.xxx" properties. AWS credentials are valid in a context of a region.

There are several options for configuring the connection details:

• Automatic Credential Discovery

• Access Key and Secret Key

• Chained IAM Roles Assumption

Automatic Credential Discovery

By default, the Spring Cloud AWS starter automatically configures a DefaultCredentialsProvider, which looks for AWS credentials in this order:

1. Java System Properties—aws.accessKeyId and aws.secretAccessKey

2. Environment Variables—AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

3. Web Identity Tokens—The credentials from system properties or environment variables

4. Credential Profiles Files—The default location is at ~/.aws/credentials, which is shared by all AWS SDKs and the AWS CLI.

5. Amazon EC2 Container Services—The credentials delivered through the Amazon EC2 container service if the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable is set and security manager has permission to access the variable.

6. Instance Profile Credentials—These credentials are delivered through the Amazon EC2 metadata service.

Access Key and Secret Key

You can manually specify an AWS Access Key and Secret Key through the application configuration, which uses the Spring Cloud AWS authentication libraries.

You can set the cloud.aws.credentials.xxx as well as cloud.aws.region.xxx in application.yml. For more details about these configuration options, see:

• the AWS Credentials section of the Spring Cloud AWS Core documentation

• the Regions, Availability Zones, and Local Zones section in the Amazon Relational Database Service User Guide

Follow the example below to set the Access Key and Secret Key:

spring:
  cloud:
    aws: # SqsTemplate configuration
      credentials:
        access-key: <aws credentials/access key> #Specifies the access key
        secret-key: <aws credentials/secret key> #Specifies the secret key
    region:
        static: us-east-1 # A static value for region used by auto-configured AWS clients (e.g., eu-west-1) as AWS credentials are valid in a context of a region.
      auto: false

Chained IAM Roles Assumption

Chained IAM role assumption allows connectors 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 connector host AWS account's role (single-pod-identity-role in account 718462147973).

• When a connector 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]

To set up chained IAM role assumption for your connector, perform the following steps:

1. Create a role called single-pod-identity-role in the connector host environment.

2. If your connector is hosted on an EC2 instance, attach the following trust policy:

   {
     "Version":"2012-10-17",
     "Statement":[
       {
         "Effect":"Allow",
         "Principal":
           {
             "Service":"ec2.amazonaws.com"
           },
       "Action":[
        "sts:TagSession",
        "sts:AssumeRole"
        ]
       }
     ]
   }

3. If your connector is hosted on EKS pods, attach the following trust policy:

   {
     "Version":"2012-10-17",
     "Statement":[
       {
         "Effect":"Allow",
         "Principal":
           {
             "Service":"pods.eks.amazonaws.com"
           },
       "Action":[
        "sts:TagSession",
        "sts:AssumeRole"
        ]
       }
     ]
   }

4. Create an AWS policy called cross-account-solace-policy with the following policy document:

   {
     "Version":"2012-10-17",
     "Statement":[{
       "Sid":"AssumeRoleOnThirdPartyAccount",
       "Effect":"Allow",
       "Action":[
        "sts:TagSession",
        "sts:AssumeRole"
        ]
       "Resource":"arn:aws:iam::*:role/solace-mi-workload-role"
     }]
   }

5. Attach this policy to the single-pod-identity-role.

6. 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::<MI_HOST_AWS_ACCOUNT_ID>:role/single-pod-identity-role"
       },
       "Action":[
        "sts:TagSession",
        "sts:AssumeRole"
        ]
     }]
   }

   where <MI_HOST_AWS_ACCOUNT_ID> is the ID of the AWS account where the connector is hosted.

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

   • sqs:GetQueueAttributes

   • sqs:GetQueueUrl

   • sqs:SendMessage

   • sqs:ReceiveMessage

   • sqs:DeleteMessage

8. Configure your connector to authenticate using chained IAM role assumption:

   spring:
     cloud:
       aws:
         credentials:
           chained-iam-assumption:
             account-id: <resource-owner-account-id>
             session-name: <optional‑session‑name>
             external-id: <optional‑external‑id>

   Where:

   • account-id (required): The ID of the AWS account where solace-mi-workload-role was configured.

   • session-name (optional): A custom Security Token Service (STS) session name. If not configured, the default solace-mi-workload-session.

   • external-id (optional): An arbitrary ID to use if the resource owner's trust policy requires an sts:ExternalId condition.

     To configure it, you 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":"<my_external_id_string>"
       }
     }

Amazon SQS Binder Configuration Options

The following properties are available at the Amazon SQS binder level.

These properties are to be prefixed with spring.cloud.stream.sqs.bindings.<function name>.consumer. For more information, see SQS Binder configuration.

Config Option	Type	Valid Values	Default Value	Description
maxMessagesPerPoll	int	1-10	10	The number of messages that are returned per poll.
visibilityTimeout	int	> 0	30	The duration (in seconds) that polled messages are hidden from subsequent poll requests after having been retrieved.
pollTimeout	int	1-20	10	The duration (in seconds) that the system waits for new messages to arrive when polling.
listenerShutdownTimeout	int	> 0	10	The number of seconds that the listener is given to gracefully finish its work on shutdown before interrupting the current thread.
snsFanout	boolean	trueor false	false	It enables the automatic deserialization of incoming SNS-formatted messages. By default, SNS messages are delivered in JSON-format, encapsulating both the message content and various metadata, such as the message ID, timestamp, and the topic ARN. Enabling snsFanout allows this connector to automatically parse the JSON structure for extracting and separating the payload message from the metadata. This functionality is particularly beneficial for applications that consume messages from SNS topics that are forwarded to SQS queues because it streamlines the handling of such messages.
consumer.concurrency	int	> 0	1	The number of concurrent threads to launch. By specifying a value, you launch concurrent threads that continuously poll for the maxMessagesPerPoll per thread. Threads asynchronously process all messages. Each thread must complete the processing of its batch of messages prior to retrieving more messages. If the duration for message processing is highly variable from message to message, we recommend to set a lower value for the maxMessagesPerPoll, and a higher value for consumer.concurrency. Using this parameter increases the number of API calls made to the Amazon SQS queue, which may increase the its cost. For more information, see Amazon SQS Pricing.

Only set snsFanOut to true (enable) if all incoming messages are SNS-formatted messages. If you set snsFanout property to true, the connector deserializes every incoming message as an SNS-formatted message, but if there are messages that are not SNS-formatted, failures occur.

FIFO SQS Queues

To use  FIFO (First-In-First-Out) SQS queues, you must provide a group ID and a deduplication ID (though you can choose not to set it). With this binder, you can set the message headers, message_groupId and message_deduplicationId. For more information about FIFO queues, see FIFO queues.

Header Name	Type	Applies To	Description
sqs_groupId	string	Amazon SQS	The identifier for a distinct ordered message group within an Amazon SQS queue. This identifier ensures that messages within the group are processed in the same order that they are sent. This parameter must be set and if not provided, Amazon SQS rejects the message with an error.
sqs_deduplicationId	string	Amazon SQS	A token used for deduplication of sent messages. When set, messages with the same deduplication identifier are not sent within a five-minute interval. If this parameter is not set:  For releases 1.2.3 and later; the PubSub+ replication group ID (solace_replicationGroupMessageId) is used as the deduplication identifier For releases earlier than 1.2.3, the value remains unset.

Connecting to Multiple Systems

To connect to multiple systems of the same type, use the multiple binder syntax.    

For example:

spring: 
  cloud:
    stream: 
      binders:
        
        # 1st solace binder in this example 
     solace1:
          type: solace 
       environment: 
         solace: 
           java:
             host: tcp://localhost:55555
         
     # 2nd solace binder in this example 
     solace2:
          type: solace 
          environment: 
            solace: 
           java:
             host: tcp://other-host:55555
        
     # The only sqs binder 
     sqs1:
          type: sqs      
          # Add `environment` property map here if you need to customize this binder. 
          # But for this example, we'll assume that defaults are used.
        # The only sqs binder 
     sqs2:
          type: sqs      
          # Add `environment` property map here if you need to customize this binder. 
       # But for this example, we'll assume that defaults are used.
          
     # Required for internal use 
     undefined:
          type: undefined 
     bindings:
          input-0:
            destination: <input-destination> 
         binder: sqs1          output-0:
            destination: <output-destination>
            binder: solace1 # Reference 1st solace binder 
       input-1:
            destination: <input-destination> 
         binder: sqs2          
           output-1:
            destination: <output-destination>
            binder: solace2 # Reference 2nd solace binder

The configuration above defines two binders of type solace and of type sqs, which are then referenced within the bindings.

Each binder above is configured independently under spring.cloud.stream.binders.<bindername>.environment.