4

I have an SQS URL which includes region as well. I am using official Go SDK to perform operations on this SQS which require AWS region to initialize the session. Currently, I have written a utility function to parse the URL and return AWS region.

Sample URL: https://sqs.us-east-1.amazonaws.com/774557911234/my_sqs_name

Sample Initialization code:

sess, err := session.NewSession()
if err != nil {
    return
}

s := sqs.New(sess, aws.NewConfig().WithRegion(getRegionFromSQSURL(config.SQSURL))

Sample function to get region from URL

func getRegionFromSQSURL(url string) string {
    return strings.Split(url, ".")[1]
}

Just wondering if this is the correct approach.

Would there be any case where SQS URL will have a different region in URL than the region in which SQS exists?

Should I just add one more environment variable to be set in the service?

Mark Amery
  • 143,130
  • 81
  • 406
  • 459
Mayank Patel
  • 8,088
  • 5
  • 55
  • 75

3 Answers3

5

Cited from here: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-queue-message-identifiers.html

Important

In your system, always store the entire queue URL exactly as Amazon SQS returns it to you when you create the queue (for example, http://sqs.us-east-2.amazonaws.com/123456789012/queue2). Don't build the queue URL from its separate components each time you need to specify the queue URL in a request because Amazon SQS can change the components that make up the queue URL.

As explained, they can change the structure of the URL sometimes in the future for whatever reason. Queue region will probably still stay somewhere in the url, but not necessarily in the spot that you expect it to be.

So, all thinks considered, I think that introducing new environment variable is the right way to go.

dkasipovic
  • 5,930
  • 1
  • 19
  • 25
3

Yes, it should be perfectly safe to extract the region from the queue URL.

The documented recommendation cited elsewhere does not say that it isn't safe to deconstruct a queue URL into its components, but rather recommends against constructing a queue URL from its component parts. The admonition is to store the entire URL. There is no recommendation not to parse it at all.

In your system, always store the entire queue URL exactly as Amazon SQS returns it to you when you create the queue

The hostname portion of the URL is quite deterministic, and the regional endpoints for SQS are very consistently sqs.${region}.amazonaws.com.

There is no obvious reason not to rely on the hostname for determining the region. AWS rarely changes endpoint hostnames and in the few instances that they have, it has been to make them more predictable. Meanwhile, the old ones are still quietly there -- for example, the original endpoints, such as queue.amazonaws.com and us-west-1.queue.amazonaws.com are still active and appear to be fully functional even though these were officially replaced by sqs.us-[east | west]-1.amazonaws.com. AWS has more recently been more consistent and hierarchical with endpoint conventions, but in doing so, they have not broken older clients where these values are hard-coded.

Michael - sqlbot
  • 169,571
  • 25
  • 353
  • 427
0

If I understand this correctly, the question asks whether it is okay to extract the AWS Region from the SQS URL...

An Easy answer would be YES. But I DO NOT Recommend this.

Firstly, extracting the Region from a fixed SQS URL which is saved in the config file is just an additional processing. Since it is already stored in the Config file, we can specify the AWS-region in the Config file as well, because the region that we work in won't change dynamically unless we decide to change it manually. If you look at this documentation, the AWS Region is generally saved in the config file for better maintainability.

Second, using a split to extract the region from a String is implausible. It is like trying to hack things around to get what you need. This is not a good coding practice.

Third, what you have given above is the AWS SQS Endpoint for a specific queue. Read this documentation and understand the structure of AWS endpoints. The AWS endpoints don't always contain the region in it, within the Sting structure. It's always a best practice to maintain a separate parameter in the config file for the AWS Region.

Some services, such as IAM, do not support regions; therefore, their endpoints do not include a region. Some services, such as Amazon EC2, let you specify an endpoint that does not include a specific region, for example, https://ec2.amazonaws.com. In that case, AWS routes the endpoint to us-east-1.

Keet Sugathadasa
  • 11,595
  • 6
  • 65
  • 80