SQS
What does zop.dev create for SQS?
zop.dev manages SQS queues with the most complete lifecycle of any resource type in its Go provisioner (create, update, delete, get, list, and apply), with configuration passed through the configs object. SQS bills per request with 1 million free monthly, and a queue's type cannot change after creation.
| Field | Value |
|---|---|
| Cloud | aws |
Amazon SQS is a fully managed message queue for decoupling services and buffering work. zop.dev manages queues through its provisioner API with full lifecycle support.
Queues with create, update, delete, and apply
SQS queues with full create, update, delete, get, list, and apply lifecycle.
Queue settings passed through configs
Standard queue configuration passed through the provisioner's configs object.Full CRUD plus apply in the Go provisioner
One of the most complete resource types in the Go provisioner: full CRUD plus apply.
Apply makes queues declarative
Most resource types stop at CRUD; SQS also implements apply, which converges the queue toward a declared configuration rather than imperatively editing it. The practical difference shows up as drift handling: a retention or visibility setting changed by hand in the console gets pulled back to the declared value on the next apply, so the configuration in the platform is the configuration in production, not a hopeful record of it.
The type and the name outlive the decision
A standard queue can never become a FIFO queue, or the reverse. The choice is permanent at
creation, and moving between them means a new queue and a consumer migration. FIFO names must
end in .fifo, so the name encodes the choice too. Names have one more sharp edge: after
deleting a queue, AWS requires roughly 60 seconds before the same name can be created again,
which intermittently breaks naive delete-and-recreate automation.
Requests are the unit of billing
SQS bills per request (send, receive, and delete each count) with the first 1 million requests free each month. The subtle cost is empty receives: a tight polling loop on a quiet queue pays for every poll that returns nothing. Long polling, with a receive wait of up to 20 seconds, is the fix: fewer requests, lower cost, and lower delivery latency at the same time. It is the rare setting that improves every axis at once.
Visibility timeout encodes your failure story
The visibility timeout is a promise about processing time: a consumed message stays hidden for that long, and reappears for redelivery if not deleted. Set it shorter than real processing time and healthy work gets processed twice; set it very long and a crashed consumer delays retry by the full window. Standard queues deliver at-least-once regardless, so consumers must tolerate duplicates either way.