Reference · built on requestConnectorStreams, queues & webhooks

Amazon SQS

Messages and queue attributes from Amazon SQS standard and FIFO queues, with dead-letter queue redrive, through the SQS API.

Request accessPricing ↗

About

Amazon SQS is a hosted queue from Amazon Web Services for messages moving between application components. A standard queue takes a near-unlimited rate of API calls. A FIFO queue keeps order within a MessageGroupId and, without high throughput mode, allows 300 transactions per second per partition per action. A message holds XML, JSON, or plain text up to 1 MiB and up to 10 attributes. A consumer calls ReceiveMessage, works on the message while its visibility timeout hides it from others, then calls DeleteMessage. A redrive policy moves a message to a dead-letter queue after maxReceiveCount receives.

Through Fibric, an operator reads messages and queue attributes and proposes a send, a delete, a visibility change, or a redrive of dead-lettered messages. You approve. The connector makes one API call and leaves a receipt.

This is a reference listing. It documents what Fibric would read from Amazon SQS and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Messages from a queue through ReceiveMessage, up to 10 per call, with long polling by WaitTimeSeconds
  • Each message's body, up to 10 message attributes, and MessageGroupId on FIFO queues
  • Queue attributes from GetQueueAttributes, including visibility timeout, retention period, and the redrive policy
  • Queues in the account from ListQueues and a queue's URL from GetQueueUrl
  • Source queues that point at a dead-letter queue, from ListDeadLetterSourceQueues
  • Redrive progress from ListMessageMoveTasks

Proposed actions

  • Target capability: propose sending a message with SendMessage, or up to 10 with SendMessageBatch, carrying a MessageGroupId on FIFO queues
  • Target capability: propose deleting a received message with DeleteMessage or DeleteMessageBatch once the operator has recorded it
  • Target capability: propose extending or shortening a message's visibility with ChangeMessageVisibility, up to 12 hours
  • Target capability: propose moving dead-lettered messages back to their source queue with StartMessageMoveTask
  • Target capability: propose a queue attribute change with SetQueueAttributes, such as the redrive policy or visibility timeout

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Redrive a dead-letter queue after the fix ships

    A consumer bug pushed messages past maxReceiveCount into the dead-letter queue. The operator reads them, confirms the fix is deployed, and proposes StartMessageMoveTask back to the source queue. You approve. The receipt lists the task.

    With Webhook Replay

  • Catch a queue that nobody is draining

    The operator polls GetQueueAttributes and watches the approximate message count climb while no consumer deletes anything. It names the queue and the last time a delete was seen.

    With Integration Health

  • Hand a webhook burst to a queue

    Inbound webhooks land on a queue instead of hitting an endpoint directly. The operator reads them at its own pace with long polling and extends visibility on the ones it is still working.

    With Alert Noise, Quota Headroom

Requirements

  • An AWS account with queues in the Region the connector runs against
  • An IAM policy allowing ReceiveMessage, DeleteMessage, ChangeMessageVisibility, and GetQueueAttributes on the queue ARN, plus SendMessage for writes
  • For redrives, a dead-letter queue in the same AWS account and Region as its source queue
  • A MessageGroupId on every message the connector sends to a FIFO queue. Without it the send fails
Authentication
AWS IAM credentials, normally an IAM role, allowed sqs: actions on each queue's ARN; a queue policy set with AddPermission grants another account access.

Limits

  • A message is at most 1,048,576 bytes (1 MiB). Larger payloads need the Extended Client Library, which keeps the body in Amazon S3
  • Messages are kept 4 days by default, and retention runs from 60 seconds to 1,209,600 seconds (14 days)
  • The visibility timeout is 30 seconds by default and at most 12 hours. A message timer delays delivery at most 15 minutes
  • On a standard queue a dead-lettered message keeps its original enqueue timestamp, so it can expire sooner than the dead-letter queue's retention suggests

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Amazon SQS ↗

Questions and answers

How does a message end up in a dead-letter queue?
The source queue's redrive policy sets maxReceiveCount. When a consumer has received a message that many times without deleting it, SQS moves it to the dead-letter queue. The dead-letter queue must sit in the same account and Region, and a redrive allow policy controls which source queues may use it.
What throughput does a FIFO queue allow?
Without high throughput mode, each partition allows 300 transactions per second per action, or 3,000 messages per second with batches of 10. High throughput mode raises the per-Region ceiling. Standard queues support a very high, nearly unlimited number of API calls per second.
What is the largest message the connector can send?
1,048,576 bytes, which is 1 MiB, containing XML, JSON, or unformatted text in the allowed Unicode ranges. The Amazon SQS Extended Client Library for Java or Python sends a reference to a payload in Amazon S3 of up to 2 GB instead.
Ask about Amazon SQS

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Amazon SQS through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy