AWS SQS: Amazon Simple Queue Service

Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. SQS eliminates the complexity and overhead associated with managing and operating message-oriented middleware and empowers developers to focus on differentiating work. Using SQS, you can send, store, and receive messages between software components at any volume, without losing messages or requiring other services to be available. Get started with SQS in minutes using the AWS console, Command Line Interface or SDK of your choice, and three simple commands.

Benefits AWS SQS provides

->It eliminates the administrative overhead:

AWS manages all ongoing operations and underlying infrastructure needed to provide a highly available and scalable message queuing service. With SQS, there is no upfront cost, no need to acquire, install, and configure messaging software, and no time-consuming build-out and maintenance of supporting infrastructure. SQS queues are dynamically created and scale automatically so you can build and grow applications quickly and efficiently.

->Helps in keeping the sensitive data secure:

We can use Amazon SQS to exchange sensitive data between applications using server-side encryption (SSE) to encrypt each message body. Amazon SQS SSE integration with AWS Key Management Service (KMS) allows us to centrally manage the keys that protect SQS messages along with keys that protect our other AWS resources. AWS KMS logs every use of our encryption keys to AWS CloudTrail to help meet our regulatory and compliance needs.

->It reliably delivers the messages:

We can Amazon SQS to transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be available. SQS lets us decouple application components so that they run and fail independently, increasing the overall fault tolerance of the system. Multiple copies of every message are stored redundantly across multiple availability zones so that they are available whenever needed.

->It scales elastically and is cost-effective:

Amazon SQS leverages the AWS cloud to dynamically scale based on demand. SQS scales elastically with your application so you don’t have to worry about capacity planning and pre-provisioning. There is no limit to the number of messages per queue, and standard queues provide nearly unlimited throughput. Costs are based on usage which provides significant cost saving versus the “always-on” model of self-managed messaging middleware.

Use-Cases

->BMW

The BMW Group is using AWS for its connected car application that collects sensor data from BMW 7 Series cars to give drivers dynamically updated map information.

->NASA

The NASA Image and Video Library provides easy access to more than 140,000 still images, audio recordings, and videos — documenting NASA’s more than half a century of achievements in exploring the vast unknown. The architecture includes Amazon SQS to decouple incoming jobs from pipeline processes and Amazon Simple Notification Service to trigger the processing pipeline when new content is updated.

->Other companies include:

*Pinterest

*redBus

*Coursera

*Cred

and many more.

Queue types provided by AWS SQS

Amazon SQS offers two queue types for different application requirements:

Standard Queues

Unlimited Throughput: Standard queues support a nearly unlimited number of transactions per second (TPS) per API action.

At-Least-Once Delivery: A message is delivered at least once, but occasionally more than one copy of a message is delivered.

Best-Effort Ordering: Occasionally, messages might be delivered in an order different from which they were sent.

FIFO Queues

High Throughput: By default, FIFO queues support up to 300 messages per second (300 send, receive, or delete operations per second). When you batch 10 messages per operation (maximum), FIFO queues can support up to 3,000 messages per second. If you require higher throughput, you can enable high throughput mode for FIFO (offered as a Preview in select regions) on the Amazon SQS console, which will support up to 30,000 messages per second with batching, or up to 3,000 messages per second without batching.

Exactly-Once Processing: A message is delivered once and remains available until a consumer process and deletes it. Duplicates aren’t introduced into the queue.

First-In-First-Out Delivery: The order in which messages are sent and received is strictly preserved (i.e. First-In-First-Out).

In conclusion, we can use AWS SQS to send, receive, or delete messages in batches of up to 10 messages or 256KB. Batches cost the same amount as single messages, meaning SQS can be even more cost-effective for customers that use batching, securely share Amazon SQS queues anonymously or with specific AWS accounts. Queue sharing can also be restricted by IP address and time-of-day.

Thank you for taking some precious time to read this article!

Feel free to ask any queries. Don’t forget to share this article with your fellow acquaintances. Follow me on LinkedIn using the link provided below:

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to Save and Load AR World-mapping Data to Create a Persistent AR Experience

Scrum forces you to crack the tough nuts that hold you back

Car stuck in the mud

How do I connect the WS-Trust connector of WSO2 Identity Server?

Telegram sticker competition

BP Daily Digest #13 — animations in mobile apps, Python code bottlenecks, and more

10 Things That Would Make GitHub Actions Even Better

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jayesh Jain

Jayesh Jain

More from Medium

Configure Session Manager access for federated users using SAML session tags — AWS SSO edition

Welcome to the Cloud Computing!

How to build GDSC Community — Novi Sad Edition

AWS Account Migration Journey — Part 2