|Transactions||None, ReceiveOnly (Message visibility timeout)|
|Timeouts||Native (up to 15 minutes), TimeoutManager|
|Large message bodies||Native (Requires S3)|
|Scripted Deployment||PowerShell, CloudFormation, C#|
|Native integration||Not supported|
- Fully managed turn-key messaging infrastructure. SQS queues requires very 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 relatively expensive when using larger volumes of messages.
The IAM account requires the following permissions:
By default, AWS Access Key ID and AWS Secret Access Key are discovered from environment variables of the machine that is running the endpoint:
- Access Key ID goes in
- Secret Access Key goes in
var transport = endpointConfiguration.UseTransport<SqsTransport>(); transport.Region("ap-southeast-2"); // S3 bucket only required for messages larger than 256KB transport.S3BucketForLargeMessages("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.