Open thrau opened 5 months ago
Thanks for reaching out. I could reproduce this issue. The AWS_ENDPOINT_URL
environment variable documented here was not used when running SQS commands in version 1.33.6, even though other services like SNS and S3 used that variable. (Also AWS_ENDPOINT_URL_SQS
appears to not work when testing on v1, even though AWS_ENDPOINT_URL_SNS
did.)
I also tested in v2, and it appears that the environment variable does work as expected for SQS in 2.16.1. I recommend migrating to v2 if you're able to. Otherwise you can also specify --endpoint-url
in your command. In the meantime I'll mark this for further review and bring it up with the team.
Confirmed the issue with the team and created a backlog item for addressing it. A few other services are affected due to the changes that were introduced via https://github.com/aws/aws-cli/pull/7203. In the meantime as mentioned above please use --endpoint-url
or migrate to v2 in order to work around this.
thanks for the prompt and clear communication @tim-finnigan :+1:
This bug affects the service SQS when using custom profiles in the AWS CLI v1, for both environment variable and parameter configuration:
AWS_PROFILE=localstack aws sqs list-queues # Fails (custom profile environment variable)
aws --profile localstack sqs list-queues # Fails (custom profile CLI parameter)
aws --endpoint-url=http://localhost:4566/ sqs list-queues # Works (using endpoint URL CLI parameter)
aws --profile localstack lambda list-functions # Works (using another service than SQS)
# AWS CLI version (latest as of 2024-07-29)
aws --version
aws-cli/1.33.31 Python/3.11.7 Darwin/23.5.0 botocore/1.34.149
Beyond LocalStack, this issue also affects any enterprise reverse proxy configurations that rely on endpoint configuration using custom profiles.
Describe the bug
When using
AWS_ENDPOINT_URL
together withaws sqs
, it seems that specifically SQS commands are resolvingqueue.amazonaws.com
as endpoint provider instead of what is specified inAWS_ENDPOINT_URL
Expected Behavior
The following commands should resolve to localhost:4566:
Current Behavior
However, I can see they're being directed to
queue.amazonaws.com
:Full debug output:
Reproduction Steps
Possible Solution
No response
Additional Information/Context
It seems specific to the CLI. When using boto3 directly, this works fine:
CLI version used
aws-cli/1.33.6 Python/3.11.5 Linux/5.15.0-107-generic botocore/1.34.124
Environment details (OS name and version, etc.)
Linux 5.15.0-107-generic #117-Ubuntu SMP Fri Apr 26 12:26:49 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux