Simple Queue Service (SQS)

WHAT IS IT?
SQS is one of AWS’s oldest services, first announced in 2004. It gives you access to a message queue to store messages while waiting for a computer to process them. Amazon SQS enables you to decouple components of an application and let them communicate asynchronously (on their own schedules). Each message is sent to a service like a Lambda function or EC2 instance.
Those decoupled components can store their messages in a fail-safe queue that will wait for computation. This can be really useful if you, for example, lose an availability zone for whatever reason. The message becomes available in the queue if an EC2 instance goes down, enabling other EC2 instances to pick up the slack.

WHAT’S THE FUSS?

If you’re building on SQS, you’re by definition creating a distributed application: one that does work across a network via decoupled pieces. And that brings with it a whole new layer of design and operational considerations. You can choose whether you want to create a standard queue or a FIFO (first-in-first-out) queue. Both have some advantages: Standard queues ensure that your message is delivered at least once and make a best effort to arrange them in the same order as received. But that’s a best effort, and you shouldn’t assume order! FIFO queues deliver messages in the exact order as they were received. The message is delivered and remains available until a consumer processes it and deletes it. Duplicates are not allowed into the queue in this case. SQS also implements visibility timeout—essentially how long the queue waits for one consumer before making it available to the next one. For example, let’s say a message is made available to one EC2 instance and isn’t executed in some target time. That message will then be available for another EC2 instance to grab it and run it.