Naming conventions for SNS / SQS

Question

In an ETL process we are implementing we will create an Amazon SNS topic which will send messages to an Amazon SQS queue.

In the documentation we didn't see a particular spec regarding names so I was wondering if someone could recommend best practises regarding the naming conventions for SNS topics and the SQS queues.

The scope is to know whether there are best practices in naming topics (SNS) and queues (SQS) in order to follow the best approach for naming. For instance, is the camel case recommended? Should the topic name / queue name give a representation of the domain?

Answer 1

We implemented the fanout pattern and found that the SQS queue inherting the SNS topic name was the best approach as it aides in development, debugging, and as you raised representing the domain knowledge.

For example, if you have an application called StrawberryShaker . The topic would be called StrawberryShaker and the queues subscribed to it would all be prefixed with StrawberryShaker .

There are some name length you should be aware of:-

A queue name can have up to 80 characters. The following characters are accepted: alphanumeric characters, hyphens (-), and underscores (_).

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-limits.html

Topic names are limited to 256 characters. Alphanumeric characters plus hyphens (-) and underscores (_) are allowed.

https://aws.amazon.com/sns/faqs/

Hope that helps!

Answer 2

You can name SNS Topics and SQS Queues however you like, as long as it doesn't complain (eg spaces or illegal characters).

Be aware that, over time, you might have many topics and many queues, and they form part of the ARN so they will be hard to change in future. I would recommend a prefix for the application, and a descriptive portion. For example, if the unicorn application is pushing an invoice to a queue, call the queue:

unicorn_invoice

Don't include 'topic' or 'queue' in the name as they are irrelevant (eg unicorn_invoice is better than unicorn_invoice_queue ).

If many different teams are using the same AWS account, you could add an additional tier to indicate who 'owns' the resource, such as:

lawson_unicorn_invoice

CamelCase is also fine, if that is common in your company:

lawsonUnicornInvoice