When reading a message from a standard SQS queue, the reader is able to read the message and, once read, the message becomes invisible. This visibility timeout enables the message to automatically become visible if the first consumer that has read the message does not delete the message before the visibility timeout expires. 

For example, let's say we have a task that takes up to 30 seconds to process on our consumer application. We set the visibility timeout to 45 seconds to make sure we have enough time to process the message and delete it with our consumer application. The consumers are distributed across a cluster of EC2 instances. Instance number 10 picks up message A and starts processing it. The visibility timeout kicks in and, if the instance successfully processes it within the time frame, it will delete the message while invisible as the task is completed. But if the instance fails during processing, then the task has not been completed, and after 45 seconds the visibility timeout will make the message visible again, and another instance can come along, pick that message up, and process the task at hand:

The message in the queue must be deleted after it has been successfully processed, as the visibility timeout will make the message visible again if the message is not deleted. This is why we say that the standard queues have an at least once delivery implemented.

This functionality is not enabled on FIFO queues; once the message is received with a FIFO queue, the message is automatically deleted from the queue and the service does not keep a copy. With FIFO queues, we need to handle backend failures and message histories with a different approach as, once a consumer fails, the message will not be retrievable from the queue.