|Transactions||None, ReceiveOnly (Message visibility timeout)|
|Timeouts||Native (Requires FIFO Queues)|
|Large message bodies||Native (Requires S3)|
|Scripted Deployment||PowerShell, CloudFormation, C#|
|Native integration||Not supported|
- Fully managed turn-key messaging infrastructure. SQS queues requires little effort to set up, maintain, and manage over time.
- Integrates seamlessly with other services provided by AWS, such as IAM, CloudWatch, and Lambda. For organizations already committed to AWS, SQS is a natural choice.
- Can be used as a gateway between endpoints that may not have direct connectivity to each other.
- Can send and receive large messages that exceed the queue limitations by storing large payloads in S3. For more information review the documentation for the transport topology and configuration options.
- Like other message brokers, there is no local store-and-forward mechanism available. If an endpoint cannot reach SQS, either due to network problems or if SQS is unavailable, the endpoint will not be able to send nor receive messages.
- Can be expensive with large volumes of messages.
The IAM account requires the following permissions:
- If using server-side encryption of SQS queues, all NServiceBus endpoints (as well as ServiceControl) will require the
kms:GenerateDataKeypermission in order to support key management.
- Access Key ID goes in
- Secret Access Key goes in
- Region Key goes in
var transport = endpointConfiguration.UseTransport<SqsTransport>(); // S3 bucket only required for messages larger than 256KB var s3Configuration = transport.S3("myBucketName", "my/key/prefix");
For more configuration options consult the configuration options page.
Messages sent from within a handler are batched with up to ten messages per batch depending on the size of the message. Messages sent outside a handler are not batched.