Amazon SQS

You can configure Amazon SQS as either a source or a target.

To configure the connection details for Amazon SQS in your Micro-Integration, see Amazon SQS Connection Parameters

You must also define at least one Micro-Integration Flow that specifies:

the endpoints where data is consumed from and published to. For more information, see Micro-Integration Flow Parameters.
how the header and payload fields should be mapped. For more information, see Mapping Headers and Payloads

For a listing of available message headers, see Amazon SQS Message Headers.

Amazon SQS Connection Parameters

The following table describes the connection parameters for Amazon SQS.

Field	Description
AWS Region	The AWS region for this SQS Queue.
Authentication Scheme	The authentication scheme to use when connecting to Amazon SQS. One of: AWS Access Key—Additional configuration is required. For more information, see AWS Access Key. AWS Chained IAM Role Assumption—Additional configuration is required. For more information, see AWS Chained IAM Role Assumption. Authentication using AWS Chained IAM Role Assumption is supported only for event brokers hosted on AWS.

Field

Description

AWS Region

The AWS region for this SQS Queue.

Authentication Scheme

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

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

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

AWS Access Key

Field	Description
AWS Access Key	An AWS Access Key ID.
AWS Secret Key	The Secret Key associated with the Access Key ID.

AWS 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:

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"
     ]
  }]
}

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

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 must be the account where the solace-mi-workload-role exists.

Session Name

Field	Description
AWS Account ID	The 12-digit AWS Account ID to be used for IAM role assumption. This must be the account where the `solace-mi-workload-role` exists.
Session Name	The 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>" } }

The 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 each Flow. Each Flow can have different settings, but they all share the connection details of the parent Micro-Integration. These parameters differ depending on whether Amazon SQS is configured as a source or a target.

Amazon SQS Source Parameters

The following table describes the parameters for configuring Amazon SQS as a source.

Field	Description
Queue Name	The source SQS queue name.

Amazon SQS Target Parameters

The following table describes the parameters for configuring Amazon SQS as a target.

Setting a Smart Topic Destination on the Mappings step overrides the target destination field set on the Details step.

Field	Description
Queue Name	The target SQS queue name.

Provide feedback