Delay Queues
Hide all new messages from consumers for N seconds.
Useful when you want a global head-start before processing — e.g. give downstream systems time to provision before work hits them.
What it is
Delay queues postpone delivery of new messages to consumers for a configured number of seconds. Messages sent to the queue remain invisible to consumers for the duration of the delay period.
- Default (minimum): 0 seconds.
- Maximum: 15 minutes (900 seconds).
- Configured via DelaySeconds queue attribute.
Delay vs visibility timeout
Both features hide messages temporarily, but at different stages. Delay queues hide messages when first added to the queue. Visibility timeouts hide messages only after a consumer has received them.
- Delay queue: hidden on enqueue → visible after delay expires.
- Visibility timeout: hidden on receive → visible again if not deleted.
Standard vs FIFO behavior
For standard queues, changing the per-queue delay setting is not retroactive — it does not affect messages already in the queue. For FIFO queues, changing delay is retroactive and affects messages already queued.
When to use
Use delay queues when all messages in a queue should wait the same amount of time before processing — e.g. cooling-off period, coordinated startup delay, or debouncing a burst.
- For per-message delays on standard queues, use message timers instead.
- For delays beyond 15 minutes, use EventBridge Scheduler.
- !Max delay is 15 minutes. For longer scheduling, use EventBridge Scheduler.
- !FIFO queues only support queue-level delays, not per-message timers.
- !Changing delay on a standard queue does not affect messages already enqueued.